On Mon, 09 Aug 1999 18:34:43 +0900, Shigeru Miyata wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
>
>1. Please do not reformat source code when you are going to take diffs.
I intended to reduce the changes to those really altering the cod base.
Nevertheless I was not very successful not to confuse diff. The
sequence of the function definitions in the module seems partly
arbitrary and makes it unreadable for me.
To cleanly implement the path cleanup, in the way suggested by
Jean-Marc, I unfortunately had to alter the sequence of some function
definitions in filetools.C and nearly completely reformat it, taking
out many '#ifdef __EMX__' and writing a more generic solution instead.
Moreover I had to put the simpler (called) path handling functions
before the more complex (caller) path handling functions. I tried to
survive without this, but as I'm a human and not a linker program, I
gave up after several hours trying to keep track of the already cleaned
parameters and those still in need to be cleaned, in order to avoid
multiple (even recursive) or unnecessary appliance of the cleanup-path
function and not to forget important parameters.
> Your patch is not readable! (and I cannot comment well.)
This is true! I'm sorry.
I'll provide a diff that is hopefully better readable later, when my
patch has a bit more matured. (As it is hard work to undo every format
change, I'll beg for pardon here, not being able to supply such a diff
now.) And as I already said, I can't read the code without them. BTW:
The diff utility is very easy to confuse, spitting out unreadable
spaghetti diffs. Shall I try other flags? E.g. 'mgdiff', that I use to
graphically view and keep track of my changes does a much better job.
I already detected a bug (in emx' Library C?), where _getname() returns
arbitrary results when processing an empty string instead of just
returning the empty string.
* I'll took this opportunity not to write another workaround (or
completely forget about DBCS: X/2 will run with this in the near
future, so why not thinking a bit about future compatibility when it
doesn't cost too much work) but to hopefully cleaner implement several
things:
* I suppressed the '#ifdef __EMX__' in 'lyx_cb.C' and used macros
defined in 'os2_config.h' instead, being defined to empty if
'os2_config.h' is not included.
* I moved the the OS/2 init code away from main.C, where you'll find a
macro OS_INIT() instead. It's defined to empty by default and redefined
in 'os2_config.h'. This one, if applicable, conveniently toggles a
default flag ('cmd.exe' syntax is not used) to 'cmd.exe' syntax is used
on startup, instead of checking every time, when a helper program is
used.
* Several more small changes involved.
I'll do a bit more testing before supplying this patch (though the list
is very useful as an archive of all the steps of ones work).
>2. Please do not use 1.0.3 as the codebase. Lars has already
>incorporated
> some of the changes you have proposed in the CVS repositry. It is
> really important to distinguish what's the meat.
>(BTW Lars made a typo temppath <-> tempath, so 1.0.4pre4 doesn't
>compile.)
I know. I'm sorry for the inconvenience. I already took those changes
completely out and implemented a macro solution in 'os2_config.h', as
described above. Again I beg for pardon, as I wanted to avoid the
complications or possible bugs in a prerelease, while being still on
the way to work out a more consistent scheme for my patch. I'll try to
use 1.0.4pre4 in the future. In the meanwhile I simply assumed,
everybody still has a 1.0.3-tarball lying on the disk.
>> Besides numerous small changes to improve readability and supress unnnec=
>> essary parameters, I tried to
>> wrap most system specific code into small 'inline static' helper functio=
>> ns, that take 'const'
>> parameters and get hopefully mostly optimized out, when the respective '=
>> #ifdef __EMX__' does not apply
>> to your box. I moved LString method lowercase() and my later additions f=
>> rom LString class to non-member
>> functions, so as not to 'clutter up LString even more'.
>
>The "inline" keyword is meaningless since you are using it in *.C
Those are 'static' functions; I'm a bit confused that inlining within a
module is not possible?
>> The one major change was an access warning with double try to remove LyX=
>> -tmp files. This is important
>> in overcrowded and unresponsive networks and on small OS/2-EMX partition=
>> s with reduced free storage
>> place. I found it especially annoying that EMX (in an effort to be a bet=
>> ter unix than unix, as someone
>> said) forbids LyX any access (marking for deletion), if a tmp-file is p=
>> reviewed or otherwise accessed
>> by any process. This always left me with extremely *huge* piles of garba=
>> ge. Now the solution here is a
>> warning to wake up the EMX-security officer, so to unlock the locked fil=
>> es and try to remove
>> afterwards.
>
>I don't think trying to remove files twice help. Besides, if some app
>locks a file, then it has reasons to do this. It is not LyX's
>responsibility to outact the system integrity with a cheat. If you
>are talking about dvipm, then you can configure it not to lock dvi
>files (dvipm.dlg file must not be in the LyX-tmp dir, since this
>file will be locked instead.)
The warning recommends to close previewers (XDVI, gv, etc.: They all
lock LyX' tmp-files). After closing them, the tmp-files are cleanly
removed by LyX.
I think it improves stability to recommend the user to close child
processes before closing LyX, instead of letting them hang around as
'motherless zombies'. Correct me, if I'm mistaken here.
So please be a bit patient,
greetings,
Arnd
