Re: latest stg/git commandline completions code

Re: latest stg/git commandline completions code

[Blaisorblade]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Tuesday 25 October 2005 14:24, Ben Clifford wrote:
> hi. I'm interested in playing with the stg/git commandline completion code
> - are you still actively working on it?
Well, yes, I've been still tuning it - but actually I'm not _maintaining_ it, 
I'm using stgit on the Linux kernel so when on a command I don't have tab 
completion I add the needed one (having the time and feeling to do it).

However, it's still done with enough care and polish to be shippable.

> if so, do you have any more 
> formalised distribution process (like a git repo!) rather than grabbing
> code out of email list postings? I can't seem to find much on google...
Well, Catalin's TODO included "bash completions", so I assume the thing could 
be merged by him. Anyway,

I'm attaching the current version.

Btw, it's under GPL v2.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

[-- Attachment #2: stg-compl --]
[-- Type: text/plain, Size: 5672 bytes --]

#Stacked git bash completion.

#TODO:
# My opinion about bash completion is that they're excessively slow, especially
# when the system is under load.
#
# So:
# - save the list of stg commands in a file, created at install moment; on an
# idle Athlon 64 laptop at 800MHz, stg help takes 0.22 seconds of CPU time,
# without disk I/O.
#
# - read .git/patches/$branch/{applied,unapplied} directly instead of invoking
# stg.
#

#XXX: must test for bash version, done in generic bash-completion and the
#generic value can be seen from here, if we are included by the loop at the end
#of /etc/bash_completion, i.e. if we're installed in /etc/bash-completion.d.
#
#Gentoo should be fixed to allow this.

bashdefault="-o bashdefault"
default="-o default"

#XXX: not StGit specific, valid for git too.
__git_refs()
{
    for i in $(echo .git/refs/heads/*); do
	echo ${i#.git/refs/heads/}
    done
    for i in $(echo .git/refs/tags/*); do
	echo ${i#.git/refs/tags/}
    done
    echo HEAD
}

__stg_unapplied()
{
    stg unapplied 2>/dev/null $@
}

__stg_applied()
{
    stg applied 2>/dev/null $@
}

__stg_all_patches()
{
    __stg_applied $@; __stg_unapplied $@
}

#XXX: Find a better name for this.
#
__stg_all_patch_ranges()
{
    __stg_all_patches $@|while read i; do echo $i/; done
}

__stg_top()
{
    stg top 2>/dev/null $@
}

__stg_branches()
{
    #for i in $(compgen -f .git/patches/); do
    for i in $(echo .git/patches/*); do
	echo ${i#.git/patches/}
    done
}

_stg_range()
{
    #Ugly - should return the result rather than set COMPREPLY.
    local cur=$1 patches=$2
    if [ "${cur#*:}" != "${cur}" ]; then
	# Complete the 2nd range component, after ':'.
	COMPREPLY=( $(compgen -W "${patches}" -- ${cur#*:}) )
    else
	COMPREPLY=( $(compgen -W "${patches}" -- $cur) )
    fi
}

_stg ()
{
    local cur cmd cmds opts
    cur=${COMP_WORDS[COMP_CWORD]}
    COMPREPLY=()
    if [ $COMP_CWORD -eq 1 ]; then
	cmds=$(stg help|tail +4|awk '{print $1}')
	COMPREPLY=( $(compgen -W "${cmds}" -- $cur) )
    else
	local cmd=${COMP_WORDS[1]}
	local prev=${COMP_WORDS[COMP_CWORD-1]}
	local o_help="-h --help"
	local o_branch="-b --branch"
	#XXX: Add -b support - pass "-b branch" to unapplied and applied.
	#This can be done by calling __stg_unapplied directly below
	#instead of setting patches here.
	#But: how to look for -b? I'm scared about looping over opts
	#(I don't like completions when they take so much time).
	case $cmd in
	    push)
	    if [ "$prev" = "-t" -o "$prev" = "--to" ]; then
		_stg_range "$cur" "$(__stg_unapplied)"
#		if [ "${cur#*:}" != "${cur}" ]; then
#		    COMPREPLY=( $(compgen -W "$(__stg_unapplied)" -- ${cur#*:}) )
#		else
#		    COMPREPLY=( $(compgen -W "$(__stg_unapplied)" -- $cur) )
#		fi
	    else
		opts="-a --all -n --number -t --to --reverse --undo $o_help"
		COMPREPLY=( $(compgen -W "${opts} $(__stg_unapplied)" -- $cur) )
	    fi
	    ;;

	    pop)
	    if [ "$prev" = "-t" -o "$prev" = "--to" ]; then
		COMPREPLY=( $(compgen -W "$(__stg_applied)" -- $cur) )
	    else
		opts="-a --all -n --number -t --to $o_help"
		COMPREPLY=( $(compgen -W "${opts}" -- $cur) )
	    fi
	    ;;

	    export)
	    if [ "$prev" = "-r" -o "$prev" = "--range" ]; then
		_stg_range "$cur" "$(__stg_applied)"
	    else
		opts="-n --numbered -d --diff -t --template -r --range \
		$o_branch $o_help"

		COMPREPLY=( $(compgen $default -W "${opts}" -- $cur) )
	    fi
	    ;;
	    mail)
	    if [ "$prev" = "-r" -o "$prev" = "--range" ]; then
		_stg_range "$cur" "$(__stg_applied)"
#		if [ "${cur#*:}" != "${cur}" ]; then
#		    COMPREPLY=( $(compgen -W "$(__stg_applied)" -- ${cur#*:}) )
#		else
#		    COMPREPLY=( $(compgen -W "$(__stg_applied)" -- $cur) )
#		fi
	    else
		opts="-a --all -r --range --to --cc --bcc -v --version \
		-t --template -f --first -s --sleep --refid -u --smtp-user \
		-p --smtp-password $o_branch $o_help"

		COMPREPLY=( $(compgen $bashdefault -W "${opts} \
		$(__stg_applied)" -- $cur) )
	    fi
	    ;;
	    diff)
	    if [ "$prev" = "-r" ]; then
		if [ "${cur#*:}" != "${cur}" ]; then
		    COMPREPLY=( $(compgen -W "$(__stg_all_patch_ranges)" -- \
		    ${cur#*:}) )
		else
		    COMPREPLY=( $(compgen -W "$(__stg_all_patch_ranges)" -- \
		    $cur) )
		fi
	    else
		opts="-r -s --stat $o_help"

		COMPREPLY=( $(compgen -W "${opts}" -- $cur) )
	    fi
	    ;;
	    id)
	    if [ "$prev" = "-b" -o "$prev" = "--branch" ]; then
		COMPREPLY=( $(compgen -W "$(__stg_branches)" -- $cur) )
	    else
		opts="$o_branch $o_help"
		#there's a lot of possible id's to complete
		COMPREPLY=( $(compgen -W "${opts} $(__stg_all_patch_ranges) \
		$(__git_refs)" -- $cur) )
	    fi
	    ;;
	    rename)
	    if [ "$prev" = "-b" -o "$prev" = "--branch" ]; then
		COMPREPLY=( $(compgen -W "$(__stg_branches)" -- $cur) )
	    else
		COMPREPLY=( $(compgen -W "$(__stg_all_patches)" -- $cur) )
	    fi
	    ;;
	    delete)
	    opts="${o_help}"
	    COMPREPLY=( $(compgen -W "${opts} $(__stg_unapplied; __stg_top)" \
	    -- $cur) )
	    ;;
	    series|unapplied|applied)
	    if [ "$prev" = "-b" -o "$prev" = "--branch" ]; then
		COMPREPLY=( $(compgen -W "$(__stg_branches)" -- $cur) )
	    else
		opts="$o_branch $o_help"
		[ "$cmd" = "series" ] && \
		    opts="$opts -e --empty"
		COMPREPLY=( $(compgen -W "${opts}" -- $cur) )
	    fi
	    ;;
	    refresh)
	    opts="-f --force -e --edit -s --showpatch -m --message \
	    -a --author --authname --authemail --authdate --commname
	    --commemail $o_help"

	    COMPREPLY=( $(compgen $bashdefault -W "${opts}" -- $cur) )
	    ;;
	    *)
	    COMPREPLY=( $(compgen $bashdefault -W "${o_help}" -f -- $cur) )
	    ;;
	esac
    fi
}

complete $default -F _stg stg

# vi: set ft=sh sw=4:

Re: latest stg/git commandline completions code

[Catalin Marinas]

Blaisorblade <blaisorblade@yahoo.it> wrote:
> I'm using stgit on the Linux kernel so when on a command I don't have tab 
> completion I add the needed one (having the time and feeling to do
> it).

You can have a look at the tlacontrib project scripts (I can forward
them to you since you would need tla/baz to clone/checkout the project
and this procedure is a combination of 'tag' and 'get' commands). They
automatically generate the commands together with the options and are
later used in completion.

Of course, your approach would work as well but it requires more
maintance.

>> if so, do you have any more formalised distribution process (like a
>> git repo!) rather than grabbing code out of email list postings? I
>> can't seem to find much on google...
>
> Well, Catalin's TODO included "bash completions", so I assume the
> thing could be merged by him. Anyway, I'm attaching the current
> version.

When you think it is ready, I'm happy to include it (though I would
prefer a more dynamic approach like the tla one but since I don't have
time for it I'll just use yours).

Thanks.

-- 
Catalin

Re: latest stg/git commandline completions code

[Blaisorblade]

On Tuesday 25 October 2005 17:18, Catalin Marinas wrote:
> Blaisorblade <blaisorblade@yahoo.it> wrote:
> > I'm using stgit on the Linux kernel so when on a command I don't have tab
> > completion I add the needed one (having the time and feeling to do
> > it).

> You can have a look at the tlacontrib project scripts (I can forward
> them to you since you would need tla/baz to clone/checkout the project
> and this procedure is a combination of 'tag' and 'get' commands). They
> automatically generate the commands together with the options and are
> later used in completion.

> Of course, your approach would work as well but it requires more
> maintance.

_Yes_, it wasn't ever intended to be published, and the help output doesn't 
seem, at a quick look, trivially parsable (the source is better to parse but 
I refuse that. Also, some options require still a special handling.

The best idea seems to write a Python script sourcing the Stgit source 
(stgit/main.py to get commands, and then loading each class and iterating 
over the "options" module member). I'm not fluent in Python enough currently, 
but when I'll find time I'll probably study a bit reflection and write this 
down (my Python experience amounts to some random readings on reviews and a 
couple of days with Python docs).

> >> if so, do you have any more formalised distribution process (like a
> >> git repo!) rather than grabbing code out of email list postings? I
> >> can't seem to find much on google...

> > Well, Catalin's TODO included "bash completions", so I assume the
> > thing could be merged by him. Anyway, I'm attaching the current
> > version.

> When you think it is ready, I'm happy to include it (though I would
> prefer a more dynamic approach like the tla one but since I don't have
> time for it I'll just use yours).

Btw, what do you think about speeding up completions by reimplementing things 
like "stg applied" or "stg unapplied" via cat (as noted in the comments at 
the beginning of the script)? Tab completions can easily livelock a shell on 
a busy system, so it's worthy speeding the thing up.

> Thanks.

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

Re: latest stg/git commandline completions code

[Catalin Marinas]

On 25/10/05, Blaisorblade <blaisorblade@yahoo.it> wrote:
> The best idea seems to write a Python script sourcing the Stgit source
> (stgit/main.py to get commands, and then loading each class and iterating
> over the "options" module member).

I can add a function in stgit/main.py which would list the options.
The tla-completion generates a file listing a command with its option
on every line:

  push -a -all -n --number -t --to --reverse --undo -h --help
  ...

Since I don't know much about the bash completion, let me know of the
format you'd prefer.

> Btw, what do you think about speeding up completions by reimplementing things
> like "stg applied" or "stg unapplied" via cat (as noted in the comments at
> the beginning of the script)? Tab completions can easily livelock a shell on
> a busy system, so it's worthy speeding the thing up.

In general, it is better to use the stg commands but the repository
structure won't probably change for a long time and it's OK to
optimise (if the speed improvement is visible). Anyway, these
particular commands are pretty fast (they behave like cat) but there
are others which are slower (usually the commands involving calls to
the GIT tool).

--
Catalin

Re: latest stg/git commandline completions code

[Blaisorblade]

On Tuesday 25 October 2005 18:24, Catalin Marinas wrote:
> On 25/10/05, Blaisorblade <blaisorblade@yahoo.it> wrote:
> > The best idea seems to write a Python script sourcing the Stgit source
> > (stgit/main.py to get commands, and then loading each class and iterating
> > over the "options" module member).

> I can add a function in stgit/main.py which would list the options.
> The tla-completion generates a file listing a command with its option
> on every line:

>   push -a -all -n --number -t --to --reverse --undo -h --help
>   ...

> Since I don't know much about the bash completion, let me know of the
> format you'd prefer.
Ok, I'll look into that. Probably it'll be around "opts_push="-a --all -n 
--number...", i.e. this one works fine, through name indirection, i.e. you 
say "expand the var which name is given by this expr".

> > Btw, what do you think about speeding up completions by reimplementing
> > things like "stg applied" or "stg unapplied" via cat (as noted in the
> > comments at the beginning of the script)? Tab completions can easily
> > livelock a shell on a busy system, so it's worthy speeding the thing up.

> In general, it is better to use the stg commands but the repository
> structure won't probably change for a long time
Ok.
> and it's OK to 
> optimise (if the speed improvement is visible).
I believe it is, yes.
> Anyway, these 
> particular commands are pretty fast (they behave like cat) but there
> are others which are slower (usually the commands involving calls to
> the GIT tool).

They _would_ behave like cat, except that Python is slow enough. Half a second 
on a (almost) idle system means seconds and seconds on a busy system, and 
it's pretty frequent that when I don't wait enough for an op. to complete I 
get a traceback from the import statements, which haven't been completed. 

And let's leave Gentoo's emerge alone - I'd say imports can take up to a 
minute.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

Re: latest stg/git commandline completions code

[Catalin Marinas]

On 25/10/05, Blaisorblade <blaisorblade@yahoo.it> wrote:
> They _would_ behave like cat, except that Python is slow enough. Half a second
> on a (almost) idle system means seconds and seconds on a busy system, and
> it's pretty frequent that when I don't wait enough for an op. to complete I
> get a traceback from the import statements, which haven't been completed.

That's a thing I should fix in StGIT - trapping the exception
generated by SIGTERM and exiting silently.

> And let's leave Gentoo's emerge alone - I'd say imports can take up to a
> minute.

That's probably because it checks the status of the tree before
importing but this command wouldn't be used to generate the
completion.

--
Catalin

Re: latest stg/git commandline completions code

[Blaisorblade]

On Wednesday 26 October 2005 13:34, Catalin Marinas wrote:
> On 25/10/05, Blaisorblade <blaisorblade@yahoo.it> wrote:
> > They _would_ behave like cat, except that Python is slow enough. Half a
> > second on a (almost) idle system means seconds and seconds on a busy
> > system, and it's pretty frequent that when I don't wait enough for an op.
> > to complete I get a traceback from the import statements, which haven't
> > been completed.

> That's a thing I should fix in StGIT - trapping the exception
> generated by SIGTERM and exiting silently.
Yep.

> > And let's leave Gentoo's emerge alone - I'd say imports can take up to a
With imports I mean Python import statement, in the case of the Gentoo 
"emerge" command (which is written in Python).

Not the import command (and checking the state of the tree can take tens of 
minutes, here - with a non-idle machine, though).
> > minute.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

Re: latest stg/git commandline completions code

[Ben Clifford]

> I'm using stgit on the Linux kernel so when on a command I don't  
> have tab
> completion I add the needed one (having the time and feeling to do  
> it).
>
> However, it's still done with enough care and polish to be shippable.
>
>

I've added some stuff to this to do a few cogito, gitk and (one) git  
completions, split into different files. I thought I might as well  
toss what I have out for anyone interested to play with.

I tried to put it in a new git repo online, but I'm having  
difficulties - the poor link I'm on makes it not so much fun to  
experiment. So I've tarred up my local repo warts and all and put it at:

http://www.hawaga.org.uk/ben/tech/gitcompletion- 
a108bdc110dad770ec5c092759a8bc511790d21f.tar

Ben
-- 
Ben Clifford
http://www.hawaga.org.uk/ben/

Re: latest stg/git commandline completions code

[Petr Baudis]

Dear diary, on Tue, Nov 08, 2005 at 11:16:28AM CET, I got a letter
where Ben Clifford <benc@hawaga.org.uk> told me that...
> I've added some stuff to this to do a few cogito, gitk and (one) git  
> completions, split into different files. I thought I might as well  
> toss what I have out for anyone interested to play with.
> 
> I tried to put it in a new git repo online, but I'm having  
> difficulties - the poor link I'm on makes it not so much fun to  
> experiment. So I've tarred up my local repo warts and all and put it at:
> 
> http://www.hawaga.org.uk/ben/tech/gitcompletion- 
> a108bdc110dad770ec5c092759a8bc511790d21f.tar

Nice, I would like to add cg completion to Cogito's contrib/ - could you
please add some header to it with (c) information and stuff? (And make
it available somewhere just as a plain file.)

Besides, it would be probably best to just autogenerate the
auto-completion code - the usage information in Cogito is supposed to be
100% consistent and correct, so it should be a reliable source for that.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: latest stg/git commandline completions code

[Ben Clifford]

On 10 Nov 2005, at 09:23, Petr Baudis wrote:
>
> Nice, I would like to add cg completion to Cogito's contrib/ -  
> could you
> please add some header to it with (c) information and stuff? (And make
> it available somewhere just as a plain file.)

OK, will do.

> Besides, it would be probably best to just autogenerate the
> auto-completion code - the usage information in Cogito is supposed  
> to be
> 100% consistent and correct, so it should be a reliable source for  
> that.

yeah, I was thinking about that this morning -- maybe I'll be in the  
mood to implement...

There are a few small common functions that are used by all the git  
completions, though. I suppose for going into cogito's contrib/ I  
should include them directly in cogito completion code, but that  
seems a little messy, as it would be nice to keep them in-sync with  
what is used in the other completion files. hmm.

Ben

-- 
Ben ベン Бэн
http://www.hawaga.org.uk/ben/

Re: latest stg/git commandline completions code

[Petr Baudis]

Dear diary, on Thu, Nov 10, 2005 at 02:59:09AM CET, I got a letter
where Ben Clifford <benc@hawaga.org.uk> said that...
> There are a few small common functions that are used by all the git  
> completions, though. I suppose for going into cogito's contrib/ I  
> should include them directly in cogito completion code, but that  
> seems a little messy, as it would be nice to keep them in-sync with  
> what is used in the other completion files. hmm.

Then could you please separate those from the git completion to some
kind of 'library'?

Dear diary, on Thu, Nov 10, 2005 at 07:57:34AM CET, I got a letter
where Ben Clifford <benc@hawaga.org.uk> said that...
> On 10 Nov 2005, at 09:23, Petr Baudis wrote:
> >Besides, it would be probably best to just autogenerate the
> >auto-completion code - the usage information in Cogito is supposed  
> >to be
> >100% consistent and correct, so it should be a reliable source for  
> >that.
> 
> Maybe reliable and consistent but I think that info would need a bit  
> of augmentation to use for specifying autocompletion - for example,  
> in the case of:
> 
> > Usage: cg-branch-add BRANCH_NAME LOCATION
> 
> BRANCH_NAME should *not* exist so it doesn't make sense to  
> autocomplete from the branch list, but in the case of:

When you do

	cat > <tab><tab>

bash happily autocompletes as well. I don't think this is a problem,
besides it can be useful when you want to use some existing branch name,
just slightly modified.

> The amount of augmentation is probably not too much -  probably  
> sufficient  to specify for each parameter a completion-source(s)  
> (heads, branches, filenames, blah) that doesn't get displayed in -- 
> help. But this is more information to maintain and get out of date...

It's enough if we auto-build the completion and complain loudly and
error out when we hit something unknown.

> (I confess to having pretty much no idea how zsh completion works...)

Me neither. :-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: latest stg/git commandline completions code

[Ben Clifford]

>> There are a few small common functions that are used by all the git
>> completions, though.

> Then could you please separate those from the git completion to some
> kind of 'library'?

that's done now.


> When you do
>
>     cat > <tab><tab>
>
> bash happily autocompletes as well. I don't think this is a problem,
> besides it can be useful when you want to use some existing branch  
> name,
> just slightly modified.

ok, convinced - I changed 'branch' and 'checkout' to complete on new  
branch name.

http://www.hawaga.org.uk/gitcompletion/git-compl-lib
http://www.hawaga.org.uk/gitcompletion/cg-compl

are the two latest versions of the code (source the -lib then the cg-  
file)

There is no autogeneration - I'm still playing round. Its just good- 
old-fashioned manually hard coded.

The git repo that I'm keeping this and the other completion code  
(stg, git and gitk) in is at http://www.hawaga.org.uk/gitcompletion.git

-- 
Ben ベン Бэн
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,  
SMS number(s) at above URL.

Re: latest stg/git commandline completions code

[Ben Clifford]

On 10 Nov 2005, at 09:23, Petr Baudis wrote:

> Dear diary, on Tue, Nov 08, 2005 at 11:16:28AM CET, I got a letter
> where Ben Clifford <benc@hawaga.org.uk> told me that...
>
>> I've added some stuff to this to do a few cogito, gitk and (one) git
>> completions, split into different files. I thought I might as well
>> toss what I have out for anyone interested to play with.

btw, I got the repository for this working (it was working all along,  
it seems)...

cg clone http://www.hawaga.org.uk/gitcompletion.git

-- 
Ben ベン Бэн
http://www.hawaga.org.uk/ben/

Re: latest stg/git commandline completions code

[Ben Clifford]

On 10 Nov 2005, at 09:23, Petr Baudis wrote:






> Besides, it would be probably best to just autogenerate the
> auto-completion code - the usage information in Cogito is supposed  
> to be
> 100% consistent and correct, so it should be a reliable source for  
> that.
>
>
>
>

Maybe reliable and consistent but I think that info would need a bit  
of augmentation to use for specifying autocompletion - for example,  
in the case of:

 > Usage: cg-branch-add BRANCH_NAME LOCATION

BRANCH_NAME should *not* exist so it doesn't make sense to  
autocomplete from the branch list, but in the case of:

 > Usage: cg-fetch [-f] [-v] [BRANCH_NAME]

BRANCH_NAME *must* exist so it makes sense to autocomplete from the  
branch list.

The amount of augmentation is probably not too much -  probably  
sufficient  to specify for each parameter a completion-source(s)  
(heads, branches, filenames, blah) that doesn't get displayed in -- 
help. But this is more information to maintain and get out of date...

I wonder if Nikolai has had thoughts about that for zsh completion?
Hopefully if anything gets added, it would be useful for both zsh and  
bash

(I confess to having pretty much no idea how zsh completion works...)

Ben

-- 
Ben ベン Бэн
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,  
SMS numbers at above URL.