I've seen the future of Linux...

Message

#16 Post by MU » Thu 12 Mar 2009, 23:14

Gtkbasic is not the future, but just 200 kb, including Gtk wrappers

It is not as powerfull as a language with full Gtk implementation (like freebasic), but I could write programs, that astonished myself.

Win-Thumbs
A kind of visual taskbar.
http://murga-linux.com/puppy/viewtopic. ... 389#174389

ControlCenter Prototype
unfinished, work in progress
http://murga-linux.com/puppy/viewtopic.php?t=24656

Muppy-Filer
http://murga-linux.com/puppy/viewtopic.php?t=32575

GtkBasic
A small Basic-Interpreter with a simple IDE and example programs.
Main purpose is to develop small utilities for Puppylinux.
http://murga-linux.com/puppy/viewtopic.php?p=155083

However, I think that vala is suited better for Puppy.
Very small compiled executables.
"official" Gnome language, so hopefully this will get a lot of support in future.
Syntax seems simple, and is very similar to Java.
Who goes for a Java2vala converter? That would be *really* cool.
Especially with a swing2gtk converter in addition.
http://puppylinux.com/blog/?viewDetailed=00595
http://puppylinux.com/blog/?viewDetailed=00596

Gdesklets (Python) start up pretty slow, and require a huge Python installation, so I never really was convinced from Python.
And I find Python not easy to understand, maybe this is the effect, if you learned other languages before (like C).

Mark

Mr. Maxwell · #17 Post by **Mr. Maxwell** » Fri 13 Mar 2009, 01:56

I encourage everyone who has not used Python before to install it and give it a try. Really it is a great language, if it spawns clone languages it has to be good (python just spawned a few).

MUguest · #18 Post by **MUguest** » Fri 13 Mar 2009, 08:54

Visual Basic also is popular, so should we use it?

Here is an interesting benchmark:
http://google.com/search?q=cache:n0jYRX ... +slow&cd=2

Python is even slower than Java

But the benchmark is old, maybe it got better meanwhile.
It was just the first one I found.

An important issue seems to be the time required to start the virtual machine.
I really don't want to do "programming language bashing", but slogans like "is the future" are not good to determine the quality.
Benchmarks give reproducable results.

Mark

Lobster · #19 Post by **Lobster** » Fri 13 Mar 2009, 09:03

Python is even slower than Java

Too slow.
You know what I found the main problem with python?
Basically a programming language without an easy method to create
a GUI is of limited use to me . . .

I will persevere with Genie, the Python like language that compiles . . .
Python is never going to be in Puppy as standard.
It is too big.
So it may be the best thing ever but . . .

It is too big.

mcewanw · #20 Post by **mcewanw** » Fri 13 Mar 2009, 10:14

Mr. Maxwell wrote: I truly believe . . . Python really is the way of the future. I'm not biased, I've reaserched this for several hours.

There is nothing like conviction.

Mr. Maxwell · #21 Post by **Mr. Maxwell** » Fri 13 Mar 2009, 23:47

I can shrink Python down to 2.5MB you know...

Aitch · #22 Post by **Aitch** » Sat 14 Mar 2009, 00:13

Mr Maxwell

10 bonus points for perseverance.....

but the writing's on the wall

Aitch

Mr. Maxwell · #23 Post by **Mr. Maxwell** » Sat 14 Mar 2009, 00:23

Last thing I'm going to say: (about python)

You guys really don't know what you're missing

.

I guess I'm going to have to learn genie.

Maybe I'll give linux for scrach a shot and see if I can replace bash...

#24 Post by **Pizzasgood** » Sat 14 Mar 2009, 05:14

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.

For example, MU want's benchmarks. So give him some. Translate some scripts to python and compare execution times between python and bash.

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.

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.

Personally, I would be perfectly happy if Puppy included a small python by default.

Mr. Maxwell · #25 Post by **Mr. Maxwell** » Sat 14 Mar 2009, 15:01

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.

