[SLUG] Your top-ten linux desktop apps

[Grant Parnell]

For this Friday's SLUG meeting we're doing a newbie oriented talk for the
second half of the meeting and SLUGlets will be where all the tech guru's
head for a chat on random stuff like coding and key signing etc.

It just occurred to me that we should get a run-down of some likely apps
to talk about, and if you really like maybe a 3-5 minute talk from you
about some of them.

For starters what apps do you tend to use the most?
Here's my top 10 list in order of use:-

gnome-terminal
firefox (squirrelmail,google)
qfaxreader
nautilus
xv (old, small image viewer)
gimp
openoffice
gnumeric
xmms
grip

OK so I'm a command-line junkie and I use it about 90% of the time. I
don't really use a lot of GUI apps for much. Pretty boring stuff. I
mentioned squirrelmail because although it's a webmail app many users
consider email an application itself no matter how it's accessed.

I would be happy to demo qfaxreader, and gnumeric.

-- 
--
Electronic Hobbyist, Former Arcadia BBS nut, Occasional nudist, Linux
Guru, SLUG President, AUUG and Linux Australia member, Sydney
Flashmobber, Tenpin Bowler, BMX rider, Walker, Raver & rave music lover,
Big kid that refuses to grow up. I'd make a good family pet, take me home
today!

Some people actually read these things it seems.


-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

Grant Parnell wrote:

> For this Friday's SLUG meeting we're doing a newbie oriented talk for the
> second half of the meeting and SLUGlets will be where all the tech guru's
> head for a chat on random stuff like coding and key signing etc.
> 
> It just occurred to me that we should get a run-down of some likely apps
> to talk about, and if you really like maybe a 3-5 minute talk from you
> about some of them.
> 
> For starters what apps do you tend to use the most?
> Here's my top 10 list in order of use:-

I'll bite :-). My somewhat unorthodox list:

  gcc
  Nedit text editor
  GNU Octave
  Ocaml
  Valgrind
  
Erik
-- 
+---+
  Erik de Castro Lopo
+---+
C offers you enough rope to hang yourself.
C++ offers a fully equipped firing squad, a last cigarette and
a blindfold.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Sridhar Dhanapalan]

On Mon, 26 Sep 2005 15:57, "Grant Parnell" <[EMAIL PROTECTED]> wrote:
> For this Friday's SLUG meeting we're doing a newbie oriented talk for the
> second half of the meeting and SLUGlets will be where all the tech guru's
> head for a chat on random stuff like coding and key signing etc.
>
> It just occurred to me that we should get a run-down of some likely apps
> to talk about, and if you really like maybe a 3-5 minute talk from you
> about some of them.
>
> For starters what apps do you tend to use the most?
> Here's my top 10 list in order of use:-

My most used apps (in no particular order):

RXVT
Konsole (when I need more than a single terminal)
Konqueror
Nedit
Kate
OpenOffice.org
QIV (Quick Image Viewer - similar to XV)
GQView (when I want to view many images at once)
The GIMP
Galeon (uses Firefox's renderer but has a better UI)
Downloader for X (D4X)
Kontact
Gkrellm
EasyTAG
XMMS
Madman (Music organiser, like Rhythmbox or iTunes)
Xine
MPlayer
K3B
GNOME Disc Catalogue



-- 
Sridhar Dhanapalan  [Yama | http://www.pclinuxonline.com/]
  {GnuPG/OpenPGP: http://dhanapalan.webhop.net/yama.asc
   0x049D38B4 : A7A9 8A02 78CB AB1B FCE4 EEC6 2DD9 249B 049D 38B4}

Windows: Designed for the Internet.
The Internet: Designed for UNIX.


pgpiUOzTRaGdL.pgp
Description: PGP signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Pia Waugh]

> For starters what apps do you tend to use the most?
> Here's my top 10 list:-
> 
> gnome-terminal
> firefox (squirrelmail,google)
> gimp
> openoffice
evince
gaim
evolution
palm sync
xchat
rhythmbox

I also suggest showing off f-spot, totem, and some cool stuff like celestia,
the tux series of kid foo, and maybe gramps (genealogy application).

Cheers,
Pia

-- 
Linux Australia http://linux.org.au/
 
  Jeff: Whatchootalkin'boutwillis?
Pia: What's Willis?
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Ken Foskey]

On Mon, 2005-09-26 at 15:57 +1000, Grant Parnell wrote:

> gnome-terminal
> firefox (squirrelmail,google)
> qfaxreader
> nautilus
> xv (old, small image viewer)
> gimp
> openoffice
it's openoffice.org 
> gnumeric
> xmms
> grip

evolution
terminal server client (remote desktop for windows)
project

Must have utils:

xkill
diff
grep
find
df

Techo stuff...
ssh
gpg  (gpgedit script)
gvim & cream (cool gvim extensions...)

Programming:

cvs
valgrind
perl
gcc
g++
apache

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Peter Miller]

On Mon, 2005-09-26 at 19:45 +1000, Erik de Castro Lopo wrote:

> I'll bite :-). My somewhat unorthodox list:
> 
>   gcc

of course.

Plus:

vim - because my 20-something year unix veteran fingers already know the
key strokes 

> Valgrind

How did we ever live without it?

wget / curl - because some web sites make it far too hard to download
via a browser

The Gimp - because I can (and do) add my own plugins

timex - I have yet to find a better minute minder (after I hacked it
slightly).  Some have more features, but I haven't found a *significant*
improvement.

Aegis - everyone should be useing a VC/SCM for all programming tasks:
pick one, there are now over a dozen F/OSS possibilities


> C offers you enough rope to hang yourself.
> C++ offers a fully equipped firing squad, a last cigarette and
> a blindfold.

and better type safety that sh, tcl, php and a shit load of other
"advanced" make-the- type-up- at-run-time you-can-only-find- bugs-by-
customers-using- it-for- real-and- suing-you (that some simple compile
time static analysis would have found) scripting languages.
(Don't you just love Erik's language trolls?)

-- 
Regards
Peter Miller <[EMAIL PROTECTED]>
/\/\*http://www.canb.auug.org.au/~millerp/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.


signature.asc
Description: This is a digitally signed message part
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Hal Ashburner]

Desktop apps? For this I read gui, gentle learning curve, suitable for
people who dislike learning about the computer.
In no special order the ones I use regularly and like are

firefox
rhythmbox
sound juicer
sweep
gqview
wesnoth
 oowriter or abiword (equally good in different ways)
lifrea
xine
gnumeric --I liked the app so much I... etc.

and for non-free software
ut2004
quake3
Wolfenstein Enemy-Territory (free beer)
I wish evolution were in the above list.

vim, gcc, valgrind, cscope, gdb, ddd, perl, latex, gnome-terminal,
ssh, mutt, irssi all probably get more of a workout than the desktop
apps :)

 --
Kind regards,
Hal Ashburner
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Graham Smith]

Konqueror - using  fish to transfer files - fish://@host
Konqueror - to display man/info pages
freenx 


-- 
Regards,

Graham Smith
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

Peter Miller wrote:

> > C offers you enough rope to hang yourself.
> > C++ offers a fully equipped firing squad, a last cigarette and
> > a blindfold.
> 
> and better type safety that sh, tcl, php and a shit load of other
> "advanced" make-the- type-up- at-run-time you-can-only-find- bugs-by-
> customers-using- it-for- real-and- suing-you (that some simple compile
> time static analysis would have found) scripting languages.

Thats why I'm so keen on O'Caml. It offers even more static analysis
than C and C++. Its significantly more difficult to write bugs into
an O'Caml program than a C or C++ program.

> (Don't you just love Erik's language trolls?)

They keep me entertained :-).

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"There are two kinds of large software systems: those that 
evolved from small systems and those that don't work."
-- Seen on slashdot.org, then quoted by amk
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[QuantumG]

Erik de Castro Lopo wrote:


Thats why I'm so keen on O'Caml. It offers even more static analysis
than C and C++. Its significantly more difficult to write bugs into
an O'Caml program than a C or C++ program.
 



Sounds like the antithesis of Objective-C and other dynamically typed 
languages.


Fun.

Trent
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[yiz]

C offers you enough rope to hang yourself.
C++ offers a fully equipped firing squad, a last cigarette and
a blindfold.


Our system architect calls me crazy,
But coding in C makes me feel pretty.

Since I always remotely log on to a linux box, I am command line junkie. The
things I use most are:

1) vim/vi

2) gdb
The more buggy your code is the more useful this debugging tool is ^_^

3) cvs
That's ... if you have more than 1 person working on the code.

As for programming languages I recommand:

C/C++ (gcc/g++)
perl
shell (script)

I am not sure these are the "desktop" apps you are refering to, but I 
use linux

mainly for programming purposes.

cheers,

yiz







--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Erik de Castro Lopo wrote:


Peter Miller wrote:

 


C offers you enough rope to hang yourself.
C++ offers a fully equipped firing squad, a last cigarette and
a blindfold.
 


and better type safety that sh, tcl, php and a shit load of other
"advanced" make-the- type-up- at-run-time you-can-only-find- bugs-by-
customers-using- it-for- real-and- suing-you (that some simple compile
time static analysis would have found) scripting languages.
   



Thats why I'm so keen on O'Caml. It offers even more static analysis
than C and C++. Its significantly more difficult to write bugs into
an O'Caml program than a C or C++ program.

 



I do not know O'Caml, so I just want to ask the equivalent of ff code.
I can RTFM but if I can see the  equivalent of this code, it'd be helpful.
I wish to have a quick idea of the language.

#include 

int integer_array[] = {1,-2,3,-4,5,-6,-7,8,-9,32727000};
int *ptr;

int main(void)
{
   int i;
   ptr = &integer_array[0];
   printf("\n\n");

   for (i = 0; i < 10; i++)
   {
 printf("integer_array[%d] = %d   ",i,integer_array[i]);
 printf("ptr + %d = %d\n",i, *(ptr + i));
   }
   return 0;
}


Thanks.
---

O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

O Plameras wrote:

> I do not know O'Caml, so I just want to ask the equivalent of ff code.

Probably the best place to get an idea of the language is the
Pleac project:

http://pleac.sourceforge.net/pleac_ocaml/index.html

> I can RTFM but if I can see the  equivalent of this code, it'd be helpful.
> I wish to have a quick idea of the language.

O'Caml is not a general replacement for C. It doesn't have
pointers for the same reasons Java doesn't have pointers.
You also can't realistically write a Linux device driver 
in O'Caml (although there is a project that attempts this
I personally think its a bad idea.).

The O'caml version of your program therefore doesn't do the
pointer part and reduces to:

let integer_array = [| 1 ; -2 ; 3 ; -4 ; 5 ; -6 ;
-7 ; 8 ; -9 ; 32727000 |] ;;

Array.mapi (fun i x
-> Printf.printf "integer_array[%d] = %d\n" i x
) integer_array ;;

The first part (let ...) is pretty obvious. The second part
probably looks odd to someone who has only programmed in
C, C++ and java. It creates an annonimous function which takes
two integer parameters (i and x) and then mapps that function
onto the array. The anonymous functions gets called once for
each element in the array passing the array index and value
each time.

You will notice that something like the Array.mapi function is
much less likely to contain errors than the C for loop.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"I consider C++ the most significant technical hazard to the survival
of your project and do so without apologies." -- Alistair Cockburn
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[QuantumG]

Erik de Castro Lopo wrote:


You will notice that something like the Array.mapi function is
much less likely to contain errors than the C for loop.
 



What I noticed is that they invented syntax when they could have just as 
easily have used C syntax.  Way to knife your language.


Trent
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Bruce Badger]

On 9/27/05, O Plameras <[EMAIL PROTECTED]> wrote:
> I can RTFM but if I can see the  equivalent of this code, it'd be helpful.
> I wish to have a quick idea of the language.
>
> #include 
>
> int integer_array[] = {1,-2,3,-4,5,-6,-7,8,-9,32727000};
> int *ptr;
>
> int main(void)
> {
> int i;
> ptr = &integer_array[0];
> printf("\n\n");
> for (i = 0; i < 10; i++)
> {
>   printf("integer_array[%d] = %d   ",i,integer_array[i]);
>   printf("ptr + %d = %d\n",i, *(ptr + i));
> }
> return 0;
> }

In Smalltalk:

integerArray := #(1 -2 3 -4 5 -6 -7 8 -9 32727000 9876543210).
Transcript cr.
1 to: integerArray size do: [:index|
Transcript
show: 'integerArray[', index printString, '] = ';
show: (integerArray at: index) printString;
cr].
^0

Notes:
o The index of the first position in an Array is 1
o Objects have a memory address, but only the VM knows what it is
o I popped in a larger number at the end of the Array :-)

Here is the result of evaluating the above:

integerArray[1] = 1
integerArray[2] = -2
integerArray[3] = 3
integerArray[4] = -4
integerArray[5] = 5
integerArray[6] = -6
integerArray[7] = -7
integerArray[8] = 8
integerArray[9] = -9
integerArray[10] = 32727000
integerArray[11] = 9876543210

All the best,
Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Lindsay Holmwood]

Grant Parnell wrote:


For starters what apps do you tend to use the most?


xterminal
leafpad
firefox
thunderbird
nautilus
gaim
gimp
vim
f-spot

Although more recently i've been using epiphany instead of firefox, due 
to its lighter feel. I'm slowly moving away from nautilus to thunar (an 
xfce file manager) as more and more features are being implemented.


