3 new builtins
5 views
Skip to first unread message
kkubasik
Jan 18, 2008, 11:52:53 PM1/18/08
to Hotwire Shell
So, I've been using both of these for a little while now, and thought
I would see what the process was for submitting patches etc.
The first builtin is replace, its similar to filter except it replaces
any pattern with another, basic use.
./--
---->happy.txt
---->hotwire.py
ls | prop uri | replace py python
would return
happy.txt
hotwire.python
The second is called 'hotbuild' and runs the appropriate build
sequence based on files in the current working directory, it needs
some love, but its a nice idea.
The final builtin performs a beagle search returning File objects so
they can be manipulated via hotwire, the command (bsearch) is my intro
to real python threading, so bear with me.
syntax is easy enough
bsearch <query term>
Hotbuild is by no means ready for additon, but i wanted to float the
idea, replace on the other hand is extremely useful and something
missing from the core scripting set in hotwire. Anyways, let me know
what the proper process is. Also, I plan to be more involved in
hotwire, and I wanted to know what the system was for applying for svn
access.
http://groups.google.com/group/hotwire-shell/web/bsearch.py
http://groups.google.com/group/hotwire-shell/web/replace.py
http://groups.google.com/group/hotwire-shell/web/hotbuild.py
Cheers!
Kevin Kubasik
I would see what the process was for submitting patches etc.
The first builtin is replace, its similar to filter except it replaces
any pattern with another, basic use.
./--
---->happy.txt
---->hotwire.py
ls | prop uri | replace py python
would return
happy.txt
hotwire.python
The second is called 'hotbuild' and runs the appropriate build
sequence based on files in the current working directory, it needs
some love, but its a nice idea.
The final builtin performs a beagle search returning File objects so
they can be manipulated via hotwire, the command (bsearch) is my intro
to real python threading, so bear with me.
syntax is easy enough
bsearch <query term>
Hotbuild is by no means ready for additon, but i wanted to float the
idea, replace on the other hand is extremely useful and something
missing from the core scripting set in hotwire. Anyways, let me know
what the proper process is. Also, I plan to be more involved in
hotwire, and I wanted to know what the system was for applying for svn
access.
http://groups.google.com/group/hotwire-shell/web/bsearch.py
http://groups.google.com/group/hotwire-shell/web/replace.py
http://groups.google.com/group/hotwire-shell/web/hotbuild.py
Cheers!
Kevin Kubasik
Colin Walters
Jan 20, 2008, 12:28:18 AM1/20/08
to Hotwire Shell
Cool, thanks for the additions!
I've added the replace.py into SVN, though we should probably refactor
it and filter.py to have a common superclass say StringOpBuiltin.
Committed r792
A hotwire/builtins/replace.py
M hotwire/builtin.py
r792 = 5bbc2fe3f6f55b59c0efd0d0656f91fcb27744cc (git-svn)
On bsearch, I have a few questions:
* Do we need to have both the Hotwire threaded=True and async going on
here? If we can make the Beagle search synchronous that would work.
Another approach is to remove the threaded=True and use the async
Beagle search, but I haven't actually tested the non-threaded case
much in Hotwire and we'd have to make sure the cancellation API
worked.
* Looks like we're taking the directory as an argument and store it in
"path", but it's not actually used? Is there a way to have the Beagle
search restricted to the current/specified directory tree? That seems
like it would be a pretty nice way for coders to use Beagle on project
trees directly from the shell.
* Could use some removal of commented areas, also the coding style in
Hotwire is to use __on_hits_added for handlers instead of just
"hits_added" which makes it private to the class and more clear it's a
signal handler.
On hotbuild:
I was thinking actually it would be neat if the larger Hotwire code
base had some idea of a "project" tree. There are a lot of
potentially useful things to do with this information, a smarter
"hotbuild" that auto-searches for the correct Makefile being one of
those. I haven't yet thought a lot about how exactly these kinds of
things should work though. I also want don't want to lose sort of
"freeform/no-setup" aspect that defines a shell versus an IDE.
I've added the replace.py into SVN, though we should probably refactor
it and filter.py to have a common superclass say StringOpBuiltin.
Committed r792
A hotwire/builtins/replace.py
M hotwire/builtin.py
r792 = 5bbc2fe3f6f55b59c0efd0d0656f91fcb27744cc (git-svn)
On bsearch, I have a few questions:
* Do we need to have both the Hotwire threaded=True and async going on
here? If we can make the Beagle search synchronous that would work.
Another approach is to remove the threaded=True and use the async
Beagle search, but I haven't actually tested the non-threaded case
much in Hotwire and we'd have to make sure the cancellation API
worked.
* Looks like we're taking the directory as an argument and store it in
"path", but it's not actually used? Is there a way to have the Beagle
search restricted to the current/specified directory tree? That seems
like it would be a pretty nice way for coders to use Beagle on project
trees directly from the shell.
* Could use some removal of commented areas, also the coding style in
Hotwire is to use __on_hits_added for handlers instead of just
"hits_added" which makes it private to the class and more clear it's a
signal handler.
On hotbuild:
I was thinking actually it would be neat if the larger Hotwire code
base had some idea of a "project" tree. There are a lot of
potentially useful things to do with this information, a smarter
"hotbuild" that auto-searches for the correct Makefile being one of
those. I haven't yet thought a lot about how exactly these kinds of
things should work though. I also want don't want to lose sort of
"freeform/no-setup" aspect that defines a shell versus an IDE.
Colin Walters
Jan 22, 2008, 4:56:02 PM1/22/08
to Hotwire Shell
I forgot to reply to this part:
> and I wanted to know what the system was for applying for svn access.
You think you might be able to clean up the bsearch thing, then I can
add you to the SVN so you'll be able to commit it?
> Anyways, let me know
> what the proper process is. Also, I plan to be more involved in
> hotwire,
Awesome!
> what the proper process is. Also, I plan to be more involved in
> hotwire,
> and I wanted to know what the system was for applying for svn access.
add you to the SVN so you'll be able to commit it?
kkubasik
Jan 24, 2008, 12:05:37 PM1/24/08
to Hotwire Shell
On Jan 19, 10:28 pm, Colin Walters <cgwalt...@gmail.com> wrote:
> Cool, thanks for the additions!
>
> I've added the replace.py into SVN, though we should probably refactor
> it and filter.py to have a common superclass say StringOpBuiltin.
> Committed r792
> A hotwire/builtins/replace.py
> M hotwire/builtin.py
> r792 = 5bbc2fe3f6f55b59c0efd0d0656f91fcb27744cc (git-svn)
superclass provide? Its a pretty limited chunk of code.
>
> On bsearch, I have a few questions:
>
> * Do we need to have both the Hotwire threaded=True and async going on
> here? If we can make the Beagle search synchronous that would work.
> Another approach is to remove the threaded=True and use the async
> Beagle search, but I haven't actually tested the non-threaded case
> much in Hotwire and we'd have to make sure the cancellation API
> worked.
>
I won't lie, thats pretty much just left from the handler I copied as
> On bsearch, I have a few questions:
>
> * Do we need to have both the Hotwire threaded=True and async going on
> here? If we can make the Beagle search synchronous that would work.
> Another approach is to remove the threaded=True and use the async
> Beagle search, but I haven't actually tested the non-threaded case
> much in Hotwire and we'd have to make sure the cancellation API
> worked.
>
a template, I had some odd crashes/hangs when I got rid of it, so I
kept it. hypothetically all our code is async (by far the recommended
way to use beagle, the sync handlers are not as tested, and can be
slow, especially on large result sets) but im not 100% sure on how
threaded=True actually affects the hotwire handler, I'm assuming it
just puts it in its own thread. Anyways, I'm open to consolidating
this one way, to be honest I'm quite new to the python threading API,
so I'm not 100% sure how it works.
> * Looks like we're taking the directory as an argument and store it in
> "path", but it's not actually used? Is there a way to have the Beagle
> search restricted to the current/specified directory tree? That seems
> like it would be a pretty nice way for coders to use Beagle on project
> trees directly from the shell.
Yeah, we can query for files in a specific directory, its not an
> "path", but it's not actually used? Is there a way to have the Beagle
> search restricted to the current/specified directory tree? That seems
> like it would be a pretty nice way for coders to use Beagle on project
> trees directly from the shell.
implemented feature in bsearch yet, but I plan to implement it soon,
after I clean up some of it on the beagle side and make sure it won't
cause issues on older beagle builds. (Just for everyones reference,
just add inuri:file:///home/kkubasik/dirtoq/ to the query string to
search in a directory)
> * Could use some removal of commented areas, also the coding style in
> Hotwire is to use __on_hits_added for handlers instead of just
> "hits_added" which makes it private to the class and more clear it's a
> signal handler.
>
Not a problem at all, any other coding conventions I should take note
> Hotwire is to use __on_hits_added for handlers instead of just
> "hits_added" which makes it private to the class and more clear it's a
> signal handler.
>
of? I'm not great on code formatting, so I try to nip those probles in
the bud by making it practice ASAP. ;)
> On hotbuild:
>
> I was thinking actually it would be neat if the larger Hotwire code
> base had some idea of a "project" tree. There are a lot of
> potentially useful things to do with this information, a smarter
> "hotbuild" that auto-searches for the correct Makefile being one of
> those. I haven't yet thought a lot about how exactly these kinds of
> things should work though. I also want don't want to lose sort of
> "freeform/no-setup" aspect that defines a shell versus an IDE.
>
Yeah, the current hotbuild is pretty stupid, but I really like the
>
> I was thinking actually it would be neat if the larger Hotwire code
> base had some idea of a "project" tree. There are a lot of
> potentially useful things to do with this information, a smarter
> "hotbuild" that auto-searches for the correct Makefile being one of
> those. I haven't yet thought a lot about how exactly these kinds of
> things should work though. I also want don't want to lose sort of
> "freeform/no-setup" aspect that defines a shell versus an IDE.
>
idea of maybe hotbuild-settings "--prefix=/usr --enable-cool-feature"
or something which drops a .hotbuild file in a dir. Or some other
means of more advanced config. What I really like/want to see out of
this is the ability to just run something like
walk | hotbuild
to build all projects in a dir or summin. There are a lot of cool
places to take something like this, but I'd love to hear some thoughts
from others using hotwire on what they might want/like to use this
type of thing for.
Anyways, I can cleanup the bsearch handler and add the in directory
component of a query, as to determining the exact implementation of
the async stuff, I'll wait for some input (ill try to get on the IRC
to discuss ) before determining what to do there.
As for hotbuild, lets get some ideas flowing!
>
> > Cheers!
> > Kevin Kubasik
Kevin Kubasik
Jan 28, 2008, 2:06:45 AM1/28/08
to Hotwire Shell
Hey! so here's a cleaned up bsearch, which implements the ability to
search within a specified directory. It still needs some serious
hardening, but I just wanted to make sure this was the right approach.
I've also got an initial patch with some basic performance cleanup,
and I also did an initial implementation of a clear history feature.
http://groups.google.com/group/hotwire-shell/web/bsearch+%282%29.py
Anyways, since the other features are more my way of learning the
codebase, and cause more problems then they solve (yet!) there just
sitting in a Git repo at:
http://kubasik.net/git/hotwire-kkubasik.git/
Anyways, thought I would share.
Cheers,
Kevin Kubasik
search within a specified directory. It still needs some serious
hardening, but I just wanted to make sure this was the right approach.
I've also got an initial patch with some basic performance cleanup,
and I also did an initial implementation of a clear history feature.
http://groups.google.com/group/hotwire-shell/web/bsearch+%282%29.py
Anyways, since the other features are more my way of learning the
codebase, and cause more problems then they solve (yet!) there just
sitting in a Git repo at:
http://kubasik.net/git/hotwire-kkubasik.git/
Anyways, thought I would share.
Cheers,
Kevin Kubasik
Reply all
Reply to author
Forward
0 new messages