On 6 Sep 1999 06:13:13 +0900, [EMAIL PROTECTED] wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
>
>> Going up the stack 'till main() I'm now convinced that _heapset(9)
>> produces on my box a self-induced crash (heap corruption) in emx libs.
>> I'm unsure why this happens, it shouldn't, I think
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> Going up the stack 'till main() I'm now convinced that _heapset(9)
> produces on my box a self-induced crash (heap corruption) in emx libs.
> I'm unsure why this happens, it shouldn't, I think (or did I forget
> misunderstand it's function: Heap freespac
>On 3 Sep 1999 14:09:33 +0900, [EMAIL PROTECTED] wrote:
>>>Now uncommenting in figinset.C:
>>> // assert (_heapset(9) == _HEAPOK);
>>> printf("The empty heap is set to 9 and checked: \n"); fflush(NULL);
>>>
>>>to
>>>
>>> assert (_heapset(9) == _HEAPOK);
>>> printf("The empty heap is set to
On Fri, 03 Sep 1999 10:29:01 +0200, Stephan Witt wrote:
>I don't think it's a real problem with "zombie-like" running xdvi's.
Only minor annoyance.
>1. You can see them.
> You can regularily quit them.
> You can decide yourself when to do so.
Except they decide themselves (they crash with
On 3 Sep 1999 14:09:33 +0900, [EMAIL PROTECTED] wrote:
>>Now uncommenting in figinset.C:
>
>It seems you have modified Makefile and use figinset.org.C
Which is figinset.C. (Did some preliminary cleanup in figinset.mod.C).
>
>> // assert (_heapset(9) == _HEAPOK);
>> printf("The empty heap is se
Arnd Hanses wrote:
>
> On 31 Aug 1999 17:57:55 +0200, Lars Gullik Bj°nnes wrote:
>
> >Stephan Witt <[EMAIL PROTECTED]> writes:
> >
> >| LaTeX and Xdvi are children of LyX and directed by LyX to the
> >| internally computed hidden tmp-directory. I'm aware of that
> >| effect: If I close a file an
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
>Now uncommenting in figinset.C:
It seems you have modified Makefile and use figinset.org.C
>
>
> // assert (_heapset(9) == _HEAPOK);
> printf("The empty heap is set to 9 and checked: \n"); fflush(NULL);
>
>to
>
> assert (_heapset(9) == _HEAPOK);
On 31 Aug 1999 17:57:55 +0200, Lars Gullik Bj°nnes wrote:
>Stephan Witt <[EMAIL PROTECTED]> writes:
>
>| LaTeX and Xdvi are children of LyX and directed by LyX to the
>| internally computed hidden tmp-directory. I'm aware of that
>| effect: If I close a file and reopen it again, then I have to
>|
On 16 Aug 1999 11:11:04 +0900, [EMAIL PROTECTED] wrote:
>SIGSEGV is indeed occured in gs. This can be a bug in gs, but it is
>more likely a LyX problem. Since gs was a *forked* child, not a *spawned*
>child, the addressing space of gs could have been corrupted when it was
>inherited from LyX.
Stephan Witt <[EMAIL PROTECTED]> writes:
| LaTeX and Xdvi are children of LyX and directed by LyX to the
| internally computed hidden tmp-directory. I'm aware of that
| effect: If I close a file and reopen it again, then I have to
| close my running Xdvi too, because it is useless now, when using
Lars Gullik Bjønnes wrote:
>
> "Arnd Hanses" <[EMAIL PROTECTED]> writes:
>
> | (Often used instead of/to emulate pipe: Sorry, I'm only a casual
> | programmer, so I've always problems to use the correct terminology.
> | Grateful for any hints.)
>
> Xdvi should just watch the file for changes. I
"Arnd Hanses" <[EMAIL PROTECTED]> writes:
| (Often used instead of/to emulate pipe: Sorry, I'm only a casual
| programmer, so I've always problems to use the correct terminology.
| Grateful for any hints.)
Xdvi should just watch the file for changes. It might have some
problems when the file is
On 30 Aug 1999 20:48:44 +0200, Lars Gullik Bj°nnes wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> writes:
>
>| So a problem with destroying tmpdir might arise when reloading an
>| already open file (dismissing changes), which would close the buffer
>| and reopen it. Pipelining then to the same (alread
"Arnd Hanses" <[EMAIL PROTECTED]> writes:
| So a problem with destroying tmpdir might arise when reloading an
| already open file (dismissing changes), which would close the buffer
| and reopen it. Pipelining then to the same (already open) instance of
| Xdvi might confuse it?
What pipelining?
On 30 Aug 1999 14:58:16 +0200, Lars Gullik Bj°nnes wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> writes:
>
>| in buffer.C is a destructor method
>|
>| Buffer::~Buffer()
>| [...]
>| if (!tmppath.empty()) {
>| DestroyBufferTmpDir(tmppath);
>| }
>| [
"Arnd Hanses" <[EMAIL PROTECTED]> writes:
| in buffer.C is a destructor method
|
| Buffer::~Buffer()
| [...]
| if (!tmppath.empty()) {
| DestroyBufferTmpDir(tmppath);
| }
| [...]
|
| I'm not sure, only suspect this destructor runs sometim
On 28 Aug 1999 14:28:11 +0900, [EMAIL PROTECTED] wrote:
>Now I'm confused. You are now talking about dvi update, right?
>But your patch modified the behaviour of DestroyTmpDir() which is called
>only when LyX is quitting. What problem(s) are you intending to solve?
Well,
it's not difficult to
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> which made xdvi crash. My guess is, sometimes the file is first
> removed/truncated by LyX, then rewritten. A warning to close xdvi,
LyX does not remove/truncate/rewrite dvi files except at the exit time.
It is LaTeX compiler which does the job. In fac
On Thu, 12 Aug 1999 17:23:35 +0900, Shigeru Miyata wrote:
>Arnd, I think I have ported most of your patch to 1.1
>Please check.
[...]
> - I didn't call CleanupPath() if it is unnecessary. Calling it in
>GetCWD is in fact harmful, although it is *I* who says don't bother
>DBCS safeness.
On 12 Aug 1999 16:22:30 +0900, [EMAIL PROTECTED] wrote:
[...]
>> 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.
>
>You are talking about opened files, not file lockings! On OS/2 files
On 23 Aug 1999 15:51:00 +0900, [EMAIL PROTECTED] wrote:
>>Moreover it won't hurt and shows the reader of the code how
>> the nls support works... Making the code transparent even for non-emx
>> programmers was my main intention here.
>
>1.0 is a dead end. No one except emx programmer
On 23 Aug 1999 15:51:19 +0900, [EMAIL PROTECTED] wrote:
>
>It is irrevalent, since, except for a few, all the X11 apps here (including
>LyX) are single threaded. -Zmt flag in the compiler/linker does not make
>your application multithreaded, nor even thread safe.
>> Attached follows the very exp
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> >> fork() doesn't work correctly in multithread programs. [e.g. X11 apps]
> >
> >which is simply untrue!
>
> Unfortunately not! It *is* a citation of the emx docs:
It is irrevalent, since, except for a few, all the X11 apps here (including
LyX) are
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> The automatic check was introduced in a more or less recent emx fix.
> There are supposedly still emx libraries installed where the init() is
> necessary.
It is introduced in 0.9c Since XFree86 doesn't work with 0.9b+fixes
It is not necessary.
>
On Fri, 20 Aug 1999 21:58:51 +0100, Arnd Hanses wrote:
>What I found was that the commands passed to gs appear to work:
>
>The inline figure is printed to screen on my box when the exact
>commands as passed by LyX are given to gs in an xterm, though the
>printed figure immediately disappears fro
On 20 Aug 1999 22:59:42 +0900, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] (Lars Gullik Bjnes) wrote:
>
>> | SIGSEGV is indeed occured in gs. This can be a bug in gs, but it is
>> | more likely a LyX problem. Since gs was a *forked* child, not a *spawned*
>> | child,
>>
>> What is the differenc
On 20 Aug 1999 22:58:50 +0900, [EMAIL PROTECTED] wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
>
>> For this purpose I wrote an experimental os2init() routine, that I
>> would like to move eventually to emxOS2Compat.C. Those routines (for
>> now) are used only once in main.C, so they could bec
[EMAIL PROTECTED] (Lars Gullik Bjnes) wrote:
> | SIGSEGV is indeed occured in gs. This can be a bug in gs, but it is
> | more likely a LyX problem. Since gs was a *forked* child, not a *spawned*
> | child,
>
> What is the difference?
On UNIX the only way to create a new process is to fork an e
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> For this purpose I wrote an experimental os2init() routine, that I
> would like to move eventually to emxOS2Compat.C. Those routines (for
> now) are used only once in main.C, so they could become 'static' (no
> more name-space pollution), if conditionall
On 16 Aug 1999 16:38:08 +0200, Lars Gullik Bj°nnes wrote:
>[EMAIL PROTECTED] writes:
>
>| SIGSEGV is indeed occured in gs. This can be a bug in gs, but it is
>| more likely a LyX problem. Since gs was a *forked* child, not a *spawned*
>| child,
>
>What is the difference?
fork() is Unix specifi
On 16 Aug 1999 11:10:00 +0900, [EMAIL PROTECTED] wrote:
[overview of nls-support, encoding, locale and portability]
>There are many encodings for even a single language. Consider, for
>example, German. There are at least two commonly used encodings:
>ISO8859-1 and codepage850.
For backward/
[EMAIL PROTECTED] writes:
| SIGSEGV is indeed occured in gs. This can be a bug in gs, but it is
| more likely a LyX problem. Since gs was a *forked* child, not a *spawned*
| child,
What is the difference?
Lgb
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> Wouldn't it improve readability to use strictly macros like
> GET_CURRENT_DIR, CHANGE_DIR, etc. in C++ class headers and #define them
> with support headers?
We have already discussed this. The readability argument is your
personal preference. While,
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> [Here's my main interest:
>
> I made NormalizePath() a static function of src/lyx_main.C, as it's
> only used
> there. Am I right, that signal handler call (SIGSEGV in some forked
> child)
> happened before and my patch can't be the reason for the crash?
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> Sure. Perhaps CleanupPath() should better be implemented using nls-safe
> emx lib C string macros internally, only if this not so nice toward
> LString? Or even better make LString clean for Double/triple Byte
> Character Strings?
There are many encodin
On Thu, 12 Aug 1999 17:23:35 +0900, Shigeru Miyata wrote:
>Arnd, I think I have ported most of your patch to 1.1
>Please check.
---
Index: lyx/src/lyxlib.h
===
RCS file: /usr/local/lyxsrc/cvsroot/lyx/src/lyxlib.h,v
retrievin
On Fri, 13 Aug 1999 00:07:10 +0100, Duncan Simpson wrote:
>
>Arnd Hanses posted:
>
>>
>> Provided, box isn't too modern. New vendor patches (or new glibc) break
>> configure tests, 'till someone is so kind as to provide the fix (which
>> in turn breaks other tests, elsewhere, etc.)
>>
>Sort of
Arnd Hanses posted:
>
> Provided, box isn't too modern. New vendor patches (or new glibc) break
> configure tests, 'till someone is so kind as to provide the fix (which
> in turn breaks other tests, elsewhere, etc.)
>
Sort of strange... I have used linux since 0.99pl13, libc 4 (the old a.out
On Thu, 12 Aug 1999 17:23:35 +0900, Shigeru Miyata wrote:
>Arnd, I think I have ported most of your patch to 1.1
>Please check.
I'm not so fast there, 1.1 is still exotic. So please be very
patient...
>notes:
> - I don't like the ExtList[] idea. ".exe" and ".cmd" are checked
>there
>becau
On Wed, 11 Aug 1999 17:16:01 +0100, Duncan Simpson wrote:
>> On 11 Aug 1999 15:11:23 +0200, Lars Gullik Bj°nnes wrote:
>>
>>This solution would produce elegant source code, if and only if
>>configure runs successfully. If not, you are left on you own.
>>
>Actually it is not hyper-impossible to
Arnd, I think I have ported most of your patch to 1.1
Please check.
notes:
- I don't like the ExtList[] idea. ".exe" and ".cmd" are checked
there
because OS/2 shells does not distinguish them and it is necessary to
handle lyx.exe, configure.cmd, reLyX.cmd, noweb2lyx.cmd in a unified
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> >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?
Sorry I was wrong.
> The warning recommends to close previewers (XDVI, gv, etc.: Th
On 11 Aug 1999 15:11:23 +0200, Lars Gullik Bj°nnes wrote:
> From: Duncan Simpson <[EMAIL PROTECTED]>
>Due to various systems not supporting symlinks (M$ systems are the most
>prominent example) could I suggest a header called something like
>"os_specifics.h" generated by configure by from os_s
--- Start of forwarded message ---
Message-Id: <199908111253.NAA16344@ io.stargate.co.uk>
To: [EMAIL PROTECTED] (Lars Gullik Bj nnes)
Subject: Re: 3026 public symbol exports in LyX global name space (wa: Re:
LaTeX file handling)
Date: Wed, 11 Aug 1999 13:53:57 +0100
From: Duncan S
On 11 Aug 1999 14:11:45 +0200, Lars Gullik Bj°nnes wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> writes:
>
>| Is this bug-bound? Everybody does it (at least in C), I'd say
>| configure
>
>Everybody does not use it...not even in C
Look into GNU-project sources...
(But as I'll already said, I'll ins
"Arnd Hanses" <[EMAIL PROTECTED]> writes:
| Is this bug-bound? Everybody does it (at least in C), I'd say
| configure
Everybody does not use it...not even in C
| is severely broken in too many cases (not only with emx but on systems
| like AIX, IRIX, CRAY etc., too). I'd better not trust this p
On 11 Aug 1999 11:56:22 +0200, Lars Gullik Bj°nnes wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> writes:
>
>| os2-defines.h :
>|
>| ---
>| [...]
>|
>| #if defined(_LYX_MAIN_C) || defined(_FILETOOLS_C)
>| #include "LString.h"
>| [...]
return temppath;
retur
"Arnd Hanses" <[EMAIL PROTECTED]> writes:
| os2-defines.h :
|
| ---
| [...]
|
| #if defined(_LYX_MAIN_C) || defined(_FILETOOLS_C)
| #include "LString.h"
I will not have any code that depend on the include guards.
| //An internal helper to better handle DOS-
On 10 Aug 1999 20:24:36 +0200, Lars Gullik Bj°nnes wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> writes:
>
>| Well, as nice as LyX-programming is, first of all I need a program to
>| write, not to hack with :). So my enthusiasm for 1.1.x was at first a
>| bit limited. But who knows...
>
>Well you kno
"Arnd Hanses" <[EMAIL PROTECTED]> writes:
| Well, as nice as LyX-programming is, first of all I need a program to
| write, not to hack with :). So my enthusiasm for 1.1.x was at first a
| bit limited. But who knows...
Well you know, I don't know how large patches I will allow in 1,0,x
series...
On 10 Aug 1999 14:53:43 +0200, Lars Gullik Bj°nnes wrote:
>You are looking at the wrong code-base. You should look at the 1.1.x
>series, at lot of things are different there. Actually the 1.1.x
>series is where you should put in your much welcome effort, not in
>1.0.x. (important things can be ba
"Arnd Hanses" <[EMAIL PROTECTED]> writes:
[this is comments on 1.0.x right?]
| Just a personal note:
|
| * Keeping track of 3026 globally exported names only in the executable
| scattered all over hundred or so modules, chaotically cross-linked to
| and fro is a bit difficult. In other words: T
"Arnd Hanses" <[EMAIL PROTECTED]> writes:
| I've seen often the double cast in the code:
|
| LString foo = LString (bar);
|
| What would be the best coding style in those cases?
LString foo(bar);
Lgb
Hi,
just for info here as a mime attachment a gzipped list of the public
symbol exports in LyX' global name space.
I made it with 'emxexp' tool. It contains all the public symbol names,
the name of the exporting module and the respective (type) declaration.
I used this list to learn a bit abo
On Mon, 09 Aug 1999 18:34:30 +0900, Shigeru Miyata wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
>
>> I was trying to paste really harmless text (no 'umlauts', etc. this time=
>> )
>> into LyX' main window, while the LaTeX-preamble form popup was open. And=
>> :
>>
>> Click mouse-butt
On Mon, 09 Aug 1999 18:35:10 +0900, Shigeru Miyata wrote:
Thank you very much for the fast answer; I'm always grateful for
criticism:
>"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
>
>> temp = AddName( OnlyPath(file), temp );
>>
>> // Replace spaces with underscores, also in director
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 con
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> temp = AddName( OnlyPath(file), temp );
>
> // Replace spaces with underscores, also in directory
> temp.subst(' ','_');
This is wrong! You must not rename the file you may not be the
creator.
> Note:
> I'm not sure why, but g
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
1. Please do not reformat source code when you are going to take diffs.
Your patch is not readable! (and I cannot comment well.)
2. Please do not use 1.0.3 as the codebase. Lars has already
incorporated
some of the changes you have proposed in the
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> I was trying to paste really harmless text (no 'umlauts', etc. this time=
> )
> into LyX' main window, while the LaTeX-preamble form popup was open. And=
> :
>
> Click mouse-button2. Crash!
Try to set breakpoint in BufferView::WorkAreaSelection
Hi again,
trying to find bugs in my patch, I was doing my best to make LyX crash in
'gdb'.
Finally I succeeded!
But I was not amused at all (most disappointed) when examining closer what
had happened: As it seems it is unrelated to my patch; yet another xforms
issue. It's confusing; my gues
On Sat, 07 Aug 1999 01:39:25 +0100, Arnd Hanses wrote:
>Better also let path through the underscore '_':
And even better would be better coding style (using some fancy macro):
This is all to be put into filetools.C
--snip-
// Let pass through FRIEND of LaTeX & shell; stop the fo
On Fri, 06 Aug 1999 22:11:37 +0100, Arnd Hanses wrote:
>+#define EXTENSION_MARKER '.' /* Let through the 'full-stop' */
[...]
+ inline static
+LString toAsciiAlnum(LString const &string)
+{
+ LString tmp(string);
+ for (int i = 0; i < tmp.length(); i++) {
+
On Fri, 06 Aug 1999 23:42:50 +0100, Arnd Hanses wrote:
>On Fri, 06 Aug 1999 22:11:37 +0100, Arnd Hanses wrote:
>
>>+/* non portable EMX C Library fn, should handle DBCS[*] too */
>>+ LString sh = _getname( getenv("EMXSHELL") );
>>+
>
>Looking closer at the patch, I found line
On Fri, 06 Aug 1999 22:11:37 +0100, Arnd Hanses wrote:
>+/* non portable EMX C Library fn, should handle DBCS[*] too */
>+ LString sh = _getname( getenv("EMXSHELL") );
>+
Looking closer at the patch, I found line 612 of lyx_cb.C lacks a cast:
+/* non portable EMX C Library
On Sat, 31 Jul 1999 16:33:32 +1000 (GMT+1000), Allan Rae wrote:
>On 30 Jul 1999, Lars Gullik Bj°nnes wrote:
>
>> "Arnd Hanses" <[EMAIL PROTECTED]> writes:
>>
>> | The reason for prefering to use a const function and an additional
>> | variable is:
>>
>> As I said below this is a matter of style
On 30 Jul 1999 23:43:09 +0200, Lars Gullik Bj°nnes wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> writes:
>
>| The reason for prefering to use a const function and an additional
>| variable is:
>
>As I said below this is a matter of style.
>
>a) void foo(string &);
>b) string foo(string const &);
>
>I
On 30 Jul 1999, Lars Gullik Bjønnes wrote:
> "Arnd Hanses" <[EMAIL PROTECTED]> writes:
>
> | The reason for prefering to use a const function and an additional
> | variable is:
>
> As I said below this is a matter of style.
>
> a) void foo(string &);
> b) string foo(string const &);
>
> I lik
"Arnd Hanses" <[EMAIL PROTECTED]> writes:
| The reason for prefering to use a const function and an additional
| variable is:
As I said below this is a matter of style.
a) void foo(string &);
b) string foo(string const &);
I like b best since it does not change/modify its parameters.
| A real
On 30 Jul 1999 21:57:08 +0200, Lars Gullik Bj°nnes wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> writes:
>
>| 1) Using a const function parameter and an additional variable of class
>| LString. (see above)
>
>I this best.
The reason for prefering to use a const function and an additional
variable is
"Arnd Hanses" <[EMAIL PROTECTED]> writes:
| 1) Using a const function parameter and an additional variable of class
| LString. (see above)
I this best.
| 2) Using only one non-const variable. (You'll have to instantiate one
| in all cases.)
A matter of style.
| 3) Using a pointer to the proce
On 27 Jul 1999 16:44:49 +0200, Lars Gullik Bj°nnes wrote:
>And even better would be a function that does not clutter up LString
>anymore:
>
>LString discardSign(LString const & str)
>{
> LString tmp(str);
> for (int i = 0; i < tmp.length(); ++i)
> tmp[i] &= 0x7f;
>
On Thu, 29 Jul 1999 15:05:03 +0200 (MET DST), Jean-Marc Lasgouttes
wrote:
>> "Arnd" == Arnd Hanses <[EMAIL PROTECTED]> writes:
>
>Arnd> I rechecked my patch again and could no more find obvious
>Arnd> mistakes. Now LyX is finally doing what I want on my box. I
>Arnd> think you can now safely
> "Arnd" == Arnd Hanses <[EMAIL PROTECTED]> writes:
Arnd> I rechecked my patch again and could no more find obvious
Arnd> mistakes. Now LyX is finally doing what I want on my box. I
Arnd> think you can now safely compile and stress-test, if you have a
Arnd> little time (or even read it, if yo
On Thu, 29 Jul 1999 17:39:27 +0900, Shigeru Miyata wrote:
>for (;notfound && *EL_p!=NULL; EL_p++)
sure ! I didn't look close enough, so I notfound && this myself ? :)
Cheers,
Arnd
"Arnd Hanses" <[EMAIL PROTECTED]> wrote:
> I rechecked my patch again and could no more find obvious mistakes. Now
> LyX is finally doing what I want on my box. I think you can now safely
> compile and stress-test, if you have a little time (or even read it, if
> you want).
In FileOpenSearch() i
On Wed, 28 Jul 1999 18:34:20 +0100, Arnd Hanses wrote:
>On Wed, 28 Jul 1999 17:55:00 +0200 (MET DST), Jean-Marc Lasgouttes
>wrote:
>
>>> "Arnd" == Arnd Hanses <[EMAIL PROTECTED]> writes:
>>
>>Arnd> On Wed, 28 Jul 1999 11:01:21 +0200 (MET DST), Jean-Marc
>>Arnd> Lasgouttes wrote:
>> BTW I
On Wed, 28 Jul 1999 16:47:00 +0100, Arnd Hanses wrote:
>On Tue, 27 Jul 1999 22:34:52 +0100, Arnd Hanses wrote:
>
>>On Mon, 26 Jul 1999 19:00:33 +0200 (MET DST), Jean-Marc Lasgouttes
>>wrote:
>>
>>>Could you use that in your patches, you can do either
>>> name = CleanupPath(name);
>>>or
>>> LStri
On Wed, 28 Jul 1999 11:01:21 +0200 (MET DST), Jean-Marc Lasgouttes
wrote:
>>> BTW I like your suggestion of using isalnum().
>
>Arnd> Well, it's only a macro shorthand.
>
>Arnd> Please note, until filetools.C are cleaned, I have to let '.'
>Arnd> (dots) pass through this filter. I could not find a
On Tue, 27 Jul 1999 22:34:52 +0100, Arnd Hanses wrote:
>On Mon, 26 Jul 1999 19:00:33 +0200 (MET DST), Jean-Marc Lasgouttes
>wrote:
>
>>Could you use that in your patches, you can do either
>> name = CleanupPath(name);
>>or
>> LString temp = CleanupPath(name);
>>
>
>You've asked for it...
New v
On Wed, 28 Jul 1999 10:59:53 +0200 (MET DST), Jean-Marc Lasgouttes
wrote:
>Arnd> LString I found nice, filetools interesting: Is it possible to
>Arnd> build a shared library with a simple and consistent interface
>Arnd> out of such tool classes? (The LyTK base classes library?) At
>Arnd> least on
> "Arnd" == Arnd Hanses <[EMAIL PROTECTED]> writes:
Arnd> On 27 Jul 1999 06:57:29 +0900, [EMAIL PROTECTED] wrote:
>> BTW I like your suggestion of using isalnum().
Arnd> Well, it's only a macro shorthand.
Arnd> Please note, until filetools.C are cleaned, I have to let '.'
Arnd> (dots) pass
> "Arnd" == Arnd Hanses <[EMAIL PROTECTED]> writes:
Arnd> On Mon, 26 Jul 1999 19:00:33 +0200 (MET DST), Jean-Marc
Arnd> Lasgouttes wrote:
>>> "Arnd" == Arnd Hanses <[EMAIL PROTECTED]>
>>> writes:
>>
Arnd> LString I found nice, filetools interesting: Is it possible to
Arnd> build a sh
On Mon, 26 Jul 1999 19:00:33 +0200 (MET DST), Jean-Marc Lasgouttes
wrote:
>Could you use that in your patches, you can do either
> name = CleanupPath(name);
>or
> LString temp = CleanupPath(name);
>
You've asked for it...
>I did not try it, but it should obviously work, and the overhead for
>
"Arnd Hanses" <[EMAIL PROTECTED]> writes:
[...]
| Similar for lowercase() method, etc.
|
| I've no idea, if this is correct and clean. I'm still learning and all
| that is a bit complicated. Probably LString documentation can be
| enhanced, so that you can avoid answering over and over all the s
>>OK, Let's get these in first. I just commited a new function
>>CleanupPath() in cvs which does the following:
>>
>>===
>>RCS file: /usr/local/lyxsrc/cvsroot/lyx-1_0_x/src/filetools.C,v
>>retrieving revision 1.5
>>retrieving revision
On Mon, 26 Jul 1999 19:00:33 +0200 (MET DST), Jean-Marc Lasgouttes
wrote:
>> "Arnd" == Arnd Hanses <[EMAIL PROTECTED]> writes:
>
>Arnd> LString I found nice, filetools interesting: Is it possible to
>Arnd> build a shared library with a simple and consistent interface
>Arnd> out of such tool c
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| A correct syntax would be something like
|
| LString LString::discardSign() const
| {
| LString tmp = this;
| for (int i=0; i
On 27 Jul 1999 06:57:29 +0900, [EMAIL PROTECTED] wrote:
>BTW I like your suggestion of using isalnum().
Well, it's only a macro shorthand.
Please note, until filetools.C are cleaned, I have to let '.' (dots)
pass through this filter. I could not find a safe and efficient method
for stripping a
first of all: in the meantime I'd actually prefer Mime-style
encoding or replacement with a single char (say "_"). Anyway:
> With Andre's code I did not understand, how he would actually test for
> the best replacement (testing individually per char through a
The idea was simply to put the repl
On Mon, 26 Jul 1999 14:03:37 +0200 (MET DST), Jean-Marc Lasgouttes
wrote:
>Arnd> I'd like a safe and *efficient* method for conversion to
>Arnd> printable ASCII. Steal such a thing from somewhere to use it
>Arnd> with class LString?
>
>Use =XX (where XX is the hex value) like MIME does. This is
> "Arnd" == Arnd Hanses <[EMAIL PROTECTED]> writes:
Arnd> I'd like a safe and *efficient* method for conversion to
Arnd> printable ASCII. Steal such a thing from somewhere to use it
Arnd> with class LString?
Use =XX (where XX is the hex value) like MIME does. This is already
used in InsetR
> >+LString& LString::toAsciiPrintable()
> >+{
> >+for (int i=0; i >+p->s[i] &= 0x7f;
> >+p->s[i] |= 0x20; /* bad idea! */
> >+}
> >+return *this;
> >+}
What about a simple table lookup?
const char toAsciiData[] = " . ";
LString& LString::toAsciiP
> >XOR them all and let the processor sort them out :)
>
> You mean a toggle of all set bits of the mask, so that you can almost
> be sure, that at least one non-printable or non-ASCCI will result:
> Those file name picky versions of LaTeX will never run, your work will
> never be printed...
>
On Sat, 24 Jul 1999 13:35:03 -0500, Richard E. Hawkins wrote:
>
>> Well, and this one:
>>
>> >+ p->s[i] |= 0x20; /* fill dwarf bits to 32 and */
>> >+ p->s[i] &= 0x7f; /* decapitate all giants ... */
>>
>> This is efficient but random toggles many ascci chars... A bloody
>>
> Well, and this one:
>
> >+p->s[i] |= 0x20; /* fill dwarf bits to 32 and */
> >+p->s[i] &= 0x7f; /* decapitate all giants ... */
>
> This is efficient but random toggles many ascci chars... A bloody
> massacre of many innocent bits...
XOR them all and let the proces
On Sat, 24 Jul 1999 14:04:05 +0100, Arnd Hanses wrote:
>+ p->s[i] &= 0x7f;
>+ !(isprint(p->s[i])) ? (p->s[i] |= 0x20) : ; /* ? */
Well, and this one:
>+ p->s[i] |= 0x20; /* fill dwarf bits to 32 and */
>+ p->s[i] &= 0x7f; /* decapitate all gia
On Fri, 23 Jul 1999 02:30:19 +0100, Arnd Hanses wrote:
Add to LString.C:
>+/* SMiyata: bitwise AND 0x7f a string is more efficient than subst();
>+** ISO-8859-x and EUC (Extended Unix Code) works just fine with this.
>+** The only remaining problem is that Microsoft/IBM codepages,
>+** Shift-JI
On Fri, 23 Jul 1999 02:30:19 +0100, Arnd Hanses wrote:
Reading the patch, I see small mistakes:
1)
diff -p -N -r -U 4 -X excl.tmp src/original/filetools.C
src/modified/filetools.C
--- src/original/filetools.CWed May 12 06:51:18 1999
+++ src/modified/filetools.CFri Jul 23 01:18:56 1999
@@
On Fri, 23 Jul 1999 02:30:19 +0100, Arnd Hanses wrote:
>+ name.toAsciiPrintable(); /* AHanses: Set bit 0, unset bit >= 5
Arrgh typo in comment, I meant:
+ name.toAsciiPrintable(); /* AHanses: bit 4 high, bit > 5 low,
leave 0-3,5 as is */
1 - 100 of 104 matches
Mail list logo