Don't worry, I was planning to do make a prototype.

For example, MU want's benchmarks. So give him some. Translate some scripts to python and compare execution times between python and bash.

How to I make a benchmark?

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.

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 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.

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).

Personally, I would be perfectly happy if Puppy included a small python by default.

Yeah! Thats what I'm talking about!

Lets see if I can figure out how to boot a text Linux into the Python interperater using a Python script... (might take a long time)

#26 Post by **Pizzasgood** » Sun 15 Mar 2009, 05:49

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.

You could also use system monitoring tools to see how much ram they use.

An detail is to make it easy for other people to repeat the same benchmark test for themselves, so they can verify it, make variations, test on other equipment, etc.

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.

Well, yeah. The point is so that people can feel for themselves how un-noticeable (or otherwise) it is.

Mr. Maxwell · #27 Post by **Mr. Maxwell** » Sun 15 Mar 2009, 14:05

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.

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)

Code: Select all

for i in range(10000):
    pass

You could also use system monitoring tools to see how much ram they use.

Don't worry, I'm going to go overachiever on this benchmark project.

EDIT:

Nevermind the benchmark part, it's the "time" command.

Mr. Maxwell · #28 Post by **Mr. Maxwell** » Tue 17 Mar 2009, 23:05

Any requests on code to benchmark?

I've been doing a couple so far and python averages 11 times faster than bash. But that's with a hash table test which Python is 29 times faster than bash in.

(no joke, it's true, you will have to wait quite a long time for the finished resualts as I'm going to put together a nice little paper on this benchmark test)

Mr. Maxwell · #29 Post by **Mr. Maxwell** » Wed 18 Mar 2009, 02:20

Ok I have a 10 page PDF attached that has the resualts of the benchmarking. It has 5 tests which have the source code and anyalsis included. One very important thing to note is that file reading and writing is not included. I could not figure out how do either in either laungauge, the output file just dissipered.

Any help on that would be nice and I will update the report with the new benchmarks.

#30 Post by **Pizzasgood** » Wed 18 Mar 2009, 04:31

One way of processing files with Bash is with the read command, by piping the contents through 'while' with 'read LINE' as the test:

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

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.

I also wasn't aware of 'seq'. Handy.

(It shows how few numeric things I have to do when shell-scripting that I wasn't aware of those.)

Those are interesting results. I didn't expect it to be that much faster. I should have, but I didn't stop to think about it.

Some more practical benchmarks would involve moving, copying, and deleting files, appending text, inserting text, modifying things, piping output from one program into another program, etc. For example, to take a directory named initrd-tree/ and convert it into an initrd.gz file, I do this:

Code: Select all

cd initrd-tree
find . | ../cpio -o -H newc | gzip -9 > ../initrd.gz

I have very little experience with Python so I don't know what the equivalent would be. I doubt it could be any more elegant than that. Pipes like that are frequent in shell scripts. I do a lot of piping with grep and often sed. So those would be a good thing to get a benchmark on.

Often, scripts are short and simple, just used to handle a couple basic tasks before letting some other program do the real work. For example, this is a script I call record_tv that I use to record tv using mencoder. It basically just chooses a unique file name to output to, checks that mplayer isn't already running (unlike a VCR, I cannot watch and record simultaneously), and then records channel $1 for the time specified in $2.

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"

Another thing is generic "management" type stuff. Example: the "propagate" script from my Pebble build tree. I try to maintain Pebble packages for several versions of Puppy, which have slightly different contents, but they all share a script and two binaries in common, which are the most important components and are generally the things that change from release to release. So I keep a single copy in a generic/ subdirectory, and use this script to copy them into all the other package directories.

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

And then the create_packages script from that same project, which takes all the subdirectories, builds the new initrd.gz files, creates the .pet and .tar.gz packages, etc.

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"

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.

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. And if I wanted to write nearly anything with more than a very basic Gui, I'd want something besides Bash. Same goes for if I had a lot of processing of data and no existing programs to deal with it (as opposed to several existing programs that each do a portion of what I need, so I can just pipe them together in a couple simple lines of Bash.) For example, if I wanted to parse the contents of a bunch of star catalogs and run some calculations based on the relative and absolute magnitudes of the stars to approximate their position relative to the Sun in Cartesian coordinates, I would most certainly not want Bash. (I did a little of that last year, in Perl).

Lobster · #31 Post by **Lobster** » Wed 18 Mar 2009, 11:15

I guess I'm going to have to learn genie.

Yes

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?

DMcCunney · #32 Post by **DMcCunney** » Wed 18 Mar 2009, 11:58

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:
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
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.

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.

Ash is effectively the Bourne shell script language without various of the improvements of ksh and bash. Most of the scripts that control *nix systems are in the Bourne dialect, and ash is smaller and faster to load, so it often gets the nod for non-interactive usage.

<...>

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.

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!"

)

