Re: [SLUG] Installing Perl modules on Solaris

[saurabh shukla]

Hi Gavin,

Thanks for the direction.

Here is what I had to do to get it working. Hoping it will help someone 
who faces the same problem.


I follwed the following steps to get it working.

1) Got perl from sunfreeware.com, and it didnt work with my version of 
gcc 3.23 (which I had got from sunfreeware.com).


2) Got gcc version  3.4.2 from sun's website. Its part of free software 
for solaris.


Got some error like:
> /usr/ccs/bin/as: error: unknown option '-'
> /usr/ccs/bin/as: error: unknown option 't'
> /usr/ccs/bin/as: error: unknown option 'aditional-format'
>

3) This happened because of mixture of solaris and gnu components 
causing errors. Set my PATH to 
/usr/sfw/bin:/opt/sfw/bin:/usr/local/bin:/usr/bin:/usr/sbin


and it all worked perfectly.

Saurabh




Gavin Carr wrote:

On Thu, Sep 29, 2005 at 03:33:27PM +1000, saurabh shukla wrote:


   I see you're using perl 5.008004 on sun4-solaris-64int, okay.




cc -c   -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO 
-xO3 -xspace -xildoff   -DVERSION=\"1.48\" -DXS_VERSION=\"1.48\" -KPIC 
"-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"  -DDBI_NO_THREADS Perl.c

/bin/sh: cc: not found
make: *** [Perl.o] Error 1
 /usr/local/bin/make  -- NOT OK
Running make test
 Can't test without successful make
Running make install
 make had returned bad status, install seems impossible


I dont have cc installed on my machine however I do have gcc version 
3.3.2 installed. Can I change some setting to force perl to use gcc 
instead of CC ?



Welcome to the joys of solaris! Nope, you can't use gcc to compile perl 
modules into a cc-compiled perl or the ground will open and swallow you 
up, etc. Your best bet is probably to grab the perl from sunfreeware.com, 
or to go and find yourself a cc to use. Only affects non-pure-perl 
modules, of course, but they're the best ones.


Cheers,
Gavin




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

[Luke Yelavich]

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

[SLUG] Tonights desktop apps talks - interactive

[Grant Parnell]

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

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



-- 
--
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] C-Pointers and Perl ?

[Matthew Hannigan]

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

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

[Matthew Hannigan]

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

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

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

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

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

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


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

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

[Angus Lees]

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

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

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

 #!/usr/bin/pugs
 use v6;

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

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

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

Re: [SLUG] PDA development help

[Benno]

On Thu Sep 29, 2005 at 20:46:07 -0700, pesoy misak wrote:
>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
>

Mmm, I found 3 or 4 years ago when I was doing this for a living that
Palm had quite extensive documentation which made it easy to target
using a GNU toolchain.

The device I was targetting did not have network ability and database
updates were down when the device was placed in the cradle and
performed a HotSync.

Basically we wrote our own HotSync script in python which would
download the data from the palm and then do apprpriate database
inserts to get stuff into the postgres database.

I still don't think I'm actually answering the question you have, but
I'm trying!

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

[pesoy misak]

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

[SLUG] slow default route and website

[Ben Donohue]

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] Your top-ten linux desktop apps

[James]

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

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

Re: [SLUG] C-Pointers and Perl ?

[James]

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 , 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] PDA development help

[Erik de Castro Lopo]

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] Your top-ten linux desktop apps

[James]

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

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

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

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

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

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

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

intel lets you:

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

most other architectures insist

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

or even worse

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

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

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

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

Re: [SLUG] PDA development help

[Peter Hardy]

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] PDA development help

[Benno]

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

[SLUG] PDA development help

[pesoy misak]

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] C-Pointers and Perl ?

[Bruce Badger]

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

Re: [SLUG] Output from 64 bit machine

[Benno]

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 ?

[Benno]

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

[Ian Wienand]

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 ?

[Bruce Badger]

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

[Benno]

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] Re: squirrellmail/roundcube

[Del]

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

[Erik de Castro Lopo]

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] C-Pointers and Perl ?

[Robert Collins]

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


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: OS implementation languages (was: Re: [SLUG] C-Pointers and Perl ?)

[Erik de Castro Lopo]

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] Your top-ten linux desktop apps

[O Plameras]

Erik de Castro Lopo wrote:


O Plameras wrote:

 

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



I have never personally seen such a book.

 



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

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

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



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



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

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

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

first hand.

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

were the same.

Erik
 




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

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

Re: [SLUG] Output from 64 bit machine

[Robert Collins]

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


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

[Peter Rundle]

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] Ajax-based Open Source Exchange replacement

[Kevin Saenz]

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

OS implementation languages (was: Re: [SLUG] C-Pointers and Perl ?)

[Benno]

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] Your top-ten linux desktop apps

[Erik de Castro Lopo]

O Plameras wrote:

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

I have never personally seen such a book.

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

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

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

Re: [SLUG] C-Pointers and Perl ?

[Erik de Castro Lopo]

[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] Output from 64 bit machine

[Erik de Castro Lopo]

Peter Rundle wrote:

> Compiled on a Dec Alpha running OpenVMS 7.2
> 
> VMS>run 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 ?

[Benno]

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

[SLUG] Ajax-based Open Source Exchange replacement

[slug]

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] Output from 64 bit machine

[O Plameras]

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

VMS>run 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

Please change the topicRe: [SLUG] Your top-ten linux desktop apps

[David]

Gr.

Can't you guys change the subject line?

I was REALLY interested in the top ten thread
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

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