F-Spot rocks when it comes to photo management. Almost as good as 
Google's picasa. :-)


Cheers,
Lindsay
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Gottfried Szing]

hi

F-Spot rocks when it comes to photo management. Almost as good as 
Google's picasa. :-)


does someone can suggest a good and fast(!) image browser for linux? sth 
like acdsee for windows?


i cannot try f-spot because my debian box cannot resolve some depencies.

br, gottfried
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Raphael Kraus]

G'day Gottfried and all...

> does someone can suggest a good and fast(!) image browser for linux? sth 
> like acdsee for windows?
> 
> i cannot try f-spot because my debian box cannot resolve some depencies.


gThumb image view under gnome is the most acdsee like...

# apt-get install gthumb

should do it!

All the best.

Raphael
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Sam Couter]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 3) cvs
> That's ... if you have more than 1 person working on the code.

... or even if you're working alone.

> As for programming languages I recommand:
> 
> C/C++ (gcc/g++)
> perl
> shell (script)

Java
Python
-- 
Sam "Eddie" Couter  |  mailto:[EMAIL PROTECTED]
Debian Developer|  mailto:[EMAIL PROTECTED]
|  jabber:[EMAIL PROTECTED]
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Jared Woodbridge]

> From: "Grant Parnell" <[EMAIL PROTECTED]>
> For starters what apps do you tend to use the most?
amaroK
Mozilla Firefox (1.5b ATM)
Kate
Konsole
Kopete
The GIMP
Kaffeine
Konqueror
Azureus
Quake 3  :-)

I do alot of stuff in a shell (on Konsole) including most file
management (Konqueror is mostly just for browsing files), but there is
no particular text based program I use alot.

--
breadcrust
Jared Woodbridge
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

QuantumG wrote:

> Erik de Castro Lopo wrote:
> 
> >You will notice that something like the Array.mapi function is
> >much less likely to contain errors than the C for loop.
> 
> What I noticed is that they invented syntax when they could have just as 
> easily have used C syntax.  Way to knife your language.

Nice troll or was it?

Actually, O'Caml is part of the ML family of languages Which is where
it gets its syntax. The ML languages date back to the 1970s at which 
time the C language was not yet even a teenager.

http://en.wikipedia.org/wiki/ML_programming_language

Python also invented its own syntax. Was that a bad thing?

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
Being really good at C++ is like being really good at using rocks to
sharpen sticks." -- Thant Tessman
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Erik de Castro Lopo wrote:


You will notice that something like the Array.mapi function is
much less likely to contain errors than the C for loop.
 


I can modify my C-program to remove that problem in the ff. So,
as to whether a C-program is more prone to error relies on the
manner and style of coding and not intrinsic to C-language. Don't
you think ?

#include 

int integer_array[] = {1,-2,3,-4,5,-6,-7,8,-9,32727000};
int *ptr, *past_end, *iptr;

int main(void)
{
ptr = &integer_array[0];
iptr = ptr; printf("\n\n");

past_end = integer_array + sizeof(integer_array)/sizeof(int);
while (ptr < past_end)
{
printf("integer_array[%d] = %d ",(ptr - iptr),*ptr);
ptr++;
putchar('\n');
}
return 0;
}

--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

O Plameras wrote:

> I can modify my C-program to remove that problem in the ff. So,
> as to whether a C-program is more prone to error relies on the
> manner and style of coding and not intrinsic to C-language. Don't
> you think ?

I don't think its specific to the C language, I think its intrinsic
to all looping operations in imperative programming.

All you've done is replace the for loop with a while loop. You are
still setting the start condition and the end condition for the 
looping operation. These are things the compiler (or rather the
language) expect you to do.

By contrast, the O'caml mapi function automatically figures out
the start and end conditions from what it knows about the array.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"Religion is a magic device for turning unanswerable questions into
unquestionable answers." -Art Gecko, Wombat Discord-1, 128649
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Erik de Castro Lopo wrote:


O Plameras wrote:

 


I can modify my C-program to remove that problem in the ff. So,
as to whether a C-program is more prone to error relies on the
manner and style of coding and not intrinsic to C-language. Don't
you think ?
   



I don't think its specific to the C language, I think its intrinsic
to all looping operations in imperative programming.

All you've done is replace the for loop with a while loop. You are
still setting the start condition and the end condition for the 
looping operation. These are things the compiler (or rather the

language) expect you to do.

 



In doing so I have a dramatic change in the way my program now behaves.

The problem with the for loop in the previous program is that every time
I change the size of my array I also need to change my for loop. In real
C-programs as we know this is where the problem lies, we change one
and not remembering to change the other.

In the modified program  the size of array may be modified at will and
there is no need to remembering and change the loop.  We may format
our array anywhere in the application and no need to change the loop.

This is where the power of C-pointer lies. If I am prepared and able,
as a programmer, to put good and compact pointer-arithmetic into my
programs  I'd  get  better and concise C-programs. It is in the ability
of the C-programmer. He has a fine-grained control as to what should
happen.


By contrast, the O'caml mapi function automatically figures out
the start and end conditions from what it knows about the array.

 



This is what the modified C-program does with the concised while loop.


Erik
 




--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[QuantumG]

Erik de Castro Lopo wrote:


Nice troll or was it?
 



read The End Of History And The Last Programming Language.

Best I can find for a web reference:
  
   
http://www.cs.iastate.edu/~leavens/ComS541Fall97/hw-pages/history/gabriel.html


Basically if your language is "new" and you don't have a C syntax, 
you're unnecessarily placing yourself outside of the mainstream.  It's a 
bitch, but it's just syntax, so why not make it intuitive to the vast 
majority of programmers (however unfortunate that may be).


Trent
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[QuantumG]

Erik de Castro Lopo wrote:


All you've done is replace the for loop with a while loop. You are
still setting the start condition and the end condition for the 
looping operation. These are things the compiler (or rather the

language) expect you to do.
 



In Io (a dynamically typed language) you'd do:

   array := List clone append(3, 2, -1, 4, 11, 1231232)
   array foreach(i, v, writeln("array[", i, "] = ", v))

and foreach tends to be defined for just about every data type so you 
get a lot of consistency.


But yes, you're right, the C language should have a foreach keyword.

Trent
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Luke Yelavich]

On Mon, Sep 26, 2005 at 03:57:25PM EST, Grant Parnell wrote:
> For starters what apps do you tend to use the most?

In no particular order:
links2 - web browsing.
mutt - email
nano - text/document editing.
pdftotext/html, catdoc etc - Utilities to convert PDF/word documents to 
text for reading
snownews - RSS newsfeed reader.
firefox - For when I need to brows graphical sites, and speech is not 
useful.
grip - Much more flexible wen it comes to file naming, as I use a custom 
written script to keep to my music archive layout and file names.
gnome-terminal - Whenever I am in GNOME and need something done quickly.
zinf - Play music on the console
Rhythmbox - My main music player.
xine - DVD watching.
-- 
Luke Yelavich
GPG key: 0xD06320CE 
 (http://www.themuso.com/themuso-gpg-key.txt)
Email & MSN: [EMAIL PROTECTED]
ICQ: 18444344


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Dave Kempe]

On Mon, Sep 26, 2005 at 03:57:25PM EST, Grant Parnell wrote:


For starters what apps do you tend to use the most?



It seems a sad state of linux on the desktop where nearly everyone has 
replied with what would be considered command-line apps. Or perhaps 
there was a joke there I missed. I totally understand the lovely feeling 
of power that wielding gcc as your mail client gives you, but really, 
for people who get their kicks from other things in life, mutt is not a 
desktop app :)


dave
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Benno]

On Wed Sep 28, 2005 at 09:01:00 +1000, Dave Kempe wrote:
>>On Mon, Sep 26, 2005 at 03:57:25PM EST, Grant Parnell wrote:
>>
>>>For starters what apps do you tend to use the most?
>
>
>It seems a sad state of linux on the desktop where nearly everyone has 
>replied with what would be considered command-line apps. Or perhaps 
>there was a joke there I missed. I totally understand the lovely feeling 
>of power that wielding gcc as your mail client gives you, but really, 
>for people who get their kicks from other things in life, mutt is not a 
>desktop app :)

But its an app I use on my desktop. I don't think its necessarily means its
a sad state of the GNU/Linux desktop, just that the people here find command
line tools more powerful.

Personally I find mutt a better email client than any other mail client on 
any other system. (Partially because it will use my favourite text editor,
not some half-arsed one.)

Oh, and I would really consider mutt command line, more a TUI (text user 
interface),
which is probably a step above interactive command driven interface like 
mail(1),
which is a step above some purely command line app (like cat).

Benno
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Robert Collins]

On Tue, 2005-09-27 at 18:25 +1000, Sam Couter wrote:
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > 3) cvs
> > That's ... if you have more than 1 person working on the code.
> 
> ... or even if you're working alone.

One can argue that CVS is only useful if you are working alone ;0

Rob

-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Matthew Hannigan]

On Tue, Sep 27, 2005 at 11:46:20PM +1000, O Plameras wrote:
> Erik de Castro Lopo wrote:
> 
> >You will notice that something like the Array.mapi function is
> >much less likely to contain errors than the C for loop.
> > 
> >
> I can modify my C-program to remove that problem in the ff. So,
> as to whether a C-program is more prone to error relies on the
> manner and style of coding and not intrinsic to C-language. Don't
> you think ?

It's still brittle; for instance look what happens if you
naively try to move printing to a function:

#include 


void p(int integer_array[])
{
int *ptr, *past_end, *iptr;

ptr = &integer_array[0];
iptr = ptr; printf("\n\n");

past_end = integer_array + sizeof(integer_array)/sizeof(int);
while (ptr < past_end)
{
printf("integer_array[%d] = %d ",(ptr - iptr),*ptr);
ptr++;
putchar('\n');
}
}

int main(void)
{
int some_integer_array[] = {1,-2,3,-4,5,-6,-7,8,-9,32727000};
p(some_integer_array);
}
$ make op-array
cc op-array.c   -o op-array
$ ./op-array


integer_array[0] = 1
$
OOPS!  -- sizeof gives the size of int*, not int[].

I'd give the C++ equivalant, but without static initializers for vectors,
(coming in the next standard!) it's a little too ugly :-)

Matt

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[David]

On Wed, Sep 28, 2005 at 09:09:38AM +1000, Benno wrote:
> On Wed Sep 28, 2005 at 09:01:00 +1000, Dave Kempe wrote:
> >>On Mon, Sep 26, 2005 at 03:57:25PM EST, Grant Parnell wrote:
> >>
> >>>For starters what apps do you tend to use the most?
> 
> Personally I find mutt a better email client than any other mail client on 
> any other system. (Partially because it will use my favourite text editor,
> not some half-arsed one.)
> 
> Oh, and I would really consider mutt command line, more a TUI (text user 
> interface),
> which is probably a step above interactive command driven interface like 
> mail(1),
> which is a step above some purely command line app (like cat).

I'm not quite so hard core as some sluggers, so I use a mixture. I'm 
teaching my wife (who does buckets of email every day) to do the same 
thing:

mutt for speed
squirrelmail for pictures, html, pdf, other gui crap, etc.

If they are doing low volumes, I can't imagine a punter using mutt. It's 
really hard to convince someone raised on gui that consoles are actually 
easier.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Bruce Badger]

On 9/28/05, David <[EMAIL PROTECTED]> wrote:
> If they are doing low volumes, I can't imagine a punter using mutt. It's
> really hard to convince someone raised on gui that consoles are actually
> easier.

Perhaps we could have a SLUG talk on mutt?

I've heard so many good things about mutt, so I'l like to give it a
try, but feel that I don't have the time to learn how to get going
with it.

So, a talk that covered:
o Running mutt for the very first time
o Configuring for IMAP ( and POP, and local mail file etc...)
o How to fetch & read mail
o efficient ways of searching mail
o how to send an email
o how to filter mail (e.g. I have Evolution move my mail around as it arrives)
o just *why* mutt is more efficient that a GUI mail tool
... and all the things that makes mutt cool! :-)

All the best,
Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[David]

On Wed, Sep 28, 2005 at 11:29:29AM +1000, Bruce Badger wrote:
> On 9/28/05, David <[EMAIL PROTECTED]> wrote:
> > If they are doing low volumes, I can't imagine a punter using mutt. It's
> > really hard to convince someone raised on gui that consoles are actually
> > easier.
> 
> Perhaps we could have a SLUG talk on mutt?
> 
> I've heard so many good things about mutt, so I'l like to give it a
> try, but feel that I don't have the time to learn how to get going
> with it.
 
>  just *why* mutt is more efficient that a GUI mail tool
> ... and all the things that makes mutt cool! :-)

One word: speed
Most functions done with single keystrokes.
As someone else said: use the text editor you choose, not the one foisted 
on you.

I'd  love a talk on mutt.. i know that I'm only using a fraction of it's 
tools.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Taryn East]

* David <[EMAIL PROTECTED]> spake thus:
> On Wed, Sep 28, 2005 at 11:29:29AM +1000, Bruce Badger wrote:
> > On 9/28/05, David <[EMAIL PROTECTED]> wrote:
> > > If they are doing low volumes, I can't imagine a punter using mutt. It's
> > > really hard to convince someone raised on gui that consoles are actually
> > > easier.
> > 
> > Perhaps we could have a SLUG talk on mutt?
> > 
> > I've heard so many good things about mutt, so I'l like to give it a
> > try, but feel that I don't have the time to learn how to get going
> > with it.
>  
> >  just *why* mutt is more efficient that a GUI mail tool
> > ... and all the things that makes mutt cool! :-)
> 
> One word: speed

