On 5/18/11 May 18 -12:26 AM, Chun Tian (binghe) wrote:

I found a workaround for myself:

(in-package :asdf)

(defun user-homedir () #P"Macintosh HD:Users:binghe:")

with above code loaded as a ASDF patch, I can load other packages well.

As I read this, it's simply a bug in MCL --- they just aren't implementing user-homedir-pathname properly.

Isn't that right?

--binghe

在 2011-5-18，13:05， Chun Tian (binghe) 写道：

...

Hi, ASDF developers

Some time ago I can use ASDF with Macintosh Common Lisp, but recently I can't any more.

I updated to latest ASDF 2 and compile/load it into MCL (my current version is 6.0, but 5.2.1 has the same problem):

? (pushnew #P"Macintosh HD:Users:binghe:Lisp:usocket:branches:0.5.x:" asdf:*central-registry* :test 'equal) (#P"Macintosh HD:Users:binghe:Lisp:usocket:branches:0.5.x:") ? (asdf:load-system :usocket)

...

Error: Not an absolute pathname: #4P"home:" While executing: ASDF::RESOLVE-ABSOLUTE-LOCATION-COMPONENT Type Command-. to abort.

See the Restarts… menu item for further choices. 1 >

I don't know what does ASDF::RESOLVE-ABSOLUTE-LOCATION-COMPONENT try to do, but I see a fact that MCL's standard function USER-HOMEDIR-PATHNAME can only return the MCL installation directory but current Mac user's home directory:

? (user-homedir-pathname) #4P"home:" ? (truename *) #P"Macintosh HD:Users:binghe:Lisp:MCL 6.0:"

I think above function should return #P"Macintosh HD:Users:binghe:" instead. And I see ASDF depend on USER-HOMEDIR-PATHNAME, so that there's no way to store compiled fasls into "~/.cache/common-lisp" ...

Regards,

Chun Tian (binghe)

---

asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

On 18 May 2011, at 15:28, Robert Goldman wrote:

On 5/18/11 May 18 -12:26 AM, Chun Tian (binghe) wrote:

...

I found a workaround for myself:

(in-package :asdf)

(defun user-homedir () #P"Macintosh HD:Users:binghe:")

with above code loaded as a ASDF patch, I can load other packages well.

As I read this, it's simply a bug in MCL --- they just aren't implementing user-homedir-pathname properly.

Isn't that right?

No, it's not right. The meaning of user-homedir-pathname is (intentionally) underspecified in ANSI CL.

MCL (and thus RMCL) were originally developed for Mac OS 9 and older. In those operating systems, the notion of a user directory didn't exist, so the user-homedir-pathname function doesn't have any meaning there, and is allowed by ANSI CL to be implementation-dependent, so MCL does something that seems arbitrary to non-MCL users, but has a meaning for MCL users. RMCL's existence is justified to be able to run code that was originally developed for MCL, so changing the meaning of user-homedir-pathname would unnecessarily break existing applications (and it seems that there are considerably more users than some people seem to assume).

It would be good if ASDF wouldn't rely on such underspecified features, or if it would have a way to deal with the lack of such features in a more meaningful way because, for example, this may not be the last time in history that the notion of a user directory isn't supported or, as another example, that pathnames look different from the usual Unix flavors that you see these days.

Pascal

-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

On 19 May 2011, at 20:58, Robert Goldman wrote:

On 5/19/11 May 19 -1:24 PM, Pascal Costanza wrote:

...

On 18 May 2011, at 15:28, Robert Goldman wrote:

...

On 5/18/11 May 18 -12:26 AM, Chun Tian (binghe) wrote:

...

I found a workaround for myself:

(in-package :asdf)

(defun user-homedir () #P"Macintosh HD:Users:binghe:")

with above code loaded as a ASDF patch, I can load other packages well.

As I read this, it's simply a bug in MCL --- they just aren't implementing user-homedir-pathname properly.

Isn't that right?

No, it's not right. The meaning of user-homedir-pathname is (intentionally) underspecified in ANSI CL.

I was not very careful here. The meaning of U-H-D is *not* underspecified when the host is provided as an (optional) argument. If we were providing our host as an argument to the function, then I believe the MCL behavior would be clearly buggy, since the spec says:

"The definition of home directory is implementation-dependent, but defined in Common Lisp to mean the directory where the user keeps personal files such as initialization files and mail."

There is no such directory in pre Mac OS X.

I don't think that the MCL behavior of supplying the installation directory of the lisp implementation is defensible in light of the above language.

OK, in this case I was not careful. Here is what the documentation says:

When Macintosh Common Lisp is run, two logical hosts are set up automatically: * The host "ccl" is set to the directory holding the MCL application. * The host "home" is set to the directory holding the document that was launched with Macintosh Common Lisp.

user-homedir-pathname returns #P"home:" which points to wherever you started MCL from (for example, by double-clicking on some .lisp file).

...

It would be good if ASDF wouldn't rely on such underspecified features, or if it would have a way to deal with the lack of such features in a more meaningful way because, for example, this may not be the last time in history that the notion of a user directory isn't supported or, as another example, that pathnames look different from the usual Unix flavors that you see these days.

Point taken, but I think this is unfair to ASDF. This seems more like a case where (as with many things involving interaction with filenames and directories) the ANSI standard doesn't give us any /specified/ features that fill a very real need. So we necessarily rely on underspecified features. What are the /specified/ features that will fill this need?

Indeed, one of the things that ASDF does is provide a POSIX-ish portable file system sub-system precisely because the specified facilities (pathnames, logical pathnames) didn't do the job.

Because ASDF 2.x caused me some trouble in RMCL, I actually put some effort into learning logical pathnames - and they seem to work extremely well, as far as I can tell (but it requires specifying :ignore-inherited-configuration in my source registry configuration, which seems somewhat unclean to me - but I don't really know...)

Pascal

-- Pascal Costanza

...

: Pascal Costanza Because ASDF 2.x caused me some trouble in RMCL, I actually put some effort into learning logical pathnames - and they seem to work extremely well, as far as I can tell

Beware logical pathnames. They may "work extremely well" in some implementations, and completely differently in some other — or be absent or not well supported. In other words, they are not portable, not enough the extremely constrained subset that is defined as portable in the spec. That's the main reason why ASDF2, while it will let you use them, isn't based on them.

If you want to start on a crusade to the spec to be extended to be more useful and/or to get all Lisp implementations to actually use such a spec — I'm sure many CL users will love you (especially janderson!). Good luck.

...

(but it requires specifying :ignore-inherited-configuration in my source registry configuration, which seems somewhat unclean to me - but I don't really know...)

Why do you have to :ignore-inherited-configuration ??? Is there or was there something buggy in ASDF2? Why didn't you report the bug and get it fixed?

: Robert Goldman One undesirable feature is their refusal to permit filenames containing underscores or spaces:

word---one or more uppercase letters, digits, and hyphens.

And SBCL, being the language lawyering prick we love it to be, does enforce these limitations like all those it can from the standard. Of course, Corman doesn't have portable pathnames, I wouldn't trust GCL, and there might be bugs in ABCL, etc.

I have also found that in practice merge-pathnames works inconsistently across lisp implementations.  Those inconsistencies seem acceptable within the scope of the ANSI spec.  This is actually something that is true of pathnames in general, and not just logical pathnames.  I believe that this is part of the reason that Faré moved to his own POSIX-y pathnames.

CL Pathnames are a pile of FAIL. Implementors try to save the day, each in his own way, incompatible with what other implementors do. ASDF papers somewhat over the fail with its own syntactic abstraction layer.

Every time I have used logical pathnames, or even just used pathnames, they have blown up in my face, sooner or later, when code moved from one lisp implementation to another.  I, for one, welcome Fare replacing them inside ASDF2...

Thank you!

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Trillions of fossils can't be wrong!

If you use multiple lisp implementations, I'm now convinced that using logical pathnames is tantamount to taking a big pile of hours, putting them in an ashtray, and setting fire to them.

However, if you are only ever, ever, ever going to use but one implementation, then feel free to use "portable" pathnames and other forms of non-portable pathnames to your heart's content.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There's no worse blasphemy than to claim authority on telling what pleases or displeases God. Hence prophets and priests are the most impious men on earth.

I tried to use the mechanism promoted by ASDF. It worked in 7 out of 8 Common Lisp implementations that I have checked. Unfortunately, it didn't work in the eighth one at all, no matter what I tried. This has cost me quite some time that was eventually wasted.

I apologize for any such bug. What mechanism are you talking about, which implementation did it fail on, and how may we help you with it?

Communication is a two-way street, and we can't fix your problems if you don't communicate about them. I now see that there was an issue about RMCL that didn't get fixed in my attempt in january, and that in the long email discussion that took place I missed one of your complaints.

Please keep complaining if there is anything we miss.

It sometimes helps to start a new discussion with a specific complaint, rather than respond to a long earlier discussion that started with a different complaint, even when the two complaints are somehow related.

I then invested the time to learn logical pathnames, and came up with a solution that works in 8 out of 8 Common Lisp implementations. So my experience is exactly the opposite of yours.

I'm just the messenger. I don't understand why I get attacked for delivering the message.

Logical pathnames work well as long as all your files follow the naming restrictions. Which is not the case for all CL programs and libraries, even less so when you're integrating with other languages and their naming conventions, or (shudder) files that have version numbers in them...

If they work well for you, more power to you. But ASDF cannot possibly depend on them.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Life is the worst of all social inequalities. To suppress inequalities, one must either resurrect all the dead people (and give life to all the potential living people), or exterminate all the actually living. Egalitarians, since they cannot further their goal by the former method, inevitably come to further it by the latter method.

On 21 May 2011, at 01:21, Faré wrote:

...

Logical pathnames work well as long as all your files follow the naming restrictions. Which is not the case for all CL programs and libraries, even less so when you're integrating with other languages and their naming conventions, or (shudder) files that have version numbers in them...

If they work well for you, more power to you. But ASDF cannot possibly depend on them.

Also, logical-pathnames require some magic setup to happen early in the system configuration. Details of such configuration is completely implementation-dependent, and it would be a bootstrapping catch-22 to require casual users to do this configuration before they could use ASDF. More work for less bang. Yet another reason why ASDF does not depend on logical-pathnames, and why I do not recommend that anyone should bother with them for anything remotely "portable". Of course, if you already paid the price, you're free to keep using them and live with their limitations.

The setup is not that hard. Here is what I have in my .sbclrc

(setf (logical-pathname-translations "costanza") `(("**;*.fasl.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.fasl" (lisp-implementation-type) (lisp-implementation-version))) ("**;*.*.*" "/Users/costanza/**/*.*")))

This is all that is necessary, and it looks pretty much the same for all CL implementations. This can probably very easily be abstracted to make it even easier to set up.

I don't have anything against the support for Unix-style pathnames, but I don't think that ASDF is the right place to define them. Either they are useful for people who only care for Unix-like environments, but then they probably care independent from whether they want to use ASDF or not. Or they don't want to narrow themselves down to Unix-style environments, but then getting that overhead just for wanting to use ASDF doesn't make that much sense. In my opinion, this speaks for separating them out of ASDF (and ASDF could take advantage of them in case it detects they are present).

I know this is all difficult to set up and requires a lot of time and energy, so I also understand why you may not want to go the extra mile to work on such a separation.

Pascal

-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

On 23 May 2011, at 00:17, Faré wrote:

...

The setup is not that hard. Here is what I have in my .sbclrc

(setf (logical-pathname-translations "costanza") `(("**;*.fasl.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.fasl" (lisp-implementation-type) (lisp-implementation-version))) ("**;*.*.*" "/Users/costanza/**/*.*")))

This is all that is necessary, and it looks pretty much the same for all CL implementations. This can probably very easily be abstracted to make it even easier to set up.

But ASDF can't require each and every user to learn about logical pathnames and how to set them up in their specific implementation, each and every system writer to adhere to naming limitations of "logical pathnames", etc. That would raise the bar to adoption, not lower it.

This is only true under the assumption that what ASDF 2 adds on top of ASDF 1 is easy to learn, but that's not the case either.

...

I don't have anything against the support for Unix-style pathnames, but I don't think that ASDF is the right place to define them.

We needed *some* syntax for relative pathnames, to allow things like (:module "baz/quux" :components ((:file "foo/bar-V1.200"))) And considering their limitations, logical pathnames didn't cut it.

[...]

Please explain what you want to separate from ASDF, and how you propose users of ASDF to portably specify relative pathnames.

In the bad old days of ASDF 1, I've done my lot of (:module "foo-bar" :pathname #.(merge-pathnames (make-pathname :directory '(:relative "foo" "bar") :defaults *some-directory* #| required for the :host and :device slots |#) *some-directory*) ...)

NO, THANKS! Now it's just (:module "foo/bar" ...)

Why was that necessary? It was possible to say (:module "foo" (:module "bar" ...) ...) [or something similar], no?

...

I know this is all difficult to set up and requires a lot of time and energy, so I also understand why you may not want to go the extra mile to work on such a separation.

Since you seem to be the only one here with a clue what you mean, why don't you come with a proposal and/or a patch?

Well, as a minimum, I have two requests to make changes in the documentation:

- In Section 3.1, the documentation says the following: "The simplest way to add a path to your search path, say /home/luser/.asd-link-farm/ is to create the directory ~/.config/common-lisp/source-registry.conf.d/ and there create a file with any name of your choice but the type conf, for instance 42-asd-link-farm.conf containing the line: (:directory "/home/luser/.asd-link-farm/")"

This is very confusing, because the "old style" using asdf:*central-registry* is decidedly much simpler. So the sentence above needs some explanation in what sense the "new style" is simpler.

- Section 5.3.6 should be renamed. The main body of the text is about how to use logical pathnames with ASDF 2, and is not a "warning." The recommendation not to use logical pathnames should also be removed, because it is not substantiated (and is therefore not a "warning," because it doesn't say what the potentially bad effects of using logical pathnames are).

There are advantages and disadvantages with using both either logical pathnames or the ASDF 2 approach. Any future Common Lisp implementation that claims adherence to ANSI CL will support logical pathnames, and so it will be relatively straightforward to use logical pathnames in conjunction with ASDF 2, while ASDF 2 will probably need patching in order to support such a future Common Lisp system, which can be regarded as an advantage of logical pathnames over the ASDF 2 approach.

I think that statements of personal preference should not have a place in the documentation of a tool that is supposed to be used by the whole Common Lisp community, but such a documentation should rather reflect the wide range of opinions in that community.

Pascal

-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

On 29 May 2011, at 23:05, Robert Goldman wrote:

On 5/28/11 May 28 -1:50 PM, Pascal Costanza wrote:

...

....

...

Well, as a minimum, I have two requests to make changes in the documentation:

• In Section 3.1, the documentation says the following: "The simplest way to add a path to your search path, say /home/luser/.asd-link-farm/ is to create the directory ~/.config/common-lisp/source-registry.conf.d/ and there create a file with any name of your choice but the type conf, for instance 42-asd-link-farm.conf containing the line: (:directory "/home/luser/.asd-link-farm/")"

This is very confusing, because the "old style" using asdf:*central-registry* is decidedly much simpler. So the sentence above needs some explanation in what sense the "new style" is simpler.

I would be happy to splice into the manual an account of the "old school" way to configure ASDF. I mostly still use this myself, albeit with the aid of a couple of ancillary libraries that are used at our company to make it possible to smoothly make consistent configurations across users without enforcing commonality in users' directory trees. Hence my configuration instructions are not easily portable. But I would be happy to merge contributions from you or others to the manual and wrangle the texinfo.

Until then, the manual states that asdf:*central-registry* is maintained for backwards compatibility, so I believe Fare is correct to refer to this as the simplest method, with the implicit qualifier of "current" or "going forward." Again, if you disagree strongly enough, you are more than welcome to supply a documentation patch.

Why is the *central-registry* approach considered "old school?" What exactly is better about the approach put forward by ASDF 2?

...

• Section 5.3.6 should be renamed. The main body of the text is about how to

use logical pathnames with ASDF 2, and is not a "warning." The recommendation not to use logical pathnames should also be removed, because it is not substantiated (and is therefore not a "warning," because it doesn't say what the potentially bad effects of using logical pathnames are).

Actually, it does say what some problems are. E.g.,

The `asdf-output-translation' layer will avoid trying to resolve and translate logical-pathnames. The advantage of this is that you can define yourself what translations you want to use with the logical pathname facility. The disadvantage is that if you do not define such translations, any system that uses logical pathnames will behave differently under asdf-output-translations than other systems you use.

The non-uniformity of treatment here qualifies as a problem, IMO.

This sounds like a weird statement to me: If you don't provide the necessary logical pathname translations, then the logical pathname doesn't make any sense anyway, or so it seems to me.

What is the motivation behind that paragraph? To me it sounds like it talks about something that cannot work in the first place. Maybe I misunderstand this.

That said, I will push a patch with a more neutral title.

...

There are advantages and disadvantages with using both either logical pathnames or the ASDF 2 approach. Any future Common Lisp implementation that claims adherence to ANSI CL will support logical pathnames, and so it will be relatively straightforward to use logical pathnames in conjunction with ASDF 2, while ASDF 2 will probably need patching in order to support such a future Common Lisp system, which can be regarded as an advantage of logical pathnames over the ASDF 2 approach.

You are certainly free to do so. Our experience differs from yours.

That's fine, of course. I only object to the ASDF 2 documentation seemingly promoting a particular approach for which there is not necessarily a community-wide consensus that it's the best one under all circumstances.

Pascal

-- Pascal Costanza

...

But ASDF can't require each and every user to learn about logical pathnames and how to set them up in their specific implementation, each and every system writer to adhere to naming limitations of "logical pathnames", etc. That would raise the bar to adoption, not lower it.

This is only true under the assumption that what ASDF 2 adds on top of ASDF 1 is easy to learn, but that's not the case either.

Does not compute.

Setting up logical pathname is a step that ought to be done before ASDF is loaded and/or used. Some implementations don't even provide a way to load an initialization file (e.g. lwper). If you're willing to contribute a guide to how to do these things on each of the 15 platforms we support, I'll include it in the ASDF manual.

I could have tried to resurrect one of the old mechanisms of loading configuration files as lisp code, but they were decidedly neither modular nor portable nor future-proof. There's a reason they didn't take on.

...

In the bad old days of ASDF 1, I've done my lot of       (:module "foo-bar" :pathname       #.(merge-pathnames (make-pathname :directory '(:relative "foo" "bar") :defaults *some-directory* #| required for the :host and :device slots |#) *some-directory*) ...)

NO, THANKS! Now it's just (:module "foo/bar" ...)

Why was that necessary? It was possible to say (:module "foo" (:module "bar" ...) ...) [or something similar], no?

It's possible to have nested modules, indeed, and rpgoldman importantly fixed the bug in module dependencies for ASDF 2.

But let's just suppose for a minute that you're part of a project with thousands of files where tens of developers simultaneously edit files. At some point, you need to add a dependencyn between files that were originally in different directories, and you don't want to move the file, either because it would cause painful gratuitous merge conflicts, or just because the directories denote some logical grouping independent from the dependency order. Suddenly, you find yourself either creating plenty of gratuitous modules with different names but identical pathname, or using hierarchical names, which in the bad old days meant playing games with merge-pathnames.

• In Section 3.1, the documentation says the following: "The simplest way to add a path to your search path, say /home/luser/.asd-link-farm/ is to create the directory ~/.config/common-lisp/source-registry.conf.d/ and there create a file with any name of your choice but the type conf, for instance 42-asd-link-farm.conf containing the line: (:directory "/home/luser/.asd-link-farm/")"

This is very confusing, because the "old style" using asdf:*central-registry* is decidedly much simpler. So the sentence above needs some explanation in what sense the "new style" is simpler.

"old style" is much simpler if you either solve the issue of documenting configuration for 15 different implementations, or don't support the writing of lisp scripts distributed independently from the libraries they are using.

I invite you to read the paper Robert Goldman and I wrote, particularly section 4.5 "Decentralized configuration". http://common-lisp.net/project/asdf/ilc2010draft.pdf

• Section 5.3.6 should be renamed. The main body of the text is about how to use logical pathnames with ASDF 2, and is not a "warning." The recommendation not to use logical pathnames should also be removed, because it is not substantiated (and is therefore not a "warning," because it doesn't say what the potentially bad effects of using logical pathnames are).

I renamed it to "Using logical pathnames", and added a note regarding why we do not recommend logical pathnames to newcomers.

There are advantages and disadvantages with using both either logical pathnames or the ASDF 2 approach. Any future Common Lisp implementation that claims adherence to ANSI CL will support logical pathnames, and so it will be relatively straightforward to use logical pathnames in conjunction with ASDF 2, while ASDF 2 will probably need patching in order to support such a future Common Lisp system, which can be regarded as an advantage of logical pathnames over the ASDF 2 approach.

I don't believe there will be many "future Common Lisp implementations". Several existing implementations have problems with logical pathnames (or sometimes physical pathnames) that are decidedly not going away. Logical pathnames have limitations that are enforced in SBCL, and make them inapplicable to a variety of situations.

I think that statements of personal preference should not have a place in the documentation of a tool that is supposed to be used by the whole Common Lisp community, but such a documentation should rather reflect the wide range of opinions in that community.

Between James Anderson and you, I know of only two people who ever care about logical pathnames — and either of you is welcome to write a guide to using them, though I will only include it in the ASDF doc if it is comprehensive enough in (1) how to configure them on each of 15 supported implementations (distinguishing LW and LWper), and (2) how to deal with physical pathnames that don't fit.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The rule is perfect: in all matters of opinion our adversaries are insane. — Mark Twain

On 19 May 2011, at 21:57, Faré wrote:

...

...

: Pascal Costanza Because ASDF 2.x caused me some trouble in RMCL, I actually put some effort into learning logical pathnames - and they seem to work extremely well, as far as I can tell

Beware logical pathnames. They may "work extremely well" in some implementations, and completely differently in some other —

Not according to my experience.

or be absent or not well supported.

That would be a non-conforming CL implementation.

In other words, they are not portable, not enough the extremely constrained subset that is defined as portable in the spec. That's the main reason why ASDF2, while it will let you use them, isn't based on them.

If you want to start on a crusade to the spec to be extended to be more useful and/or to get all Lisp implementations to actually use such a spec — I'm sure many CL users will love you (especially janderson!). Good luck.

I don't understand what I did to deserve such snippy remarks. ASDF 2 has problems with a particular conforming Common Lisp implementation because it depends on a feature that is implementation-dependent by definition. All I did is that I asked for workarounds and reported whatever I could to enable you to fix the problem.

...

...

(but it requires specifying :ignore-inherited-configuration in my source registry configuration, which seems somewhat unclean to me - but I don't really know...)

Why do you have to :ignore-inherited-configuration ??? Is there or was there something buggy in ASDF2? Why didn't you report the bug and get it fixed?

I did report this particular issue on 23 January 2011 in this mailing list.

...

: Robert Goldman One undesirable feature is their refusal to permit filenames containing underscores or spaces:

word---one or more uppercase letters, digits, and hyphens.

And SBCL, being the language lawyering prick we love it to be, does enforce these limitations like all those it can from the standard. Of course, Corman doesn't have portable pathnames, I wouldn't trust GCL, and there might be bugs in ABCL, etc.

Yes, some CL implementations extend certain CL features with additional capabilities. This is allowed by the CL specification, and relying on such extensions makes your programs non-portable by definition. So if you want your program / library to be portable, you shouldn't rely on them. I don't see what's so hard to understand about these concepts.

...

Every time I have used logical pathnames, or even just used pathnames, they have blown up in my face, sooner or later, when code moved from one lisp implementation to another. I, for one, welcome Fare replacing them inside ASDF2...

Thank you!

I think it's ok to have alternatives to the existing standard features. I don't think that ASDF should push such an alternative to the extent that the existing standard feature cannot be used anymore (or only with workarounds).

I'm not sure what your intention is, but the way you react to my problem reports gives me the impression that you _may_ not be interested in giving CL logical pathnames the same status as your own Unix-specific solution. Maybe my impression is wrong, but then I don't understand your reaction at all.

Pascal

-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.