Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 12 Dec 2018, 00:03
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
I've seen the future of Linux...
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 4 [56 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Author Message
MU


Joined: 24 Aug 2005
Posts: 13647
Location: Karlsruhe, Germany

PostPosted: Thu 12 Mar 2009, 19:14    Post subject:  

Gtkbasic is not the future, but just 200 kb, including Gtk wrappers Wink
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.php?p=174389#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

_________________
my recommended links
Back to top
View user's profile Send private message Visit poster's website 
Mr. Maxwell


Joined: 30 Aug 2008
Posts: 215
Location: Nebraska, USA

PostPosted: Thu 12 Mar 2009, 21:56    Post subject:  

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).
_________________
Super amazing game!
Back to top
View user's profile Send private message 
MUguest

Joined: 09 Dec 2006
Posts: 73

PostPosted: Fri 13 Mar 2009, 04:54    Post subject:  

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

Here is an interesting benchmark:
http://google.com/search?q=cache:n0jYRXigfrIJ:furryland.org/~mikec/bench/+python+slow&cd=2

Python is even slower than Java Sad
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
Back to top
View user's profile Send private message 
Lobster
Official Crustacean


Joined: 04 May 2005
Posts: 15239
Location: Paradox Realm

PostPosted: Fri 13 Mar 2009, 05:03    Post subject:  

Quote:
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 . . . Crying or Very sad
It is too big.

_________________
YinYana AI Buddhism
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Fri 13 Mar 2009, 06:14    Post subject: guilty as convicted  

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.
Back to top
View user's profile Send private message Visit poster's website 
Mr. Maxwell


Joined: 30 Aug 2008
Posts: 215
Location: Nebraska, USA

PostPosted: Fri 13 Mar 2009, 19:47    Post subject:  

I can shrink Python down to 2.5MB you know...
_________________
Super amazing game!
Back to top
View user's profile Send private message 
Aitch


Joined: 04 Apr 2007
Posts: 6815
Location: Chatham, Kent, UK

PostPosted: Fri 13 Mar 2009, 20:13    Post subject:  

Mr Maxwell

10 bonus points for perseverance.....

but the writing's on the wall Wink

Aitch Smile
Back to top
View user's profile Send private message 
Mr. Maxwell


Joined: 30 Aug 2008
Posts: 215
Location: Nebraska, USA

PostPosted: Fri 13 Mar 2009, 20:23    Post subject:  

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

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

I guess I'm going to have to learn genie. Crying or Very sad Maybe I'll give linux for scrach a shot and see if I can replace bash...

_________________
Super amazing game!
Back to top
View user's profile Send private message 
Pizzasgood


Joined: 04 May 2005
Posts: 6266
Location: Knoxville, TN, USA

PostPosted: Sat 14 Mar 2009, 01:14    Post subject:  

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.

_________________
Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Back to top
View user's profile Send private message 
Mr. Maxwell


Joined: 30 Aug 2008
Posts: 215
Location: Nebraska, USA

PostPosted: Sat 14 Mar 2009, 11:01    Post subject:  

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.

Quote:
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? Embarassed

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

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

Quote:
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)

_________________
Super amazing game!
Back to top
View user's profile Send private message 
Pizzasgood


Joined: 04 May 2005
Posts: 6266
Location: Knoxville, TN, USA

PostPosted: Sun 15 Mar 2009, 01:49    Post subject:  

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.


Quote:
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.
_________________
Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Back to top
View user's profile Send private message 
Mr. Maxwell


Joined: 30 Aug 2008
Posts: 215
Location: Nebraska, USA

PostPosted: Sun 15 Mar 2009, 10:05    Post subject:  

Quote:
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:
for i in range(10000):
    pass


Quote:
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. Very Happy

EDIT:

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

_________________
Super amazing game!
Back to top
View user's profile Send private message 
Mr. Maxwell


Joined: 30 Aug 2008
Posts: 215
Location: Nebraska, USA

PostPosted: Tue 17 Mar 2009, 19:05    Post subject:  

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. Very Happy (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)

_________________
Super amazing game!
Back to top
View user's profile Send private message 
Mr. Maxwell


Joined: 30 Aug 2008
Posts: 215
Location: Nebraska, USA

PostPosted: Tue 17 Mar 2009, 22:20    Post subject:  

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. Confused Any help on that would be nice and I will update the report with the new benchmarks.
_________________
Super amazing game!
Back to top
View user's profile Send private message 
Pizzasgood


Joined: 04 May 2005
Posts: 6266
Location: Knoxville, TN, USA

PostPosted: Wed 18 Mar 2009, 00:31    Post subject:  

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:
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:
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:
#!/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:
#!/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:
#!/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).

_________________
Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 4 [56 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1973s ][ Queries: 11 (0.0352s) ][ GZIP on ]