[O Plameras]

[EMAIL PROTECTED] wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

 


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

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



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

 



I take your point.

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

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

Sigh 

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

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

Re: [SLUG] Output from 64 bit machine

[telford]

-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
> 
> VMS>run 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

[telford]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

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

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

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

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

- Tel

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

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

[SLUG] Output from 64 bit machine

[Peter Rundle]

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

VMS>run 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

[telford]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

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

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

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

- Tel

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

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

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

[Ian Wienand]

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

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

-i


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

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

[telford]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Sep 29, 2005 at 10: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

[telford]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

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

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

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

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

Re: [SLUG] C-Pointers and Perl ?

[telford]

-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

[O Plameras]

Erik de Castro Lopo wrote:


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


O Plameras wrote:

 


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

Can anyone clarify ?
   



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

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



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

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

Thanks.

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

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

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

[Erik de Castro Lopo]

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


O Plameras wrote:

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

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

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


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

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

[Erik de Castro Lopo]

O Plameras wrote:

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

That is not right.

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

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

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

Erik

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

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

[O Plameras]

Erik de Castro Lopo wrote:


O Plameras wrote:

 


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



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

 


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



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

 



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

Can anyone clarify ?


it appears without having gone through the arch-docs.
   



I thoroughly recommend you do.

Erik
 




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

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

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

[O Plameras]

Erik de Castro Lopo wrote:


O Plameras wrote:

 


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



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

 



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

change should really be a register architecture change.

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


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



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

 


it appears without having gone through the arch-docs.
   



I thoroughly recommend you do.

Erik
 




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

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

[SLUG] Converting video tapes.

[John Gibbons]

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]

O Plameras wrote:

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

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

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

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

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

I thoroughly recommend you do.

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

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

[O Plameras]

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] C-Pointers and Perl ?

[Jeff Waugh]

> > 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] C-Pointers and Perl ?

[James Gray]

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 ?

[Benno]

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] Your top-ten linux desktop apps

[Ian Wienand]

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

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

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

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

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

-i


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

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

[Robert Collins]

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


ROTFL.

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

Rob

-- 
GPG key available at: .


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

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

[Erik de Castro Lopo]

O Plameras wrote:

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

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

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

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

[O Plameras]

Felix Sheldon wrote:


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

Thanks for this. 


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

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


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

Thanks again.

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



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

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

[Erik de Castro Lopo]

[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

[telford]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

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

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

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

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


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

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


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


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

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

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

[Felix Sheldon]

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


O Plameras wrote:



Does anybody have a 64-bit computer ?

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


Thanks.

#include 

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


Ian Wienand wrote:


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


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



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

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

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







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

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

[Erik de Castro Lopo]

Jeff Waugh wrote:

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

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

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

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

[Jeff Waugh]

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

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

- Jeff

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

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

[Ian Wienand]

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

Have a look at the AMD64 ABI, for example

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

Figure 3.1 gives you the size of types.

-i


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

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

[Erik de Castro Lopo]

O Plameras wrote:

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

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

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

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

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

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

[O Plameras]

Ian Wienand wrote:


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


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



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

-i
 



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

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

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

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

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

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

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

[O Plameras]

Does anybody have a 64-bit computer ?

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


Thanks.

#include 

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


Ian Wienand wrote:


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


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



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

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

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





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

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

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

[Erik de Castro Lopo]

Ian Wienand wrote:

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

Indeed!!

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

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

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

[Ian Wienand]

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

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

-i


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

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

[O Plameras]

Ian Wienand wrote:


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


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



 



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


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

 


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

I use this code to check:

[EMAIL PROTECTED] cp]# cat sizeof.c

#include 

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

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


I have a 32-bit PC.


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

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




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

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

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

[Ian Wienand]

On Thu, Sep 29, 2005 at 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

[Bruce Badger]

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

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

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

2 ** 64
18446744073709551616

2 ** 128
340282366920938463463374607431768211456

2 ** 256
115792089237316195423570985008687907853269984665640564039457584007913129639936

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

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

Re: [SLUG] C-Pointers and Perl ?

[Erik de Castro Lopo]

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] C-Pointers and Perl ?

[O Plameras]

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 ?

[Erik de Castro Lopo]

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] Your top-ten linux desktop apps

[O Plameras]

Bruce Badger wrote:


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


Python can be nicer than that:

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

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



So can Smalltalk! :-)

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



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

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

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

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



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

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

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

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




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

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

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

[Andrew Bennetts]

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

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

-Andrew.

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

[SLUG] Re: squirrellmail/roundcube

[Ben Buxton]

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

[Bruce Badger]

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

So can Smalltalk! :-)

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

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

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

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

[SLUG] Re: ctrl-alt-left ctrl-alt-right under VNC (OT?)

[Bill]

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] C-Pointers and Perl ?

[O Plameras]

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

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

[O Plameras]

Sam Couter wrote:


O Plameras <[EMAIL PROTECTED]> wrote:
 


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



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

 

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


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


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

to make the program work.

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


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

to make the program work.

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

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


for (initialise; guard; increment) { body }

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

 



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


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

 

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


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



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

 


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

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


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



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

 


Aha !  So, it's C language.

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


Erik said:

 


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


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



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

I've explained this previously. 


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

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

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

[Andrew Bennetts]

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

Python can be nicer than that:

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

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

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

-Andrew.

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

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

[Erik de Castro Lopo]

Angus Lees wrote:

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

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

So, Gus, what happens when you do:

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

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

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

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

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


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