On Friday 04 May 2007 16:15:12 Abdelrazak Younes wrote:
> The preamble is part of the LyX file right? So it is susceptible to
> contain non latin unicode characters.
Do we a bug number and a user report for that one? ;-)
What would it be different between latin and non latin unicode?
I tri
The preamble is part of the LyX file right? So it is susceptible to
contain non latin unicode characters.
Shouldn't we transform that to docstring?
Abdel.
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> If it had only had been in math...
Lars> I am now leaning even further to use string in the arrays.
Not really. If you look at why the string is compared to "error", it
is because this is used as a marker for end-of-array, whi
Angus Leeming <[EMAIL PROTECTED]> writes:
| As flagged by MSVC. Committing now.
| --
| Angus
>
| Index: src/ChangeLog
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
| retrieving revision 1.2096
| diff -u -p -r1.20
As flagged by MSVC. Committing now.
--
AngusIndex: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.2096
diff -u -p -r1.2096 ChangeLog
--- src/ChangeLog 20 Jan 2005 21:34:22 - 1.20
John Weiss <[EMAIL PROTECTED]> writes:
>> PATH_MAX does not seem like a good idea. (and then you must at least
>> zero out application_support first.)
>
| Umm, Lars, the constructor for POD arrays *always* zeros out the
| elements, remember? (It's in the Standard; I know. I spent the
| summer st
John Weiss wrote:
> Umm, Lars, the constructor for POD arrays *always* zeros out the
> elements, remember?
Nonsense. There's no such thing as a constructor for POD types.
Maybe you're confusing things with what happens when a thing is defined as
*static*?
> (It's in the Standard; I know. I spen
> | Given this, which is MacOS X code to fill 'application_support':
> >> >
> >> | unsigned char application_support[PATH_MAX + 1];
> >> | OSStatus const status_code =
> >> | FSRefMakePath(&fsref, application_support, PATH_MAX);
> >&
t; | unsigned char application_support[PATH_MAX + 1];
>> | OSStatus const status_code =
>> | FSRefMakePath(&fsref, application_support, PATH_MAX);
>> >
>> | what's the correct way to create a std::string?
>> >
>> | std::s
> | OSStatus const status_code =
> | FSRefMakePath(&fsref, application_support, PATH_MAX);
> >
> | what's the correct way to create a std::string?
> >
> | std::string(application_support) fails.
>
> Do you know its length?
>
>std::string(application_s
Lars Gullik Bjønnes wrote:
> |char array[PATH_MAX + 1];
> |FSRefMakePath(&fsref, reinterpret_cast(array), PATH_MAX);
>
> So FSRefMakePath really should have another type.
It's hard to know how native API's are meant to be used when I've never,
ever coded for a Mac and haven't played with one for
Angus Leeming <[EMAIL PROTECTED]> writes:
>> | I think that it's safe to cast, but am I correct?
>> | std::string(reinterpret_cast(application_support));
>>
>> We should try to avoid it.
>
| Googling (strlen FSRefMakePath), I see lots of this sort
;
> | what's the correct way to create a std::string?
>>
> | std::string(application_support) fails.
>
> Do you know its length?
>
>std::string(application_support, application_support + length);
>
> ??
No. And, of course, std::strlen doesn't like
what's the correct way to create a std::string?
>
| std::string(application_support) fails.
Do you know its length?
std::string(application_support, application_support + length);
??
| error: invalid conversion from `unsigned char*' to `const char*'
Hmm... bad type to ret
Given this, which is MacOS X code to fill 'application_support':
unsigned char application_support[PATH_MAX + 1];
OSStatus const status_code =
FSRefMakePath(&fsref, application_support, PATH_MAX);
what's the correct way to create a std::strin
Kayvan A. Sylvan wrote:
> I had to do this to compile latest CVS on Cygwin:
Thank you. Now in.
--
Angus
7 22:53:03
@@ -17,6 +17,7 @@
#include
using std::endl;
+using std::string;
// OK, this is ugly, but it is the only workaround I found to compile
// with gcc (any version) on a system which uses a non-GNU toolchain.
Index: src/support/
Angus Leeming wrote:
> Yes and yes.
Done.
Jürgen.
Juergen Spitzmueller wrote:
> aspell.C, aspell_local.h have been forgotten.
> Is the attached patch correct (it compiles) and, if yes, can I apply
> it?
Yes and yes.
--
Angus
diff -u -r1.8 aspell.C
--- src/aspell.C 12 Sep 2003 07:41:09 - 1.8
+++ src/aspell.C 7 Oct 2003 12:11:39 -
@@ -22,6 +22,8 @@
#include
+using std::string;
+
ASpell::ASpell(BufferParams const &, string const & lang)
: els(0), spell_error_object(0)
Index: src/aspell
Martin Vermeer wrote:
> Of course it might be that an added became superfluous
> again by a later added one... I did not go back to check that (Would
> Angus have a script for that?).
Every header file should be able to be compiled on its own. I do have
a script to check that. Doing so (after up
Lars Gullik Bjønnes wrote:
> Did you fix all the problems in one go, or did you try to recompile
> in between.
> My method was to begin a recombile everytime i added a
It really doesn't matter though does it? Any file with a std::string
arg needs to know what std::string is. I w
Martin Vermeer <[EMAIL PROTECTED]> writes:
| In other words, a legal implementation can require #include
| throughout?
Yes.
--
Lgb
mpiled...
> My method was to begin a recombile everytime i added a
Same here.
Of course it might be that an added became superfluous again
by a later added one... I did not go back to check that (Would Angus
have a script for that?).
> >> But it shouldn't really matter... st
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Tue, Oct 07, 2003 at 06:32:29AM +0200, Lars Gullik Bjønnes spake thusly:
>> To: Martin Vermeer <[EMAIL PROTECTED]>
>> Cc: [EMAIL PROTECTED]
>> Subject: Re: std::string pathc
>> From: [EMAIL PROTECTED] (Lars
On Tue, Oct 07, 2003 at 06:32:29AM +0200, Lars Gullik Bjønnes spake thusly:
> To: Martin Vermeer <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: std::string pathc
> From: [EMAIL PROTECTED] (Lars Gullik Bjønnes)
> Organization: LyX Developer http://www.lyx.org/
>
Michael Schmitt <[EMAIL PROTECTED]> writes:
| Hello,
>
| I started with good intentions, was going to clean up bugzilla... but
| I all did for the next two hours was to recompile the whole tree and
| fix compilation errors thanks to the std::string patch. Hmpf... §%§$%§
>
| Lars,
it shouldn't really matter... strange though that STLport does not
forward declare std::string in about the same places as libstdc++.
--
Lgb
Martin Vermeer <[EMAIL PROTECTED]> writes:
| Thanks...
Early bird get the ...
| when you did this I pretty much knew how I would spend the
| rest of the evening... here's the patch needed for STLport. Feel free
| to commit, I'm hitting the sack.
>
| And *please* Lars, don't do anything yucky bef
1.86
+++ src/paragraph_pimpl.C 6 Oct 2003 19:58:09 -
@@ -31,6 +31,7 @@ using lyx::pos_type;
using std::endl;
using std::upper_bound;
+using std::lower_bound;
using std::string;
using std::ostream;
Index: src/textcursor.h
Michael Schmitt wrote:
> Lars, how did you manage to compile LyX? Some #include's are
> missing! Please see the attached patch.
Strange. I only needed the one in LColor.h to compile the Qt frontend.
Nonetheless, the others certainly do no harm, so I've added 'em too.
--
Angus
Hello,
I started with good intentions, was going to clean up bugzilla... but I
all did for the next two hours was to recompile the whole tree and fix
compilation errors thanks to the std::string patch. Hmpf... §%§$%§
Lars, how did you manage to compile LyX? Some #include's are missing!
P
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I am not quite sure what you are refering to, only find a
Lars> Solaris note about lyxstring might be needed. I just removed
Lars> that.
Lars> Did you have other changes in mind?
Well, I would have bet that we did mention --wi
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>>
| | Lars> Ok if I commit this now?
>>
| | Yes. Did you remember to modify INSTALL?
>
| No.
>
| I'll have a look at it now.
I am
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Ok if I commit this now?
>
| Yes. Did you remember to modify INSTALL?
No.
I'll have a look at it now.
--
Lgb
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Ok if I commit this now?
Yes. Did you remember to modify INSTALL?
JMarc
On Mon, Oct 06, 2003 at 04:45:30PM +0200, Lars Gullik Bjønnes wrote:
>
> Ok if I commit this now?
Just do it...
Andre'
Ok if I commit this now?
--
Lgb
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Friday 03 October 2003 2:34 pm, Lars Gullik Bjønnes wrote:
>> Object now or be silent forever!
>
| Why don't you post a patch to boost with all your
| bloody whitespace changes ;-)
O, forgot to get rid of those
| Apart from that --- go
On Friday 03 October 2003 2:34 pm, Lars Gullik Bjønnes wrote:
> Object now or be silent forever!
Why don't you post a patch to boost with all your
bloody whitespace changes ;-)
Apart from that --- go for it!
Angus
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| #ifdef __GLIBCPP__
>
| #include
>
| #endif
My preliminary results show that we gain close to nothing by doing
this.
--
Lgb
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Sep 10, 2003 at 05:52:27PM +, Angus Leeming wrote:
>> And Responder #3.
>> Summary: investigate writing your own string_fwd.h header file.
>
| Lars?
>
| Would you be ok with something like
>
| lstringfwd.h
>
| #ifndef LSTRINGFWD_H
| #define
Angus Leeming <[EMAIL PROTECTED]> writes:
| Personally, if compile-time overhead was a read problem,
| would rather implement a custom header for
| each platform I am using...
This looks like a much better solution to me.
(this might actually be something that we can get into boost...)
So,
e
>
> lstringfwd.h
Call it 'support/std_string_fwd.h'. I can't abide that 'L' prefix. And it is
attempting to forward declare std::string, so the name is reasonable too...
> This would already help most of us...
Try it and post the compile times. That's the only evidence worth having.
Angus
On Wed, Sep 10, 2003 at 05:52:27PM +, Angus Leeming wrote:
> And Responder #3.
> Summary: investigate writing your own string_fwd.h header file.
Lars?
Would you be ok with something like
lstringfwd.h
#ifndef LSTRINGFWD_H
#define LSTRINGFWD_H
#if __GNUCC__ > 3
# include "bits/stringf
And Responder #3.
Summary: investigate writing your own string_fwd.h header file.
Angus
,--- Forwarded message (begin)
Subject: Re: class String : public std::string {};
From: Ivan Vecerina <[EMAIL PROTECTED]>
Date: Wed, 10 Sep 2003 16:43:55 +
Hi Angus,
|
On Fri, Apr 05, 2002 at 01:44:15PM +0200, Lars Gullik Bjønnes wrote:
> std::string does not have a virtual destructor. It has never been
> inteded for inheritence.
Hm. Yes. That of course, does not mean it would not work for our stuff. We
don't need the virtual destructor, do we?
> >> Inheriting will mostlikely not work well, wrapping might work,
> >>
> | Mind telling me why?
>
> std::string does not have a virtual destructor. It has never been
> inteded for inheritence.
>
I'm only thinking of doing something like this:
size_
"Bjarke Roune" <[EMAIL PROTECTED]> writes:
>> | How about using a std::string wrapper which contains the needed asserts?
>> >
>> | I'm thinking of inheriting a wrapper from std::string and import that in
| the
>> | global namespace rather than s
> | How about using a std::string wrapper which contains the needed asserts?
> >
> | I'm thinking of inheriting a wrapper from std::string and import that in
the
> | global namespace rather than std::string. This way, LyX will always be
using
> | the assert-improved string,
> | I think that lyxstring is really better for our needs than
> | std::string. The fact that STL authors try to force us to use
> | std::string is a different matter :)
>
> Because of the asserts?
>
How about using a std::string wrapper which contains the needed asserts
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
| What is your recommendation regarding LyX RPMs? Should I generated
| them --with-included-string? That's my inclination, considering the
| 800K bloat.
Just use --with-included-string ... unless you want to create gtk
rpm's :-)
Lgb
On Tue, Jul 25, 2000 at 12:22:14AM +0200, Lars Gullik Bjønnes wrote:
>
> I have reduced LyX' requirements on std::string so that we are now
> able to compile with the std::string distributed with egcs and gcc
> 2.95.x. LyX will use this by default. If you want to use the lyxstr
I have reduced LyX' requirements on std::string so that we are now
able to compile with the std::string distributed with egcs and gcc
2.95.x. LyX will use this by default. If you want to use the lyxstring
you have to use --with-included-string. One "bad" thing about the
std::s
54 matches
Mail list logo