I'd agree, but I'd add configurability. Though I'm sure there are GUI
mail clients out there that can be as highly configured as mutt - I
haven't found one (don't get me started on evolution). :P ;)

I also like it because I'm a vim person... 
I also read my email through ssh...

I think there's a lot of horses for courses involved too, but it's the
best I've come across and the most highly adaptable to my changing
needs.

> I'd  love a talk on mutt.. i know that I'm only using a fraction of it's 
> tools.

I'd agree there!

Cheers,
Taryn

-- 
This .sig temporarily out-of-order.
We apologise for any inconvenience
- The Management
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Mike MacCana]

On Wed, 2005-09-28 at 11:17 +1000, David wrote:

> mutt for speed
> squirrelmail for pictures, html, pdf, other gui crap, etc.

You might be interested in roundcube. OSS webmail like Squirrelmail,
except it doesn't look like arse.

http://www.roundcube.net/

Mike

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[James Polley]

On 9/28/05, Mike MacCana <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-09-28 at 11:17 +1000, David wrote:
>
> > mutt for speed
> > squirrelmail for pictures, html, pdf, other gui crap, etc.
>
> You might be interested in roundcube. OSS webmail like Squirrelmail,
> except it doesn't look like arse.
>
> http://www.roundcube.net/
>
> Mike

I use Mutt and squirrelmail too; strangely, aesthetical considerations
are low on my list of priorities. Given that David uses mutt, I
suspect they're similarly low on his list of priorities.. so looking
"like arse" doesn't give a damn as long as it's stable and does what
is needed.

Roundcube does look kinda purty.. but it's in alpha, and it uses
everyone's favorite toy database for some inexplicable reason. Why
does a webmail client need to use a database? If it really must, why
doesn't it use a real database?

Might suit your needs/wants... I'll stick with Squirrelmail for now
--
There is nothing more worthy of contempt than a man who quotes himself
- Zhasper, 2005
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[David]

On Wed, Sep 28, 2005 at 03:54:55PM +1000, Mike MacCana wrote:
> On Wed, 2005-09-28 at 11:17 +1000, David wrote:
> 
> > mutt for speed
> > squirrelmail for pictures, html, pdf, other gui crap, etc.
> 
> You might be interested in roundcube. OSS webmail like Squirrelmail,
> except it doesn't look like arse.
> 
> http://www.roundcube.net/
> 
> Mike


interesting.. but two questions

* If it uses a mysql backend, how nicely does it co-operate with mutt?
* did you use it to send this email? because if you did, it stripped the 
mailing list threading info ;-)

It does LOOK cuter than Squirrel, but I'm only interested if function 
comes before form!
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Sam Couter]

O Plameras <[EMAIL PROTECTED]> wrote:
> In doing so I have a dramatic change in the way my program now behaves.

No. A for loop is just a different way of expressing a while loop;
they're different syntax but identical in behaviour. Watch:

for (initialise; guard; increment) { body }

initialise; while (guard) { body; increment; }

Using a for loop or while loop, you've still explicity stated the
initial state (start of the array), the guard condition (not at the end
of the array yet) and the increment (next position in the array).

> In the modified program  the size of array may be modified at will and
> there is no need to remembering and change the loop.  We may format
> our array anywhere in the application and no need to change the loop.

Only works for static sized arrays, as has been demonstrated, and leads
to insidious hard to detect bugs when you change to dynamic arrays
because they're just pointers.

> This is where the power of C-pointer lies. If I am prepared and able,
> as a programmer, to put good and compact pointer-arithmetic into my
> programs  I'd  get  better and concise C-programs. It is in the ability
> of the C-programmer. He has a fine-grained control as to what should
> happen.

Humans make mistakes. Minimising the impact of the mistakes is a winning
strategy. Ignoring the fact that people make mistakes is a losing
strategy. Use C when you must, something smarter when you can.

Erik said:

> >By contrast, the O'caml mapi function automatically figures out
> >the start and end conditions from what it knows about the array.
> 
> This is what the modified C-program does with the concised while loop.

No it doesn't. You explicity told it the initial state and guard
condition, and also the increment operation. Any language with a foreach
construct will actually figure those out itself. C will not.
-- 
Sam "Eddie" Couter  |  mailto:[EMAIL PROTECTED]
Debian Developer|  mailto:[EMAIL PROTECTED]
|  jabber:[EMAIL PROTECTED]
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Angus Lees]

At Tue, 27 Sep 2005 14:12:54 +1000, Erik de Castro Lopo wrote:
> let integer_array = [| 1 ; -2 ; 3 ; -4 ; 5 ; -6 ;
> -7 ; 8 ; -9 ; 32727000 |] ;;
> 
> Array.mapi (fun i x
> -> Printf.printf "integer_array[%d] = %d\n" i x
> ) integer_array ;;

Hey, my first actual perl6 program:

 #!/usr/bin/pugs
 use v6;

 my @integer_array = <1 -2 3 -4 5 -6 -7 8 -9 32727000>;

 for 0 .. @integer_array - 1 {
   say "integer_array[$_] = @integer_array[$_]";
 }


-- 
 - Gus
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

Angus Lees wrote:

> At Tue, 27 Sep 2005 14:12:54 +1000, Erik de Castro Lopo wrote:
> > let integer_array = [| 1 ; -2 ; 3 ; -4 ; 5 ; -6 ;
> > -7 ; 8 ; -9 ; 32727000 |] ;;
> > 
> > Array.mapi (fun i x
> > -> Printf.printf "integer_array[%d] = %d\n" i x
> > ) integer_array ;;
> 
> Hey, my first actual perl6 program:
> 
>  #!/usr/bin/pugs
>  use v6;
> 
>  my @integer_array = <1 -2 3 -4 5 -6 -7 8 -9 32727000>;
> 
>  for 0 .. @integer_array - 1 {
>say "integer_array[$_] = @integer_array[$_]";
>  }

Oh, cool, a Perl person. Wait, that was another thread :-).

So, Gus, what happens when you do:

   for 1 .. @integer_array {
say "integer_array[$_] = @integer_array[$_]";
   }

O'caml's Array.mapi function and the foreach construct of a lot
of other languages make screwups like this impossible.

Even Python has a better version (although not as nice as O'Caml)
of this:

integer_array = [ 1, -2, 3, -4, 5, -6, -7, 8, -9, 32727000]

for k in range (len (integer_array)):
print "integer [%d] = %d" % (k, integer_array [k])


Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"O'Caml ... a "language designed for smart people" if there 
ever was one." -- Mike Vanier
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Andrew Bennetts]

On Thu, Sep 29, 2005 at 05:17:21PM +1000, Erik de Castro Lopo wrote:
[...]
> 
> Even Python has a better version (although not as nice as O'Caml)
> of this:
> 
> integer_array = [ 1, -2, 3, -4, 5, -6, -7, 8, -9, 32727000]
> 
> for k in range (len (integer_array)):
> print "integer [%d] = %d" % (k, integer_array [k])

Python can be nicer than that:

integer_array = [1, -2, 3, -4, 5, -6, -7, 8, -9, 32727000]

for index, value in enumerate(integer_array):
print "integer [%d] = %d" % (index, value)

You could also use the map function (or something similar from the itertools
module) if you really want, but it's a bit more awkward and doesn't really
enhance readability or correctness at all in this case.

-Andrew.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Sam Couter wrote:


O Plameras <[EMAIL PROTECTED]> wrote:
 


In doing so I have a dramatic change in the way my program now behaves.
   



No. A for loop is just a different way of expressing a while loop;
they're different syntax but identical in behaviour. Watch:

 

Yes I have changed the behavior of the original C program, if you 
consider this,


If I changed this:
From, int integer_array[] = {1,-2,3,-4,5,-6,-7,8,-9,32727000}; 
To,  int integer_array[] = {1,-2,3};


I must also change this,
From, for (i = 0; i < 10; i++) {...}
To, for (i = 0; i < 3; i++) {...}

to make the program work.

In my modified program, if I changed this,
From, int integer_array[] = {1,-2,3,-4,5,-6,-7,8,-9,32727000}; 
To,  int integer_array[] = {1,-2,3};


Don't have to change this,
past_end = integer_array + sizeof(integer_array)/sizeof(int);
while (ptr < past_end) {...}

to make the program work.

If this is not a change in behavior, what is ?

What I'm also trying to point out is that C is better with
pointer-arithmetic which many languages do not have including
O'Caml.


for (initialise; guard; increment) { body }

initialise; while (guard) { body; increment; }

 



Any programmer or computer person ( experienced or novice) knows this. 


Using a for loop or while loop, you've still explicity stated the
initial state (start of the array), the guard condition (not at the end
of the array yet) and the increment (next position in the array).

 

Yes, that's true I had to in my code. The point is I don't have to 
change my while-loop
each time I change my array size in my specific example. 


In the modified program  the size of array may be modified at will and
there is no need to remembering and change the loop.  We may format
our array anywhere in the application and no need to change the loop.
   



Only works for static sized arrays, as has been demonstrated, and leads
to insidious hard to detect bugs when you change to dynamic arrays
because they're just pointers.

 


That's what I have in my program.  I have specified a static array.

Show us a specific situation where  in that code  the modified program
will not work. 


This is where the power of C-pointer lies. If I am prepared and able,
as a programmer, to put good and compact pointer-arithmetic into my
programs  I'd  get  better and concise C-programs. It is in the ability
of the C-programmer. He has a fine-grained control as to what should
happen.
   



Humans make mistakes. Minimising the impact of the mistakes is a winning
strategy. Ignoring the fact that people make mistakes is a losing
strategy. Use C when you must, something smarter when you can.

 


Aha !  So, it's C language.

Good thing about C is that it has one of the least number of 
vocabularies  to learn and
master. 


Erik said:

 


By contrast, the O'caml mapi function automatically figures out
the start and end conditions from what it knows about the array.
 


This is what the modified C-program does with the concised while loop.
   



No it doesn't. You explicity told it the initial state and guard
condition, and also the increment operation. Any language with a foreach
construct will actually figure those out itself. C will not.
 

I've explained this previously. 


--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Bruce Badger]

On 9/29/05, Andrew Bennetts <[EMAIL PROTECTED]> wrote:
> Python can be nicer than that:
>
> integer_array = [1, -2, 3, -4, 5, -6, -7, 8, -9, 32727000]
>
> for index, value in enumerate(integer_array):
> print "integer [%d] = %d" % (index, value)

So can Smalltalk! :-)

integerArray :=  #(1 -2 3 -4 5 -6 -7 8 -9 32727000 9876543210).
integerArray doWithIndex: [:element :index|
Transcript show: 'integer [', index printString, '] = ', element
printString; cr]

(can you other guys handle the big number I added at the end OK?)

Of course, beauty is in the eye of the beholder.

All the best,
  Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Andrew Bennetts]

On Thu, Sep 29, 2005 at 06:52:29PM +1000, Bruce Badger wrote:
[...]
> integerArray :=  #(1 -2 3 -4 5 -6 -7 8 -9 32727000 9876543210).
[...]
> 
> (can you other guys handle the big number I added at the end OK?)

Python handles it and other arbitrary length integers with no trouble.

-Andrew.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Bruce Badger wrote:


On 9/29/05, Andrew Bennetts <[EMAIL PROTECTED]> wrote:
 


Python can be nicer than that:

   integer_array = [1, -2, 3, -4, 5, -6, -7, 8, -9, 32727000]

   for index, value in enumerate(integer_array):
   print "integer [%d] = %d" % (index, value)
   



So can Smalltalk! :-)

integerArray :=  #(1 -2 3 -4 5 -6 -7 8 -9 32727000 9876543210).
 



On my Computer which is a 32-bit,  my C compiler is able to handle Integer
size 4 bytes = 32 bits. So 2 exponent 32 less 1 is 2147483647. This is 
the max

that my computer can handle. Can't handle your number  9876543210.

With C on 64-bit your number will not be a problem as an integer. C integer
is size 8 bytes = 64 bits. So 2 exponent 64 less 1 can be handled.

Is your computer 64-bit or does smalltalk handles wider size integers ?



integerArray doWithIndex: [:element :index|
Transcript show: 'integer [', index printString, '] = ', element
printString; cr]

(can you other guys handle the big number I added at the end OK?)

Of course, beauty is in the eye of the beholder.

All the best,
 Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/
 




--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Bruce Badger]

On 9/29/05, O Plameras <[EMAIL PROTECTED]> wrote:
> Bruce Badger wrote:
> >integerArray :=  #(1 -2 3 -4 5 -6 -7 8 -9 32727000 9876543210).
> On my Computer which is a 32-bit,  my C compiler is able to handle Integer
> size 4 bytes = 32 bits. So 2 exponent 32 less 1 is 2147483647. This is
> the max
> that my computer can handle. Can't handle your number  9876543210.
>
> With C on 64-bit your number will not be a problem as an integer. C integer
> is size 8 bytes = 64 bits. So 2 exponent 64 less 1 can be handled.
>
> Is your computer 64-bit or does smalltalk handles wider size integers ?

Smalltalk can handle integers of an arbitrary size, limited only by
the physical resources of the machine (e.g. RAM).

