From: Walt Mankowski Date: 23:16 on 30 Dec 2007 Subject: My own personal perl I hate macports. I know lots of people love it, but it seems like no matter what I try to do with it, I end up wanting to tear out my hair. I hate macports, and it hates me right back. Everyone's been telling me how great git is (I suspect it's as hateful as any other vc software, but I won't know until I try it on a real project), so I decided to give it a try. On debian this is easy -- "apt-get install git-core". But installing it on my macs wasn't so easy. Git sadly isn't in fink, so I tried installing it from macports. As you'd expect, before it could build git-core it had to download and install some dependencies, things like expat and libiconv. I figured it was going to take a while so I went back to what I was doing. A few minutes later I checked to see how it was doing. To my surprise, it was building perl! WTF! Oh, and since according to the macports installation instructions. /opt/local/bin was at the front of my PATH, their perl was now my default perl! I'd just been using the default Tiger perl (5.8.6, I think) so none of the CPAN modules I'd installed were visible to this perl. According to the macports people, this is a Feature. Everything's supposed to be self-contained, so since git-core comes with a few auxiliary perl scripts it needs its own copy of perl as well. I suppose that makes some sort of sense. But it seems to me that if you can't figure out how to install a few perl scripts ON A SYSTEM THAT SHIPS WITH PERL without essentially breaking the system perl, then something's very, very wrong. Sigh. And don't get me started on the hateful way they handle package dependencies... Walt
From: Benjamin Reed Date: 01:53 on 31 Dec 2007 Subject: Re: My own personal perl -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Walt Mankowski wrote: > Git sadly isn't in fink, so I tried installing it from macports. As git's in fink, but it's not in the binary repository, so you need to enable unstable and then 'fink install' it. http://pdb.finkproject.org/pdb/package.php/git - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development http://www.racoonfink.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHeEuQUu+jZtP2Zf4RAgd9AKCNk553SbDDKXzAl2nhdxbhSfOR8QCeO6GK gIphTRHlpe3DNlpDO5kkByk= =FjPD -----END PGP SIGNATURE-----
From: Walt Mankowski Date: 02:19 on 31 Dec 2007 Subject: Re: My own personal perl On Sun, Dec 30, 2007 at 08:53:20PM -0500, Benjamin Reed wrote: > git's in fink, but it's not in the binary repository, so you need to > enable unstable and then 'fink install' it. Yeah, I know. I was really trying to avoid messing with unstable unless I really had to. I'm sure it'll make it to stable in another 2-3 years. :) Walt
From: Benjamin Reed Date: 02:36 on 31 Dec 2007 Subject: Re: My own personal perl -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Walt Mankowski wrote: > Yeah, I know. I was really trying to avoid messing with unstable > unless I really had to. I'm sure it'll make it to stable in another > 2-3 years. :) If you'll mess with macports, you might as well use fink unstable. It's tested at least as well as their "everything" tree. =) - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development http://www.racoonfink.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHeFXDUu+jZtP2Zf4RAteRAJ44KzvT8FVS3+3jPH4xf3uX9iO/zgCePwIV yQNnUedQ6admtwHAYB9CQjg= =FgDg -----END PGP SIGNATURE-----
From: Walt Mankowski Date: 02:45 on 31 Dec 2007 Subject: Re: My own personal perl --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 30, 2007 at 09:36:51PM -0500, Benjamin Reed wrote: > Walt Mankowski wrote: >=20 > > Yeah, I know. I was really trying to avoid messing with unstable > > unless I really had to. I'm sure it'll make it to stable in another > > 2-3 years. :) >=20 > If you'll mess with macports, you might as well use fink unstable. It's > tested at least as well as their "everything" tree. =3D) Yeah, well I only tried it because I figured it was more stable than unstable, and that it would handle dependencies better than compiling =66rom tarballs... Walt --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHeFfJXfGeK2entYQRAkqmAKDEznt4+RG2bCSRvSw2hIL3bb6n0gCfW4ib wJAH9TdD/gPZ8dyA82aYkD0= =V4wt -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ--
From: numien Date: 06:39 on 31 Dec 2007 Subject: Re: My own personal perl Walt Mankowski wrote: > ...and that it would handle dependencies better than compiling > from tarballs... > > Walt Handle dependencies... there's an oxymoron in that, I'm sure.
From: numien Date: 20:42 on 01 Jan 2008 Subject: Java types/compilers/something Type mismatch: cannot convert from List<Serializable> to List<Serializable> That's very... kind... of you, Java. I much appreciate your strict typing keeping me from making the mistake of accidentally using a List<Serializable> as a List<Serializable> when it obviously wasn't what I meant. Really. I'll come worship the Sun-god in a few hours, once I'm done stabbing my eyes out.
From: Jarkko Hietaniemi Date: 22:47 on 01 Jan 2008 Subject: Re: Java types/compilers/something numien@xxxxxxxxx.xxx wrote: > Type mismatch: cannot convert from List<Serializable> to List<Serializable> > > That's very... kind... of you, Java. I much appreciate your strict > typing keeping me from making the mistake of accidentally using a > List<Serializable> as a List<Serializable> when it obviously wasn't what > I meant. Really. I'll come worship the Sun-god in a few hours, once I'm > done stabbing my eyes out. Here's C++ in all its typing glory: x.cc:2: error: invalid cast from type ‘int’ to type ‘int’ > >
From: Yossi Kreinin Date: 08:47 on 02 Jan 2008 Subject: Re: Java types/compilers/something Jarkko Hietaniemi wrote: > numien@xxxxxxxxx.xxx wrote: >=20 >>Type mismatch: cannot convert from List<Serializable> to List<Serializa= ble> >=20 > x.cc:2: error: invalid cast from type =91int=92 to type =91int=92 >=20 Um... how did you do this?
From: Jarkko Hietaniemi Date: 13:07 on 02 Jan 2008 Subject: Re: Java types/compilers/something Yossi Kreinin wrote: > Jarkko Hietaniemi wrote: >> numien@xxxxxxxxx.xxx wrote: >> >>> Type mismatch: cannot convert from List<Serializable> to List<Serializable> >> x.cc:2: error: invalid cast from type ‘int’ to type ‘int’ > > Um... how did you do this? > reinterpret_cast<int>(0)
From: Peter da Silva Date: 13:27 on 02 Jan 2008 Subject: Re: Java types/compilers/something On 2008-01-02, at 07:07, Jarkko Hietaniemi wrote: > reinterpret_cast<int>(0) What in the name of Ritchie does that mean?
From: Jarkko Hietaniemi Date: 15:06 on 02 Jan 2008 Subject: Re: Java types/compilers/something On Jan 2, 2008 8:27 AM, Peter da Silva <peter@xxxxxxx.xxx> wrote: > On 2008-01-02, at 07:07, Jarkko Hietaniemi wrote: > > reinterpret_cast<int>(0) > > What in the name of Ritchie does that mean? I don't know, and apparently g++ doesn't know either. > >
From: Walt Mankowski Date: 15:15 on 02 Jan 2008 Subject: Re: Java types/compilers/something On Wed, Jan 02, 2008 at 10:06:38AM -0500, Jarkko Hietaniemi wrote: > On Jan 2, 2008 8:27 AM, Peter da Silva <peter@xxxxxxx.xxx> wrote: > > On 2008-01-02, at 07:07, Jarkko Hietaniemi wrote: > > > reinterpret_cast<int>(0) > > > > What in the name of Ritchie does that mean? > > I don't know, and apparently g++ doesn't know either. Isn't it just the C++ way of doing this: (int) 0 Not sure why you'd ever need to do that, mind you...
From: Yossi Kreinin
Date: 16:24 on 02 Jan 2008
Subject: Re: Java types/compilers/something
Walt Mankowski wrote:
>
> Isn't it just the C++ way of doing this:
>
> (int) 0
There are 4 ways of doing "this" in C++: reinterpret_cast, static_cast,
dynamic_cast and const_cast. Now, const_cast can only cast away cv qualifiers
(const and volatile). dynamic_cast uses RTTI for the casting, which means that
it won't downcast a pointer to the wrong derived type, and has a chance of
working with virtual inheritance. static_cast works according to the statically
known type info, ignoring dynamic type info, and won't cast away cv qualifiers.
I think. Now, the question is, and I really mean "the question" because I don't
know the answer: what does reinterpret_cast do? I think it's supposed to be for
"reinterpreting the bits of x having type A as if it really had the type B", but
I'm pretty sure it's more complicated than that. I only used it once to pass
parameters to an asm macro and then it stopped working upon a compiler upgrade
and I changed the spelling to C-like and it worked.
>
> Not sure why you'd ever need to do that, mind you...
>
Macro expansion or template instantiation or code generation or whatever results
in all kinds of corner cases. It's nice when int a[]={1,2,}; compiles although a
human probably wouldn't insert that last comma, for example. And then the error
message in the reinterpret_cast case is utterly ridicuous.
From: Rafael Garcia-Suarez Date: 16:33 on 02 Jan 2008 Subject: Re: Java types/compilers/something On 02/01/2008, Yossi Kreinin <yossi.kreinin@xxxxxxxx.xxx> wrote: > I think. Now, the question is, and I really mean "the question" because I don't > know the answer: what does reinterpret_cast do? I think it's supposed to be for > "reinterpreting the bits of x having type A as if it really had the type B", but > I'm pretty sure it's more complicated than that. I only used it once to pass > parameters to an asm macro and then it stopped working upon a compiler upgrade > and I changed the spelling to C-like and it worked. It's for converting between pointers to unrelated types. I *think* it can also be used for refs (foo&). I *think* it can also be used for storing a pointer into a sufficently large int, and vice versa.
From: Walt Mankowski
Date: 16:39 on 02 Jan 2008
Subject: Re: Java types/compilers/something
--OROCMA9jn6tkzFBc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Jan 02, 2008 at 06:24:00PM +0200, Yossi Kreinin wrote:
> Macro expansion or template instantiation or code generation or whatever=
=20
> results in all kinds of corner cases. It's nice when int a[]=3D{1,2,};=20
> compiles although a human probably wouldn't insert that last comma, for=
=20
> example. And then the error message in the reinterpret_cast case is utter=
ly=20
> ridicuous.
Good point. I've worked on a system that generates C code. It
intentionally does things like that which would be fairly hateful if a
human programmer did them, but make sense for machine-generated code.
It makes the generator simpler if it doesn't have to worry about
dealing with the weird edge cases.
Walt
--OROCMA9jn6tkzFBc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHe75NXfGeK2entYQRAleAAJ9X53z/nTafSmCWFBKxvnFIm7QcbQCgt89R
qfTw+psc6atoIBsodk8mctM=
=uGxF
-----END PGP SIGNATURE-----
--OROCMA9jn6tkzFBc--
Generated at 10:26 on 16 Apr 2008 by mariachi