lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [lmi-commits] master 0c2d6b4 30/33: Revert "Revert "Trap excep


From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] master 0c2d6b4 30/33: Revert "Revert "Trap exceptions from filesystem library""
Date: Fri, 14 May 2021 16:21:43 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0

On 5/14/21 1:38 PM, Vadim Zeitlin wrote:
> On Mon,  3 May 2021 08:15:56 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> 
> GC> branch: master
> GC> commit 0c2d6b415b881858794a2a9713eac962f8f54a45
[...]
> GC>     However, given '/opt/lmi/data/configurable_settings.xml' contents:
> GC>       
> <default_input_filename>Z:/etc/opt/lmi/default.ill</default_input_...
> GC>       <print_directory>Z:/opt/lmi/print</print_directory>
> GC>     lmi-gtk's GUI now shows
> GC>       Input defaults: /opt/lmi/bin/Z:/etc/opt/lmi/default.ill
> GC>       Printout directory: /opt/lmi/print
> GC>     where one textcontrol is as intended but the other is not. It is not
> GC>     clear whether the reverted commit has anything to do with that, but
> GC>     it seems wise to back it out temporarily pending investigation of this
> GC>     anomaly. The present commit can be reverted (enthusiastically) later.
> 
>  I'd like to debug and really fix this, but first of all I'd like to
> understand what exactly are we trying to do here, i.e. which control is
> considered to be "as intended" and which one is not?

I ran lmi-msw and saved configurable settings; result above.

Then I ran lmi-gtk, in the same /opt/lmi/ hierarchy, and therefore
using the same configurable-settings file. I expected the msw
drive-letter-colon prefix to be removed, so that in the gtk GUI
I'd see:
  /etc/opt/lmi/default.ill
  /opt/lmi/print
The "Printout directory" came out as I had expected.

The problem is that the "Input defaults" came out this way:
  /opt/lmi/bin/Z:/etc/opt/lmi/default.ill
That's just wrong. Although you could interpret it as a $PATH with
two filepaths, so that zsh's $path would be a two-element array:
  /opt/lmi/bin/Z   /etc/opt/lmi/default.ill
it's supposed to be a single full-path that names a single file.

Now I ask myself whether the existence of
  /etc/opt/lmi/default.ill
matters. It does not exist. Could that contribute to the problems?
Apparently not: experimentally I do this:
  $touch /etc/opt/lmi/xyzzy.ill
and, using lmi-msw, make that the default; then lmi-gtk shows
  /opt/lmi/bin/Z:/etc/opt/lmi/xyzzy.ill
as "Input defaults", where I would now have expected
  /etc/opt/lmi/xyzzy.ill

As a further experiment, I change it to the intended
  /etc/opt/lmi/xyzzy.ill
in the lmi-gtk GUI, and press "OK" to save the settings.
Then the settings file contains
  <default_input_filename>/etc/opt/lmi/xyzzy.ill</default_input_filename>
  <print_directory>/opt/lmi/print</print_directory>
as hoped. And then I close lmi-gtk, reload it, and
inspect the settings in the GUI, and they're as intended.

Now I load lmi-msw. It shows:
  Input defaults:     Z:\etc\opt\lmi\xyzzy.ill
  Printout directory: Z:\opt\lmi\print
as expected. I make a trivial change (pause 11 seconds between
printouts instead of 10) and hit "OK"; the combination of those
two steps causes the settings file to be saved. Now it contains:
  <default_input_filename>Z:/etc/opt/lmi/xyzzy.ill</default_input_filename>
  <print_directory>Z:/opt/lmi/print</print_directory>

After closing lmi-msw and starting lmi-gtk, the dialog shows:
  Input defaults:     /opt/lmi/bin/Z:/etc/opt/lmi/xyzzy.ill
  Printout directory: /opt/lmi/print
as before. "Input defaults" is obviously wrong on the face of it.
None of my experiments has prevented that.

> I think the bottom is
> meant to be the good one, but I'm not totally sure, could you please
> confirm this?

[answered above]

> And, if if this is indeed the intended/correct version, is
> the intention to only hide "Z:" in the UI or to also remove it from the
> configuration file as well?

Iff the configuration file is saved--i.e., if at least one element
is changed in the GUI and the "OK" button is pressed.

>  I'd also like to note that I don't see any differences in behaviour with
> and without this commit (i.e. 0c2d6b415b881858794a2a9713eac962f8f54a45),
> i.e. I still see the path with "Z:" in the middle even with the current
> master, including it -- just as I see the same path if I revert this commit
> (thus re-re-reverting the original change). Could you also please confirm
> that this commit really does change the behaviour for you, because I just
> don't see how it can and maybe I'm just misunderstanding something here?

See this above:

> GC>     where one textcontrol is as intended but the other is not. It is not
> GC>     clear whether the reverted commit has anything to do with that, but
> GC>     it seems wise to back it out temporarily pending investigation of this
> GC>     anomaly. The present commit can be reverted (enthusiastically) later.

I didn't check whether that commit had any causal relationship
with the reported error. But something is demonstrably wrong
and needs to be fixed.

>  Finally, I'd like to say (once again? I don't remember if I have already
> written this, sorry if I'm repeating myself) that I think that
> remove_alien_msw_root() shouldn't exist at all because IMO the paths should
> never be mangled in this way and the right solution would be to use
> different data directories for the MSW and native versions to prevent them
> from overwriting each others files. This is especially true if you really
> want to remove "Z:" from the configuration file too, as this would mean
> that running MSW version after running the Linux one wouldn't work.

Running lmi-msw after running lmi-gtk does work (above).

If we're going to step back and redesign anything, then IIRC
we should step back farther and do a deeper redesign--I think
I cited some older email thread on that topic, somewhere earlier
in the present thread. I have no time to work on that myself now.
But either we fix the problem at the surface, or at the root--not
anywhere in between.

First let's see whether you can even reproduce the problem
with the elaborated steps above.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]