e.g.  The following are Smalltalk expressions with results on the
following line:

2 ** 64
18446744073709551616

2 ** 128
340282366920938463463374607431768211456

2 ** 256
115792089237316195423570985008687907853269984665640564039457584007913129639936

It sounds like Python can do this too.  As can Ruby (I just checked).

All the best,
 Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Ian Wienand]

On Thu, Sep 29, 2005 at 07:39:51PM +1000, O Plameras wrote:
> With C on 64-bit your number will not be a problem as an integer. C
> integer is size 8 bytes = 64 bits. So 2 exponent 64 less 1 can be
> handled.

This isn't correct; there are two main models for 64 bit computing.
LP64 where longs and pointers are 64 bits (Linux, most UNIX?) and the
Windows model where only pointers are 64 bits.  Many might suggest
this is because so much Windows code would break if long suddenly
became 64 bits, but I think the official reason is efficiency within
the API.

In both cases an int is 32 bits.  In both models a long long will be
64 bits, no matter what your architecture.  It's no wonder people use
Python/Perl/OCaml/Haskell/Smalltalk so they don't have to worry about
any of this.

-i
[EMAIL PROTECTED]
http://www.gelato.unsw.edu.au


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Ian Wienand wrote:


On Thu, Sep 29, 2005 at 07:39:51PM +1000, O Plameras wrote:
 


With C on 64-bit your number will not be a problem as an integer. C
integer is size 8 bytes = 64 bits. So 2 exponent 64 less 1 can be
handled.
   



 



This should be 8 bytes = 64 bits.
So 2 exponent (64-1) - 1 = max int size in 64 bit machine.


This isn't correct; there are two main models for 64 bit computing.
LP64 where longs and pointers are 64 bits (Linux, most UNIX?) and the
Windows model where only pointers are 64 bits.  Many might suggest
this is because so much Windows code would break if long suddenly
became 64 bits, but I think the official reason is efficiency within
the API.

 


I don't have 64-bit I have 32-bit.

I use this code to check:

[EMAIL PROTECTED] cp]# cat sizeof.c

#include 

int main(void)
{
   printf("size of a char is %d\n", sizeof(char));
   printf("size of a short is %d\n", sizeof(short));
   printf("size of a int is %d\n", sizeof(int));
   printf("size of a long is %d\n", sizeof(long));
   printf("size of a float is %d\n", sizeof(float));
   printf("size of a double is %d\n", sizeof(double));
   return 0;
}
[EMAIL PROTECTED] cp]# make sizeof
cc sizeof.c   -o sizeof

[EMAIL PROTECTED] cp]# ./sizeof
size of a char is 1
size of a short is 2
size of a int is 4
size of a long is 4
size of a float is 4
size of a double is 8
[EMAIL PROTECTED] cp]#   


I have a 32-bit PC.


In both cases an int is 32 bits.  In both models a long long will be
64 bits, no matter what your architecture.  It's no wonder people use
Python/Perl/OCaml/Haskell/Smalltalk so they don't have to worry about
any of this.

-i
[EMAIL PROTECTED]
http://www.gelato.unsw.edu.au
 




--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Ian Wienand]

On Thu, Sep 29, 2005 at 09:42:41PM +1000, O Plameras wrote:
> This should be 8 bytes = 64 bits.
> So 2 exponent (64-1) - 1 = max int size in 64 bit machine.

I think you missed my point.  An int is still only 32 bits on a 64 bit
machine.  On a 64 bit machine running Linux a long will be 64 bits,
however on Windows a long is always 32 bits.

-i


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

Ian Wienand wrote:

> It's no wonder people use
> Python/Perl/OCaml/Haskell/Smalltalk so they don't have to worry about
> any of this.

Indeed!!

I've been spending ***way*** too much time in the day job fiddling
around with fscking linked lists in C, knowing all along that doing
it in O'caml would have been trivial and fun. In C its such a PITA.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"I believe C++ instills fear in programmers, fear that the 
interaction of some details causes unpredictable results. Its 
unmanageable complexity has spawned more fear-preventing tools 
than any other language, but the solution _should_ have been 
to create and use a language that does not overload the 
whole goddamn human brain with irrelevant details."
-- Erik Naggum
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Does anybody have a 64-bit computer ?

Are you able to compile and run the following code  and publish the 
results ?


Thanks.

#include 

int main(void)
{
  printf("size of a char is %d\n", sizeof(char));
  printf("size of a short is %d\n", sizeof(short));
  printf("size of a int is %d\n", sizeof(int));
  printf("size of a long is %d\n", sizeof(long));
  printf("size of a float is %d\n", sizeof(float));
  printf("size of a double is %d\n", sizeof(double));
  return 0;
}


Ian Wienand wrote:


On Thu, Sep 29, 2005 at 07:39:51PM +1000, O Plameras wrote:
 


With C on 64-bit your number will not be a problem as an integer. C
integer is size 8 bytes = 64 bits. So 2 exponent 64 less 1 can be
handled.
   



This isn't correct; there are two main models for 64 bit computing.
LP64 where longs and pointers are 64 bits (Linux, most UNIX?) and the
Windows model where only pointers are 64 bits.  Many might suggest
this is because so much Windows code would break if long suddenly
became 64 bits, but I think the official reason is efficiency within
the API.

In both cases an int is 32 bits.  In both models a long long will be
64 bits, no matter what your architecture.  It's no wonder people use
Python/Perl/OCaml/Haskell/Smalltalk so they don't have to worry about
any of this.

-i
[EMAIL PROTECTED]
http://www.gelato.unsw.edu.au
 





--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Ian Wienand wrote:


On Thu, Sep 29, 2005 at 09:42:41PM +1000, O Plameras wrote:
 


This should be 8 bytes = 64 bits.
So 2 exponent (64-1) - 1 = max int size in 64 bit machine.
   



I think you missed my point.  An int is still only 32 bits on a 64 bit
machine.  On a 64 bit machine running Linux a long will be 64 bits,
however on Windows a long is always 32 bits.

-i
 



I am now not sure because I don't have a 64-bit machine.

It is easy to check if one has a 64-bit machine.  I'm curious to know.

I learned that on 16-bit machine, int is size = 2
  32-bit machine, int is size =4
  64-bit machine, int is size =8.

I have just confirm and publish the results for 32-bit machine Is
4 bytes=32-bits, so
2 exponent (32-1) - 1 = max integer size.

--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

O Plameras wrote:

> 
> Does anybody have a 64-bit computer ?
> 
> Are you able to compile and run the following code  and publish the 
> results ?

I tested an example almost identical to this (also tested sizeof (void*))
and it was published in the book I co-authored:

http://www.amazon.com/exec/obidos/ASIN/0672315971/103-7229015-2079814

In those tests, sizeof(int) was 4 on 64 bit Linux systems. It hasn't changed
since.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"... there's something really scary about a language (C++) where
copying state from one object to another is this complicated"
-- Richard Gillam
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Ian Wienand]

On Thu, Sep 29, 2005 at 09:59:26PM +1000, O Plameras wrote:
> It is easy to check if one has a 64-bit machine.  I'm curious to
> know.

Have a look at the AMD64 ABI, for example

http://www.x86-64.org/documentation/abi.pdf

Figure 3.1 gives you the size of types.

-i


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Jeff Waugh]

> I've been spending ***way*** too much time in the day job fiddling around
> with fscking linked lists in C, knowing all along that doing it in O'caml
> would have been trivial and fun. In C its such a PITA.

If you coded in glib, you wouldn't have to worry about silly stuff like
that. :-)

- Jeff

-- 
EuroOSCON: October 17th-20thhttp://conferences.oreillynet.com/eurooscon/
 
   "Well, the English don't have any experience with terrorism..." - Fox
   News on London Blasts
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

Jeff Waugh wrote:

> 
> 
> > I've been spending ***way*** too much time in the day job fiddling around
> > with fscking linked lists in C, knowing all along that doing it in O'caml
> > would have been trivial and fun. In C its such a PITA.
> 
> If you coded in glib, you wouldn't have to worry about silly stuff like
> that. :-)

You know Python. You know there is a huge difference between Python/Perl/
O'caml etc lists and the braindamage that is linked list handling of C.
Glib does not bring C lists up to the level usability and safety of lists
in the languages mentioned.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"XML is not a language in the sense of a programming language any
more than sketches on a napkin are a language." -- Charles Simonyi
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Felix Sheldon]

[EMAIL PROTECTED] ~/Desktop $ gcc sizeof.c
[EMAIL PROTECTED] ~/Desktop $ ./a.out
size of a char is 1
size of a short is 2
size of a int is 4
size of a long is 8
size of a float is 4
size of a double is 8


O Plameras wrote:



Does anybody have a 64-bit computer ?

Are you able to compile and run the following code  and publish the 
results ?


Thanks.

#include 

int main(void)
{
  printf("size of a char is %d\n", sizeof(char));
  printf("size of a short is %d\n", sizeof(short));
  printf("size of a int is %d\n", sizeof(int));
  printf("size of a long is %d\n", sizeof(long));
  printf("size of a float is %d\n", sizeof(float));
  printf("size of a double is %d\n", sizeof(double));
  return 0;
}


Ian Wienand wrote:


On Thu, Sep 29, 2005 at 07:39:51PM +1000, O Plameras wrote:
 


With C on 64-bit your number will not be a problem as an integer. C
integer is size 8 bytes = 64 bits. So 2 exponent 64 less 1 can be
handled.
  



This isn't correct; there are two main models for 64 bit computing.
LP64 where longs and pointers are 64 bits (Linux, most UNIX?) and the
Windows model where only pointers are 64 bits.  Many might suggest
this is because so much Windows code would break if long suddenly
became 64 bits, but I think the official reason is efficiency within
the API.

In both cases an int is 32 bits.  In both models a long long will be
64 bits, no matter what your architecture.  It's no wonder people use
Python/Perl/OCaml/Haskell/Smalltalk so they don't have to worry about
any of this.

-i
[EMAIL PROTECTED]
http://www.gelato.unsw.edu.au
 







--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[telford]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Sep 27, 2005 at 10:23:16PM +1000, Erik de Castro Lopo wrote:
> QuantumG wrote:
> 
> > Erik de Castro Lopo wrote:
> > 
> > >You will notice that something like the Array.mapi function is
> > >much less likely to contain errors than the C for loop.
> > 
> > What I noticed is that they invented syntax when they could have just as 
> > easily have used C syntax.  Way to knife your language.
> 
> Nice troll or was it?
> 
> Actually, O'Caml is part of the ML family of languages Which is where
> it gets its syntax. The ML languages date back to the 1970s at which 
> time the C language was not yet even a teenager.

C itself started in 1972 which makes it quite comparable with ML,
however since we are tracing ancestors here:

  FORTRAN(1954)
  Algol 58   (1958)
  Algol 60   (1960)
  CPL(1964 ??)
  BCPL   (1967)
  B  (1970)
  C  (1972)

So the roots of C go back almost as far as electronic computers and
the language evolution was systematic and well considered at every stage.
Well, everything EXCEPT for the operator precedence which remains to
this very day, ALMOST annoying enough to fix.

If the ML designers were going to borrow syntax they only had a few
places to borrow from: FORTRAN, one of the Algol-like languages, LISP
or maybe APL. Borrowing from CPL or BCPL wouldn't have been entirely silly
even back then (although the smart money would have been on FORTRAN).


The thing about syntax is that people just can't be bothered learning
weird-syntax languages. Look at LISP for example, it's another really
old language (in computer terms) and it keeps trying to catch on but 
never will because the syntax annoys people and all the really cool ideas
of LISP have been absorbed into other languages by now. The thing that
LISP got wrong was 5000 years of humans using infix notation.

If you want another example, look at oaklisp (yes, go and search for it).
When you read the design documents you can't help realising, "hey, this is
actually Java," but oaklisp sat on the shelf being a great idea with no one
using it for about 10 years until Sun came along and reworked exactly the
same idea with a C-like syntax and suddenly it got popular.


In many ways, syntax means nothing because it really has nothing to do
with how a language works. On the other hand, syntax means everything
because that's what people first see when they look at the language and
that's what they have to stare at day in and day out. Think of a great
program with a crap user interface, that's what a language is with bad
syntax. Suppose I make a language where all numeric constants have to
be entered in base 9. There's nothing wrong with base 9, it's a 
perfectly valid form of numeric expression... but no one uses it.


- Tel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iQIVAwUBQzvcn8fOVl0KFTApAQL4yxAAgJ2W1W+Q6rL7hXmc+NpWbxIxEazK97cG
bX67a03NjMxYmQxZIVq6IIl3g1XPmkCXeSAkueUM+2G8sylIqeLRyT/tfXw1vsst
d4TTbPm52ZR4a31nJ4SITDcmuiTFN+wCMjmBHFMzWDp3drBq4EWn7hiltAn790oX
VZpqphlqquoquMdcgCTFC0ffcRf5DdNSNPIXS4Xt5CZwUeLxi3e0fhw4OWKF6RaL
D0npcq65hWVKaYvF/oqtXugOixIlmksRZa4kH3rl9TZbPhZgy385RjRG4SNb1Y5A
sdSbZ4qpURNFdRzwRouvSeuWTiPDh84u2JWR1PWYbdZkzDL66VR81emWtcYWeY8p
6FaxTDBnUoVrrpjWX5ADwKOXXmfdOD241umJcVqeWi10oU7foENXfEoygLti53SC
rQ0hy+ks1ao1udpa1bgWV+cZRU+CKhAFFTHpQ8yPiqj/e1xv+bROcVhBeLI6fass
neShBVvA9hM671ZJxTwx0ImvwO/FoWWiQ11+8/SiZZcsvoD/lw3l77w04QGWE4aV
2qd4Gb9zJLFo1WWk/wDfZnZDpHfG8YPPgBiEWyCulTqM3bdwkcAdj4wYvGZfu01N
RBsds1a8HDmd+c7O52V++Cs2qBKysyo3re9M7ArZdAqdZGOUuXghqHyQ5W+tT8dR
pLCiBVTOJfk=
=5SLL
-END PGP SIGNATURE-
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

