lmi
[Top][All Lists]
Advanced

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

Re: [lmi] --gui_test_path and implicitly created output files


From: Vadim Zeitlin
Subject: Re: [lmi] --gui_test_path and implicitly created output files
Date: Sun, 14 Dec 2014 18:55:19 +0100

On Sun, 14 Dec 2014 15:58:33 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2014-12-14 14:31, Vadim Zeitlin wrote:
GC> > 
GC> >  It turns out that implementing --gui_test_path is not completely trivial
GC> > as some files are unconditionally created by lmi in the current directory:
GC> > this is the case for at least the files created by mec_server which is 
used
GC> > from mec_view with just base_filename() as the file name (i.e. "unnamed")
GC> > and ".monthly_trace" debugging files created when illustrations debugging
GC> > is enabled. In both cases we can't currently force creation of these files
GC> > in the directory specified by the --gui_test_path command line option.
GC> 
GC> Okay, I see that call to base_filename():
GC> 
GC> void mec_view::Run()
GC> ...
GC>     server(base_filename(), input_data());
GC> 
GC> But it looks like '.ill' files do something very similar:
GC> 
GC> void IllustrationView::Run(Input* overriding_input)
GC> ...
GC>     illustrator z(mce_emit_nothing);
GC>     z(base_filename(), input_data());
GC> 
GC> So...do you have in mind a method that would take care of '.ill'
GC> but not '.mec'?

 No, I wanted to make base_filename() more flexible, i.e. allow specifying
the directory it returns in some way, which would have worked for both of
them. But, as you say, it's probably not worth going into details as we're
not going to do it anyhow.

GC> >  I see the following possible solutions:
GC> > 
GC> > 0. Ignore the problem for these files and just ensure that they are 
deleted
GC> >    after the end of the test (currently this doesn't happen neither, as
GC> >    they are created as a side effect and not explicitly, so I didn't even
GC> >    know originally that they were created by lmi).
GC> 
GC> Sounds good to me.

 OK, thanks. Just to confirm: my just submitted patch doesn't do anything
about these files.


GC> Some lmi output files are created...in the directory where the program 
happens
GC> to be run, I suppose: the 'monthly_trace' and '.mec.tsv' files, for 
instance.
GC> These and quite a few others are created as deliberate side effects. Let's
GC> first address the theoretical question where they should be created: I guess
GC> the FHS would prefer /var/opt/lmi/ . Is it worth changing lmi to do that?

 It definitely would be if/when lmi were to be usable under Unix systems as
/opt/lmi/bin wouldn't typically be writable at all. And even under Windows,
theoretically speaking, these files are user-specific (as the files being
opened are opened by some specific user), so the output files should be
generated in a user-specific location as well, e.g. something like
wxStandardPaths::GetUserLocalDataDir() (see
http://docs.wxwidgets.org/trunk/classwx_standard_paths.html#a456fcd2e246c57a61dda9511e4dac9c3)

 But this is definitely more theoretical than practical consideration,
especially if no users have been ever bothered by this.

 Regards,
VZ

reply via email to

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