Re: [Texmacs-dev] 1.0.3-2 release

[David Allouche]

On Thu, Jan 22, 2004 at 06:17:57PM +0100, Joris van der Hoeven wrote:
> 
> On Thu, 22 Jan 2004, David Allouche wrote:
> > On Wed, Jan 21, 2004 at 07:26:04PM +0100, Joris van der Hoeven wrote:
> > > 709: Agree that this would be cleaner,
> > >      but has this bothered anyone so far?
> >
> > I wrote this patch in reply to some post (Treinen?) reporting
> > compilation warnings on Alpha.
> >
> > Conversely, why keep using dirty code when a clean fix is available?
> > Note that some projects have policy to compile with -Werror (or
> > something like that) to turn warnings into errors.
> 
> Is -Werror supported everywhere. In that case, I agree to use that option.

Pretty much probably supported by any remotely sane version of gcc.

> But I don't understand why to use your complicated routine
> for hashing pointers. Why is casting to an integer not enough?
> Is it not possible to cast integers to pointers on some systems?

It is not safe when ptr is larger than in (on 64 archs for example).

> If not, how can we safely cast by forgetting about the uppermost bits?

reinterpret_cast would probably do it, but its behavious is explicitely
implementation-dependent.

Would could also use a union. Aliasing rules explictely support that use
of unions.

In any case, we do not really have a garantee to get the least
significant bits, that would be dependent on issues like word-alignement
and endianess. Well, I guess we could find way to figure the right thing
for various word alignement and endianness.

> In any case, I prefer a really fast hash function. If pointers have
> a double size of int than we may also first cast to long long int and
> then to int.

My function is explicitely designed to yield insanely fast code after
optimization. The branch test and loop limits compile time const values
and the loop will generally do only one or two iterations. That means
that any half decent optimizer will produce fast code code by harcoding
the branch and unrolling the loop, even the intermediate-language
optimizer of gcc.

On i386, that should yield the same code as a hash on the pointer casted
to int.

BTW, the current code is wrong anyway because the pointer value is _not_
hashed. It seems very questionable to assume that pointers make good
hash values.

Since the patch was broken by the savannah transition, I set it to
Action=Update, AssignedTo=ddaa. I'll fix it later.

> > > 848: Page size computations have to be rewritten once.
> >
> > Beg your pardon? This patch is about improving the File menu, and moving
> > some items out from the Viem menu. You said "Perturbates me; postponed;
> > will be rediscussed later." Page size computations have nothing to do
> > with that.
> 
> That was the previous or next one then.
> In any case, I don't deel like changing this now.

In any case I really do not see what patch you are talking about and I
still expect a statement about the change to file menu.

Patch broken too, I'll update it.

> Will come later this year.

Pleeeeeeeeeeeeeease, just a itsy bitsy tiny hint!

> > Action=None, Status=Closed.
> >
> > > 868: Not really useful for reasons pointed out before.
> > >      Idea is valid, but needs a lot more work...
> >
> > Action=Update, AssignedTo=ddaa
> >
> > I'll be trying to fix up something in my branch. Anyway, Proclus will
> > probably require some significant changes in the way the contextual menu
> > is supported.
> 
> For the moment, you may just create a proclus contextual menu and
> we will add a condition. Later this year, I will have a better scheme.

That is unrelated, but it would do wonders to my morale if you
illustrated your utterances of "I'll do it better later" by a small
paragraph explaining what you have in mind.

-- 
                                                            -- ddaa