[EMAIL PROTECTED] wrote:

> If the ML designers were going to borrow syntax they only had a few
> places to borrow from: FORTRAN, one of the Algol-like languages, LISP
> or maybe APL. Borrowing from CPL or BCPL wouldn't have been entirely silly
> even back then (although the smart money would have been on FORTRAN).

Well since O'Caml and ML are functional languages, I see LISP 
as a conceptual if not syntactic ancestor of O'caml and ML.

The syntactic ancestor of ML is mathematics (let x = ...) which 
dates back at least 2000 years.

> If you want another example, look at oaklisp (yes, go and search for it).
> When you read the design documents you can't help realising, "hey, this is
> actually Java," but oaklisp sat on the shelf being a great idea with no one
> using it for about 10 years until Sun came along and reworked exactly the
> same idea with a C-like syntax and suddenly it got popular.

The very existance and popularity of Python is a perfect counter
example.

However, yes, the O'caml syntax is weird for people who have only
programmed in C, C++, Java, and Perl.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"Projects promoting programming in natural language are intrinsically
doomed to fail." -- Edsger Dijkstra
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Felix Sheldon wrote:


[EMAIL PROTECTED] ~/Desktop $ gcc sizeof.c
[EMAIL PROTECTED] ~/Desktop $ ./a.out
size of a char is 1
size of a short is 2
size of a int is 4
size of a long is 8
size of a float is 4
size of a double is 8

Thanks for this. 


The only change from 32-bit to 64-bit machine as far as
data type sizes are concerned is 'long'. Changed from 4 to 8 bytes.
This resolves the argument comprehensively.

This means that there is going to be minimal improvements from
a 32-bit to 64-bit PCs. 


I had wanted to buy a 64-bit CPU, but with this I will defer.
I need to check that documentation re AMD64.

Thanks again.

O. Plameras
http://www.acay.com.au/~oscarp/tutor



--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

O Plameras wrote:

> The only change from 32-bit to 64-bit machine as far as
> data type sizes are concerned is 'long'.

E, sizeof (void*) and any other pointer is 8 on 64 bit 
systems and 4 on 32 bit systems. This is a very important
difference.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
C++: The power, elegance and simplicity of a hand grenade.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Robert Collins]

On Thu, 2005-09-29 at 22:40 +1000, O Plameras wrote:
...
> This means that there is going to be minimal improvements from
> a 32-bit to 64-bit PCs. 
> 
> I had wanted to buy a 64-bit CPU, but with this I will defer.
> I need to check that documentation re AMD64.


ROTFL.

You might want to check void * pointers too, oh, and as for
improvements, that depends on much more than simple data type sizess.

Rob

-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Ian Wienand]

On Thu, Sep 29, 2005 at 10:40:47PM +1000, O Plameras wrote:
> The only change from 32-bit to 64-bit machine as far as
> data type sizes are concerned is 'long'. Changed from 4 to 8 bytes.
> This resolves the argument comprehensively.
> 
> This means that there is going to be minimal improvements from
> a 32-bit to 64-bit PCs. 
> 
> I had wanted to buy a 64-bit CPU, but with this I will defer.
> I need to check that documentation re AMD64.

When thinking about why things are as they are, it's always good to
consider the alternative outcome.  Imagine if the size of int did
increase to 64 bits.  Firstly a lot of code would break.  That's a
bug, and would eventually be fixed after some initial pain.

Suddenly every int variable now takes up twice as much space, every
array of ints is twice as big.  This means binary sizes increase and,
more importantly, you waste a lot of your cache.

How often does a loop counter overflow a 32 bit variable?  To be sane
people would have to reduce the size of variables they know won't
overflow.  So maybe you could make a short a 32 bit variable on your
64 bit machine.  But now when people try to move their code between
machines might find their counter becomes 16 bits, which is much more
realistically overflowed.  Now programmers have to be concerned about
sizeof(int) and sizeof(short) to maintain portability.  It would be a
debacle.

64 bits is mostly about addressing; the times we need to cater for 64
bit variables that aren't addresses are limited.  I'd still consider
an AMD64; there are a number of architectural enhancements over x86.
Of course if you want a real 64 bit architecture, pick up an Itanium
from somewhere :)

-i


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Robert Collins wrote:


On Thu, 2005-09-29 at 22:40 +1000, O Plameras wrote:
...
 


This means that there is going to be minimal improvements from
a 32-bit to 64-bit PCs. 


I had wanted to buy a 64-bit CPU, but with this I will defer.
I need to check that documentation re AMD64.
   




ROTFL.

You might want to check void * pointers too, oh, and as for
improvements, that depends on much more than simple data type sizess.
 



I was anticipating 64-bit will give similar improvements in speed
from a 16-bit to 32-bit machine. I have a good idea of the change
in speed from 16-bit to 32-bit. It appears this is not going to be
the case with 16-bit to 32-bit.

The so-called 64-bit is really not 64-bit. The registers are still
32-bit, it appears without having gone through the arch-docs.

Yes, sizeof(void *) I've assumed to be correct between 32-bit and
64-bit machines. Thanks, just the same.

--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

O Plameras wrote:

> I was anticipating 64-bit will give similar improvements in speed
> from a 16-bit to 32-bit machine. I have a good idea of the change
> in speed from 16-bit to 32-bit. It appears this is not going to be
> the case with 16-bit to 32-bit.

Any speed up moving from 16 to 32 bits was due to clock speed, not
the number of bits in the registers.

> The so-called 64-bit is really not 64-bit. The registers are still
> 32-bit,

Sorry, thats wrong. The registers *ARE* 64 bit.

> it appears without having gone through the arch-docs.

I thoroughly recommend you do.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"To me C++ seems to be a language that has sacrificed orthogonality
and elegance for random expediency." -- Meilir Page-Jones
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Erik de Castro Lopo wrote:


O Plameras wrote:

 


I was anticipating 64-bit will give similar improvements in speed
from a 16-bit to 32-bit machine. I have a good idea of the change
in speed from 16-bit to 32-bit. It appears this is not going to be
the case with 16-bit to 32-bit.
   



Any speed up moving from 16 to 32 bits was due to clock speed, not
the number of bits in the registers.

 



The clock speed change is indicated by MegaHertz change and the 32-bit 
to 64-bit

change should really be a register architecture change.

Given two CPUs one 32-bit and another 64-bit with the same Megahertz or
clock speed, the 64-bit is significantly faster.


The so-called 64-bit is really not 64-bit. The registers are still
32-bit,
   



Sorry, thats wrong. The registers *ARE* 64 bit.

 


it appears without having gone through the arch-docs.
   



I thoroughly recommend you do.

Erik
 




--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Erik de Castro Lopo wrote:


O Plameras wrote:

 


I was anticipating 64-bit will give similar improvements in speed
from a 16-bit to 32-bit machine. I have a good idea of the change
in speed from 16-bit to 32-bit. It appears this is not going to be
the case with 16-bit to 32-bit.
   



Any speed up moving from 16 to 32 bits was due to clock speed, not
the number of bits in the registers.

 


The so-called 64-bit is really not 64-bit. The registers are still
32-bit,
   



Sorry, thats wrong. The registers *ARE* 64 bit.

 



So what is the reasoning why the int are still 4 bytes instead of 8 bytes ?

Can anyone clarify ?


it appears without having gone through the arch-docs.
   



I thoroughly recommend you do.

Erik
 




--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

O Plameras wrote:

> Given two CPUs one 32-bit and another 64-bit with the same Megahertz or
> clock speed, the 64-bit is significantly faster.

That is not right.

As you saw from the sizeof experiment, the only thing that changes
when going from 32 bits to 64 bits is sizeof(long) and sizeof (void*).

Given the same application compiled for the two architectures (and with 
everything else being equal), the 64 bit one will be slightly slower
because all pointers are 8 bytes in size as opposed to 4 bytes on 32
bit architectures. The larger pointer size on 64 bit systems means that
more memory to CPU bandwidth is chewed bu transferring the larger
pointers to the CPU.

Also remember than most high end 32 bit Pentium CPUs have had a 64
bit wide data bas for ages. This was done to maximize the bandwidth
from slow dram to the CPU caches.

Erik

PS : I'm on the list, You don't need to CC replies to me.
-- 
+---+
  Erik de Castro Lopo
+---+
"It has been discovered that C++ provides a remarkable facility
for concealing the trival details of a program -- such as where 
its bugs are." -- David Keppel
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

Please do not CC me on replies. I am subscribed to the list.


O Plameras wrote:

> So what is the reasoning why the int are still 4 bytes instead of 8 bytes ?
>
> Can anyone clarify ?

There are a whole bunch of things in programs where a 32 bit integer
is sufficient and 64 bits is complete overkill. The first example that
comes to mind is counters used in for loops, or array indexing. For
most of these cases, using a 32 bit integer will be faster than using
a 64 bit integer (mainly because of memory bandwidth when the register
is loaded from or stored to dram).

In addition, C is used for low level programming where the programmer
needs to be able to address 32 bit hardware registers. If int was 
32 bits, what would you use for accessing these registers.


Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"C++ is like jamming a helicopter inside a Miata and expecting 
some sort of improvement." -- Drew Olbrich
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Erik de Castro Lopo wrote:


Please do not CC me on replies. I am subscribed to the list.


O Plameras wrote:

 


So what is the reasoning why the int are still 4 bytes instead of 8 bytes ?

Can anyone clarify ?
   



There are a whole bunch of things in programs where a 32 bit integer
is sufficient and 64 bits is complete overkill. The first example that
comes to mind is counters used in for loops, or array indexing. For
most of these cases, using a 32 bit integer will be faster than using
a 64 bit integer (mainly because of memory bandwidth when the register
is loaded from or stored to dram).

In addition, C is used for low level programming where the programmer
needs to be able to address 32 bit hardware registers. If int was 
32 bits, what would you use for accessing these registers.
 



Many books in C programming teaches that 64-bit machines have 8 bytes 
int size,
at least the ones I gone through.  I have not gone through your book 
that you
co-authored. Did you or your book say anything about int sizes in 
relation to

machine architecture ? And what did you say there ? I'm curious ?

Thanks.

O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[telford]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Sep 29, 2005 at 09:59:26PM +1000, O Plameras wrote:

> I am now not sure because I don't have a 64-bit machine.
> 
> It is easy to check if one has a 64-bit machine.  I'm curious to know.

Actually, just checking one 64 bit machine would not be enough.
If you stick to Linux and gcc then you get fairly consistent results
but C is bigger than gcc (only slightly).

- Tel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iQIVAwUBQzxkV8fOVl0KFTApAQL4zQ/8DpoD+Qhq4hLNJI3Fax1y1cTxYdrUygBT
gXHCk0yLkXLjLMtzaYGNnRVV9Ob6JTCuGPP6llIBSSBhSWkusH+ruxKw4PtQgrOB
bumYztj2KYU+/nSDWQTLSrbu365mukGO3G8nGJHEJYjYUqVx3d2AB6LZC6+qpe6y
EsRNVOeOfz6kY674Ce9fFqIDoQ84Wgi4fhfZJM/WfPk951uWiGpFPK+dKJ5YPbaM
0J7IEPiCEg4PezVBPYsQpVWJd/eecZ/AP9Nnte6CkTxbDncUufBUV2uTpXj8Ivpa
ZgHmPUUsX7+kTfe8dBgubm69wZt/MLjQM4p+uKURMCbWtvOhtoXWrDQz6O3tCTvq
hvgM3Ox/z30AlXwMeU9YSat98StC7iaaCMJm9iBkmuVEBZ2LpO6SzHHHE88cLH7I
g/Y6afBPQ0ogYjslkZHhhOT9KphKTmdSCogjDJKcfe+HMoMuJ0Y+YdnB6vn8jZ7V
/ts1Efc3qbPUqKsxnR2WBRnrjKaEKab/TgPkRn3Z5Rb7/crkMLoqJ2WP8532GnTX
e+IzMtW2zakJCBq0yi33qGp8jrhRhMj8fFxe98z0wYRTuLQ55LgO5D6+e6ijzkZn
enDkxm7T+ajEOaDJWVVu9OjJhIYAXON4yPDoY/1w2WhsYm6T44DoKJWn22AqmBrH
jmrI8lyEL0w=
=4LgO
-END PGP SIGNATURE-
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[telford]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Sep 29, 2005 at 10:35:22PM +1000, Erik de Castro Lopo wrote:

> The very existance and popularity of Python is a perfect counter
> example.

Python only got popular because Europe was so very desperate to write
code in something that was not "made in the USA". Most of them don't
realise that Python borrows heavily from "S-plus" which was made in
the USA but better to let the sleeping dog stay sleeping.