Modern hardware is fast and powerful enough that it's feasible to use an interpreted language instead of a compiled one, and the interpreted nature can speed development and debugging. (Python does compile to "bytecode", ala Java, but that's not the same thing as compiling to native machine code.) It's aimed at a different problem domain than shell scripts.

Most current Unix and Linux distros I'm aware come with Python, (and Perl and TclTk)as basic parts of the distribution. Puppy is unusual in not including it by default.

You *can* use Python to diddle the ASCII data comprising most *nix config files, and I recall seeing at least one Linux distro that does

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.

The usual solution to that is to use Perl, which is intended for just such cases, and replaces sed and awk.

The shell (whether ash, bash, csh, tcsh, zsh or whatever, is intended to be a glue language, where you couple together other programs in a pipeline to do what you want to do, with the shell providing high-level control constructs. The drawback is two fold:

First, Unix was developed by programmers, who wanted a better environment for software development. Software source code is all ASCII, and the implicit assumption of the shell and pipelines is that programs are passing around ASCII strings. If the data you are diddling is not ASCII, this breaks down.

Second, pipelines are one dimensional, and assume a linear set of processing steps. Not all processing lends itself to that approach. (There was an experimental effort called the 2D shell that supported more complex processing models, but I don't believe that ever made it out of Bell Labs. (I've only seen it referred to in papers and documentation.)
______
Dennis

DMcCunney · #33 Post by **DMcCunney** » Wed 18 Mar 2009, 12:10

Lobster wrote:
I guess I'm going to have to learn genie.
Yes
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?

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.)

Modern hardware is fast enough that you can often write in Python and not have to resort to C. Performance will be quite acceptable.

This breaks down somewhat in Puppy, which tends to be used on older hardware that may not be fast enough.

Incidentally, poking around a bit, it appears Geany has a Vala mode.
______
Dennis

Lobster · #34 Post by **Lobster** » Wed 18 Mar 2009, 12:48

Yep if speed is no problem the future would be the slowly
but easy to use Ruby.

My approach is what language is being used by Puppy developers
or being explored by them?

What they write
is our future.

One day we may end up using ASQ which requires some developments
in hardware, AI and programming mentality . . .
http://tmxxine.com/Wikka/wikka.php?wakk ... evelopment

DMcCunney · #35 Post by **DMcCunney** » Wed 18 Mar 2009, 14:22

Lobster wrote:Yep if speed is no problem the future would be the slowly
but easy to use Ruby.

If you can deal with Ruby, you can deal with Python. Ruby was developed to address perceived lacks in Python.

The main use of Ruby I'm aware of therese days in in "Ruby on Rails" web development.

My approach is what language is being used by Puppy developers
or being explored by them?

What they write is our future.

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.

The first question I'd ask is "What do you plan to develop in Genie?" Depending on the answer, it's possible you'd be better off using something else.
______
Dennis

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

I've seen the future of Linux...

guilty as convicted