Re: [SLUG] Your top-ten linux desktop apps
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
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
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
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
Re: [SLUG] Your top-ten linux desktop apps
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
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
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: WAS - Re: [SLUG] Your top-ten linux desktop apps
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 stdio.h
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
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 stdio.h
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
#include stdio.h
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
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:
snippety
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 stdio.h
#include stddef.h
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
On Mon Oct 03, 2005 at 19:44:44 -0500, [EMAIL PROTECTED] wrote:
#include stdio.h
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
Re: WAS - Re: [SLUG] Your top-ten linux desktop apps
[EMAIL PROTECTED] wrote:
#include stdio.h
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?
You refer to 32-bit intel computer in the above illustration.
Our compiler allocates,
the start of struct at the word alignment and memory must
be contiguous.
So, 2 characters = initials is started at the beginning of a word
byte and our word byte = 4 bytes. But only the first 2 bytes
are taken because we have only two characters. The last two
bytes in the 'word' are empty.
When the compiler continued on to allocate memory for the
next object in the struct, which in this case is int, this is
allocate memory beginning at the next word byte by skipping
the two empty bytes.
So,
2 char + 2 empty + 4 bytes = 8 bytes.
The is the struct itself and has 8 bytes.
--
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
On Mon, Oct 03, 2005 at 07:44:44PM -0500, [EMAIL PROTECTED] wrote: 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? http://www.eskimo.com/~scs/C-faq/q2.13.html -- 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
On Tue, Oct 04, 2005 at 12:28:51PM +1000, Matthew Hannigan wrote: http://www.eskimo.com/~scs/C-faq/q2.13.html A better link, to the whole faq is http://www.faqs.org/faqs/C-faq/faq/ What's remarkable is the amount of space in the faq devoted to exactly the issues mentioned in this thread. -- 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
-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
CHange the Subject when you change the subject (was Re: [SLUG] Your top-ten linux desktop apps)
Thanks. Mike -- 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
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 stdio.h
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
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
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: [SLUG] Your top-ten linux desktop apps
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: dynamic vs static type checking (was Re: [SLUG] Your top-ten linux desktop apps)
On 9/29/05, Angus Lees [EMAIL PROTECTED] wrote: At Tue, 27 Sep 2005 12:00:09 +1000, Bruce Badger wrote: In fact, the very best of the JITing VMs can get performance that exceeds that attainable by static compilation - because there is more information available at run time to base the tuning decisions upon. If a program's use changes over its invocation, and the JIT continually shifts its optimisation targets, then I can see the potential benefit of this approach. I don't believe, however, that there are many programs that have this dynamic behaviour. I agree. It is only in very dynamic, high throughput and long-lived services that one would see a measurable benefit in having such a sophisticated VM, though I would not be surprised to see heavily used web servers falling into this category. You can gain the same runtime knowledge in a statically compiled C program by compiling with gcc's -ffprofile-arcs, running over some typical use cases (will write a bunch of .gcda files) and then recompiling with -fbranch-probabilities. Right. For static problems, or problems with a well understood number of modes of operation static compilation can be superb. For each new mode encountered in the wild, though, one would have to tweak the compiler hints and rebuild to keep up with our imaginary perfect JITer. I think the key is your first point. The cases where absolute performance is critical are very rare indeed. I'm happy, though, that I am using an environment where I can focus on the problem at hand, and delegate many low-level issues to the environment itself and at the same time expect performance on a par with (and perhaps even better than?) the best hand-crafted binaries. Only real circumstances will tell. I'd love to work in an environment that was sophisticated and high-load enough to put some of the advanced JITing VMs to the test. 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
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
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
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
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
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
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
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
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
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 stdio.h
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
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
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
Does anybody have a 64-bit computer ?
Are you able to compile and run the following code and publish the
results ?
Thanks.
#include stdio.h
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
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
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
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
quote who=Erik de Castro Lopo 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
Jeff Waugh wrote: quote who=Erik de Castro Lopo 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
[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 stdio.h
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
-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
[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
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
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
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: http://www.robertcollins.net/keys.txt. 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
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
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
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
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
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
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
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
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
-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
-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
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
-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
-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
[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
Please change the topicRe: [SLUG] Your top-ten linux desktop apps
Gr. Can't you guys change the subject line? I was REALLY interested in the top ten thread -- 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 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
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
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
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
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
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
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
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
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: dynamic vs static type checking (was Re: [SLUG] Your top-ten linux desktop apps)
At Tue, 27 Sep 2005 12:00:09 +1000, Bruce Badger wrote: On 9/27/05, Erik de Castro Lopo [EMAIL PROTECTED] wrote: There are large classes of problems where running speed is an important issue. Static typing does make for faster run times and in cases where that moves your program from being too slow to being fast enough, that is not a premature optimisation. Modern VMs (e.g. many of the Smalltalk VMs) dynamically compile code, i.e. they JIT. [...] In fact, the very best of the JITing VMs can get performance that exceeds that attainable by static compilation - because there is more information available at run time to base the tuning decisions upon. If a program's use changes over its invocation, and the JIT continually shifts its optimisation targets, then I can see the potential benefit of this approach. I don't believe, however, that there are many programs that have this dynamic behaviour. You can gain the same runtime knowledge in a statically compiled C program by compiling with gcc's -ffprofile-arcs, running over some typical use cases (will write a bunch of .gcda files) and then recompiling with -fbranch-probabilities. -- - 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
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
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
[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
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
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 stdio.h
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
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
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
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
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
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
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
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
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: http://www.robertcollins.net/keys.txt. 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
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 stdio.h
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
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
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
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. snip 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
* 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. snip 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
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
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
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
quote who=Grant Parnell 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
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 nagit's openoffice.org /nag 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
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
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
Konqueror - using fish to transfer files - fish://user@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
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
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
dynamic vs static type checking (was Re: [SLUG] Your top-ten linux desktop apps)
QuantumG wrote: 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. Yep, thats right. The problem with dynamic typing is that it postones testing for an important class of errors (type errors) until run time. The main way of avoiding type errors in dynamically typed languages is by using a test suite (or face the possibility of sending a program with unchecked type errors to your customers). Even if you have a test suite, how sure are you that it will catch all errors? How much effort are you putting into the development of the test suite? Contrast the above with O'Caml (or Haskell) where you cannot create an executable with type errors [0]. You still need a test suite for programs written in O'caml, but the set of possible problems to test for is much smaller and hence requires less effort [1]. Erik [0] : Well you can, by using the O'caml Marshall module (which most O'Caml programmers don't use very often if at all) or by linking O'caml to C code. [1] : Yes, I'm lazy. 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 -- +---+ Erik de Castro Lopo +---+ The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code. -- Paul Graham -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: dynamic vs static type checking (was Re: [SLUG] Your top-ten linux desktop apps)
On 9/27/05, Erik de Castro Lopo [EMAIL PROTECTED] wrote: The problem with dynamic typing is that it postones testing for an important class of errors (type errors) until run time. Nah. In fact the oposite is true. Static typing is just another form of premature optimisation! I make extensive use of dynamically typed languages (Smalltalk mostly) and the class of problem one might imagine that static typing save you from I just don't encounter in practice. Each to their own, of course :-) -- 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