- Tel

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iQIVAwUBQzxmMMfOVl0KFTApAQLUpA//dtLh4F8eK6h8RfFtcFfB7gVDcrPSvOvp
9Z7qLeFkfATYrwxtRN3GtuV8P9PtiaQQf4/+pgOdrkams12XwxeDX2EFsWh7R1zc
UbObe07X9MO7H/TGRtvSKYva5hJUG4Sw4wVwPUHR+Ft/P3ec4Em2XeKW55ScgLSY
2zgA0bDt9pEzdgI5rMezlNvM3tRhNKw6YrBrEtRf5zuqQW8/n4e54eVT96FybsjQ
0B9n4w8AqiZGabS1ffQPtLKB8EiVRVYzCS/jRbcREh+OdOcUmtYJU11IoZPuMNSH
yVS+Wjeu6gPjCpwudiuxS8q++GO7oYQOPCinOqR9wTqSK5t1qVTJ5YMltk8ibJE1
4iE9HCNQtDAsUGdst01moQjxlM7NFFYYc3GF0tNMdt2Q8ZBR9VaGvf+/nGB+Rpqk
F3xAocirwEyqiJyc3Mk4rX0/xixvQJ4TNzEGQXkWB7hQXKIpkyuRztwIhlXbTgPZ
N7l991ZC26fE4P8wNaKwM360glGy2hMVjDGddTg/swTYgoWlrLZvoGSJaPgQUvbg
j2SuKcJFYMoRzUtH5N0UYfqFbC1c3zhHqzEqEN4cEGddfEL7RyYTRD6/EaBbPjiY
YaCGdbEyilAwPZa3yNF0eKvxlK4OBOrxEVaRazE1dHOxGapQ7GjSDINVVC77h+xX
8PB8i/LgaB8=
=V3/J
-END PGP SIGNATURE-
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Ian Wienand]

On Fri, Sep 30, 2005 at 08:01:59AM +1000, [EMAIL PROTECTED] wrote:
> Actually, just checking one 64 bit machine would not be enough.
> If you stick to Linux and gcc then you get fairly consistent results
> but C is bigger than gcc (only slightly).

I'd suggest it is the other way around; gcc implements *much* more
than the C standard.  C99 says that the minimum size of an integer is
2 bytes, but anything bigger is OK.  The real reference is the
relevant ABI for the architecture/operating system combination.

-i


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[telford]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Sep 29, 2005 at 10:40:47PM +1000, O Plameras wrote:

> This means that there is going to be minimal improvements from
> a 32-bit to 64-bit PCs. 

Since all your pointers are now twice as large, any data structure
that uses linked lists (or trees) is now also twice as large.
Since memory chips are not any faster on 64 bit architectures,
most of your programs will run slower.

Thankfully, AMD supports 32 bit pointers by running in back-compatibility
mode so you can still have fast programs with small data structures.

- Tel

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iQIVAwUBQzxnDMfOVl0KFTApAQLntBAAgc4iY4JCvWZUUarvZutU7Lx75wDzdXzD
zV+kLgbK5E4jXbObMVDYmTv5S1cSgOleBl3X7ZxhvJc3M/h2N+9ufa/N5pFRqeWJ
w+tfOuu2xIwSc9VEgDL4KoLm/ZADm/xrqU//yTz3rTZDF0vFXf0yzhxG711vPxJc
zYQ3lws/7EKLICuPNHmbifZ0L+0rpPHW2yYETX8nPLN2ZmnBrJgvoK6y8CUR3A62
ovOiwsyS2+Y7vuxxx0Hax9YrdDgjOrNVLyqgyDZy5AtAXllX86LcjXcXIIy6fZ8b
GEVEK9I8ZcGGFU6ygPuvRPvHi576Jl0Pi5qUAoccOgEW4ZWOuVrvUS/CJ2kxhjkX
Rfy5spG7Ln6+1je0VqyzP8j1UgafrJqovOSbdGqtozvsUE//1cvQBofT1/ViyC2R
sUcWR6u1XCBb11n9lMJBpYRK2FPXWSw5dWYdTfbQnO/jcoTASwZuDcDyqZcD7x6H
633CSBalfZ3D58p6n8hj5SpDBg254Ul1C6CtaE1fKdTGTt08+vdS0dlGw8TosfNS
n5JAqt1MnDcyV0xo8W1YiRzf8050eIdGE+2y8zfuZme0arErjffoZaPktqb962cg
qZ1jHnkco9tkHQ14gSWMWwN7p6NsH9uU3lghR4m3hpu8vYpZuGI2Er+Kwq7rlfdh
e0AWt1/7M4g=
=bwvj
-END PGP SIGNATURE-
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[telford]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Sep 30, 2005 at 07:44:01AM +1000, Erik de Castro Lopo wrote:

> In addition, C is used for low level programming where the programmer
> needs to be able to address 32 bit hardware registers. If int was 
> 64 bits, what would you use for accessing these registers.
^ (corrected)

You would use int. You would also use a function to access the
hardware register and the function would contain whatever CPU magic
is required to access the register.

The hard problem is when you have a 32 bit number inside a structure
and the structure is packed so you have to access exactly that
particular number with bothering anything on either side. Nothing to
do with hardware registers. The structure could be out of a file,
off the network, or read from any device. O'caml programmers obviously
don't spend much time thinking about binary compatibility of data
transfer to other machines.

Oh yeah, I remember... file I/O is not a "functional" concept.

- Tel

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iQIVAwUBQzxpwMfOVl0KFTApAQI9BQ/+P05WcQJ3cTvSCkBGh93LAcI23DpIkgTc
DZbCCs7h9Y0G2KChma49SsGz5a+AakXD324+i10u0MiSWaJC3sR3hpnZigNAMZqL
UG85bgKXIc13DnWgsUaT9Ioaef7w1pAcqNTEU2RjoSw1TDSlE5KyxHP7Ko0RsKla
9A/VElDWt8uVo+eXP5rqSLNdaFi5QpkmgQRkWvsNlbBlghx8Rqz/DDMFt90IDg7W
5Y7ltyq8FEX+q9/TtJe9axl40fwofo+JykvEJhz4KGAW1/jNiGugwD/UBU92oOo6
CDbU4kXrfDTBqKR8ggUFbGH6C/dFuXSW3CW/UNzBxTmw8MY+ezrDDTsmB4XM+PY3
2bDdpDEWgihBPiwW/dMfCw1bZXjkkjAoPTAKYCwdS/uYg9TcPfF4tpylTisMLPnL
5YQw/87GPmO+5HyX0nlP8egVPqYoIFPfc/89NasqlHh8nIAashyOz1xUPWgHuleN
Qg88nPwiY/u2u0FoUPoRQlAM5cQQ3w2GOXIqQKtw3MFQee5pEw3UvDpQwrdwYblO
FAr9bM/Q76PAtykwJaMBUh7lnqWizrbJAVOtEdu7tr8NZbX9AytO36udL18M3DDa
him+hOy0z/QOiz16UUXuS5pYUk+lX1gCj8grsqoiYyKwMM5RuW0SxDZOoEEn8kLM
UOXOupu/zv4=
=ZpjW
-END PGP SIGNATURE-
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

[EMAIL PROTECTED] wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Sep 29, 2005 at 09:59:26PM +1000, O Plameras wrote:

 


I am now not sure because I don't have a 64-bit machine.

It is easy to check if one has a 64-bit machine.  I'm curious to know.
   



Actually, just checking one 64 bit machine would not be enough.
If you stick to Linux and gcc then you get fairly consistent results
but C is bigger than gcc (only slightly).

 



I take your point.

I am just surprised because many books in C programming teaches by starting
with int sizes. And the ones I've seen and C programming classes I sat 
says 16-bit

Machine = int 2; 32-bit Machine=int 4; and 64-bit Machine=int 8.

Sigh 

--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

O Plameras wrote:

> Many books in C programming teaches that 64-bit machines have 8 bytes 
> int size, at least the ones I gone through. 

I have never personally seen such a book.

> I have not gone through your book 
> that you
> co-authored. Did you or your book say anything about int sizes in 
> relation to
> machine architecture ? And what did you say there ? I'm curious ?

I wrote a program like your sizeof program (but including sizeof(void*))
and showed the output on a 32 bit x86 Linux machine and a 64 bit Alpha 
Linux machine. The sizes of all data types other than long and void*
were the same.

Erik
-- 
+---+
  Erik de Castro Lopo
+---+
"Always code as if the person who ends up maintaining your
code will be a violent psychopath who knows where you live."
-- Martin Golding
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Erik de Castro Lopo wrote:


O Plameras wrote:

 

Many books in C programming teaches that 64-bit machines have 8 bytes 
int size, at least the ones I gone through. 
   



I have never personally seen such a book.

 



What did you say about Basic Data Types in your book as it is essential
to know and differentiate between these types ? and as C is closely bound
to hardware architecture you must have said something about these data
types as it relates to 16-bit/32-bit/64-bit ?

I have not gone through your book 
that you
co-authored. Did you or your book say anything about int sizes in 
relation to

machine architecture ? And what did you say there ? I'm curious ?
   



I wrote a program like your sizeof program (but including sizeof(void*))
 



Well that's good idea.  I was writing for myself and I always assume the 
pointer
must cover the whole range of possible addresses, 2 exp (32-1) - 1 in 
32-bit; and
2 exp (64-1) -1 in 64-bit. And so sizeof (void *) is sort of "understood 
you". But
we just learned the authors of C programming books as well as CPU 
manufacturers
don't necessarily agree with each other in terms of what they say and 
what they

make. We must check first-hand, no problem there.

And, also, in that case I should also include "sizeof(unsigned)" which 
in C programming
is usually the same as sizeof(int). But we learned again that we must 
satisfy ourselves

first hand.

and showed the output on a 32 bit x86 Linux machine and a 64 bit Alpha 
Linux machine. The sizes of all data types other than long and void*

were the same.

Erik
 




--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[James]

On Friday 30 September 2005 06:07, [EMAIL PROTECTED] wrote:
> > So what is the reasoning why the int are still 4 bytes instead of 8 bytes
> > ?
> >
> > Can anyone clarify ?
>
> There are a whole bunch of things in programs where a 32 bit integer
> is sufficient and 64 bits is complete overkill. The first example that
> comes to mind is counters used in for loops, or array indexing. For
> most of these cases, using a 32 bit integer will be faster than using
> a 64 bit integer (mainly because of memory bandwidth when the register
> is loaded from or stored to dram).
>
> In addition, C is used for low level programming where the programmer
> needs to be able to address 32 bit hardware registers. If int was
> 32 bits, what would you use for accessing these registers.

Everyone is missing the most important point!!! sizeof (int) is a compiler 
issue NOT a harware issue. It does not make good sense, but you can have 64 
bit ints on a Z80 (old 8 bit processor) or 16 bit ints on a 64 bit machine.

Having ints the same size as the hardware is a GoodThing (tm).

tick-tock-tick-tock-bing! 64 bit ints are touted as being an easier fix than 
re-org'ing the epoch, so 64bit ints WILL happen and 64bit machines are better 
equipped to handle this

   Explains: in 2039 the clock (32 bit) will overflow. This is Y2K bug with a 
 vengance and a certainty.

Will 64 bit ints waste the cache. This is deep dark art, but I believe NOT:
cache is for speed. speed = 1 access to get the data so ...
c...a char in cache
ss..a short in cache
a 32int in cache
a 64int in cache

you still use 1 cache per item, but the cache is 64bit wide

intel lets you:

[address 0] .. ii ii .. .. .. .. ..

most other architectures insist

[address 0] ii ii .. .. .. .. .. ..

or even worse

[address 0] ii ii .. .. ll ll ll ll  wasting the two .. locations. 

There are gcc options (alignment) to tell gcc to do this (much more efficient 
at cost of wasted space) but thought experiments don't work to explain if 
youc can/can't/should.

You can even have compilers that generate 32bit ints and 64bit ints on the 
same machine at the same time (carefull with the libraries)

James
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[James]

On Friday 30 September 2005 06:07, [EMAIL PROTECTED] wrote:
> > This means that there is going to be minimal improvements from
> > a 32-bit to 64-bit PCs.
>
> Since all your pointers are now twice as large, any data structure
> that uses linked lists (or trees) is now also twice as large.
> Since memory chips are not any faster on 64 bit architectures,
> most of your programs will run slower.
>
> Thankfully, AMD supports 32 bit pointers by running in back-compatibility
> mode so you can still have fast programs with small data structures.

My previous posting about thought experiments applies. This is not true.
In general a 64bit processor will get 2x as much data per time unit as a 32bit
processor and it will be faster as a result
James
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Angus Lees]

At Thu, 29 Sep 2005 17:17:21 +1000, Erik de Castro Lopo wrote:
>for 1 .. @integer_array {
> say "integer_array[$_] = @integer_array[$_]";
>}

Yeah sorry.  Did I mention it was my first ever perl6 program?

Try this version, note the iterator, the typed array (compile-time
checked/optimised) and the bigint.

 #!/usr/bin/pugs
 use v6;

 my int @integer_array = (1, -2, 3, -4, 5, -6, -7, 8, -9,
  32727000, 9876543210);

 for @integer_array.kv -> ($i, $value) {
   say "integer_array[$i] = $value";
 }

-- 
 - Gus
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Matthew Hannigan]

