Posted: Fri 13 Mar 2009, 23:47
I can shrink Python down to 2.5MB you know...
READ-ONLY Archive
https://oldforum.puppylinux.com/
Don't worry, I was planning to do make a prototype.Pizzasgood wrote:I've learned this since coming here: doing things gets more done than talking. That's true in general, of course, but especially so in Linux-world. Linux is a largely DIY community. If there's something you want, you can talk about it to gauge interest, but you generally have to set up some kind of working example to get people to actually care. Give them something tangible. Otherwise it's all hypothetical to them, and they soon get on with their own projects and forget.
How to I make a benchmark?For example, MU want's benchmarks. So give him some. Translate some scripts to python and compare execution times between python and bash.
The benifit is more for the probramer than the end user, there will be a speed diference but it won't be vary noticible due to the nature of the scripts.If it turns out acceptable, then build a working prototype Puppy to prove your point. Then people could see precisely what size difference is made, and feel the speed changes themselves.
But it would not be hard to make an extension module for Python so you could call bash like commands from inside Python (plus that module would be written in C). That way you get the best of both worlds (or best of 3 worlds if you include GUI).I personally don't see any reason to completely replace Bash. Bash is good at what it does. When it becomes weird is when you're attempting to go beyond what it was intended for. Those are the times when one should consider using something more like Python, Perl, or C. Especially if arrays or more-than-basic string manipulation is needed. Too much ambiguity in Bash, especially when it comes to spaces.
Bash scripts are very good at linking multiple other programs together. That is their purpose. I would not want to use any other language for that. Boot scripts are something I would not generally consider in any language besides Bash.
I would not want to write a fancy gui package manager or control panel in Bash. I might not want to write an Xorgwizard in Bash. I'd definitely prefer to write my 3d engine in anything at all besides Bash...
Use the spoon for soup, the fork for pasta, and the spork for target practice, IMHO.
Yeah! Thats what I'm talking about!Personally, I would be perfectly happy if Puppy included a small python by default.
Well, yeah. The point is so that people can feel for themselves how un-noticeable (or otherwise) it is.The benifit is more for the probramer than the end user, there will be a speed diference but it won't be vary noticible due to the nature of the scripts.
I should've stated my question better, I just need to know how to gauge the execution time, like calling a program which times the execution and then prints to the command line. As far as the programs I was thinking an empty loop like this: (in Python code)One way of doing benchmarks is to just make a script in python and measure the time it takes to run. Then do the same thing with Bash. You'd want to make a bunch of different comparisons though, including both short and long scripts to see the differences in startup time and execution time. Since they'd probably be pretty fast, you might have to measure the short scripts by running them repeatedly in a loop.
Code: Select all
for i in range(10000):
pass
Don't worry, I'm going to go overachiever on this benchmark project.You could also use system monitoring tools to see how much ram they use.
Code: Select all
cat /some/file.txt | while read LINE; do
echo "The following line is one line of text from /some/file.txt:"
echo $LINE
done
Code: Select all
cd initrd-tree
find . | ../cpio -o -H newc | gzip -9 > ../initrd.gz
Code: Select all
#!/bin/sh
#
#Records channel $1 for either $2 minutes, or $2 [hh:]mm:ss[.ms]
#Saves output at /opt/vids/
#Does not execute if mplayer is already running
#
OUT_DIR="/opt/vids"
SUFFIX=".avi"
NUMBER=0
while [ -f "${OUT_DIR}/${NUMBER}${SUFFIX}" ]; do
NUMBER=$(expr $NUMBER + 1)
done
OUTPUT="${OUT_DIR}/${NUMBER}${SUFFIX}"
[ "$(ps -Ao comm | grep "^mplayer")" ] && exit
if [ "$(echo "$2" | grep ':')" ]; then
TIME="$2"
else
TIME="00:$2:00"
fi
mencoder tv:// -tv channels=${1}-TMP -endpos "$TIME" -o "$OUTPUT"
Code: Select all
#!/bin/sh
#set important variables
. ../vars.rc
#make sure we're in the right place
[ ! "$(basename $(pwd) )" = "generic" ] && exit
for i in $PVERS; do
#copy in the binaries
cp bin/* ../$i/new-init-stuff/bin/
cp bin/* ../$i/pup_xxx/bin/
#remove (if they exist) and then recreate the framebuffer devices (avoids corruption)
rm -f ../$i/new-init-stuff/dev/fb0
rm -f ../$i/pup_xxx/dev/fb0
mknod ../$i/new-init-stuff/dev/fb0 c 29 0
mknod ../$i/pup_xxx/dev/fb0 c 29 0
done
Code: Select all
#!/bin/sh
#make sure we're in the right place
[ ! "$(basename $(pwd) )" = "zz_packages" ] && exit
#set important variables
. ../vars.rc
#setup
[ -d "$VERSION" ] && rm -rf "$VERSION" 1>/dev/null 2>&1
mkdir "$VERSION"
cd "$VERSION"
#create pebble_dev-$VERSION
echo "Creating pebble_dev-$VERSION..."
mkdir "pebble_dev-$VERSION"
cd ../../
for i in *; do [ ! "$i" = "zz_packages" ] && cp -a "$i" "zz_packages/$VERSION/pebble_dev-$VERSION/$i"; done
cd "zz_packages/$VERSION/pebble_dev-$VERSION/"
mkdir "zz_packages"
cp "../../create_packages" "zz_packages/"
for i in $PVERS; do
(cd $i; ./makeclean)
done
cd ../
tar czfp "pebble_dev-$VERSION.tar.gz" "pebble_dev-$VERSION"
for i in $PVERS; do
#create pebble_inst$i-$VERSION
echo "Creating pebble_inst$i-$VERSION..."
cp -a "../../$i/unleashed_extras" "pebble_inst$i-$VERSION"
tar czfp "pebble_inst$i-$VERSION.tar.gz" "pebble_inst$i-$VERSION"
rm -rf "pebble_inst$i-$VERSION" 1>/dev/null 2>&1
#create pebble_p$i-$VERSION
echo "Creating pebble_p$i-$VERSION..."
(
cd "pebble_dev-$VERSION/$i/"
[ -e makeext2initrd ] && ./makeext2initrd
[ -e makecpioinitrd ] && ./makecpioinitrd
)
mkdir "pebble_p$i-$VERSION"
cd "pebble_p$i-$VERSION"
cp "../pebble_dev-$VERSION/$i/initrd.gz" "initrd.gz"
cp -a "../pebble_dev-$VERSION/$i/pup_xxx" "pebble_postinit-$VERSION"
tar czfp "pebble_postinit-$VERSION.tar.gz" "pebble_postinit-$VERSION"
tgz2pet "pebble_postinit-$VERSION.tar.gz"
rm -rf "pebble_postinit-$VERSION" 1>/dev/null 2>&1
tar czfp "../pebble_p$i-$VERSION.tar.gz" *
cd ../
rm -rf "pebble_p$i-$VERSION" 1>/dev/null 2>&1
done
rm -rf "pebble_dev-$VERSION" 1>/dev/null 2>&1
sync
cd ..
echo
echo "Done"
YesI guess I'm going to have to learn genie.
Let was first added in the Korn shell, and Bash got it from there. Performance improvements were a focus of ksh, and one solution was built-ins to replace things like eval that had to be called as external commands. Replacing /bin/echo with a built-in (that is an alias to the print primitive) was another example.Pizzasgood wrote:One way of processing files with Bash is with the read command, by piping the contents through 'while' with 'read LINE' as the test:I wasn't aware of the 'let' command. I've been using eval for things that need to be ash-compatible, and $[$VAR+$i] for Bash-only things. The square brackets are much faster than eval in Bash and slightly faster than let, but are not supported in ash. The 'let' is many many times faster than 'expr', and ash using let is significantly faster than Bash with any of the above. And the speeds of let and square-brackets are even closer when using #!/bin/sh rather than #!/bin/bash. So I'm going to be using let from now on. Good stuff. Thanks.Code: Select all
cat /some/file.txt | while read LINE; do echo "The following line is one line of text from /some/file.txt:" echo $LINE done
Python is an interpreted language powerful enough that you can write complete applications in it, including fancy GUI stuff using PythonTK. It's also cross-platform, and available for Windows, Mac OS/X, and *nix. (I have several text editors in my collection written entirely in Python, and a couple of others that use Python as an extension language. Eric S. Raymond was going on at one point about what Lisp got wrong and Python got right. I suggested he rewrite Gnu Emacs, which is based on Lisp, to use Python instead, and he said "Don't tempt me!" )They all have a loop or two. But the actual tasks are mostly using generic programs like 'cp', 'tar', 'mencoder', etc. What benefit would there be in using Python for that? It seems to me like doing that stuff in anything else would just be inserting an extra layer of complexity.
I'm not trying to be argumentative. I've actually been very tempted to use things besides Bash on some projects, particularly things that need arrays. But for the above examples, it seems to me like Bash is ideal for them.
The usual solution to that is to use Perl, which is intended for just such cases, and replaces sed and awk.Now, in a script I recently wrote that does some weird interactions with the output of some 'git' commands, maybe Python would have been easier than all the calls to 'grep' and 'sed' and futile attempts to get Bash's string and array parsing to work the way I needed.
Genie bears some syntactic resemblance to Python, so I suppose you might be able to do it, but I'm not sure why you should. The advantage you would get is that Genie "compiles" to C, which is then compiled to native machine code, so your executable will theoretically be faster. But if that's a concern, you are better not writing in Python in the first place, or translating Python code to C without the intermediate Genie step.)Lobster wrote:YesI guess I'm going to have to learn genie.
http://puppylinux.com/genie/
You could even create a python to genie parser
- improving your understanding of both languages
Even I am having a go . . .
http://www.murga-linux.com/puppy/viewto ... 314#283314
Barry and MU have a record of producing Puppy code
Vala is being used by Gnome
Linus has recently moved to using Gnome
So the future is set already
Can you do a parser?
If you can deal with Ruby, you can deal with Python. Ruby was developed to address perceived lacks in Python.Lobster wrote:Yep if speed is no problem the future would be the slowly
but easy to use Ruby.
You will be better served to consider just what problem you are trying to solve. There is a reason why so many languages exist, and there isn't a "one size fits all" solution.My approach is what language is being used by Puppy developers
or being explored by them?
What they write is our future.
Not me. I have too many other projects either planned or underway as it is.1. Who is willing to help me?
If you want to replace Bash, it needs to be able to handle the situations I showed at least as elegantly as Bash did. And if you want to completely replace Bash, to the point where it isn't even included, you'll have to either write a bash (or at least sh) emulator, or have a wrapper named "bash" set up to run the script through a bash->python translator and then run the translated script with Python. Gotta support that occasional bash script you'll get from random 3rd party packages.2. What features does this Python shell need?
GTK 23. What is the prevailing GUI system for puppy?
I don't even want to think about any kind of BASH translator . (the syntax sucks) Getting Python to the stage were BASH is not needed is a long way off anyway so there's some time still. But, would someone make a list of features a good shell needs? I really have no idea so if someone could either link a list or write one up that would be wonderfull.Pizzasgood wrote:If you want to replace Bash, it needs to be able to handle the situations I showed at least as elegantly as Bash did. And if you want to completely replace Bash, to the point where it isn't even included, you'll have to either write a bash (or at least sh) emulator, or have a wrapper named "bash" set up to run the script through a bash->python translator and then run the translated script with Python. Gotta support that occasional bash script you'll get from random 3rd party packages.
Jamie MccrackenMr. Maxwell wrote: 4. How can I contact the guy who made Genie?
Maybe you should get some experience with shell scripting first. I mean, if you want to replace something, you kinda need to know what you're replacing in great enough detail to do a good job. Know thine enemy, they say.But, would someone make a list of features a good shell needs? I really have no idea so if someone could either link a list or write one up that would be wonderfull.