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
[SLUG] Optusnet send problems with evolution
Hi All, I've recently switched over to OptusNet and have had some problems sending mail from evolution. I've setup delivery so that it goes through my local exim4 mailer (as was recommended by someone on this list), but if I do things like reply to certain people (I don't know what the pattern is) or if I accept an invitation to a meeting that someone sends me, when I click Send and Receive the dialog sits there sending until I hit cancel. Now I believe (from research so far) that this is because OptusNet doesn't have any authorisation set on their SMTP server mail.optusnet.com.au. Why does this make evolution stop in it's tracks when sending ? I'm sending to the local machine now... Is there some way I can get exim to rewrite the header or get evolution configured so it doesn't try to authorise me (which causes the problem) ? Just one email causing this problem will foul up the whole outbox. The only way to get the mails resent is to open them up, make them drafts and resend them. This seems to clear whatever the problem is and they get sent. Weird It's very annoying. Thanks and Cheers David -- David Creelman GPG: 11CC 0D54 D37A 4B9C 5C65 AB63 5B18 7F99 7D77 9CA5 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Linux Lunch Box PC at $100 US each - Unveiled
Got this from www.yahoo.com http://news.yahoo.com/s/ap/20050928/ap_on_hi_te/hundred_dollar_laptop -- 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
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
[SLUG] C-Pointers and Perl ?
Hi,
Is their equivalent codes for ff in perl 6 ?
I've been told there is none in O'Caml as pointer is not available.
[EMAIL PROTECTED] oscarp]# cat f.c
int main(void)
{
int (*get_f())();
static int arr[] = { -1, 0, 1, 0, 2, +9, +3200, -3500 };
int *ptr, *pastend;
int (*fptr)();
pastend = arr + sizeof(arr)/sizeof(arr[0]);
for (ptr = arr; ptr pastend; ptr++)
if (fptr = get_f(ptr))
fptr(ptr);
return 0;
}
int (*get_f(ptr))()
int *ptr;
{
int is_neg(), is_pos();
static int (*cmds[])() = {
(int (*)())0,
is_neg,
is_pos
};
int index = 0;
if (*ptr 0)
index = 1;
if (*ptr 0)
index = 2;
return(cmds[index]);
}
is_neg (iptr)
int *iptr;
{
printf(%d is negative\n, *iptr);
}
is_pos (iptr)
int *iptr;
{
printf(%d is positive\n, *iptr);
}
--
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
[SLUG] Re: ctrl-alt-left ctrl-alt-right under VNC (OT?)
I'm not a Gnome user, but under KDE I'd just use the pager Bill G'day, (Warning: some readers may consider this mail off-topic for the list!) I'm sure I used to be able to do this (although I'm wondering now). Using gnome desktop, you can ctrl-alt-left and right between desktops. However, viewing the desktop via VNC this isn't possible (or at least not conveniently possible). (VNC client is running under WinXP.) Does anyone know a work-around? Thanks Raphael. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: squirrellmail/roundcube
Del [EMAIL PROTECTED] uttered the following thing: We just spent some time looking at PHP webmail clients. Here are our contenders list. We were looking at making extensions to them so the comments are mostly aimed at looking inside the code to see how well written it was. I don't see OpenWebmail here. Did you try it? BB -- 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] C-Pointers and Perl ?
O Plameras wrote: Hi, Is their equivalent codes for ff in perl 6 ? What is this ff? Erik -- +---+ Erik de Castro Lopo +---+ C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow away your whole leg! -- Bjarne Stroustrup -- 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] C-Pointers and Perl ?
Erik de Castro Lopo wrote: O Plameras wrote: Hi, Is their equivalent codes for ff in perl 6 ? What is this ff? ff = following 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] C-Pointers and Perl ?
O Plameras wrote: Hi, Is their equivalent codes for ff in perl 6 ? I've been told there is none in O'Caml as pointer is not available. The C equivalent of function pointers do exist in O'caml. The C example is rather silly, but here's the O'caml equivalent: let print_sign x = if x = 0 then Printf.printf % d is positive\n x else Printf.printf % d is negative\n x ;; let arr = [| -1 ; 0 ; 1 ; 0 ; 2 ; 9 ; 3200 ; -3500 |] ;; Array.map print_sign arr ;; For just about everything you can do with a pointer in C there is a better, easier, less error prone way to do the same thing in O'caml and write less lines of code to do it. The one exception I can thing of is writing devices drivers and operating systems where you need to direct access to harware. Erik -- +---+ Erik de Castro Lopo +---+ ... a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god. -- 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
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] C-Pointers and Perl ?
On Thu Sep 29, 2005 at 19:59:01 +1000, Erik de Castro Lopo wrote: O Plameras wrote: For just about everything you can do with a pointer in C there is a better, easier, less error prone way to do the same thing in O'caml and write less lines of code to do it. The one exception I can thing of is writing devices drivers and operating systems where you need to direct access to harware. Ok, you really want to make me learn O'Caml, and augment it so that is can write device drivers, and access hardware directly, because C is a totally inadequate language for writing device drivers. 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] C-Pointers and Perl ?
On Fri, 30 Sep 2005 00:36, Benno wrote: On Thu Sep 29, 2005 at 19:59:01 +1000, Erik de Castro Lopo wrote: O Plameras wrote: For just about everything you can do with a pointer in C there is a better, easier, less error prone way to do the same thing in O'caml and write less lines of code to do it. The one exception I can thing of is writing devices drivers and operating systems where you need to direct access to harware. Ok, you really want to make me learn O'Caml, and augment it so that is can write device drivers, and access hardware directly, because C is a totally inadequate language for writing device drivers. I think you got Eric's logic arse-about. He was say O'caml is good for almost anything EXCEPT writing device drivers. Not the other way around. Or maybe your sense of irony and sarcasm is lost on me at 2am James -- Generosity and perfection are your everlasting goals. pgp8udQIwDWPR.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] C-Pointers and Perl ?
quote who=James Gray Ok, you really want to make me learn O'Caml, and augment it so that is can write device drivers, and access hardware directly, because C is a totally inadequate language for writing device drivers. I think you got Eric's logic arse-about. He was say O'caml is good for almost anything EXCEPT writing device drivers. Not the other way around. Or maybe your sense of irony and sarcasm is lost on me at 2am To put it in perspective, Benno is a cranky kernel hacker. :-) - Jeff -- UbuntuBelowZero in Montreal! http://wiki.ubuntu.com/UbuntuBelowZero http://www.xach.com/debian-users-are-beatniks.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: [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
[SLUG] Converting video tapes.
I have acquired a bit of hardware that can link a video tape recorder to the computer to convert tapes into CDs and DVDs. The accompanying software is exclusively Windows. Bugger! Does anyone know if there is a Linux application that might work? John. -- 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] C-Pointers and Perl ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Sep 29, 2005 at 07:59:01PM +1000, Erik de Castro Lopo wrote: For just about everything you can do with a pointer in C there is a better, easier, less error prone way to do the same thing in O'caml and write less lines of code to do it. How about writing a network protocol stack. You get a packet and all you know about it is that here is a block of memory. You then have to figure out what sort of packet it is, how long it is and what structure to give it. C handles this very nicely with pointers to structures that can be cast into whatever you need. The one exception I can thing of is writing devices drivers and operating systems where you need to direct access to harware. If you are talking about I/O ports, you can always write a pair of functions to write and read from I/O and these can be added to any language (possibly even as inlines if the language supports that). There is no native I/O port access in C. Consider how useful functions like memcpy() and memcmp() are for writing an O/S. Consider also that an O/S is actually a form of self modifying code which strict type checking is designed to prevent. I isn't about direct hardware access, it is about having the flexibility to do what needs to be done. Try the simple exercise of writing an O'caml program that reads in a chunk of binary code from a file, and then executes that code to get a result. Less lines of code than C? - Tel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iQIVAwUBQzxjfcfOVl0KFTApAQLhaw/+MudIVmEkOmHUGX61ILbt93q4v7uVUgpF WG9vxEReMxZMJNc/bMfAaTPI5M3p9msCgClgJnooGqGmLufToP2mmAeeGj2XXuvF abCyet6Gwr4xaFXbrboHfhWCUpDuIu7ItNQsSKaoNI/upjImA2lbV1K9sBixPfzS OTKkAWCQ+Av8ZGlYmvkiI01LRzFkIdkNbDZNDCOdJdtmsdJLzu2/dXuDscJGOQDi I48Q04zG5A4YADMCJMNQpN7GNOfPsfp6FtEKPTknJYKnOANrF2BkE9BOgXS4+kwN 7NugEOAskqmdBdfoisP/q4bdUArzSP4khdgRCtDGKSIx1hr57rUMfH+bgoswAbze fx7B8FAypyEbho4XazG+NIdQ6ez0ClnB/Dj/1fsDjxUNTPPTu9SuXIIz6Jk8ZVCP t6yyO+JgAzOZe3BgEoziSjvDpSodd3h6ORXQnmgx4FVM9oT6Qj0FXazCfN9BaFFz MBMq01mC72ISDbGSjDobfTt2XjgSXTjioQWw3hsWG8ao4OTfktyhF0Q/osd6ZAJm OyHulHuBC4e+pfycjt/U7E40iKcK2TaKm9rgQ105pmR/aLEOuD2MkKvqCVwJX2bp /vCjiNiVVzgeZvNc5bIAdtxMtr3/jvBIulsNrRJypt0QACFOfqHOQZLgmVQIHRWd Nbd/dzk/Hmc= =mpjJ -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 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
[SLUG] Output from 64 bit machine
O Plameras wrote: Does anybody have a 64-bit computer ? Are you able to compile and run the following code and publish the results ? Compiled on a Dec Alpha running OpenVMS 7.2 VMSrun test.exe 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 Bit surprised, I expected a long to be 8 but there you go. HTH P. -- 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] Output from 64 bit machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Sep 30, 2005 at 08:12:53AM +1000, Peter Rundle wrote: Compiled on a Dec Alpha running OpenVMS 7.2 VMSrun test.exe 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 Bit surprised, I expected a long to be 8 but there you go. There may be compiler options involved, check the pointer size because if that is also 32 bit then your compiler is trying to be back-compatible. Not that I'm a VMS expert but I do remember a lot of tricky compiler compatibility thingies. - Tel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iQIVAwUBQzxqc8fOVl0KFTApAQIa5w/+OqK3bIF0ah93cuWKOc54IYFdMAxMyWAe 9mNFmHiy7yK8i9FXUCg09N4lmAa8rcuXJMB74370MEZ+j9+PbrGnNnt2dTF+BIPB VxlEQZKIuPsR2XVZvDCURzh5uesOtc3wG8ZleUZ0zPBUsHFi7OA0vkZtMNw8tFeX /TXUekchMyypvhNVH4nTN3Uuv3tfFZpcuPdCsRrVoSpbv8Dhlf25LplZjQVNKPs1 WC7o7mt6dd1X3emlvM5+buZssoxxvJMXu2fALcoDucPfM9njletK/53nizkzDAiU jCDhfCojBQBlr9TgCHq8zsazPSGXom02Au+yM86LBvuCUVBmGuyRRpzsIjCFscOU s8+s0G1a8v3wsxEh/udUD0FVovV7aNv/NleCk0QrIhSchjXMm/E9Crl9RmMsLpqJ SCM6zga+wJJsjauGvr0QByuKZXcwkqFcT5ht8o5Gh07bZKbtMSuTLMZ0JJXqDpAr uKJ/7agdtFjS1mQBo9ZhoyjKK2iq4ckWyh4CDIQ6e8nLp6G5+4SowiJ8ojc+S0v3 00M7PsrZ5H25iiNVPl/guj8BFCZh04H3/xoCiLrMeLwAebsTCER+AAISg9897oaT LjMr8CS4TMnxYvqphtJnBYzO3TUcTVtqPQOAQltkEtN4XxQCEOEkqyBJ/Y1CxrYd o9yt6DVb86w= =r+7k -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] Output from 64 bit machine
Peter Rundle wrote: O Plameras wrote: Does anybody have a 64-bit computer ? Are you able to compile and run the following code and publish the results ? Compiled on a Dec Alpha running OpenVMS 7.2 VMSrun test.exe 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 Bit surprised, I expected a long to be 8 but there you go. Thanks. Yep, another surprise here. It appears to me explanations previously made about 64-bit computers are no longer current across this 64-bit architecture. But I note that 32-bit explanations are still current across this architecture since there are no opposing explanations. -- 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
[SLUG] Ajax-based Open Source Exchange replacement
I thought that this is worth your look-see: www.zimbra.com It looks like an excellent open source web-based outlook AND exchange replacement. Proports to do group scheduling, has a beautiful looking web-based ajax interface with drag and drop support. Licensing is modified MPL, they are following a RedHat subscription-like business model. They have incorporated lucene for fast indexing of emails as well as postfix and a bunch of other open source technologies. I will probably see if I can replace mine and my clients squirrelmail with it as it _looks waaay better. The flash demo is about 12 minutes long on a fast DSL and worth a look just to see what some of the capabilities of AJAX. There are also a couple of pdfs worth a read. Particularly the AjaxTK (ajax toolkit) and the Architecture document. HTH Someone. Stu -- 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] C-Pointers and Perl ?
On Fri Sep 30, 2005 at 02:05:16 +1000, James Gray wrote: On Fri, 30 Sep 2005 00:36, Benno wrote: On Thu Sep 29, 2005 at 19:59:01 +1000, Erik de Castro Lopo wrote: O Plameras wrote: For just about everything you can do with a pointer in C there is a better, easier, less error prone way to do the same thing in O'caml and write less lines of code to do it. The one exception I can thing of is writing devices drivers and operating systems where you need to direct access to harware. Ok, you really want to make me learn O'Caml, and augment it so that is can write device drivers, and access hardware directly, because C is a totally inadequate language for writing device drivers. I think you got Eric's logic arse-about. He was say O'caml is good for almost anything EXCEPT writing device drivers. Not the other way around. I know, but I don't agree with him. If the language is good, there is no reason why it *shouldn't* be used for device driver programming. Device drivers are, in general, buggy pieces of crap, so having a higher level language to program them in would be a *really* good thing. I've written bindings to allow you to program drivers in python before, unfortunately the result wastoo slow :(. So a higher level compiled language like O'Caml might be kind of cool. No sarcasm intended. 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] Output from 64 bit machine
Peter Rundle wrote: Compiled on a Dec Alpha running OpenVMS 7.2 VMSrun test.exe 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 Bit surprised, I expected a long to be 8 but there you go. Many OSes support both 32 and 64 bit executables. To know which type your executable is, you should also print sizeof(void*) which will always be 8 in a 64 bit executable and 4 in a 32 bit executable. If you add a sizeof(void*) to the above I wouldn't be surprised if you find you have a 32 bit executable and need a command line option to create a 64 bit executable. Its like this on Solaris running on Sparc. Erik -- +---+ Erik de Castro Lopo +---+ The one thing that reading these five books has hammered home is how much C++ has turned into 3 languages stuck in a bag fighting to get out. Low C++, High C++, and Generic C++. -- 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] C-Pointers and Perl ?
[EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Sep 29, 2005 at 07:59:01PM +1000, Erik de Castro Lopo wrote: For just about everything you can do with a pointer in C there is a better, easier, less error prone way to do the same thing in O'caml and write less lines of code to do it. How about writing a network protocol stack. It is certainly possible to write such a beast in a language without pointers. I believe quite a bit has been done in this area with Java. You get a packet and all you know about it is that here is a block of memory. You then have to figure out what sort of packet it is, how long it is and what structure to give it. C handles this very nicely with pointers to structures that can be cast into whatever you need. The C way (with pointers) leads to non-portable and difficult to maintain code. There are better, safer ways to do it without pointers. However, for a low level task like this, I still think well written, portable C is better than Java and/or O'Caml. The one exception I can thing of is writing devices drivers and operating systems where you need to direct access to harware. If you are talking about I/O ports, you can always write a pair of functions to write and read from I/O and these can be added to any language (possibly even as inlines if the language supports that). There are people writing an OS in O'caml. Even though I really like O'Caml I still think this is a bad idea. IMO, C is still the best language for implementing low level OS features no matter how flawed it is as a language. My real complaint about C is that it is a really bad language for work with linked lists, sets, hash tables and other high level data structures. Erik -- +---+ Erik de Castro Lopo +---+ Religion is a magic device for turning unanswerable questions into unquestionable answers. -Art Gecko, Wombat Discord-1, 128649 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Your top-ten linux desktop apps
O Plameras 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
OS implementation languages (was: Re: [SLUG] C-Pointers and Perl ?)
On Fri Sep 30, 2005 at 09:37:11 +1000, Erik de Castro Lopo wrote: My real complaint about C is that it is a really bad language for work with linked lists, sets, hash tables and other high level data structures. But most of the internals of an OS, process lists, file systems, virtual memory management, ends up being all about data structures and algorithms, so I would think something that better manages those things would be a great idea. 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] Ajax-based Open Source Exchange replacement
I don't know if it is an exchange replacement. I think it's just a collaboration tool. like MS web outlook access. I have down loaded the source. I will have a look shortly. www.zimbra.comIt looks like an excellent open source web-based outlook AND exchange replacement. Proports to do group scheduling, has a beautiful lookingweb-based ajax interface with drag and drop support.Licensing ismodified MPL, they are following a RedHat subscription-like businessmodel. They have incorporated lucene for fast indexing of emails as well aspostfix and a bunch of other open source technologies.I will probably see if I can replace mine and my clients squirrelmail withit as it _looks waaay better. The flash demo is about 12 minutes long on a fast DSL and worth a lookjust to see what some of the capabilities of AJAX.There are also a couple of pdfs worth a read. Particularly the AjaxTK(ajax toolkit) and the Architecture document. HTH Someone.Stu--SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/Subscription info and FAQs: http://slug.org.au/faq/mailinglists.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: [SLUG] Output from 64 bit machine
If you add a sizeof(void*) to the above I wouldn't be surprised if you find you have a 32 bit executable and need a command line option to create a 64 bit executable. yep void * returns 4. I'm sure there is a compile option, but I couldn't see it at a quick glance. However the point is made that if you're writing C that might be ported.. P. -- 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] Output from 64 bit machine
On Fri, 2005-09-30 at 09:29 +1000, Erik de Castro Lopo wrote: Many OSes support both 32 and 64 bit executables. To know which type your executable is, you should also print sizeof(void*) which will always be 8 in a 64 bit executable and 4 in a 32 bit executable. mmm. Not entirely true. 64 bit can mean 64 bit pointers, 64 bit integers, or even just 64 bit opcodes. I'd try 64-bit sparc, ia-64 and amd-64 in 64 bit mode for comparison. 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
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: OS implementation languages (was: Re: [SLUG] C-Pointers and Perl ?)
Benno wrote: But most of the internals of an OS, process lists, file systems, virtual memory management, ends up being all about data structures and algorithms, so I would think something that better manages those things would be a great idea. O'caml is not a perfect language, but for complex high level data structures I haven't seen anything better (I've written a computer algebra system in o'caml). One of the things that IMO make O'caml bad for OS development is that native ints are only 31 bits (on 32 bit machines, 61 bits on 64 bit machines). This is done to help the garbage collector do its work. There are however other languages like cyclone http://www.research.att.com/projects/cyclone/ and another called safe-c which have yet to escape the confines of research groups. I haven't really looked at cyclone, but my suspicion is that there is a really good language still out there waiting to be written. I'd love to have a go at this, but I'm still looking for someone to pay me to do it :-). Erik -- +---+ Erik de Castro Lopo +---+ The National Multiple Sclerosis Society of America recently started an advertising campaign with the slogan MS: It's not a software company. Seasoned IT professionals will have no trouble telling the two MS's apart. One is a debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. The other is a disease. -- 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] C-Pointers and Perl ?
On Fri, 2005-09-30 at 07:58 +1000, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Sep 29, 2005 at 07:59:01PM +1000, Erik de Castro Lopo wrote: For just about everything you can do with a pointer in C there is a better, easier, less error prone way to do the same thing in O'caml and write less lines of code to do it. How about writing a network protocol stack. You get a packet and all you know about it is that here is a block of memory. You then have to figure out what sort of packet it is, how long it is and what structure to give it. C handles this very nicely with pointers to structures that can be cast into whatever you need. Its straight forward in python and smalltalk. you have an array of octets, do what you need. What you don't have is something that can be pointed at a random memory region and used to bypass the type system and vm ;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] Output from 64 bit machine
Robert Collins wrote: I'd try 64-bit sparc, ia-64 and amd-64 in 64 bit mode for comparison. This is OS dependant. All 64 bit Linux versions use the LP64 model where longs and pointers are 64 bit. Solaris on UltraSparc does the same and I haven't played with Solaris on amd-64 so I can't say. I have heard of certain old school 64 bit Unices where long was 32 bits but I think they died out when Uninx98 or Posix whatever decided that 64 bit unix should be LP64. One of the odd ones out of course is win64, where both int and long are 32 bits and pointers are 64 bits. Yep its nuts, but it is m$. Erik -- +---+ Erik de Castro Lopo +---+ Fundamentalist : Someone who is colour blind and yet wants everyone else to see the world with the same lack of colour. -- 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] Re: squirrellmail/roundcube
Ben Buxton wrote: Del [EMAIL PROTECTED] uttered the following thing: We just spent some time looking at PHP webmail clients. Here are our contenders list. We were looking at making extensions to them so the comments are mostly aimed at looking inside the code to see how well written it was. I don't see OpenWebmail here. Did you try it? No, we only looked at PHP packages. I find modifying other people's perl code to be more trouble than it's worth. -- Del -- 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] Output from 64 bit machine
On Fri Sep 30, 2005 at 10:17:03 +1000, Erik de Castro Lopo wrote: Robert Collins wrote: I'd try 64-bit sparc, ia-64 and amd-64 in 64 bit mode for comparison. This is OS dependant. All 64 bit Linux versions use the LP64 model where longs and pointers are 64 bit. Solaris on UltraSparc does the same and I haven't played with Solaris on amd-64 so I can't say. I have heard of certain old school 64 bit Unices where long was 32 bits but I think they died out when Uninx98 or Posix whatever decided that 64 bit unix should be LP64. One of the odd ones out of course is win64, where both int and long are 32 bits and pointers are 64 bits. Yep its nuts, but it is m$. And of course if you really care about the size of the types then you can use uint8_t, uint16_t, uint32_t, uint64_t, (drop the u for signed types). And then there is uintptr_t for a type that is going to be and integer large enough to hold a pointer. (Of course using printf then becomes a real bitch...) 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] C-Pointers and Perl ?
On 9/30/05, Benno [EMAIL PROTECTED] wrote: I know, but I don't agree with him. If the language is good, there is no reason why it *shouldn't* be used for device driver programming. The languages that save developers worrying about if a number is too big to be an integer mostly do the insulating by lifting the programmer away from physical resources. So, for example, memory allocation and deallocation is magic. For problems that requires memory mapping, VM based languages are not going to be a good fit (given my experience of them, anyway). Device drivers are, in general, buggy pieces of crap, so having a higher level language to program them in would be a *really* good thing. I certainly agree with this sentiment. I've written bindings to allow you to program drivers in python before, unfortunately the result wastoo slow :(. So a higher level compiled language like O'Caml might be kind of cool. Smalltalk may be interesting, then. GNU Smalltalk is pretty quick, I understand. 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] Output from 64 bit machine
On Fri, Sep 30, 2005 at 10:22:33AM +1000, Benno wrote: (Of course using printf then becomes a real bitch...) What's wrong with the PRI macros in inttypes.h? -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] C-Pointers and Perl ?
On Fri Sep 30, 2005 at 10:24:56 +1000, Bruce Badger wrote: On 9/30/05, Benno [EMAIL PROTECTED] wrote: I know, but I don't agree with him. If the language is good, there is no reason why it *shouldn't* be used for device driver programming. The languages that save developers worrying about if a number is too big to be an integer mostly do the insulating by lifting the programmer away from physical resources. So, for example, memory allocation and deallocation is magic. For problems that requires memory mapping, VM based languages are not going to be a good fit (given my experience of them, anyway). Mmm, that is true. Languages I've used/know of, generally have `a way out', some way to bypass this, by writing some small stub in C. Which I guess I was assuming O'Caml (or smalltalk) would have. 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] Output from 64 bit machine
On Fri Sep 30, 2005 at 10:28:18 +1000, Ian Wienand wrote: On Fri, Sep 30, 2005 at 10:22:33AM +1000, Benno wrote: (Of course using printf then becomes a real bitch...) What's wrong with the PRI macros in inttypes.h? Compare: uint32_t foo = 0x37; uintptr_t bar = (uintptr_t) foo; printf(Foo: PRId32 bar: PRIxPTR \n, foo, bar); with: int foo = 0x37; long bar = (long) foo; printf(Foo: %d bar: %lx\n, foo, bar); I find the second clearer, but that might just be me ;) 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] C-Pointers and Perl ?
On 9/30/05, Benno [EMAIL PROTECTED] wrote: On Fri Sep 30, 2005 at 10:24:56 +1000, Bruce Badger wrote: For problems that requires memory mapping, VM based languages are not going to be a good fit (given my experience of them, anyway). Mmm, that is true. Languages I've used/know of, generally have `a way out', some way to bypass this, by writing some small stub in C. Which I guess I was assuming O'Caml (or smalltalk) would have. Ah, I see. Yes, calling out to C is doable in a number of ways from a Smalltalk runtime. The options cover calling a library and also adding primitive functions to the Smalltalk VM. 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
[SLUG] PDA development help
Hi I am very interested in PDA development in Linux is there any solution for this platform. in this development i woudl expect a database connection no matter what the programming language is either python, perl, java, ruby etc etc any ideas will be welcomed many thanks in advance __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com -- 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] PDA development help
On Thu Sep 29, 2005 at 18:21:20 -0700, pesoy misak wrote: Hi I am very interested in PDA development in Linux is there any solution for this platform. in this development i woudl expect a database connection no matter what the programming language is either python, perl, java, ruby etc etc any ideas will be welcomed many thanks in advance Hi, By PDA can I assume you mean personal digital assistant ? Or is it some other acronym I don't know of yet. In any case, there are lots of instances of Linux running on PDAs but these vary widly. You would need to provide much more information about your target platform. As for a database connection. I'm not sure that running a fullblown (or even half blown) database server on a PDA is necessarily the best way to go. Maybe you mean connecting to a remote database server? In any case, most of those languages have libraries for most database servers out there, but the api is going to be different for each. Perhaps you can provide more information on what you are doing to get a better answer. 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] PDA development help
On Fri, 2005-09-30 at 11:27 +1000, Benno wrote: As for a database connection. I'm not sure that running a fullblown (or even half blown) database server on a PDA is necessarily the best way to go. Maybe you mean connecting to a remote database server? I suspect an sqlite db ( http://sqlite.org/ ) would make a great... maybe three-quarter blown database for a handheld. -- Pete -- 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] PDA development help
pesoy misak wrote: Hi I am very interested in PDA development in Linux is there any solution for this platform. in this development i woudl expect a database connection no matter what the programming language is either python, perl, java, ruby etc etc I've done some coding on Linux running on an iPAQ. See : http://familiar.handhelds.org/ Familiar use sqlite for a DB, but I didn't need that for the project I was working on. Erik -- +---+ Erik de Castro Lopo +---+ `[Microsoft] are in the business of giving customers exactly what they ask for, which sounds like a nice idea until you realize that most Microsoft customers are idiots.' --- Eugene O'Neil on comp.os.linux.development.system -- 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] C-Pointers and Perl ?
On Friday 30 September 2005 06:07, [EMAIL PROTECTED] wrote: For just about everything you can do with a pointer in C there is a better, easier, less error prone way to do the same thing in O'caml and write less lines of code to do it. How about writing a network protocol stack. You get a packet and all you know about it is that here is a block of memory. You then have to figure out what sort of packet it is, how long it is and what structure to give it. C handles this very nicely with pointers to structures that can be cast into whatever you need. The one exception I can thing of is writing devices drivers and operating systems where you need to direct access to harware. If you are talking about I/O ports, you can always write a pair of functions to write and read from I/O and these can be added to any language (possibly even as inlines if the language supports that). There is no native I/O port access in C. Consider how useful functions like memcpy() and memcmp() are for writing an O/S. Consider also that an O/S is actually a form of self modifying code which strict type checking is designed to prevent. I isn't about direct hardware access, it is about having the flexibility to do what needs to be done. Try the simple exercise of writing an O'caml program that reads in a chunk of binary code from a file, and then executes that code to get a result. Less lines of code than C? Horses for courses! most of my programming would be much harder to do if I had to put up with wosname from the compiler. So I love pointers and arrays and not having to touch the hardware through thick felt gloves, but I conceed that in the middle of encrypted fpos transactions you proddly (probably :-) don't want to worry about them. if O'caml works for you yay, but don't presume that C is a bad option for me! I know how to write bullet-proof C. eg SPTA (NSW) train transponder system 5000 lines very complex C (digital filtering etc) several 1000 transponders every train every day 10 years BUGS Found: 0 QED James 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
[SLUG] slow default route and website
Hi Slugs, I can't seem to get to the bottom of this. I have an ADSL modem which connects to redhat firewall and then on another firewall eth port to a centos webserver in DMZ. i also have a dial up modem on a different account for testing, completely seperate to see how the web server behaves. DNS is hosted remotely at www.nerdie.net the ADSL modem is set (virtual server) to forward http requests to the firewall. the firewall is set to forward http to the webserver. this works except you can see the initial DNS request come through but the web page only starts to download after about 15 seconds. I also notice that on the firewall if I type route it prints the first lines on the screen but the default route line pauses also for about 15 seconds before displaying. it points to the ADSL modem. I don't understand why there is this 15 second delay after DNS to *start* to display the web page. (static simple test page). any clues? Ben -- 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] PDA development help
Hi all probably i didn't explain my situation properly :( sorry I mean I am trying to develop a client for PDA (Personal Digital Assistant) either with Palm or Pocket PC now the trouble is there isn't much documentation regarding this. and the database i would require to have Postgresql that is running on a normal PC so this PDA is a normal client accesss to this db what is the best approach for this development many thanks in advance --- Erik de Castro Lopo [EMAIL PROTECTED] wrote: pesoy misak wrote: Hi I am very interested in PDA development in Linux is there any solution for this platform. in this development i woudl expect a database connection no matter what the programming language is either python, perl, java, ruby etc etc I've done some coding on Linux running on an iPAQ. See : http://familiar.handhelds.org/ Familiar use sqlite for a DB, but I didn't need that for the project I was working on. Erik -- +---+ Erik de Castro Lopo +---+ `[Microsoft] are in the business of giving customers exactly what they ask for, which sounds like a nice idea until you realize that most Microsoft customers are idiots.' --- Eugene O'Neil on comp.os.linux.development.system -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com -- 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] C-Pointers and Perl ?
On Fri, Sep 30, 2005 at 10:32:01AM +1000, Benno wrote: Mmm, that is true. Languages I've used/know of, generally have `a way out', some way to bypass this, by writing some small stub in C. Which I guess I was assuming O'Caml (or smalltalk) would have. Ocaml is surprisingly/pleasingly (take your pick ;-) low level in parts. e.g. it's possible to overflow int without so much as an exception. Matt -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Tonights desktop apps talks - interactive
Your top-ten linux desktop apps Recently a hot topic divided into two threads, one remained mostly on-track and the other became discussion of programming and console tools. Tonight we're concentrating on GUI stuff that average new Linux users might be expected to operate, and guys like me who just stick to the command line mostly can probably learn a thing or two as well. I've installed one of our 600MHz thin-client machines with a 40GB HDD and Ubuntu on it and a bunch of apps discussed this week on the mailing list. I naturally haven't had time to play with them all and configure etc, that's where you lot come in grin. Given that other people will probably face the same dilema, it might be good to spend up to about 2 minutes configuring/playing with a given application. If nobody else has come up with anything I'm sure we can play with this lot for an hour or so grin. Here's the list:- web browsers firefox(in), konqueror(in), galeon(in) file managers - nautilus(in), thunar Office apps --- OpenOffice.org(in), abiword(in), mrproject(in), Image/photo editors/viewers --- gimp(in), gthumb(in), GQview(in), xv, QIV(in), qfaxreader(in via alien symlinks), f-spot(in) Multimedia players -- xmms(in), madman(in), rhythmbox(in), mplayer, xine(in), amarok, kaffiene, zinf (console) Music/video rippers --- sound juicer(in), grip(in), Multimedia authoring/editing GNU Octave(in), sweep(in) Email - evolution(in), thunderbird(in) Voip/video conference - xten, gphone Instant Messaging - gaim(in), psi, kopete Mail backend cyrus-imapd(in), sendmail(in) Webmail --- squirrelmail(in), www.roundcube.net, OpenWebMail(in) wMail http://wmail.sourceforge.net/ -- quite small, fairly barebones, has mostly OO code with a mix of some non-OO at the top level. IlohaMail http://blog.ilohamail.org/ Not entirely OO and uses tabs for indents. Has some classes. Seems to get good reviews. Has PGP encryption. JAWmail http://www.jawmail.org/ Very nice OO looking code, although could use de-tabbing. Uses some PEAR components. NOCC http://nocc.sourceforge.net/ -- OO code, well indented. .tar.gz file extracts into current directory, so be careful. Unknown/misc Gnome disk catalog, Kate, timex -- ---GRiP--- Electronic Hobbyist, Former Arcadia BBS nut, Occasional nudist, Linux Guru, SLUG President, AUUG and Linux Australia member, Sydney Flashmobber, Tenpin Bowler, BMX rider, Walker, Raver rave music lover, Big kid that refuses to grow up. I'd make a good family pet, take me home today! Some people actually read these things it seems. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Tonights desktop apps talks - interactive
On Fri, Sep 30, 2005 at 03:17:45PM EST, Grant Parnell wrote: Multimedia players -- xmms(in), madman(in), rhythmbox(in), mplayer, xine(in), amarok, kaffiene, zinf (console) Zinf also has an X front-end, but there are far better GUI players around IMO. Zinf does seem to be just about the best for console however. I'd be happy to show zinf if need be. -- 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