On Fri, Sep 30, 2005 at 10:09:40AM +1000, O Plameras wrote:
>   and as C is closely bound
> to hardware architecture you must have said something about these data

Actually, C is not necessarily that closely bound to hardware architecture.

The following quote is from wikipedia
(http://en.wikipedia.org/wiki/C_variable_types_and_declarations#Size)

"There is some confusion in novice C programmers as to how
big these types are. The standard is specifically vague
in this area:

* A short int must not be larger than an int.
* An int must not be larger than a long int.
* A short int must be at least 16 bits long.
* A long int must be at least 32 bits long.

The standard does not require that any of these sizes are
necessarily different. It is perfectly valid, for example,
that all 3 types be 64 bits long."


--
Matt
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Sam Couter]

O Plameras <[EMAIL PROTECTED]> wrote:
> And, also, in that case I should also include "sizeof(unsigned)" which 
> in C programming
> is usually the same as sizeof(int). But we learned again that we must 
> satisfy ourselves
> first hand.

if (sizeof(unsigned) != sizeof(int)) printf("Buggy compiler!\n");

"unsigned" really means "unsigned int" which is always exactly the same
size as int (obviously).
-- 
Sam "Eddie" Couter  |  mailto:[EMAIL PROTECTED]
Debian Developer|  mailto:[EMAIL PROTECTED]
|  jabber:[EMAIL PROTECTED]
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[telford]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Sep 30, 2005 at 10:13:34AM +0800, James wrote:

> tick-tock-tick-tock-bing! 64 bit ints are touted as being an easier fix than 
> re-org'ing the epoch, so 64bit ints WILL happen and 64bit machines are better 
> equipped to handle this
> 
>Explains: in 2039 the clock (32 bit) will overflow. This is Y2K bug with a 
>  vengance and a certainty.

Not everyone codes so that time_t is equivalent to int so there's nothing
wrong with time_t being a long (and fix the code that can't handle it).

Furthermore, most people don't hard-code the epoch calculations anyhow;
they just use a library routine. The epoch could move without much breaking.

Finally, by far the most common usage of the unix clock is to subtract
two time_t in order to get a time delta and this will still work correctly
even when you overflow the register (the magic of 2's compliment).

> Will 64 bit ints waste the cache. This is deep dark art, but I believe NOT:
> cache is for speed. speed = 1 access to get the data so ...
> c...  a char in cache
> ss..  a short in cache
>   a 32int in cache
>   a 64int in cache

I believe that intel already uses larger chunks in cache than that.
The Xeon uses 64 byte chunks for L1 cache and 128 byte chunks for L2 & L3
cache. I'm not an expert on caching algorithms but my understanding
is that reading any part of the chunk will still read from the same
cache entry. Any cache system which forces you to keep multiple copies
of the same data on the same chip is going to be very inefficient.
Cache memory costs a lot in terms of space on the silicon and power
consumption, you really want to make that space count.

Then again, not all programs will have their data conveniently small
so that it fits in cache. Sometimes people want to work with decently
large hash tables.

And to cap off, there are cases where you are going to invalidate your
cache and need a reload... it ain't pretty but it happens sometimes.
Small data is fast data.

- Tel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQIVAwUBQz/S68fOVl0KFTApAQIVvw/+NDemLGW3hfOMlsE8rjFa/aTzRJxpx7FH
OJaqZAK3oAJwT3WIW9SJiEklLo/vmi0H8W5SSZPUxAJogVyxN8AaQ1n0r2M8vs5z
A0ckg4mIOrOOUBJj0Jf8HQhWtrklIZWrMJ9GapnAniwoSYfLT6D2zuusutVCNWH5
TakIZiA6AcSx8pD758p4iSfZ5VTDVhXCwTomfzbF39oCaC++e8BLO5xyZRnqEYv4
oFm+xNmCssLM9p/Syhe7f08aYd0IVBsTwZBVTSd81F5UzQ5DOfDm+uDh62t3/Tm4
KIrz10+gyMTLzDxFZCVXtg366OYps20tBKxPGF8VKPNGuZHO7wlQUrjFjLoOdCXN
d1nUqUFreHQsQ9ftsWHa78vOBYhoogJ8wo7k00+6X4IQPFVYYCclyMIk33y7yCsw
ZdIidjEE8U5GYbGzp9oN9QUafkex+5HEB47NMWzexsUEZDvcSLDjJPiVhkug9HSz
vltldirhoa0wnyGME+wSWr1tIj/a0+RT+0TW0lGVfJM4XeICv1adR6EQPhxEB1E+
x1Qp9z2AbYj8HUIqZF3/9pGcvfmiNeXr1JVqH5gf+WVqfuuxw0nwZlfgW14Q+7o1
SsnIlbluMoD8BS0Pw0xWjpUqx67WA2ReJ3dcst4A4rZ2zNJmR1bc3OvRHb8aj3u+
JO3WF0f8xZA=
=Ri52
-END PGP SIGNATURE-
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Christopher JS Vance]

On Sun, Oct 02, 2005 at 10:30:36PM +1000, [EMAIL PROTECTED] wrote:

Not everyone codes so that time_t is equivalent to int so there's nothing
wrong with time_t being a long (and fix the code that can't handle it).


Of course not.  The synopsis for time(2) on v7 Unix says

| long time(0)
|
| long time(tloc)
| long *tloc;

precisely because int was 16 bits, and therefore not long enough.

Mind you, time_t wasn't even a sparkle in anybody's eyes then...

--
Christopher Vance
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Peter Chubb]

Aren't there any emacs users on this list?  my top ten are:

Xemacs (editing)
Xemacs (mail reading/writing)
Xemacs (web browsing)
Xemacs (compiling, with make, distcc and ccache underneath)
Xemacs (remote editing, with tramp)
Xemacs (teminal window for other command line apps)
Xemacs (games!)
Xemacs (picture previewing)
Xemacs (session multiplexing)
Oh, and Xemacs's web browser sucks, so Mozilla-firefox for that...

Peter C

-- 
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Alan L Tyree]

On Fri, 7 Oct 2005 19:33:29 +1000
Peter Chubb <[EMAIL PROTECTED]> wrote:

> 
> Aren't there any emacs users on this list?  my top ten are:
> 
> Xemacs (editing)
> Xemacs (mail reading/writing)
> Xemacs (web browsing)
> Xemacs (compiling, with make, distcc and ccache underneath)
> Xemacs (remote editing, with tramp)
> Xemacs (teminal window for other command line apps)
> Xemacs (games!)
> Xemacs (picture previewing)
> Xemacs (session multiplexing)
> Oh, and Xemacs's web browser sucks, so Mozilla-firefox for that...

Yea!! Go Emacs!!

My top favourite: emacs + reftec + auctec

Must give Xemacs a run.
Cheers,
Alan


> 
> Peter C
> 
> -- 
> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT
> gelato.unsw.edu.au The technical we do immediately,  the political
> takes *forever* -- 
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
> 


-- 
Alan L Tyreehttp://www2.austlii.edu.au/~alan
Tel: +61 2 4782 2670Mobile: +61 428 148 071
Fax: +61 2 4782 7092FWD: 615662
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Angus Lees]

At Fri, 7 Oct 2005 19:33:29 +1000, Peter Chubb wrote:
> Aren't there any emacs users on this list?  my top ten are:
> 
> Xemacs (editing)
> Xemacs (mail reading/writing)
> Xemacs (web browsing)
> Xemacs (compiling, with make, distcc and ccache underneath)
> Xemacs (remote editing, with tramp)
> Xemacs (teminal window for other command line apps)
> Xemacs (games!)
> Xemacs (picture previewing)
> Xemacs (session multiplexing)
> Oh, and Xemacs's web browser sucks, so Mozilla-firefox for that...

Amen!

.. and IRC client, scientific calculator, dictionary client, address
book, wiki, appointment reminder, daily planner, music player, LDAP
gui, etc

Oh, and it all works in either text or graphical interfaces and most
of it runs just fine on win32 or mac OSX.

-- 
 - Gus
   M-x all-hail-xemacs
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Alan L Tyree]

On Sat, 08 Oct 2005 23:30:02 -0700
Angus Lees <[EMAIL PROTECTED]> wrote:

> At Fri, 7 Oct 2005 19:33:29 +1000, Peter Chubb wrote:
> > Aren't there any emacs users on this list?  my top ten are:
> > 
> > Xemacs (editing)
> > Xemacs (mail reading/writing)
> > Xemacs (web browsing)
> > Xemacs (compiling, with make, distcc and ccache underneath)
> > Xemacs (remote editing, with tramp)
> > Xemacs (teminal window for other command line apps)
> > Xemacs (games!)
> > Xemacs (picture previewing)
> > Xemacs (session multiplexing)
> > Oh, and Xemacs's web browser sucks, so Mozilla-firefox for that...
> 
> Amen!
> 
> .. and IRC client, scientific calculator, dictionary client, address
> book, wiki, appointment reminder, daily planner, music player, LDAP
> gui, etc
> 
> Oh, and it all works in either text or graphical interfaces and most
> of it runs just fine on win32 or mac OSX.

I've never tried Xemacs - are there any traps for young players when
installing both?

Thanks,
Alan


> 
> -- 
>  - Gus
>M-x all-hail-xemacs
> -- 
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
> 


-- 
Alan L Tyreehttp://www2.austlii.edu.au/~alan
Tel: +61 2 4782 2670Mobile: +61 428 148 071
Fax: +61 2 4782 7092FWD: 615662
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Erik de Castro Lopo]

Peter Chubb wrote:

> 
> Aren't there any emacs users on this list?  my top ten are:
> 
> Xemacs (mail reading/writing)
> Xemacs (web browsing)
> Xemacs (compiling, with make, distcc and ccache underneath)
> Xemacs (remote editing, with tramp)
> Xemacs (teminal window for other command line apps)
> Xemacs (games!)
> Xemacs (picture previewing)
> Xemacs (session multiplexing)

I think emacs is a wonderful OS even if I don't use it myself. My
only complaint is that it doesn't have a decent text editor :-).

Erik

-- 
+---+
  Erik de Castro Lopo
+---+
"life is too long to be an expert at harmful things, including 
such evilness as C++ and perl." -- Erik Naggum
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Your top-ten linux desktop apps

[Angus Lees]

At Sun, 9 Oct 2005 16:46:46 +1000, Alan L Tyree wrote:
> I've never tried Xemacs - are there any traps for young players when
> installing both?

Not really.  Default values for some options are different between the
two, as are some elisp package versions and unusual keybindings (M-g
is one that springs to mind).  The way you enable/disable some
features (like global font-locking) is a little different, so a
complex .emacs probably won't work without modification.

Faces (fonts, etc) have a totally different implementation, which is
mostly hidden by the elisp functions.  XEmacs defaults to using
"zmacs" regions, where the region is only "active" until the next
command then it goes away (C-x C-x will get it back though).  The
XEmacs `vc-mode' is a fork of a much older version and can't have new
version control tools (like svn or tla) added in at run time.

XEmacs comes with gnuserv/gnuclient so you can attach to running
xemacs instances.  I believe this is only available as an addon to GNU
emacs, so it may change the way you use (x)emacs a bit.  Apparently
GNU emacs doesn't have the ability to know when one of its buffers is
obscured - the XEmacs `pop-to-buffer' is significantly better, which
has a subtle affect all over emacs.

-- 
 - Gus
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

WAS - Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Matthew Hannigan wrote:


On Fri, Sep 30, 2005 at 10:09:40AM +1000, O Plameras wrote:
 


 and as C is closely bound
to hardware architecture you must have said something about these data
   



Actually, C is not necessarily that closely bound to hardware architecture.

 

The the following C program illustrates the relationship of C and 
hardware architecture on
16-bit and 32-bit (Two different architectures).  We cannot use 32-bit 
and 64-bit (AMD) to
illustrate because the int size are the same in both. This is an 
aberration for AMD CPUs, I

think.

Many documentations says that a 64-bit should really have int size=8 
instead of 4


(see http://www.osdata.com/topic/language/asm/datarep.htm
-DEC VAX *16* *bit* [2 *byte*] *word*; 32 bit [4 *byte*] longword; 64 
bit [8 *byte*]quadword;

132 bit [16 *byte*] octaword; data may be unaligned at a speed penalty *...*
)

There are other documentations similar to the above assertions on the net.

But check the C-codes.

#include 
struct verify {
  char initials[2];
  int birthdate;
};
int main(void)
{
  struct verify holes;
  printf ("%d\n", sizeof(holes.initials[0]));
  printf ("%d\n", sizeof(holes.initials));
  printf ("%d\n", sizeof(holes.birthdate));
  printf ("%d\n", sizeof(holes));
  return 0;
}
Given that the word-byte
In 16-bit computer = 2 bytes word the output is,
1
2
2
4
in  32-bit computer = 4 bytes word the output is,
1
2
4
8

Two things are different due to computer architecture.
1. The same struct have different memory sizes allocated.
2. The struct has no hole in 16-bit and has 2-byte hole in 32-bit 
because C-compiler always

   align int data types beginning at the next word byte.


The following quote is from wikipedia
(http://en.wikipedia.org/wiki/C_variable_types_and_declarations#Size)

"There is some confusion in novice C programmers as to how
big these types are. The standard is specifically vague
in this area:

* A short int must not be larger than an int.
* An int must not be larger than a long int.
* A short int must be at least 16 bits long.
* A long int must be at least 32 bits long.

The standard does not require that any of these sizes are
necessarily different. It is perfectly valid, for example,
that all 3 types be 64 bits long."


--
Matt
 




--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: WAS - Re: [SLUG] Your top-ten linux desktop apps

[James]

On Sunday 02 October 2005 10:00, [EMAIL PROTECTED] wrote:
> >On Fri, Sep 30, 2005 at 10:09:40AM +1000, O Plameras wrote:
> >  
> >
> >>  and as C is closely bound
> >>to hardware architecture you must have said something about these data
> >>    
> >
> >Actually, C is not necessarily that closely bound to hardware
> > architecture.
> >
> >  
>
> The the following C program illustrates the relationship of C and
> hardware architecture on
> 16-bit and 32-bit (Two different architectures).  We cannot use 32-bit
> and 64-bit (AMD) to
> illustrate because the int size are the same in both. This is an
> aberration for AMD CPUs, I
> think.

NO IT DOES NOT
It shows how the compiler writer CHOOSE to implement. He'd be daft to NOT but 
she is not constrained, except by the basic rules (ints are not longer than 
longs etc)

Hence no abberation is present. Likewise the POSIX C does not mandate struture
alignment.

James
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: WAS - Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

James wrote:


On Sunday 02 October 2005 10:00, [EMAIL PROTECTED] wrote:
 






Likewise the POSIX C does not mandate struture
alignment.

 



The POSIX C stuff has nothing to do here with  the issue if you examine 
the post.


Read my post !

The statement was  that data type is closely bound to computer 
architecture.


Secondly, the alignment has been shown to start at the next word boundary.

You cannot dispute this on 32-bit PC (intel or AMD). If you do,  good 
luck to your programming.

---

O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: WAS - Re: [SLUG] Your top-ten linux desktop apps

[Benno]

On Sat Oct 01, 2005 at 18:23:40 +1000, O Plameras wrote:
>Matthew Hannigan wrote:
>
>>On Fri, Sep 30, 2005 at 10:09:40AM +1000, O Plameras wrote:
>> 
>>
>>> and as C is closely bound
>>>to hardware architecture you must have said something about these data
>>>   
>>>
>>
>>Actually, C is not necessarily that closely bound to hardware architecture.
>>
>> 
>>
>The the following C program illustrates the relationship of C and 
>hardware architecture on
>16-bit and 32-bit (Two different architectures).  We cannot use 32-bit 
>and 64-bit (AMD) to
>illustrate because the int size are the same in both. This is an 
>aberration for AMD CPUs, I
>think.
>
>Many documentations says that a 64-bit should really have int size=8 
>instead of 4
>
>(see http://www.osdata.com/topic/language/asm/datarep.htm
>-DEC VAX *16* *bit* [2 *byte*] *word*; 32 bit [4 *byte*] longword; 64 
>bit [8 *byte*]quadword;
>132 bit [16 *byte*] octaword; data may be unaligned at a speed penalty *...*
>)
>
>There are other documentations similar to the above assertions on the net.

It depends on the architecture ABI. As others have shown AMD64, Itanium, (and 
I'm
pretty sure power5) architectures use 32-bit ints. Otehr 64-bit architectures 
may choose differently.

>But check the C-codes.
>
>#include 
>struct verify {
>  char initials[2];
>  int birthdate;
>};
>int main(void)
>{
>  struct verify holes;
>  printf ("%d\n", sizeof(holes.initials[0]));
>  printf ("%d\n", sizeof(holes.initials));
>  printf ("%d\n", sizeof(holes.birthdate));
>  printf ("%d\n", sizeof(holes));
>  return 0;
>}
>Given that the word-byte
>In 16-bit computer = 2 bytes word the output is,
>1
>2
>2
>4
>in  32-bit computer = 4 bytes word the output is,
>1
>2
>4
>8
>
>Two things are different due to computer architecture.
>1. The same struct have different memory sizes allocated.

Yep.

>2. The struct has no hole in 16-bit and has 2-byte hole in 32-bit 
>because C-compiler always
>   align int data types beginning at the next word byte.

I don't think the C standard specifies how a struct should be layed out
in memory.

Matthew said is wasn't `necessarily' bound to the hardware. In practise you
are going to see different data type sizes on different bits of hardware.
But just because the hardware can store an 64-bit words, doesn't mean that
the ABI is going to specify an int to be 64-bit.

Benno
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: WAS - Re: [SLUG] Your top-ten linux desktop apps

[O Plameras]

Benno wrote:


On Sat Oct 01, 2005 at 18:23:40 +1000, O Plameras wrote:
 


Matthew Hannigan wrote:

   


On Fri, Sep 30, 2005 at 10:09:40AM +1000, O Plameras wrote:


 


 and as C is closely bound
to hardware architecture you must have said something about these data
 

   


Actually, C is not necessarily that closely bound to hardware architecture.



 

The the following C program illustrates the relationship of C and 
hardware architecture on
16-bit and 32-bit (Two different architectures).  We cannot use 32-bit 
and 64-bit (AMD) to
illustrate because the int size are the same in both. This is an 
aberration for AMD CPUs, I

think.

Many documentations says that a 64-bit should really have int size=8 
instead of 4


(see http://www.osdata.com/topic/language/asm/datarep.htm
-DEC VAX *16* *bit* [2 *byte*] *word*; 32 bit [4 *byte*] longword; 64 
bit [8 *byte*]quadword;

132 bit [16 *byte*] octaword; data may be unaligned at a speed penalty *...*
)

There are other documentations similar to the above assertions on the net.
   



It depends on the architecture ABI. As others have shown AMD64, Itanium, (and 
I'm
pretty sure power5) architectures use 32-bit ints. Otehr 64-bit architectures 
may choose differently.


 


But check the C-codes.

#include 
struct verify {
char initials[2];
int birthdate;
};
int main(void)
{
struct verify holes;
printf ("%d\n", sizeof(holes.initials[0]));
printf ("%d\n", sizeof(holes.initials));
printf ("%d\n", sizeof(holes.birthdate));
printf ("%d\n", sizeof(holes));
return 0;
}
Given that the word-byte
In 16-bit computer = 2 bytes word the output is,
1
2
2
4
in  32-bit computer = 4 bytes word the output is,
1
2
4
8

Two things are different due to computer architecture.
1. The same struct have different memory sizes allocated.
   



Yep.

 

2. The struct has no hole in 16-bit and has 2-byte hole in 32-bit 
because C-compiler always

 align int data types beginning at the next word byte.
   



I don't think the C standard specifies how a struct should be layed out
in memory.
 



What do you mean ? Can you illustrate with C codes ?  Do you mean that a 
struct
are not allocated contiguous memory ?  Do you mean a struct components are 
allocated random memory. If it does not allocate contiguous memory in your
thinking, what about arrays since struct is similar to arrays except the 
objects are

of mixed types ?

And when struct components are allocated random memory, this breaks down 
the
nature and the power of C which to my mind lie in its ability to 
manipulate and

manage objects using pointers and pointer-arithmetic.



Matthew said is wasn't `necessarily' bound to the hardware. In practise you
are going to see different data type sizes on different bits of hardware.
But just because the hardware can store an 64-bit words, doesn't mean that
the ABI is going to specify an int to be 64-bit.
 

What you probably mean is it is not mandated by the standard. Some specs 
are mandated

and some are not.

That's why I used specific C codes to illustrate. Whether the C codes 
that I used follows
the standard in the sense that it does not violate the standard it is 
compliant.  After all

compliance means it does not violate mandated standards.

And in intel or amd 16-bit and 32-bit it is as demonstrated. That's what 
I meant.


--
O Plameras
http://www.acay.com.au/~oscarp/tutor

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: WAS - Re: [SLUG] Your top-ten linux desktop apps

[yiz]

#include 
struct verify {
char initials[2];
int birthdate;
};
int main(void)
{
struct verify holes;
printf ("%d\n", sizeof(holes.initials[0]));
printf ("%d\n", sizeof(holes.initials));
printf ("%d\n", sizeof(holes.birthdate));
printf ("%d\n", sizeof(holes));
return 0;
}
Given that the word-byte
In 16-bit computer = 2 bytes word the output is,
1
2
2
4
in  32-bit computer = 4 bytes word the output is,
1
2
4
8



k, I am a newb, so someone plz quickly explain to me why the variable 
'initial'

takes 2 bytes, 'birthdate' takes 4 bytes but the struct which is 2+4 = 6 bytes
takes 8 bytes?

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: WAS - Re: [SLUG] Your top-ten linux desktop apps

[Benno]

On Tue Oct 04, 2005 at 10:15:49 +1000, O Plameras wrote:
>Benno wrote:
>
>>On Sat Oct 01, 2005 at 18:23:40 +1000, O Plameras wrote:
>> 

>
>What do you mean ? Can you illustrate with C codes ?  Do you mean that a 
>struct
>are not allocated contiguous memory ?  Do you mean a struct components are 
>allocated random memory. If it does not allocate contiguous memory in your
>thinking, what about arrays since struct is similar to arrays except the 
>objects are
>of mixed types ?
>
>And when struct components are allocated random memory, this breaks down 
>the
>nature and the power of C which to my mind lie in its ability to 
>manipulate and
>manage objects using pointers and pointer-arithmetic.

What I mean is how the structure is layed out in memory is not defined by
the specification, and is up to the C compiler, or rather give the 
implementation
plenty of flexibility in the layout.

so

struct foo {
   char x;
   char y;
   int z;
};

Could be layed out in memory as: (numbers in brackets refer to clause in C99 
spec)

[ x | y | z  ] 

or possibly

[ x padding | y padding | z  ]  (6.7.2.1.12)

or more likely

[ x | y | padding | z ]

although it can't be

[ y | x | z  ]  (6.7.2.1.13)

and it also can't be:

[ padding x | y | z] (6.7.2.1.13)

"""
#include 
#include 

struct foo {
char x;
int y;
};

int main(void)
{
struct foo foo;

printf("Offset of: x: %zd  y: %zd\n", 
   offsetof(struct foo, x), 
   offsetof(struct foo, y));
if (sizeof(foo.x) == offsetof(struct foo, y))
printf("sizeof(foo.x) == offsetof(struct foo, y)\n");
else
printf("sizeof(foo.x) != offsetof(struct foo, y)\n");
}
"""

Demonstrates this. For example compiling normally with gcc will output:

Offset of: x: 0  y: 4
sizeof(foo.x) != offsetof(struct foo, y)

compiling with -fpack-struct results in:

Offset of: x: 0  y: 1
sizeof(foo.x) == offsetof(struct foo, y)


As far as I know:

struct foo;

struct foo a[];

&(a[1]) == ((uintptr_t) &a[0]) + sizeof(struct foo); (6.5.6.9 footnote 88)


>>Matthew said is wasn't `necessarily' bound to the hardware. In practise you
>>are going to see different data type sizes on different bits of hardware.
>>But just because the hardware can store an 64-bit words, doesn't mean that
>>the ABI is going to specify an int to be 64-bit.
>> 
>>
>What you probably mean is it is not mandated by the standard. Some specs 
>are mandated
>and some are not.

Thats exactly what I mean. The C99 specification does not mandate the size
of types. The platform (that is OS + architecture) usually defines an ABI
which compilers should use. It does (usually) specifiy the size of the types.

>That's why I used specific C codes to illustrate. Whether the C codes 
>that I used follows
>the standard in the sense that it does not violate the standard it is 
>compliant.  After all
>compliance means it does not violate mandated standards.
>
>And in intel or amd 16-bit and 32-bit it is as demonstrated. That's what 
>I meant.

What you provided is compliant C, however making any assumption on the 
underlying
bus speed, hardware word size, based on the size of an integer is just not going
to work, which appears to be what you are trying to say. There
is no specified relationship between hardware word size and sizeof(int). In some
ABI hwardware word size == sizeof(int), (ia32, some 16bit processors, VAX maybe)
and in others hardward word size != sizeof(int) (amd64, itanium, power4).

Benno

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: WAS - Re: [SLUG] Your top-ten linux desktop apps

[Benno]

On Mon Oct 03, 2005 at 19:44:44 -0500, [EMAIL PROTECTED] wrote:
>
>>#include 
>>struct verify {
>>char initials[2];
>>int birthdate;
>>};
>>int main(void)
>>{
>>struct verify holes;
>>printf ("%d\n", sizeof(holes.initials[0]));
>>printf ("%d\n", sizeof(holes.initials));
>>printf ("%d\n", sizeof(holes.birthdate));
>>printf ("%d\n", sizeof(holes));
>>return 0;
>>}
>>Given that the word-byte
>>In 16-bit computer = 2 bytes word the output is,
>>1
>>2
>>2
>>4
>>in  32-bit computer = 4 bytes word the output is,
>>1
>>2
>>4
>>8
>
>
>k, I am a newb, so someone plz quickly explain to me why the variable 
>'initial'
>takes 2 bytes, 'birthdate' takes 4 bytes but the struct which is 2+4 = 6 
>bytes
>takes 8 bytes?
>

See my last email, but it is likely that in memory it is layed out as:

[ char(1) | char(1) | padding(2) | int(4)   ]

So there is two bytes of padding after the characters to make sure the integer
is aligned. Having the integer aligned makes for a faster program (in general),
at the expense of a nominal (in general) amount of memory.

The compiler has done a space<->time trade off on your behalf.

Benno
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html