Re: Subject: [PATCH] Make text selectable in Help > About LyX > Version
Kornel Benko writes: | Am Mittwoch, 31. Oktober 2012 um 16:46:53, schrieb Jean-Marc | Lasgouttes >> Le 31/10/2012 16:41, Kornel Benko a écrit : >> > git log -1 --format="%H %ci" >> >> Or simply >>git log -1 --format="%h" >> >> What I do not know is where to put such code so that it is always up to >> date. This should replace the date for development releases. >> >> JMarc > | I think, it should go to configure.ac. | To prevent unneeded recompilation, the defines should not go to | created config.h. If you go that way, the solution already exists... | Like in cmake-build maybe to a file included only by version.cpp. ... other places: generate version.cpp, let version.hpp(sic) be constant. -- Lgb
Re: Subject: [PATCH] Make text selectable in Help > About LyX > Version
Pavel Sanda writes: | Jean-Marc Lasgouttes wrote: >> What I do not know is where to put such code so that it is always up to >> date. This should replace the date for development releases. > | 1) linker time, something along the lines LDFLAGS += --defsym | __GITSHA=$$(git -1 log blablabla)) |and in the code extern char __GITSHA Why not just genereate a small C file? ... ...but putting it directly into the executable might actually be a good idea. | 2) keyword substitution (this was easy in svn but far more tricky via | gitattributes) never liked them. | 3) some hell with post-commit hooks This is not a good solution methings. > | Pavel > -- Lgb
Re: Subject: [PATCH] Make text selectable in Help > About LyX > Version
Jean-Marc Lasgouttes writes: | Le 31/10/2012 16:41, Kornel Benko a écrit : >> git log -1 --format="%H %ci" > | Or simply | git log -1 --format="%h" > | What I do not know is where to put such code so that it is always up | to date. This should replace the date for development releases. Hmm... git describe is usually used for things like this. -- Lgb
Re: git in 2.1
lar...@gullik.org (Lars Gullik Bjønnes) writes: | Alessandro Di Federico writes: > | | On Fri, 2012-10-26 at 18:03 +0200, Pavel Sanda wrote: >>> No, it is not. Adding some basic support (#0) like we have with other >>> RCS >>> is one weekend work and you'll spend more time on testing than coding. >>> >>> Some folks spoke about more fancy git support - in particular >>> #1) use git for bundled format >>> #2) use (some of) git codebase instead of relying on external calls >>>we use for rcs/cvs/svn. >> | | Yes, I've read the discussion about git. The problem on when to git-push | | emerged, but honestly I think that adding a dedicated | | command/button/menu item is much easier than all the other options like | | commit+push or just commit. However I may miss something. >> | | About #2, if I'm correct the question was just about knowing if the file | | is part of a git repo since we don't want to spawn a process each time a | | document is open. In the case we'd have to check "./.git", and | | "../.git", and "../../.git". I know this may be a problem in certain | | situations, but that's what git-status does, so we don't have much | | alternative. > | I really think that calling "git status" or a similar command is | perfectly ok, and while we wait for libgit to emerge, also the right | thing to do. git config --local core.repositoryFormatVersion might be the correct thing to use. -- Lgb
Re: git in 2.1
Alessandro Di Federico writes: | On Fri, 2012-10-26 at 18:03 +0200, Pavel Sanda wrote: >> No, it is not. Adding some basic support (#0) like we have with other >> RCS >> is one weekend work and you'll spend more time on testing than coding. >> >> Some folks spoke about more fancy git support - in particular >> #1) use git for bundled format >> #2) use (some of) git codebase instead of relying on external calls >>we use for rcs/cvs/svn. > | Yes, I've read the discussion about git. The problem on when to git-push | emerged, but honestly I think that adding a dedicated | command/button/menu item is much easier than all the other options like | commit+push or just commit. However I may miss something. > | About #2, if I'm correct the question was just about knowing if the file | is part of a git repo since we don't want to spawn a process each time a | document is open. In the case we'd have to check "./.git", and | "../.git", and "../../.git". I know this may be a problem in certain | situations, but that's what git-status does, so we don't have much | alternative. I really think that calling "git status" or a similar command is perfectly ok, and while we wait for libgit to emerge, also the right thing to do. -- Lgb
Re: Compilers used for compiling LyX?
Pavel Sanda writes: | Lars Gullik Bj?nnes wrote: >> Would be fun to see how far off we are from being able to use C++11. > | Which minimum version of gcc/MSVC is needed for your fun? I think we have to wait a bit. I'd prefere c++11 to be out of experimental state in gcc. So gcc 4.8 earliest, although in reality 4.6 might be ok, 4.7 certainly is. | Are there other projects around KDE/Qt already using C++11? | Perhaps the natural time would be when Qt start to use it. Dunno. I'd say no... we can certainly use c++11 features even if Qt or other libraries do not use it. More dependant on if the toolchain (read: gcc) manage to keep the C++03 and C++11 stdlib versions ABI compatible. MSVC seems yet again to be falling behind. -- Lgb
Re: Compilers used for compiling LyX?
Jean-Marc Lasgouttes writes: | Le 29/10/2012 06:36, Liviu Andronic a écrit : >> On Sun, Oct 28, 2012 at 11:58 AM, Jean-Marc Lasgouttes >> wrote: >>> I have 4.4 on my ubuntu 10.04 install. >>> >> Are you sure? Ubuntu Lucid ships Qt 4.6.2 [1]. >> [1] >> http://packages.ubuntu.com/search?keywords=libqt4&searchon=names&suite=all§ion=all > | I meant gcc 4.4. Qt is 4.6 of course. When does support of 10.04 stop? IMHO, when a distro goes into not-supported-mode we should not have to care about it anymore. Of course the LTS distros pose a problem in that respect. -- Lgb
Re: [PATCH] src/*.cpp: reformatting to increase consistency
Stephan Witt writes: | Am 27.10.2012 um 22:21 schrieb Lars Gullik Bjønnes : > >> On 27 October 2012 21:31, Stephan Witt wrote: >>> Am 27.10.2012 um 21:12 schrieb Lars Gullik Bjønnes : >>> >>>>> This invalidates all patches hanging around for cosmetic reasons. >>>>> Is this really necessary? >>>> >>>> Why do you have patches hanging around? >>> >>> Because I didn't apply them? >> >> Commit them to one or more branches and I'll rebase them to HEAD for you. > | Thanks, but Abdel is probably right. I can easily do this myself. > >> >>>> Are you saying that changes are hostage to undisclosed patches that >>>> someone might have? >>> >>> No, I asked if it's necessary to change the code for increased >>> consistency of coding style. >> >> Not necessary, but nice. Esp. consistency within a single file. >> >>> Can you point me to the rules for coding style please? >> >> I only know of the old files in development/coding. > | The best match I found is: > | - Adapt the formatting of your code to the one used in the |other parts of LyX. In case there is different formatting for |the same construct, use the one used more often. > | So this implies one should care for *own* code, IMHO. What if "one" has not done this? Who will ever to it then? (I'd call it a "bug" in the commit even, even if it can feel overly pedantic I do belive that should be part of review comments.) | I can understand your goal and I'm often tempted to change the formatting of our code base at work myself. | But because it is a matter of taste until it's not well defined there is some chance of "code format bouncing". It is pretty well defined how we format code in LyX. We can get some bouncing of course, but sometime it is not obvious how to format everyting. esp. when it compes to overlong constructs and who to make it more readable. (As as to work... there I do it completely different. You wouldn't want that style here.) -- Lgb
Retina support on Mac
What would having retina support on Mac entail for LyX? I just got a request for that (together with a donation). -- Lgb
Re: boost
Jean-Marc Lasgouttes writes: | Le 26/10/12 19:05, Pavel Sanda a écrit : >> BTW after some decade we still include boost in our tarballs and maintain >> its updates. What was the original reason and is it still needed? Some >> distributions disable internal boost and we do not see any flood of bug >> reports. > | If one wants to compile with external boost, then it is not possible | to compile with stdlib-debug. That is a problem if we would want to ditch internal boost completely, but as long as we keep the copy it is not a problem. I have seen some discussion about this on the boost list in the last few days, and they talked about createing a "super-debug" version that is compiled with stdlib-debug turned on. A distro with a boost-debug variant like that would probably work for us as well with stdlib-debug on. -- Lgb
Re: [PATCH] src/*.cpp: reformatting to increase consistency
On 27 October 2012 21:31, Stephan Witt wrote: > Am 27.10.2012 um 21:12 schrieb Lars Gullik Bjønnes : > >>> This invalidates all patches hanging around for cosmetic reasons. >>> Is this really necessary? >> >> Why do you have patches hanging around? > > Because I didn't apply them? Commit them to one or more branches and I'll rebase them to HEAD for you. >> Are you saying that changes are hostage to undisclosed patches that >> someone might have? > > No, I asked if it's necessary to change the code for increased consistency of > coding style. Not necessary, but nice. Esp. consistency within a single file. > Can you point me to the rules for coding style please? I only know of the old files in development/coding. -- Lgb
Re: [PATCH] src/*.cpp: reformatting to increase consistency
Stephan Witt writes: | Am 27.10.2012 um 15:46 schrieb Lars Gullik Bjønnes : > >> --- >> src/AppleSpellChecker.cpp | 6 +- >> src/AspellChecker.cpp | 32 +++-- >> src/Author.cpp| 13 +- >> src/BiblioInfo.cpp| 233 +- >> src/Bidi.cpp | 1 + >> src/BranchList.cpp| 5 +- >> src/Buffer.cpp| 16 ++- >> src/BufferList.cpp| 2 + >> src/BufferParams.cpp | 5 +- >> src/BufferView.cpp| 1 + >> src/Changes.cpp | 2 + >> src/Chktex.cpp| 3 +- >> src/CmdDef.cpp| 2 +- >> src/Color.cpp | 1 + >> src/Compare.cpp | 28 +++-- >> src/ConverterCache.cpp| 6 +- >> src/CoordCache.cpp| 1 + >> src/Counters.cpp | 2 +- >> src/Cursor.cpp| 314 >> +++--- >> src/CutAndPaste.cpp | 1 + >> src/DepTable.cpp | 6 +- >> src/DocIterator.cpp | 1 + >> src/EnchantChecker.cpp| 12 +- >> src/Encoding.cpp | 3 +- >> src/FontInfo.cpp | 192 ++-- >> src/Format.cpp| 15 ++- >> src/FuncStatus.cpp| 3 +- >> src/HSpace.cpp| 1 + >> src/HunspellChecker.cpp | 34 +++-- >> src/IndicesList.cpp | 8 +- >> src/LaTeXFeatures.cpp | 2 + >> src/Layout.cpp| 19 +-- >> src/LayoutFile.cpp| 11 +- >> src/LyX.cpp | 10 +- >> src/ModuleList.cpp| 10 +- >> src/Paragraph.cpp | 32 +++-- >> src/ParagraphMetrics.cpp | 3 +- >> src/PersonalWordList.cpp | 1 + >> src/Server.cpp| 8 +- >> src/ServerSocket.cpp | 1 - >> src/Session.cpp | 1 - >> src/Text.cpp | 1 + >> src/TextClass.cpp | 92 +++--- >> src/Thesaurus.cpp | 9 +- >> src/VCBackend.cpp | 1 + >> src/VSpace.cpp| 1 + >> src/WordList.cpp | 3 +- >> src/factory.cpp | 15 ++- >> src/lengthcommon.cpp | 2 + >> src/lyxfind.cpp | 25 ++-- >> src/output_docbook.cpp| 49 >> src/output_latex.cpp | 6 +- >> src/output_plaintext.cpp | 1 + >> src/output_xhtml.cpp | 17 +-- >> src/rowpainter.cpp| 2 + >> 55 files changed, 719 insertions(+), 552 deletions(-) > | This invalidates all patches hanging around for cosmetic reasons. | Is this really necessary? I can spread it out if you want to. Only fix inconsistencies when I am going to make some other changes anyway. But I do not understand why some patches that "hang around" should be allowed to decide anything. -- Lgb
Re: Compile problem with latest pull
Kayvan Sylvan writes: | On Fedora 16: > | CXXInsetListings.o | insets/InsetLine.cpp: In member function 'virtual void | lyx::InsetLine::metrics(lyx::MetricsInfo&, lyx::Dimension&) const': | insets/InsetLine.cpp:121:33: error: 'abs' was not declared in this scope On F16, that is actually surprising. does an include of fix it? What about ? -- Lgb
Re: [PATCH] src/*.cpp: reformatting to increase consistency
> This invalidates all patches hanging around for cosmetic reasons. > Is this really necessary? Why do you have patches hanging around? Are you saying that changes are hostage to undisclosed patches that someone might have? And if it takes you more than 5 minutes to fix the conflicts that you get, of all will be trivial. Then I'll go crawl back under a rock again. -- Lgb
Re: [PATCH 1/2] Author.cpp: Change to use Modified Bernstein's hash function
Pavel Sanda writes: | Lars Gullik Bj??nnes wrote: >>Change to use Modified Bernstein's hash function > | Doesn't this imply fileformat change/conversions so hashes generated | in 2.0 are correctly recognized in 2.1? Actually if I read the usage correctly we are free to change the hash function. A new hash is created only for new authors. And if I am not missing something, the author list is per document without any cross hearing. -- Lgb
Re: [PATCH 1/2] Author.cpp: Change to use Modified Bernstein's hash function
Pavel Sanda writes: | Lars Gullik Bj??nnes wrote: >>Change to use Modified Bernstein's hash function > | Doesn't this imply fileformat change/conversions so hashes generated | in 2.0 are correctly recognized in 2.1? Right. The Author feature is really lacking in documentation. This really seems like a bad thing to use hashes for, and specially a hash that can easily get collisions. But the case 2.0 -> 2.1 and not recoginized or recoginzed wrongly isn't that already presetn for all users? Hmm... and you store the full name in the .lyx file anyway, so what is the hash really used for? Forget this patch, except perhaps the part that makes the 33 stand out. (and int for hashes... hm) -- Lgb
[PATCH 2/2] Author.{h,cpp}: remove last_id
We can get the id from the size of the author container.
---
src/Author.cpp | 3 +--
src/Author.h | 2 --
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/Author.cpp b/src/Author.cpp
index b19e2be..5efa1fa 100644
--- a/src/Author.cpp
+++ b/src/Author.cpp
@@ -77,7 +77,6 @@ bool author_smaller(Author const & lhs, Author const & rhs)
AuthorList::AuthorList()
- : last_id_(0)
{}
@@ -96,7 +95,7 @@ int AuthorList::record(Author const & a)
return i;
}
authors_.push_back(a);
- return last_id_++;
+ return authors_.size() - 1;
}
diff --git a/src/Author.h b/src/Author.h
index 7d9f3dd..4ce2bcb 100644
--- a/src/Author.h
+++ b/src/Author.h
@@ -79,8 +79,6 @@ public:
std::ostream & operator<<(std::ostream & os, AuthorList const & a);
private:
///
- int last_id_;
- ///
Authors authors_;
};
--
1.8.0
[PATCH 1/2] Author.cpp: Change to use Modified Bernstein's hash function
Also remove the manual "optimization": 33 * hash == (hash << 5) + hash,
and just let the compiler handle that. The 33 really is important for
the function so it is nicer to let it stand out more.
---
src/Author.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/Author.cpp b/src/Author.cpp
index f4658e6..b19e2be 100644
--- a/src/Author.cpp
+++ b/src/Author.cpp
@@ -27,10 +27,10 @@ static int computeHash(docstring const & name,
docstring const & email)
{
string const full_author_string = to_utf8(name + email);
- // Bernstein's hash function
+ // Modified Bernstein's hash function
unsigned int hash = 5381;
for (unsigned int i = 0; i < full_author_string.length(); ++i)
- hash = ((hash << 5) + hash) + (unsigned
int)(full_author_string[i]);
+ hash = 33 * hash ^ (unsigned int)(full_author_string[i]);
return int(hash);
}
--
1.8.0
Berntein's hash
static int computeHash(docstring const & name,
docstring const & email)
{
string const full_author_string = to_utf8(name + email);
// Bernstein's hash function
unsigned int hash = 5381;
for (unsigned int c: full_author_string)
hash = ((hash << 5) + hash) + c;
return int(hash);
}
This Bernstein's hash, where does it come from. There referneces I have
found fot Bernstein's hash is rather different, or at the very least
hast=0 as initial value.
Allso the '<< 5' is suspicious since that is * 32, whereas the
references I have found uses * 33. No... by bad it adds another hash by
hand, resulting in 33. Hmm... does that generate better code? really?
This is the Modified Bernstein's hash function:
unsigned djb_hash ( void *key, int len )
{
unsigned char *p = key;
unsigned h = 0;
int i;
for ( i = 0; i < len; i++ )
h = 33 * h ^ p[i];
return h;
}
Adapted to our code that would be:
(C++11)
static int computeHash(docstring const & name,
docstring const & email)
{
string const full_author_string = to_utf8(name + email);
// Modified Bernstein's hash function
unsigned int hash = 0;
for (unsigned int c: full_author_string)
hash = 33 * hash ^ c;
return int(hash);
}
--
Lgb
Re: Compilers used for compiling LyX?
André Pönitz writes: | On Sat, Oct 27, 2012 at 01:35:26AM +0200, Lars Gullik Bjønnes wrote: >> >> Do any of you have feeling what compilers are use to compile LyX >> now-a-days, that at what version they are? >> >> Would be fun to see how far off we are from being able to use C++11. > | Might be worth a look: > | http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx Yes. VC11, suprisingly bad. I really thought it to be a lot better. -- Lgb
Re: boost
André Pönitz writes: | I thought I could simply shut up. Alas, it looks like I can't. > | On Sat, Oct 27, 2012 at 01:12:21AM +0200, Lars Gullik Bjønnes wrote: >> lar...@gullik.org (Lars Gullik Bjønnes) writes: >> >> | | BTW after some decade we still include boost in our tarballs and maintain >> | | its updates. What was the original reason and is it still needed? >> > >> | My preferences are as follows: >> > >> | 0. Standard C++ >> | 1. Something with the same apis/behaviour as standard C++ >> | 2. Use something that is destined for standardization. >> | 3. third party libraries. >> >> These are guidlines of course. More special requirements require more >> special measures. > | Keep your list of preferences, in the order you have, but, _please_, | qualify the items with a "if it helps the users." Note that "users" in this setting is just as well other developers as users of lyx the application. OTOH. We are in much more agreement than you think. -- Lgb
Re: boost
André Pönitz writes: | I thought I could simply shut up. Alas, it looks like I can't. > | On Sat, Oct 27, 2012 at 01:12:21AM +0200, Lars Gullik Bjønnes wrote: >> lar...@gullik.org (Lars Gullik Bjønnes) writes: >> >> | | BTW after some decade we still include boost in our tarballs and maintain >> | | its updates. What was the original reason and is it still needed? >> > >> | My preferences are as follows: >> > >> | 0. Standard C++ >> | 1. Something with the same apis/behaviour as standard C++ >> | 2. Use something that is destined for standardization. >> | 3. third party libraries. >> >> These are guidlines of course. More special requirements require more >> special measures. > | My preferences are tl;dr -- Lgb
Re: boost
Pavel Sanda writes: | Lars Gullik Bj?nnes wrote: >> My preferences are as follows: >> >> 0. Standard C++ >> 1. Something with the same apis/behaviour as standard C++ >> 2. Use something that is destined for standardization. >> 3. third party libraries. >> >> In a lot of cases 1 & 2 is solved by boost, when the stdlib/toolchain at >> hand does not support it directly. > | At the moment I was not asking about using boost dependency as such, | but whether there are still valid reasons for maintaining it in our | devel tree and distribute it within tarbals (the actual size of boost/ | is 2x bigger than src/ btw). I guess the case is basically for the same people with old compilers which tends to sit on old distros. -- Lgb
Compilers used for compiling LyX?
Do any of you have feeling what compilers are use to compile LyX now-a-days, that at what version they are? Would be fun to see how far off we are from being able to use C++11. -- Lgb
Re: boost
lar...@gullik.org (Lars Gullik Bjønnes) writes: | | BTW after some decade we still include boost in our tarballs and maintain | | its updates. What was the original reason and is it still needed? > | My preferences are as follows: > | 0. Standard C++ | 1. Something with the same apis/behaviour as standard C++ | 2. Use something that is destined for standardization. | 3. third party libraries. These are guidlines of course. More special requirements require more special measures. -- Lgb
Re: boost
lar...@gullik.org (Lars Gullik Bjønnes) writes: | Pavel Sanda writes: > | | Lars Gullik Bj?nnes wrote: >>> The problem is that somethings that I find highly non-controversial are >>> not thought so by others. >> | | If this is the problem, you can always go through the usual route | | "if no one objects I'll commit this later". >> >>> (Basically TR1 is dead and is often incompatible with C++11. Boost >>> almost always changes to be compatible with C++11). >> | | Correct me if I don't remember right, but TR1 (and conversion to standard | | once settled) was just excursion how far can we get while ditching | | boost, no? IIRC we were immediately hit by MSVC errors and the rest of | | TR1 ifdefs are zombies of this track in the code. > | (if I read commit logs etc correctly...) > | the tr1 stuff is there and the support/functional.h, support/smartptr.h, | ... is there since you do "using namespace std" and becuase you get tr1 | stuff just due to included of f.ex. with msvc. -- Lgb
Re: boost
Pavel Sanda writes: | Lars Gullik Bj?nnes wrote: >> The problem is that somethings that I find highly non-controversial are >> not thought so by others. > | If this is the problem, you can always go through the usual route | "if no one objects I'll commit this later". > >> (Basically TR1 is dead and is often incompatible with C++11. Boost >> almost always changes to be compatible with C++11). > | Correct me if I don't remember right, but TR1 (and conversion to standard | once settled) was just excursion how far can we get while ditching | boost, no? IIRC we were immediately hit by MSVC errors and the rest of | TR1 ifdefs are zombies of this track in the code. (if I read commit logs etc correctly...) the tr1 stuff is there and the support/functional.h, support/smartptr.h, ... is there since you do "using namespace std" and becuase you get tr1 stuff just due to included of f.ex. | BTW after some decade we still include boost in our tarballs and maintain | its updates. What was the original reason and is it still needed? My preferences are as follows: 0. Standard C++ 1. Something with the same apis/behaviour as standard C++ 2. Use something that is destined for standardization. 3. third party libraries. In a lot of cases 1 & 2 is solved by boost, when the stdlib/toolchain at hand does not support it directly. -- Lgb
Re: git in 2.1
Pavel Sanda writes: | Alessandro Di Federico wrote: >> This year I'm planning to put up a SVN server > | Right and it must be <1.7 :-/ > >> (sigh, no git support yet, and it may be too late now) > | No, it is not. Adding some basic support (#0) like we have with other RCS | is one weekend work and you'll spend more time on testing than coding. > | Some folks spoke about more fancy git support - in particular | #1) use git for bundled format | #2) use (some of) git codebase instead of relying on external calls |we use for rcs/cvs/svn. ad #2 ... very hard. really. but feel free to use plumbing. That can give better control, but is a bit "harder" to work with. | I don't see anyone working on this goal for 2.1 so the poor-man's | solution #0 wouldn't harm #1/#2. At least it would recover the | possibility to use RCS interface for our own documentation we lost | during (in)famous git transition of lyx codebase. RCS? lost? -- Lgb
Re: [PATCH 1/3] Buffer.cpp: drop unused
lar...@gullik.org (Lars Gullik Bjønnes) writes: | Jean-Marc Lasgouttes writes: > | | Lars, >> | | I propose that you commit the patches that you know are not | | controversial. This series of patches is a good example IMO. > | The problem is that somethings that I find highly non-controversial are | not thought so by others. But of course something is more obvious than others. -- Lgb
Re: [PATCH 1/3] Buffer.cpp: drop unused
Jean-Marc Lasgouttes writes: | Lars, > | I propose that you commit the patches that you know are not | controversial. This series of patches is a good example IMO. The problem is that somethings that I find highly non-controversial are not thought so by others. | Pavel, Vincent, this is probably the moment where you should weigh in | the discussion. I'd really that you though about how to solve the "using namespace std" debacle, and the ugly workarounds you have to counter measure the namespace pollution you get because of it. Also how that affects TR1 vs. C++11 vs. boost incompabilities. (Basically TR1 is dead and is often incompatible with C++11. Boost almost always changes to be compatible with C++11). -- Lgb
[PATCH 1/2] support/lyxalgo.h: introduce lyx::clamp
This returns a clamped value, requiring it to be between low and high.
clamp(5, 0, 10) == min(max(5, 0), 10) == max(min(5, 10), 0)
---
src/support/lyxalgo.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/support/lyxalgo.h b/src/support/lyxalgo.h
index f747e27..6ffb59b 100644
--- a/src/support/lyxalgo.h
+++ b/src/support/lyxalgo.h
@@ -83,6 +83,12 @@ void eliminate_duplicates(C & c)
c.erase(std::unique(c.begin(), c.end()), c.end());
}
+template
+T const & clamp(T const & value, T const & low, T const & high)
+{
+ return std::min(high, std::max(value, low));
+}
+
} // namespace lyx
#endif // LYX_ALGO_H
--
1.8.0
[PATCH 2/2] Use clamp
---
src/BufferView.cpp| 5 +++--
src/Text3.cpp | 3 ++-
src/frontends/qt4/GuiWorkArea.cpp | 3 ++-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index bb5ed50..079ee1c 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -77,6 +77,7 @@
#include "support/lstrings.h"
#include "support/Package.h"
#include "support/types.h"
+#include "support/lyxalgo.h"
#include
#include
@@ -653,7 +654,7 @@ void BufferView::setCursorFromScrollbar()
break;
case CUR_INSIDE:
int const y = getPos(oldcur).y_;
- newy = min(last, max(y, first));
+ newy = clamp(y, last, first);
if (y == newy)
return;
}
@@ -2171,7 +2172,7 @@ void BufferView::mouseEventDispatch(FuncRequest const &
cmd0)
// surrounding Text will handle this event.
// make sure we stay within the screen...
- cmd.set_y(min(max(cmd.y(), -1), height_));
+ cmd.set_y(clamp(cmd.y(), -1, height_));
d->mouse_position_cache_.x_ = cmd.x();
d->mouse_position_cache_.y_ = cmd.y();
diff --git a/src/Text3.cpp b/src/Text3.cpp
index ecb5d25..783f600 100644
--- a/src/Text3.cpp
+++ b/src/Text3.cpp
@@ -70,6 +70,7 @@
#include "support/gettext.h"
#include "support/lassert.h"
#include "support/lstrings.h"
+#include "support/lyxalgo.h"
#include "support/lyxtime.h"
#include "support/os.h"
@@ -1530,7 +1531,7 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd)
CursorSlice old = bvcur.top();
int const wh = bv->workHeight();
- int const y = max(0, min(wh - 1, cmd.y()));
+ int const y = clamp(cmd.y(), 0, wh - 1);
tm->setCursorFromCoordinates(cur, cmd.x(), y);
cur.setTargetX(cmd.x());
diff --git a/src/frontends/qt4/GuiWorkArea.cpp
b/src/frontends/qt4/GuiWorkArea.cpp
index b0dd01e..77b81cd 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -49,6 +49,7 @@
#include "support/gettext.h"
#include "support/FileName.h"
#include "support/lassert.h"
+#include "support/lyxalgo.h"
#include "frontends/Application.h"
#include "frontends/FontMetrics.h"
@@ -935,7 +936,7 @@ void GuiWorkArea::generateSyntheticMouseEvent()
int time = 200;
if (up || down) {
int dist = up ? -e_y : e_y - wh;
- time = max(min(200, 25 / (dist * dist)), 1) ;
+ time = clamp(25 / (dist * dist), 1, 200);
if (time < 40) {
step = 8 / (time * time);
--
1.8.0
[PATCH] insets/InsetLine.cpp: use std::abs
Use std::abs in stead of std::max(v, -v).
---
src/insets/InsetLine.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/insets/InsetLine.cpp b/src/insets/InsetLine.cpp
index 86a7e5c..f72fe64 100644
--- a/src/insets/InsetLine.cpp
+++ b/src/insets/InsetLine.cpp
@@ -118,7 +118,7 @@ void InsetLine::metrics(MetricsInfo & mi, Dimension & dim)
const
// set a minimal width
int const minw = (dim.wid < 0) ? 24 : 4;
- dim.wid = max(minw, max(dim.wid, -dim.wid));
+ dim.wid = max(minw, abs(dim.wid));
Length height = Length(to_ascii(getParam("height")));
height_ = height.inPixels(max_width, fm.width(char_type('M')));
--
1.8.0
[PATCH] Use new T not new T()
---
src/Buffer.cpp| 4 ++--
src/LyX.cpp | 8
src/WordList.cpp | 2 +-
src/frontends/qt4/GuiApplication.cpp | 4 ++--
src/frontends/qt4/GuiClipboard.cpp| 2 +-
src/frontends/qt4/GuiProgressView.cpp | 2 +-
src/frontends/qt4/GuiView.cpp | 2 +-
src/frontends/qt4/GuiViewSource.cpp | 2 +-
src/frontends/qt4/PanelStack.cpp | 2 +-
src/insets/InsetListingsParams.cpp| 4 ++--
10 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index ebc5d3a..a045dea 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -493,7 +493,7 @@ Buffer::~Buffer()
Buffer * Buffer::cloneFromMaster() const
{
BufferMap bufmap;
- cloned_buffers.push_back(new CloneList());
+ cloned_buffers.push_back(new CloneList);
CloneList * clones = cloned_buffers.back();
masterBuffer()->cloneWithChildren(bufmap, clones);
@@ -549,7 +549,7 @@ void Buffer::cloneWithChildren(BufferMap & bufmap,
CloneList * clones) const
Buffer * Buffer::cloneBufferOnly() const {
- cloned_buffers.push_back(new CloneList());
+ cloned_buffers.push_back(new CloneList);
CloneList * clones = cloned_buffers.back();
Buffer * buffer_clone = new Buffer(fileName().absFileName(), false,
this);
clones->insert(buffer_clone);
diff --git a/src/LyX.cpp b/src/LyX.cpp
index 722f040..2962207 100644
--- a/src/LyX.cpp
+++ b/src/LyX.cpp
@@ -1424,7 +1424,7 @@ void setSpellChecker()
if (lyxrc.spellchecker == "native") {
#if defined(USE_MACOSX_PACKAGING)
if (!singleton_->pimpl_->apple_spell_checker_)
- singleton_->pimpl_->apple_spell_checker_ = new
AppleSpellChecker();
+ singleton_->pimpl_->apple_spell_checker_ = new
AppleSpellChecker;
singleton_->pimpl_->spell_checker_ =
singleton_->pimpl_->apple_spell_checker_;
#else
singleton_->pimpl_->spell_checker_ = 0;
@@ -1432,7 +1432,7 @@ void setSpellChecker()
} else if (lyxrc.spellchecker == "aspell") {
#if defined(USE_ASPELL)
if (!singleton_->pimpl_->aspell_checker_)
- singleton_->pimpl_->aspell_checker_ = new
AspellChecker();
+ singleton_->pimpl_->aspell_checker_ = new AspellChecker;
singleton_->pimpl_->spell_checker_ =
singleton_->pimpl_->aspell_checker_;
#else
singleton_->pimpl_->spell_checker_ = 0;
@@ -1440,7 +1440,7 @@ void setSpellChecker()
} else if (lyxrc.spellchecker == "enchant") {
#if defined(USE_ENCHANT)
if (!singleton_->pimpl_->enchant_checker_)
- singleton_->pimpl_->enchant_checker_ = new
EnchantChecker();
+ singleton_->pimpl_->enchant_checker_ = new
EnchantChecker;
singleton_->pimpl_->spell_checker_ =
singleton_->pimpl_->enchant_checker_;
#else
singleton_->pimpl_->spell_checker_ = 0;
@@ -1448,7 +1448,7 @@ void setSpellChecker()
} else if (lyxrc.spellchecker == "hunspell") {
#if defined(USE_HUNSPELL)
if (!singleton_->pimpl_->hunspell_checker_)
- singleton_->pimpl_->hunspell_checker_ = new
HunspellChecker();
+ singleton_->pimpl_->hunspell_checker_ = new
HunspellChecker;
singleton_->pimpl_->spell_checker_ =
singleton_->pimpl_->hunspell_checker_;
#else
singleton_->pimpl_->spell_checker_ = 0;
diff --git a/src/WordList.cpp b/src/WordList.cpp
index 191dc33..5dcbc14 100644
--- a/src/WordList.cpp
+++ b/src/WordList.cpp
@@ -37,7 +37,7 @@ WordList * theWordList(Language const & lang)
if (it != theGlobalWordList.end())
return it->second;
else
- theGlobalWordList[lang] = new WordList();
+ theGlobalWordList[lang] = new WordList;
return theGlobalWordList[lang];
}
diff --git a/src/frontends/qt4/GuiApplication.cpp
b/src/frontends/qt4/GuiApplication.cpp
index 7806624..60473c9 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -737,7 +737,7 @@ struct GuiApplication::Private
{
#ifdef Q_WS_WIN
/// WMF Mime handler for Windows clipboard.
- wmf_mime_ = new QWindowsMimeMetafile();
+ wmf_mime_ = new QWindowsMimeMetafile;
#endif
initKeySequences(&theTopLevelKeymap());
}
@@ -2145,7 +2145,7 @@ void GuiApplication::execBatchCommands()
// Create the global default menubar which is shown for the dialogs
// and if no GuiView is visible.
// This must be done after the session was recovered to know the "last
files".
- d->global_menubar_ = new GlobalMenuBar();
+ d->global_menubar_ = new GlobalMenuBar;
d->menus_.fillMenuBar(d->global_menubar_, 0, true);
#endif
diff --git a/src/frontends/qt4
[PATCH 3/3] Use empty() to check empty and non-empty'ness not size()
Also add FormatList::empty().
---
src/BiblioInfo.cpp | 8 +++---
src/Cursor.cpp | 4 +--
src/Format.h | 2 ++
src/KeySequence.cpp | 3 +-
src/Paragraph.cpp| 4 +--
src/client/client.cpp| 10 +++
src/frontends/qt4/GuiPrefs.cpp | 4 +--
src/frontends/qt4/GuiToolbar.cpp | 2 +-
src/frontends/qt4/Menus.cpp | 12
src/graphics/GraphicsLoader.cpp | 2 +-
src/lyxfind.cpp | 4 +--
src/mathed/CommandInset.cpp | 2 +-
src/mathed/InsetMathBox.cpp | 4 +--
src/mathed/InsetMathExInt.cpp| 6 ++--
src/mathed/InsetMathGrid.cpp | 4 +--
src/mathed/InsetMathHull.cpp | 4 +--
src/mathed/InsetMathScript.cpp | 62
src/mathed/InsetMathXArrow.cpp | 2 +-
src/mathed/InsetMathXYArrow.cpp | 4 +--
src/mathed/MathAutoCorrect.cpp | 2 +-
src/mathed/MathData.cpp | 4 +--
src/mathed/MathExtern.cpp| 12
src/mathed/MathMacro.cpp | 5 ++--
src/mathed/MathMacroTemplate.cpp | 13 -
src/mathed/MathParser.cpp| 22 +++---
src/rowpainter.cpp | 4 +--
src/support/docstring.cpp| 2 +-
src/support/weighted_btree.h | 4 +--
src/tex2lyx/text.cpp | 2 +-
29 files changed, 106 insertions(+), 107 deletions(-)
diff --git a/src/BiblioInfo.cpp b/src/BiblioInfo.cpp
index bc46e17..93094f8 100644
--- a/src/BiblioInfo.cpp
+++ b/src/BiblioInfo.cpp
@@ -66,7 +66,7 @@ docstring familyName(docstring const & name)
vector::const_iterator it = pieces.begin();
vector::const_iterator en = pieces.end();
for (; it != en; ++it) {
- if ((*it).size() == 0)
+ if ((*it).empty())
continue;
char_type const c = (*it)[0];
if (isLower(c))
@@ -99,7 +99,7 @@ docstring convertLaTeXCommands(docstring const & str)
bool scanning_cmd = false;
bool scanning_math = false;
bool escaped = false; // used to catch \$, etc.
- while (val.size()) {
+ while (!val.empty()) {
char_type const ch = val[0];
// if we're scanning math, we output everything until we
@@ -323,7 +323,7 @@ namespace {
fmt = fmt.substr(2);
// we'll remove characters from the front of fmt as we
// deal with them
- while (fmt.size()) {
+ while (!fmt.empty()) {
if (fmt[0] == ']' && fmt.size() > 1 && fmt[1] == ']') {
// that's the end
fmt = fmt.substr(2);
@@ -415,7 +415,7 @@ docstring BibTeXInfo::expandFormat(string const & format,
string fmt = format;
// we'll remove characters from the front of fmt as we
// deal with them
- while (fmt.size()) {
+ while (!fmt.empty()) {
if (counter++ > max_passes) {
LYXERR0("Recursion limit reached while parsing `"
<< format << "'.");
diff --git a/src/Cursor.cpp b/src/Cursor.cpp
index b0f7b70..e38ca5e 100644
--- a/src/Cursor.cpp
+++ b/src/Cursor.cpp
@@ -588,7 +588,7 @@ void Cursor::checkNewWordPosition()
clearNewWordPosition();
else {
FontSpan nw = locateWord(WHOLE_WORD);
- if (nw.size()) {
+ if (!nw.empty()) {
FontSpan ow = new_word_.locateWord(WHOLE_WORD);
if (nw.intersect(ow).empty())
clearNewWordPosition();
@@ -1637,7 +1637,7 @@ bool Cursor::macroModeClose()
// we have to resolve the macro here manually and check its
arity
// to put the selection behind it if arity > 0.
MacroData const * data =
buffer()->getMacro(atomAsMacro->name());
- if (selection.size() > 0 && data && data->numargs() -
data->optionals() > 0) {
+ if (!selection.empty() && data && data->numargs() -
data->optionals() > 0) {
macroArg = true;
atomAsMacro->setDisplayMode(MathMacro::DISPLAY_INTERACTIVE_INIT, 1);
} else
diff --git a/src/Format.h b/src/Format.h
index 9d91ae1..b96120b 100644
--- a/src/Format.h
+++ b/src/Format.h
@@ -201,6 +201,8 @@ public:
///
const_iterator end() const { return formatlist.end(); }
///
+ bool empty() const { return formatlist.empty(); }
+ ///
FormatList::size_type size() const { return formatlist.size(); }
private:
///
diff --git a/src/KeySequence.cpp b/src/KeySequence.cpp
index a0f2f5b..3bee9ca 100644
--- a/src/KeySequence.cpp
+++ b/src/KeySequence.cpp
@@ -125,8 +125,7 @@ size_t KeySequence::parse(string const & s)
}
[PATCH 2/3] WS cleanup, remove extraeneous spaces
---
src/BufferParams.h | 2 +-
src/CutAndPaste.cpp | 2 +-
src/LyX.h | 3 +--
src/graphics/GraphicsLoader.cpp | 5 ++---
4 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/src/BufferParams.h b/src/BufferParams.h
index 306e5bc..98f79a5 100644
--- a/src/BufferParams.h
+++ b/src/BufferParams.h
@@ -134,7 +134,7 @@ public:
DocumentClass const & documentClass() const;
/// \return A pointer to the DocumentClass currently in use: the
BaseClass
/// as modified by modules.
- DocumentClassConstPtr documentClassPtr() const;
+ DocumentClassConstPtr documentClassPtr() const;
/// This bypasses the baseClass and sets the textClass directly.
/// Should be called with care and would be better not being here,
/// but it seems to be needed by CutAndPaste::putClipboard().
diff --git a/src/CutAndPaste.cpp b/src/CutAndPaste.cpp
index 4b95b9b..9a336a1 100644
--- a/src/CutAndPaste.cpp
+++ b/src/CutAndPaste.cpp
@@ -631,7 +631,7 @@ bool multipleCellsSelected(Cursor const & cur)
}
-void switchBetweenClasses(DocumentClassConstPtr oldone,
+void switchBetweenClasses(DocumentClassConstPtr oldone,
DocumentClassConstPtr newone, InsetText & in, ErrorList &
errorlist)
{
errorlist.clear();
diff --git a/src/LyX.h b/src/LyX.h
index af43edc..70b8b7e 100644
--- a/src/LyX.h
+++ b/src/LyX.h
@@ -144,7 +144,7 @@ private:
friend Messages const & getGuiMessages();
friend KeyMap & theTopLevelKeymap();
friend Movers & theMovers();
- friend Mover const & getMover(std::string const & fmt);
+ friend Mover const & getMover(std::string const & fmt);
friend void setMover(std::string const & fmt, std::string const &
command);
friend Movers & theSystemMovers();
friend frontend::Application * theApp();
@@ -180,4 +180,3 @@ void dispatch(FuncRequest const & action, DispatchResult &
dr);
} // namespace lyx
#endif // LYX_H
-
diff --git a/src/graphics/GraphicsLoader.cpp b/src/graphics/GraphicsLoader.cpp
index f635e0b..5ed19c6 100644
--- a/src/graphics/GraphicsLoader.cpp
+++ b/src/graphics/GraphicsLoader.cpp
@@ -96,11 +96,10 @@ void LoaderQueue::loadNext()
if (ptr->status() == WaitingToLoad)
ptr->startLoading();
}
- if (!cache_queue_.empty()) {
+ if (!cache_queue_.empty())
startLoader();
- } else {
+ else
stopLoader();
- }
}
--
1.8.0
[PATCH 1/3] Buffer.cpp: drop unused
--- src/Buffer.cpp | 1 - 1 file changed, 1 deletion(-) diff --git a/src/Buffer.cpp b/src/Buffer.cpp index 8b052ad..ebc5d3a 100644 --- a/src/Buffer.cpp +++ b/src/Buffer.cpp @@ -113,7 +113,6 @@ #include #include #include -#include #include using namespace std; -- 1.8.0
Re: [PATCH 10/13] More idiomatic way of checking if a shared_ptr has an associated managed object
lar...@gullik.org (Lars Gullik Bjønnes) writes:
Ok for me to commit this?
| ---
| src/KeyMap.cpp | 17 -
| src/frontends/qt4/LayoutBox.cpp| 4 ++--
| src/graphics/GraphicsCacheItem.cpp | 2 +-
| src/graphics/GraphicsLoader.cpp| 22 +++---
| src/support/ForkedCalls.cpp| 2 +-
| 5 files changed, 23 insertions(+), 24 deletions(-)
>
| diff --git a/src/KeyMap.cpp b/src/KeyMap.cpp
| index ffd55c4..50833c9 100644
| --- a/src/KeyMap.cpp
| +++ b/src/KeyMap.cpp
| @@ -115,13 +115,12 @@ void KeyMap::bind(KeySequence * seq, FuncRequest const
& func, unsigned int r)
| LYXERR(Debug::KBMAP, "Warning: New binding for
'"
| <<
to_utf8(seq->print(KeySequence::Portable))
| << "' is overriding old binding...");
| - if (it->prefixes.get()) {
| + if (it->prefixes)
| it->prefixes.reset();
| - }
| it->func = func;
| it->func.setOrigin(FuncRequest::KEYBOARD);
| return;
| - } else if (!it->prefixes.get()) {
| + } else if (!it->prefixes) {
| lyxerr << "Error: New binding for '"
| <<
to_utf8(seq->print(KeySequence::Portable))
| << "' is overriding old binding..."
| @@ -168,10 +167,10 @@ void KeyMap::unbind(KeySequence * seq, FuncRequest
const & func, unsigned int r)
| if (r + 1 == seq->length()) {
| if (it->func == func) {
| remove = it;
| - if (it->prefixes.get())
| + if (it->prefixes)
| it->prefixes.reset();
| }
| - } else if (it->prefixes.get()) {
| + } else if (it->prefixes) {
| it->prefixes->unbind(seq, func, r + 1);
| if (it->prefixes->empty())
| remove = it;
| @@ -201,7 +200,7 @@ FuncRequest KeyMap::getBinding(KeySequence const & seq,
unsigned int r)
| && mod2 == it->mod.second) {
| if (r + 1 == seq.length())
| return it->func;
| - else if (it->prefixes.get())
| + else if (it->prefixes)
| return it->prefixes->getBinding(seq, r + 1);
| }
| }
| @@ -441,7 +440,7 @@ FuncRequest const & KeyMap::lookup(KeySymbol const &key,
|
| if (cit->code == key && cit->mod.first == check) {
| // match found
| - if (cit->prefixes.get()) {
| + if (cit->prefixes) {
| // this is a prefix key - set new map
| seq->curmap = cit->prefixes.get();
| static FuncRequest prefix(LFUN_COMMAND_PREFIX);
| @@ -507,7 +506,7 @@ KeyMap::Bindings KeyMap::findBindings(FuncRequest const &
func,
|
| Table::const_iterator end = table.end();
| for (Table::const_iterator cit = table.begin(); cit != end; ++cit) {
| - if (cit->prefixes.get()) {
| + if (cit->prefixes) {
| KeySequence seq = prefix;
| seq.addkey(cit->code, cit->mod.first);
| Bindings res2 = cit->prefixes->findBindings(func, seq);
| @@ -555,7 +554,7 @@ void KeyMap::listBindings(BindingList & list,
| Table::const_iterator it_end = table.end();
| for (; it != it_end; ++it) {
| // a LFUN_COMMAND_PREFIX
| - if (it->prefixes.get()) {
| + if (it->prefixes) {
| KeySequence seq = prefix;
| seq.addkey(it->code, it->mod.first);
| it->prefixes->listBindings(list, seq, tag);
| diff --git a/src/frontends/qt4/LayoutBox.cpp b/src/frontends/qt4/LayoutBox.cpp
| index aa22e60..e11a63d 100644
| --- a/src/frontends/qt4/LayoutBox.cpp
| +++ b/src/frontends/qt4/LayoutBox.cpp
| @@ -536,7 +536,7 @@ void LayoutBox::set(docstring const & layout)
| {
| d->resetFilter();
|
| - if (!d->text_class_.get())
| + if (!d->text_class_)
| return;
|
| if (!d->text_class_->hasLayout(layout))
Re: [PATCH] config/lyxinclude.m4: add support for -flto
Jean-Marc Lasgouttes writes: | Le 24/10/12 22:18, Lars Gullik Bjønnes a écrit : >> Jean-Marc Lasgouttes writes: >> >> | Le 24/10/2012 13:13, Lars Gullik Bjønnes a écrit : >>>> Add feature --enable-lto, link-time optimization. >>> >> | Do you see a visible gain, that would make it worth using on release >> builds? >> >> textdatabss dec hexfilename >> 8042443 28616 39624 8110683 7bc25b src/lyx-flto >> 8912062 31888 40760 8984710 891886 src/lyx >> >> (or there about). If that is enough gain to be worth it? Dunno. >> >> It if faster is not that easy to measure. > | And is the link significantly more painful (time/memory)? Oh, yes to both. All optimization is redone, although wiht -flto=6 will will run the optmization/assembly 6-way paralell so it is not that bad on a multicore machine. Also you can compile with "-flto -O0" and link with "-flto -O2". So you might get a huge speed bonus on the compiling and only way when linking/optimizing. As a side note: textdatabss dec hexfilename 8817187 31904 40760 8889851 87a5fb src/lyx-cxx11 (Most likely due to rvalue-references and move semantics.) -- Lgb
Re: [PATCH 2/2] config/lyxinclude.m4: add support for --enable-cxx11
Richard Heck writes: | On 10/23/2012 09:07 PM, Lars Gullik Bjønnes wrote: >> Using --enable-cxx11 turns on C++11 mode in gcc. | Seems like a good idea. I will have to commit 1/2 in this series as well. Ok? -- Lgb
Re: [PATCH 5/5] src/lyxfind.cpp: use local typedef to simplify
André Pönitz writes:
| On Wed, Oct 24, 2012 at 01:27:40AM +0200, Lars Gullik Bjønnes wrote:
>> André Pönitz writes:
>>
>> | On Tue, Oct 23, 2012 at 11:14:42PM +0200, lar...@gullik.org wrote:
>> >> From: Lars Gullik Bjønnes
>> >>
>> >> Use a local typedef pair P to avoid having to repeat
>> >> that multiple times.
>> >> ---
>> >> src/lyxfind.cpp | 72
>> >> -
>> >> 1 file changed, 40 insertions(+), 32 deletions(-)
>> >>
>> >> diff --git a/src/lyxfind.cpp b/src/lyxfind.cpp
>> >> index a19724b..33dbd8a 100644
>> >> --- a/src/lyxfind.cpp
>> >> +++ b/src/lyxfind.cpp
>> >> @@ -495,54 +495,62 @@ typedef vector > Escapes;
>> >> /// @note Beware of order
>> >> Escapes const & get_regexp_escapes()
>> >> {
>> >> + typedef std::pair P;
>> >> +
>> >
>> | Conveniently adding a std:: or three, so next time the discussion
>> | comes up we can reasonably claim that it is used "inconsistently"
>> | and the 'using' on top could go...
>>
>> What is your agenda really?
>
| Preventing attempts to turn the LyX code base into a guinea pig for
| programming experiments again. Especially the kind of experiment that
| add a burden for others.
Since you are not doing any, perhaps you should let those that do
decide? I am not going to push anything without a +1 anyway.
--
Lgb
Re: [PATCH] config/lyxinclude.m4: add support for -flto
Jean-Marc Lasgouttes writes: | Le 24/10/2012 13:13, Lars Gullik Bjønnes a écrit : >> Add feature --enable-lto, link-time optimization. > | Do you see a visible gain, that would make it worth using on release builds? textdatabss dec hexfilename 8042443 28616 39624 8110683 7bc25b src/lyx-flto 8912062 31888 40760 8984710 891886 src/lyx (or there about). If that is enough gain to be worth it? Dunno. It if faster is not that easy to measure. -- Lgb
[PATCH] config/lyxinclude.m4: add support for -flto
Add feature --enable-lto, link-time optimization.
Enabling link-time optimization turns debug information off (-g),
sine -flto and -g does not currently well work together.
Also stdlib-debug is turned off, does also not work well with -flto.
---
config/lyxinclude.m4 | 27 +++
1 file changed, 27 insertions(+)
diff --git a/config/lyxinclude.m4 b/config/lyxinclude.m4
index 2e529ea..67aea1f 100644
--- a/config/lyxinclude.m4
+++ b/config/lyxinclude.m4
@@ -236,6 +236,24 @@ AC_ARG_ENABLE(cxx11,
AC_HELP_STRING([--enable-cxx11],[enable C++11 mode]),,
enable_cxx11=no;)
+AC_ARG_ENABLE(lto,
+ AC_HELP_STRING([--enable-lto],[enable link time optimization]),,
+ enable_lto=no;)
+case $enable_lto in
+yes)
+ lto_opt=-flto
+ enable_debug=no
+ enable_stdlib_debug=no
+ ;;
+no)
+ lto_opt=;;
+*)
+ lto_opt="-flto=${enable_lto}"
+ enable_debug=no
+ enable_stdlib_debug=no
+ ;;
+esac
+
AC_ARG_ENABLE(assertions,
AC_HELP_STRING([--enable-assertions],[add runtime sanity checks in the
program]),,
[AS_CASE([$build_type], [dev*|pre*], [enable_assertions=yes],
@@ -322,6 +340,15 @@ if test x$GXX = xyes; then
;;
esac
fi
+ if test x$enable_lto != xno ; then
+ case $gxx_version in
+ 4.7*|4.8*)
+ lyx_flags="$lyx_flags link-time-optimization"
+ CFLAGS="$lto_opt $CFLAGS"
+ CXXFLAGS="$lto_opt $CXXFLAGS"
+ ;;
+ esac
+ fi
fi
test "$lyx_pch_comp" = yes && lyx_flags="$lyx_flags pch"
AM_CONDITIONAL(LYX_BUILD_PCH, test "$lyx_pch_comp" = yes)
--
1.8.0
[PATCH 1/2] support/Messages.cpp: add space to not be taken as user defined literal
In C++11 you are not allowed to have non-literal specifiers right
after a string literal.
---
src/support/Messages.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/support/Messages.cpp b/src/support/Messages.cpp
index ca5c110..fdcaf66 100644
--- a/src/support/Messages.cpp
+++ b/src/support/Messages.cpp
@@ -119,7 +119,7 @@ bool Messages::available(string const & c)
// this loops at most twice
while (true) {
string const filen = locale_dir + "/" + code
- + "/LC_MESSAGES/"PACKAGE".mo";
+ + "/LC_MESSAGES/" PACKAGE ".mo";
if (FileName(filen).isReadableFile())
return true;
if (contains(code, '_'))
--
1.8.0
[PATCH 2/2] config/lyxinclude.m4: add support for --enable-cxx11
Using --enable-cxx11 turns on C++11 mode in gcc. --- config/lyxinclude.m4 | 16 1 file changed, 16 insertions(+) diff --git a/config/lyxinclude.m4 b/config/lyxinclude.m4 index e532c54..2e529ea 100644 --- a/config/lyxinclude.m4 +++ b/config/lyxinclude.m4 @@ -232,6 +232,10 @@ AC_ARG_ENABLE(pch, enable_pch=no;) lyx_pch_comp=no +AC_ARG_ENABLE(cxx11, + AC_HELP_STRING([--enable-cxx11],[enable C++11 mode]),, + enable_cxx11=no;) + AC_ARG_ENABLE(assertions, AC_HELP_STRING([--enable-assertions],[add runtime sanity checks in the program]),, [AS_CASE([$build_type], [dev*|pre*], [enable_assertions=yes], @@ -306,6 +310,18 @@ if test x$GXX = xyes; then ;; esac fi + if test x$enable_cxx11 = xyes ; then + case $gxx_version in + 4.3*|4.4*|4.5*|4.6*) + lyx_flags="$lyx_flags c++11-mode" + CXXFLAGS="-std=gnu++0x $CXXFLAGS" + ;; + 4.7*|4.8*) + lyx_flags="$lyx_flags c++11-mode" + CXXFLAGS="-std=gnu++11 $CXXFLAGS" + ;; + esac + fi fi test "$lyx_pch_comp" = yes && lyx_flags="$lyx_flags pch" AM_CONDITIONAL(LYX_BUILD_PCH, test "$lyx_pch_comp" = yes) -- 1.8.0
Re: FYI: compiling with gcc 4.8
lar...@gullik.org (Lars Gullik Bjønnes) writes: | gcc 4.8.0 (4.8.0 20121023 (experimental)): > | time make -j6 | real3m9.445s | user11m53.000s | sys 0m51.485s > | size src/lyx | text databss dec hexfilename | 11348213 31352 44504 11424069 ae5145 src/lyx > | ls -l ./src/lyx | 172783951 ./src/lyx gcc 4.8.0 (4.8.0 20121023 (experimental)) in gnu++11 mode: (some warnings about deprecated auto_ptr) time make -j6 real2m59.968s user12m54.708s sys 0m53.020s size src/lyx text databss dec hexfilename 11012251 31344 44408 11088003 a93083 src/lyx ls -l src/lyx 180181591 Oct 24 02:52 src/lyx -- Lgb
Re: [PATCH 5/5] src/lyxfind.cpp: use local typedef to simplify
André Pönitz writes:
| On Tue, Oct 23, 2012 at 11:14:42PM +0200, lar...@gullik.org wrote:
>> From: Lars Gullik Bjønnes
>>
>> Use a local typedef pair P to avoid having to repeat
>> that multiple times.
>> ---
>> src/lyxfind.cpp | 72
>> -
>> 1 file changed, 40 insertions(+), 32 deletions(-)
>>
>> diff --git a/src/lyxfind.cpp b/src/lyxfind.cpp
>> index a19724b..33dbd8a 100644
>> --- a/src/lyxfind.cpp
>> +++ b/src/lyxfind.cpp
>> @@ -495,54 +495,62 @@ typedef vector > Escapes;
>> /// @note Beware of order
>> Escapes const & get_regexp_escapes()
>> {
>> +typedef std::pair P;
>> +
>
| Conveniently adding a std:: or three, so next time the discussion
| comes up we can reasonably claim that it is used "inconsistently"
| and the 'using' on top could go...
What is your agenda really?
FYI: compiling with gcc 4.8
(AMD Phenom(tm) II X6 1090T Processor) gcc 4.7.2 (4.7.2 20120921 (Red Hat 4.7.2-2)): time make CXX=/usr/bin/g++ -j6 real3m1.055s user10m31.367s sys 0m49.691s size src/lyx text data bss dec hexfilename 11339834 3133645416 11416586 ae340a src/lyx ls -l ./src/lyx 169405554 ./src/lyx gcc 4.8.0 (4.8.0 20121023 (experimental)): time make -j6 real3m9.445s user11m53.000s sys 0m51.485s size src/lyx text databss dec hexfilename 11348213 31352 44504 11424069 ae5145 src/lyx ls -l ./src/lyx 172783951 ./src/lyx It seems that size and compile time not much has happened. (a good thing) No warnings¹ with gcc 4.7 nor with 4.8 (except one in Qt but I bet that will get fixed when gcc comes closer to release) ¹ That is with my boost warnings removed patch applied. -- Lgb
Re: [PATCH 11/13] Use make_shared to create shared_ptr
Jean-Marc Lasgouttes writes:
| Le 23/10/12 21:18, Lars Gullik Bjønnes a écrit :
>> | Concerning auto, I am still not sure that I like it.
>>
>> Liking it took me some 5 seconds.
>>
>> Auto suddenly makes it nice to work with the complex types you get in
>> C++.
>>
>> Imagine:
>>
>> auto func = [](){};
>> func();
>>
>> try to figure out what type func really is. Do you care?
>
| I care that I am wirting code with unknown types and suddenly I might
| be doing something awfully inefficient without knowing it. Plus I
| suspect that people who have not read the standard will not know wheat
| are the cases where auto is fine and where are the ones where "you
| obviously can't because XXX".
>
| JMarc
>
| PS: are you really telling me that [](){} is something valid? Frightening.
:-) heh
That is the new lambda expressions in C++11. Yes, it looks weird at
first, but are not hard to get used to and lambdas are nice.
Shortest possible C++ program that call a function:
--
int main(){[](){}();}
--
/ capture list
/ argument list
/ /function body
/ //
auto lambda = [](...){ ... };
example:
---
#include
#include
#include
#include
// Compile on a newer gcc:
// g++ -std=c++11 lambda_and_more.cpp
int main() {
std::vector v({9,8,7,6,5,4,3,2,1});
std::for_each(v.begin(), v.end(), [](int i){std::cout << i;});
std::sort(v.begin(), v.end(), [](int lhs, int rhs){ return lhs < rhs; });
std::copy(v.begin(), v.end(), std::ostream_iterator(std::cout, ","));
int sum = 0;
std::for_each(v.begin(), v.end(), [&](int i){ sum += i;});
std::cout << sum << std::endl;
}
--
Lgb
Re: [PATCH 13/13] boost: changes to make it compile cleanly with gcc 4.8
lar...@gullik.org (Lars Gullik Bjønnes) writes: | --- | boost/boost/lexical_cast.hpp | 1 - | boost/boost/math/special_functions/fpclassify.hpp | 4 | boost/boost/math/special_functions/sign.hpp | 2 -- | boost/boost/regex/v4/regex_format.hpp | 2 -- | boost/boost/regex/v4/regex_split.hpp | 1 - | boost/boost/static_assert.hpp | 2 +- | boost/boost/tuple/detail/tuple_basic.hpp | 1 - | 7 files changed, 1 insertion(+), 12 deletions(-) I'd really like to commit this one. Since current status makes it very tiresome to work with. (warnings galore). (If I have to redo this later on a boost upgrade is no problem.) Ok? -- Lgb
Re: [PATCH 11/13] Use make_shared to create shared_ptr
Abdelrazak Younes writes:
| On Tue, Oct 23, 2012 at 2:27 PM, Lars Gullik Bjønnes
wrote:
>> C++11 would make the code look a lot nicer, esp. thru the use of range
>> based for, and auto:
>>
>> std::vector::iterator at = somevec.begin();
>> std::vector::iterator end = someved.end();
>> for (; at != end; ++at) {
>> ...
>> }
>>
>> would be replaced with:
>>
>> for (auto & s: somevec) {
>> ...
>> }
>>
>> and
>>
>> std::vector > & vs = getVector();
>>
>> would be replaced with:
>>
>> auto & vs = getVector();
>
| That would be nice indeed but we would then require a recent version
| of gcc and msvc. Not a real problem for msvc but gcc is a problem if
| we want to support older distribution.
Not too much. Quite a bit of C++11 is supported in compilers back to gcc
gcc 4.3, but not really useful until 4.6. (auto in 4.5, range based for
in 4.6).
CentOS 4 has gcc 4.4 (as gcc4) but is rather ancient in itself.
I am not suggesting to begin using C++11 now, but in about a year it
should be really possible.
msvc 11 has ok support I think, same with clang.
Do you have other compilers that people use regularly?
--
Lgb
Re: [PATCH 11/13] Use make_shared to create shared_ptr
Jean-Marc Lasgouttes writes: | Le 23/10/2012 15:41, Abdelrazak Younes a écrit : >> I really don't understand the rationale, sorry. I'd consider very bad >> style to create our own lyx::vector or lyx::iostream, so what's the >> point? > | FWIW, we already define lyx::assert, lyx::shared_ptr, lyx::bind. To note: the lyx::shared_ptr is there _because_ of the "using namespace std", and the pollution that drags in on some compilers. -- Lgb
Re: [PATCH 11/13] Use make_shared to create shared_ptr
Jean-Marc Lasgouttes writes:
| Le 23/10/2012 14:27, Lars Gullik Bjønnes a écrit :
>> C++11 would make the code look a lot nicer, esp. thru the use of range
>> based for, and auto:
>>
>> std::vector::iterator at = somevec.begin();
>> std::vector::iterator end = someved.end();
>> for (; at != end; ++at) {
>> ...
>> }
>>
>> would be replaced with:
>>
>> for (auto & s: somevec) {
>> ...
>> }
>
| We already have a foreach macro that is not to bad, but we do not use
| it much:
| foreach (string & s, somevec) {
| ...
| }
>
| This is admittedly not as nice as real C++11, but if we converted code
| to use it, it would be trivial later to switch to the real thing.
>
| Concerning auto, I am still not sure that I like it.
Liking it took me some 5 seconds.
Auto suddenly makes it nice to work with the complex types you get in
C++.
Imagine:
auto func = [](){};
func();
try to figure out what type func really is. Do you care?
--
Lgb
Re: [PATCH 11/13] Use make_shared to create shared_ptr
Jean-Marc Lasgouttes writes: | Le 23/10/12 01:21, Lars Gullik Bjønnes a écrit : >> Anyhow... I am going to ditch the hole series. Pick what you want from >> it if anything. >> >> I just cannot stand the hostility. > | Come on. André is bored and he feel happy to be rude like in the good | old days. Nothing really personnal :) I am pretty sure he means is personal, and I just cannot be bothered with it. | Apart from the std:: namespace issue that seems a bit disruptive and | controversial, the other patches make sense to me. Moving away from | tr1 in particular. What I think you should do is to remove the "using namespace std", and add std:: wherever needed except for on string, as that really is all over, and use "using std::string" for that. -- Lgb
Re: Ad. "using namespace std" - ref prob in c9b9748c
Abdelrazak Younes writes: | On Mon, Oct 22, 2012 at 11:53 AM, Jean-Marc Lasgouttes | wrote: >> Le 22/10/2012 00:41, Lars Gullik Bjønnes a écrit : >> >>> >>> It is mentioned in c9b9748c that "using namespace std" on msvc10 also >>> drags in std::tr1 stuff. >> >> >>> IMHO a much better solution is to just use "std::" prefix where >>> required. >> >> >> You mean using std::string everywhere? That does not sound nice. > | +1 > >> I agree though that using std:: on other less used things is not a bad idea. > | Not even that. The style is consistent right now... Is it? Or did you mean to write in-consistent? | If you let some | exception to slip in it will be worse at the end. if you disallow using namespace std, and do not use "using std::xx" to drag anything into current namespace you will not get any exceptions. but if you look now, you will find several std:: used even if "using namespace std" is in effect in the same file. -- Lgb
Re: [PATCH 11/13] Use make_shared to create shared_ptr
Richard Heck writes: | On 10/21/2012 03:11 PM, Lars Gullik Bjønnes wrote: >> Using std::make_shared (and in our case for the time being >> boost::make_shared) >> is the preferred way of creating a std::shared_ptr. >> | Can we get some kind if mini-tutorial here, then, on how to use this | routine? I see several different ways it's present in this patch. Anyhow... I am going to ditch the hole series. Pick what you want from it if anything. I just cannot stand the hostility. -- Lgb
Re: Ad. "using namespace std" - ref prob in c9b9748c
Jean-Marc Lasgouttes writes: | Le 22/10/2012 00:41, Lars Gullik Bjønnes a écrit : >> >> It is mentioned in c9b9748c that "using namespace std" on msvc10 also >> drags in std::tr1 stuff. > >> IMHO a much better solution is to just use "std::" prefix where >> required. > | You mean using std::string everywhere? That does not sound nice. I'd say that, in practise, it really is nice. You never have to verify that this "string" really is std::string. Or that any other std:: entity really is the std::thingie. And you already are using std::string in all the headers. -- Lgb
Re: Ad. "using namespace std" - ref prob in c9b9748c
André Pönitz writes: | On Mon, Oct 22, 2012 at 12:41:08AM +0200, Lars Gullik Bjønnes wrote: >> >> It is mentioned in c9b9748c that "using namespace std" on msvc10 also >> drags in std::tr1 stuff. >> >> IMHO the soltion is not to use boost::shared_ptr etc. But to stop >> using "using namespace std". I look briefly as to what was discussed in >> 2007 when the "using namespace std" was introduced all over, and afaikr >> this was done to get rid of the "using std::" lines? Agree with >> the move to get rid of all the "using" lines, but not with the solution. >> >> IMHO a much better solution is to just use "std::" prefix where >> required. > | Precisely. Where required. Fortunately, it's not very often _required_. And where required would be everywhere outside namespace std. > | Namespaces exist for a reason, and the reason is not to spell them | fully out all the time. | If that had been the intention, all the | namespace wording could have just been left out of the Standard, | greatly simplifying it. Instead of 'std::vector' we would simply be | using 'std_vector'. Or use colons as part of identifiers. | It isn't like that - luckily. | namespaces exist for a reason, and the reason is to keep things | apart when needed, not when possible. neither is their reason to mash things together at first opportunity. >> I am willing to do the work to remove "using namespace std" and put >> std:: where required. This will also make declaration signatures >> cosistent with signatures on definitions, and without haveing a >> mixture of std:: and non-std:: in source files. > | I hope this crusade stops before it begins. This kind of "work" | adds no value to the source, just introduces an additional chore | for people when writing and reading code. > | LyX source is currently in a pretty good shape. Keep it like that. | There's no need for yet another Lost Decade of Overengineering. That was a hoot coming from you. -- Lgb
Re: Ad. "using namespace std" - ref prob in c9b9748c
Abdelrazak Younes writes: | On Mon, Oct 22, 2012 at 12:41 AM, Lars Gullik Bjønnes wrote: >> >> It is mentioned in c9b9748c that "using namespace std" on msvc10 also >> drags in std::tr1 stuff. >> >> IMHO the soltion is not to use boost::shared_ptr etc. But to stop >> using "using namespace std". I look briefly as to what was discussed in >> 2007 when the "using namespace std" was introduced all over, and afaikr >> this was done to get rid of the "using std::" lines? Agree with >> the move to get rid of all the "using" lines, but not with the solution. >> >> IMHO a much better solution is to just use "std::" prefix where >> required. > | Even better solution (IMHO): fix the source code to not use shared_ptr ;-) Where ever possible, of course avoid use of pointers. Unfortunately that is not really possible to gether with inheritance and passing by base class. If your solution then is raw pointers then I have no idea what to say... -- Lgb
Re: [PATCH 08/13] support/shared_ptr.h: drop support of TR1 smart pointers
Pavel Sanda writes:
| Lars Gullik Bj?nnes wrote:
>> diff --git a/src/support/shared_ptr.h b/src/support/shared_ptr.h
>> index 69e42da..792beb2 100644
>> --- a/src/support/shared_ptr.h
>> +++ b/src/support/shared_ptr.h
>> @@ -12,22 +12,6 @@
>> #ifndef LYX_SHARED_PTR_H
>> #define LYX_SHARED_PTR_H
>>
>> -#ifdef LYX_USE_TR1
>> -
>> -#include
>> -
>> -#ifdef __GNUC__
>> -#include
>> -#endif
>> -
>> -namespace lyx
>> -{
>> -using std::tr1::shared_ptr;
>> -using std::tr1::const_pointer_cast;
>> -}
>> -
>> -#else
>> -
>
| Didn't we have plans (and actually tried on last meeting) to finally
| drop boost and use TR1 instead?
We should not use TR1. Esp. not now when have got C++11.
(TR1 is not always compatible with C++11).
| Not that I have strong opinion about either direction but this
| looks to me as if we bounce from one corner to the other corner.
I have a followup patch to the one above that will change to using
std::shared_ptr (et.al) when available.
--
Lgb
Re: [PATCH 11/13] Use make_shared to create shared_ptr
Richard Heck writes: | On 10/21/2012 03:11 PM, Lars Gullik Bjønnes wrote: >> Using std::make_shared (and in our case for the time being >> boost::make_shared) >> is the preferred way of creating a std::shared_ptr. >> | Can we get some kind if mini-tutorial here, then, on how to use this | routine? I see several different ways it's present in this patch. I thought I did it the same way always? Basically std::make_shared(Args..) creates runs new Type(Args...) for you. (except that internally it juse placement new to only do one allocation so you get the ref-count allocated for "free") In the patch I sent I use std::make_shared (really boost::make_shared) and assigns the result to a shared_ptr. shared_ptr sp = make_shared(Args..); Can you ask me a more specific question? I am at loss at what/how to tutorialize more. But: http://www.boost.org/doc/libs/1_51_0/libs/smart_ptr/make_shared.html http://en.cppreference.com/w/cpp/memory/shared_ptr/make_shared -- Lgb
Ad. "using namespace std" - ref prob in c9b9748c
It is mentioned in c9b9748c that "using namespace std" on msvc10 also drags in std::tr1 stuff. IMHO the soltion is not to use boost::shared_ptr etc. But to stop using "using namespace std". I look briefly as to what was discussed in 2007 when the "using namespace std" was introduced all over, and afaikr this was done to get rid of the "using std::" lines? Agree with the move to get rid of all the "using" lines, but not with the solution. IMHO a much better solution is to just use "std::" prefix where required. I am willing to do the work to remove "using namespace std" and put std:: where required. This will also make declaration signatures cosistent with signatures on definitions, and without haveing a mixture of std:: and non-std:: in source files. -- Lgb
Re: [PATCH 03/13] src/Lyx: use boost::scoped_ptr to hold the pimpl
André Pönitz writes:
| On Sun, Oct 21, 2012 at 08:49:06PM +0200, Lars Gullik Bjønnes wrote:
>> diff --git a/src/LyX.h b/src/LyX.h
>> index 70b8b7e..97c9b4a 100644
>> --- a/src/LyX.h
>> +++ b/src/LyX.h
>> @@ -16,6 +16,7 @@
>>
>> #include "support/strfwd.h"
>>
>> +#include
>> #include
>>
>> namespace lyx {
>> @@ -126,7 +127,7 @@ private:
>> /// Use the Pimpl idiom to hide the internals.
>> // Mostly used for singletons.
>> struct Impl;
>> -Impl * pimpl_;
>> +boost::scoped_ptr pimpl_;
>>
>
| The Empire strikes back.
>
| Bald-pointer-phobia accompanied by swift C style
| use of "struct". What a deadly combination!
Heh no... me writing way too much C the last years.
Kindo flew out of my fingers without me even noticing.
But of course it really should have been std::unique_ptr, but we are not
quite there yet.
As for the phobia...
--
Lgb
[PATCH 07/13] graphics/GraphicsLoader.cpp: use !empty() to check for non-emptyness not size()
---
src/graphics/GraphicsLoader.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/graphics/GraphicsLoader.cpp b/src/graphics/GraphicsLoader.cpp
index 8f3a4cf..04dd7bd 100644
--- a/src/graphics/GraphicsLoader.cpp
+++ b/src/graphics/GraphicsLoader.cpp
@@ -89,7 +89,7 @@ void LoaderQueue::loadNext()
LYXERR(Debug::GRAPHICS, "LoaderQueue: "
<< cache_queue_.size() << " items in the queue");
int counter = s_numimages_;
- while (cache_queue_.size() && counter--) {
+ while (!cache_queue_.empty() && counter--) {
Cache::ItemPtr ptr = cache_queue_.front();
cache_set_.erase(ptr);
cache_queue_.pop_front();
--
1.8.0.rc3.16.g8ead1bf
[PATCH 03/13] src/Lyx: use boost::scoped_ptr to hold the pimpl
---
src/LyX.cpp | 5 +
src/LyX.h | 3 ++-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/LyX.cpp b/src/LyX.cpp
index 722f040..03caff3 100644
--- a/src/LyX.cpp
+++ b/src/LyX.cpp
@@ -64,7 +64,6 @@
#include "support/Systemcall.h"
#include "support/bind.h"
-#include
#include
#include
@@ -217,7 +216,6 @@ frontend::Application * theApp()
LyX::~LyX()
{
- delete pimpl_;
singleton_ = 0;
WordList::cleanupWordLists();
}
@@ -244,10 +242,9 @@ void lyx_exit(int exit_code)
LyX::LyX()
- : first_start(false)
+ : pimpl_(new Impl), first_start(false)
{
singleton_ = this;
- pimpl_ = new Impl;
}
diff --git a/src/LyX.h b/src/LyX.h
index 70b8b7e..97c9b4a 100644
--- a/src/LyX.h
+++ b/src/LyX.h
@@ -16,6 +16,7 @@
#include "support/strfwd.h"
+#include
#include
namespace lyx {
@@ -126,7 +127,7 @@ private:
/// Use the Pimpl idiom to hide the internals.
// Mostly used for singletons.
struct Impl;
- Impl * pimpl_;
+ boost::scoped_ptr pimpl_;
/// has this user started lyx for the first time?
bool first_start;
--
1.8.0.rc3.16.g8ead1bf
[PATCH 10/13] More idiomatic way of checking if a shared_ptr has an associated managed object
---
src/KeyMap.cpp | 17 -
src/frontends/qt4/LayoutBox.cpp| 4 ++--
src/graphics/GraphicsCacheItem.cpp | 2 +-
src/graphics/GraphicsLoader.cpp| 22 +++---
src/support/ForkedCalls.cpp| 2 +-
5 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/src/KeyMap.cpp b/src/KeyMap.cpp
index ffd55c4..50833c9 100644
--- a/src/KeyMap.cpp
+++ b/src/KeyMap.cpp
@@ -115,13 +115,12 @@ void KeyMap::bind(KeySequence * seq, FuncRequest const &
func, unsigned int r)
LYXERR(Debug::KBMAP, "Warning: New binding for
'"
<<
to_utf8(seq->print(KeySequence::Portable))
<< "' is overriding old binding...");
- if (it->prefixes.get()) {
+ if (it->prefixes)
it->prefixes.reset();
- }
it->func = func;
it->func.setOrigin(FuncRequest::KEYBOARD);
return;
- } else if (!it->prefixes.get()) {
+ } else if (!it->prefixes) {
lyxerr << "Error: New binding for '"
<<
to_utf8(seq->print(KeySequence::Portable))
<< "' is overriding old binding..."
@@ -168,10 +167,10 @@ void KeyMap::unbind(KeySequence * seq, FuncRequest const
& func, unsigned int r)
if (r + 1 == seq->length()) {
if (it->func == func) {
remove = it;
- if (it->prefixes.get())
+ if (it->prefixes)
it->prefixes.reset();
}
- } else if (it->prefixes.get()) {
+ } else if (it->prefixes) {
it->prefixes->unbind(seq, func, r + 1);
if (it->prefixes->empty())
remove = it;
@@ -201,7 +200,7 @@ FuncRequest KeyMap::getBinding(KeySequence const & seq,
unsigned int r)
&& mod2 == it->mod.second) {
if (r + 1 == seq.length())
return it->func;
- else if (it->prefixes.get())
+ else if (it->prefixes)
return it->prefixes->getBinding(seq, r + 1);
}
}
@@ -441,7 +440,7 @@ FuncRequest const & KeyMap::lookup(KeySymbol const &key,
if (cit->code == key && cit->mod.first == check) {
// match found
- if (cit->prefixes.get()) {
+ if (cit->prefixes) {
// this is a prefix key - set new map
seq->curmap = cit->prefixes.get();
static FuncRequest prefix(LFUN_COMMAND_PREFIX);
@@ -507,7 +506,7 @@ KeyMap::Bindings KeyMap::findBindings(FuncRequest const &
func,
Table::const_iterator end = table.end();
for (Table::const_iterator cit = table.begin(); cit != end; ++cit) {
- if (cit->prefixes.get()) {
+ if (cit->prefixes) {
KeySequence seq = prefix;
seq.addkey(cit->code, cit->mod.first);
Bindings res2 = cit->prefixes->findBindings(func, seq);
@@ -555,7 +554,7 @@ void KeyMap::listBindings(BindingList & list,
Table::const_iterator it_end = table.end();
for (; it != it_end; ++it) {
// a LFUN_COMMAND_PREFIX
- if (it->prefixes.get()) {
+ if (it->prefixes) {
KeySequence seq = prefix;
seq.addkey(it->code, it->mod.first);
it->prefixes->listBindings(list, seq, tag);
diff --git a/src/frontends/qt4/LayoutBox.cpp b/src/frontends/qt4/LayoutBox.cpp
index aa22e60..e11a63d 100644
--- a/src/frontends/qt4/LayoutBox.cpp
+++ b/src/frontends/qt4/LayoutBox.cpp
@@ -536,7 +536,7 @@ void LayoutBox::set(docstring const & layout)
{
d->resetFilter();
- if (!d->text_class_.get())
+ if (!d->text_class_)
return;
if (!d->text_class_->hasLayout(layout))
@@ -691,7 +691,7 @@ void LayoutBox::selected(int index)
d->model_->itemFromIndex(mindex)->text());
d->owner_.setFocus();
- if (!d->text_class_.get()) {
+ if (!d->text_class_) {
updateContents(false);
d->resetFilter();
return;
diff --git a/src/graphics/GraphicsCacheItem.cpp
b/src/graphics/GraphicsCacheItem.cpp
index 60477cc..46b76c5
[PATCH 09/13] support/shared_ptr.h: introduce boost::make_shared into ns lyx
---
src/support/shared_ptr.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/support/shared_ptr.h b/src/support/shared_ptr.h
index 792beb2..3aa6492 100644
--- a/src/support/shared_ptr.h
+++ b/src/support/shared_ptr.h
@@ -12,12 +12,13 @@
#ifndef LYX_SHARED_PTR_H
#define LYX_SHARED_PTR_H
-#include
+#include
namespace lyx
{
using boost::shared_ptr;
using boost::const_pointer_cast;
+ using boost::make_shared;
}
#endif
--
1.8.0.rc3.16.g8ead1bf
[PATCH 05/13] src/graphics/GraphicsCacheItem: use boost::scoped_ptr to hold the pimpl
---
src/graphics/GraphicsCacheItem.cpp | 1 -
src/graphics/GraphicsCacheItem.h | 3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/graphics/GraphicsCacheItem.cpp
b/src/graphics/GraphicsCacheItem.cpp
index fafa78b..60477cc 100644
--- a/src/graphics/GraphicsCacheItem.cpp
+++ b/src/graphics/GraphicsCacheItem.cpp
@@ -130,7 +130,6 @@ CacheItem::CacheItem(FileName const & file)
CacheItem::~CacheItem()
{
- delete pimpl_;
}
diff --git a/src/graphics/GraphicsCacheItem.h b/src/graphics/GraphicsCacheItem.h
index 481e4b1..51f97d5 100644
--- a/src/graphics/GraphicsCacheItem.h
+++ b/src/graphics/GraphicsCacheItem.h
@@ -31,6 +31,7 @@
#include "GraphicsTypes.h"
#include
+#include
namespace lyx {
@@ -98,7 +99,7 @@ private:
/// Use the Pimpl idiom to hide the internals.
class Impl;
/// The pointer never changes although *pimpl_'s contents may.
- Impl * const pimpl_;
+ boost::scoped_ptr const pimpl_;
};
} // namespace graphics
--
1.8.0.rc3.16.g8ead1bf
[PATCH 08/13] support/shared_ptr.h: drop support of TR1 smart pointers
---
src/support/shared_ptr.h | 19 ---
1 file changed, 19 deletions(-)
diff --git a/src/support/shared_ptr.h b/src/support/shared_ptr.h
index 69e42da..792beb2 100644
--- a/src/support/shared_ptr.h
+++ b/src/support/shared_ptr.h
@@ -12,22 +12,6 @@
#ifndef LYX_SHARED_PTR_H
#define LYX_SHARED_PTR_H
-#ifdef LYX_USE_TR1
-
-#include
-
-#ifdef __GNUC__
-#include
-#endif
-
-namespace lyx
-{
- using std::tr1::shared_ptr;
- using std::tr1::const_pointer_cast;
-}
-
-#else
-
#include
namespace lyx
@@ -37,6 +21,3 @@ namespace lyx
}
#endif
-
-
-#endif
--
1.8.0.rc3.16.g8ead1bf
[PATCH 13/13] boost: changes to make it compile cleanly with gcc 4.8
---
boost/boost/lexical_cast.hpp | 1 -
boost/boost/math/special_functions/fpclassify.hpp | 4
boost/boost/math/special_functions/sign.hpp | 2 --
boost/boost/regex/v4/regex_format.hpp | 2 --
boost/boost/regex/v4/regex_split.hpp | 1 -
boost/boost/static_assert.hpp | 2 +-
boost/boost/tuple/detail/tuple_basic.hpp | 1 -
7 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/boost/boost/lexical_cast.hpp b/boost/boost/lexical_cast.hpp
index 5a3d4f0..17ce576 100644
--- a/boost/boost/lexical_cast.hpp
+++ b/boost/boost/lexical_cast.hpp
@@ -626,7 +626,6 @@ namespace boost
#ifndef BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
BOOST_STATIC_ASSERT(!std::numeric_limits::is_signed);
#endif
-typedef typename Traits::int_type int_type;
CharT const czero = lcast_char_constants::zero;
--end;
value = 0;
diff --git a/boost/boost/math/special_functions/fpclassify.hpp
b/boost/boost/math/special_functions/fpclassify.hpp
index 2abec5f..3ec1d71 100644
--- a/boost/boost/math/special_functions/fpclassify.hpp
+++ b/boost/boost/math/special_functions/fpclassify.hpp
@@ -311,7 +311,6 @@ inline bool (isfinite)(T x)
{ //!< \brief return true if floating-point type t is finite.
typedef typename detail::fp_traits::type traits;
typedef typename traits::method method;
- typedef typename boost::is_floating_point::type fp_tag;
return detail::isfinite_impl(x, method());
}
@@ -370,7 +369,6 @@ inline bool (isnormal)(T x)
{
typedef typename detail::fp_traits::type traits;
typedef typename traits::method method;
- typedef typename boost::is_floating_point::type fp_tag;
return detail::isnormal_impl(x, method());
}
@@ -447,7 +445,6 @@ inline bool (isinf)(T x)
{
typedef typename detail::fp_traits::type traits;
typedef typename traits::method method;
- typedef typename boost::is_floating_point::type fp_tag;
return detail::isinf_impl(x, method());
}
@@ -516,7 +513,6 @@ template bool (isnan)(T x)
{ //!< \brief return true if floating-point type t is NaN (Not A Number).
typedef typename detail::fp_traits::type traits;
typedef typename traits::method method;
- typedef typename boost::is_floating_point::type fp_tag;
return detail::isnan_impl(x, method());
}
diff --git a/boost/boost/math/special_functions/sign.hpp
b/boost/boost/math/special_functions/sign.hpp
index 6de88b2..feab787 100644
--- a/boost/boost/math/special_functions/sign.hpp
+++ b/boost/boost/math/special_functions/sign.hpp
@@ -110,7 +110,6 @@ template int (signbit)(T x)
{
typedef typename detail::fp_traits::type traits;
typedef typename traits::method method;
- typedef typename boost::is_floating_point::type fp_tag;
return detail::signbit_impl(x, method());
}
@@ -124,7 +123,6 @@ template T (changesign)(const T& x)
{ //!< \brief return unchanged binary pattern of x, except for change of sign
bit.
typedef typename detail::fp_traits::sign_change_type traits;
typedef typename traits::method method;
- typedef typename boost::is_floating_point::type fp_tag;
return detail::changesign_impl(x, method());
}
diff --git a/boost/boost/regex/v4/regex_format.hpp
b/boost/boost/regex/v4/regex_format.hpp
index e05862f..d2ac6b9 100644
--- a/boost/boost/regex/v4/regex_format.hpp
+++ b/boost/boost/regex/v4/regex_format.hpp
@@ -1058,7 +1058,6 @@ struct format_functor_c_string
template
OutputIter operator()(const Match& m, OutputIter i,
boost::regex_constants::match_flag_type f, const Traits& t = Traits())
{
- typedef typename Match::char_type char_type;
const charT* end = func;
while(*end) ++end;
return regex_format_imp(i, m, func, end, f, t);
@@ -1077,7 +1076,6 @@ struct format_functor_container
template
OutputIter operator()(const Match& m, OutputIter i,
boost::regex_constants::match_flag_type f, const Traits& t = Traits())
{
- typedef typename Match::char_type char_type;
return re_detail::regex_format_imp(i, m, func.begin(), func.end(), f, t);
}
private:
diff --git a/boost/boost/regex/v4/regex_split.hpp
b/boost/boost/regex/v4/regex_split.hpp
index a7ae350..dc3e43e 100644
--- a/boost/boost/regex/v4/regex_split.hpp
+++ b/boost/boost/regex/v4/regex_split.hpp
@@ -107,7 +107,6 @@ std::size_t regex_split(OutputIterator out,
std::size_t max_split)
{
typedef typename std::basic_string::const_iterator
ci_t;
- typedef typename match_results::allocator_type
match_allocator;
ci_t last = s.begin();
std::size_t init_size = max_split;
re_detail::split_pred pred(&last,
&out, &max_split);
diff --git a/boost/boost/static_assert.hpp b/boost/boost/static_assert.hpp
index 9fe9bc0..4522d01 100644
--- a/boost/boost/static_assert.hpp
+++ b/boost/boost/static_assert.hpp
@@ -122,7 +122,7 @@ template struct static_assert_test{};
#define
Re: [PATCH 01/13] Buffer.cpp: drop unused
Jean-Marc Lasgouttes writes: | This patch, and the others I saw, make sense. However, I only see | numbers 1, 2, 4 and 6 (of supposedly 13 parts). For some reason the seem to be trickling in. I'll resend the missing once if they do no show up. -- Lgb
[PATCH 11/13] Use make_shared to create shared_ptr
Using std::make_shared (and in our case for the time being boost::make_shared)
is the preferred way of creating a std::shared_ptr. This is mainly due
to two aspects:
- half the number of allocations required
- potential of using less space, and better locality
Also a failed creation of the reference counted part of the object
will not make you leak the memory of the pointer object you just passed
to the share_ptr member function. (i.e. exception in the shared_ptr
member function).
---
src/KeyMap.cpp | 2 +-
src/OutputParams.cpp | 2 +-
src/ServerSocket.cpp | 2 +-
src/TextClass.cpp | 5 +++--
src/graphics/GraphicsCache.cpp | 2 +-
src/graphics/PreviewLoader.cpp | 4 ++--
src/insets/InsetNote.cpp | 6 +++---
src/insets/InsetTabular.cpp| 8
src/support/ForkedCalls.cpp| 5 ++---
src/support/ForkedCalls.h | 2 +-
10 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/src/KeyMap.cpp b/src/KeyMap.cpp
index 50833c9..f2cecc8 100644
--- a/src/KeyMap.cpp
+++ b/src/KeyMap.cpp
@@ -141,7 +141,7 @@ void KeyMap::bind(KeySequence * seq, FuncRequest const &
func, unsigned int r)
newone->func.setOrigin(FuncRequest::KEYBOARD);
newone->prefixes.reset();
} else {
- newone->prefixes.reset(new KeyMap);
+ newone->prefixes = make_shared();
newone->prefixes->bind(seq, func, r + 1);
}
}
diff --git a/src/OutputParams.cpp b/src/OutputParams.cpp
index f8af8ad..163622d 100644
--- a/src/OutputParams.cpp
+++ b/src/OutputParams.cpp
@@ -23,7 +23,7 @@ OutputParams::OutputParams(Encoding const * enc)
moving_arg(false), inulemcmd(false), local_font(0),
master_language(0),
encoding(enc), free_spacing(false), use_babel(false),
use_polyglossia(false),
use_indices(false), use_japanese(false), linelen(0), depth(0),
- exportdata(new ExportData),
+ exportdata(make_shared()),
inComment(false), inTableCell(NO), inFloat(NONFLOAT),
inIndexEntry(false), inIPA(false), inDeletedInset(0),
changeOfDeletedInset(Change::UNCHANGED),
diff --git a/src/ServerSocket.cpp b/src/ServerSocket.cpp
index 4c34212..b18c837 100644
--- a/src/ServerSocket.cpp
+++ b/src/ServerSocket.cpp
@@ -112,7 +112,7 @@ void ServerSocket::serverCallback()
// Register the new client.
clients[client_fd] =
- shared_ptr(new LyXDataSocket(client_fd));
+ make_shared(client_fd);
theApp()->registerSocketCallback(
client_fd,
bind(&ServerSocket::dataCallback,
diff --git a/src/TextClass.cpp b/src/TextClass.cpp
index 93eae96..9236ede 100644
--- a/src/TextClass.cpp
+++ b/src/TextClass.cpp
@@ -1434,8 +1434,9 @@ Layout TextClass::createBasicLayout(docstring const &
name, bool unknown) const
DocumentClassPtr getDocumentClass(
LayoutFile const & baseClass, LayoutModuleList const & modlist)
{
- DocumentClassPtr doc_class =
- DocumentClassPtr(new DocumentClass(baseClass));
+ // Since DocumentClass::DocumentClass(LayoutFile const &) is protected
+ // std::make_shared cannot be used here.
+ DocumentClassPtr doc_class(new DocumentClass(baseClass));
LayoutModuleList::const_iterator it = modlist.begin();
LayoutModuleList::const_iterator en = modlist.end();
for (; it != en; ++it) {
diff --git a/src/graphics/GraphicsCache.cpp b/src/graphics/GraphicsCache.cpp
index f9eee10..97a0c88 100644
--- a/src/graphics/GraphicsCache.cpp
+++ b/src/graphics/GraphicsCache.cpp
@@ -112,7 +112,7 @@ void Cache::add(FileName const & file) const
return;
}
- pimpl_->cache[file] = ItemPtr(new CacheItem(file));
+ pimpl_->cache[file] = make_shared(file);
}
diff --git a/src/graphics/PreviewLoader.cpp b/src/graphics/PreviewLoader.cpp
index 6185681..82fb7ca 100644
--- a/src/graphics/PreviewLoader.cpp
+++ b/src/graphics/PreviewLoader.cpp
@@ -627,7 +627,7 @@ void PreviewLoader::Impl::startLoading(bool wait)
// Initiate the conversion from LaTeX to bitmap images files.
ForkedCall::SignalTypePtr
- convert_ptr(new ForkedCall::SignalType);
+ convert_ptr = make_shared();
convert_ptr->connect(bind(&Impl::finishedGenerating, this, _1, _2));
ForkedCall call(buffer_.filePath());
@@ -683,7 +683,7 @@ void PreviewLoader::Impl::finishedGenerating(pid_t pid, int
retval)
// Add the image to the cache only if it's actually present
if (file.isReadableFile()) {
- PreviewImagePtr ptr(new PreviewImage(parent_, snip,
file, af));
+ PreviewImagePtr ptr =
make_shared(boost::ref(parent_), snip, file, af);
cache_[snip] = ptr;
newimages.push_back(ptr);
diff --git a/src/insets/InsetNote.cpp b/src/insets/InsetNote.c
[PATCH 12/13] graphics/GraphicsImage.h: let newImage and Image::clone return a shared_ptr
---
src/frontends/qt4/GuiImage.cpp | 8
src/frontends/qt4/GuiImage.h | 2 +-
src/graphics/GraphicsCacheItem.cpp | 2 +-
src/graphics/GraphicsImage.h | 5 +++--
src/graphics/GraphicsLoader.cpp| 2 +-
5 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/src/frontends/qt4/GuiImage.cpp b/src/frontends/qt4/GuiImage.cpp
index 503ad52..f1643db 100644
--- a/src/frontends/qt4/GuiImage.cpp
+++ b/src/frontends/qt4/GuiImage.cpp
@@ -32,9 +32,9 @@ namespace lyx {
namespace graphics {
/// Implement factory method defined in GraphicsImage.h
-Image * newImage()
+shared_ptr newImage()
{
- return new GuiImage;
+ return make_shared();
}
@@ -49,9 +49,9 @@ GuiImage::GuiImage(GuiImage const & other)
{}
-Image * GuiImage::clone() const
+shared_ptr GuiImage::clone() const
{
- return new GuiImage(*this);
+ return make_shared(*this);
}
diff --git a/src/frontends/qt4/GuiImage.h b/src/frontends/qt4/GuiImage.h
index 6f60644..9e97241 100644
--- a/src/frontends/qt4/GuiImage.h
+++ b/src/frontends/qt4/GuiImage.h
@@ -34,7 +34,7 @@ public:
private:
/// Create a copy
- Image * clone() const;
+ shared_ptr clone() const;
/// Get the image width
unsigned int width() const;
/// Get the image height
diff --git a/src/graphics/GraphicsCacheItem.cpp
b/src/graphics/GraphicsCacheItem.cpp
index 46b76c5..996b0b5 100644
--- a/src/graphics/GraphicsCacheItem.cpp
+++ b/src/graphics/GraphicsCacheItem.cpp
@@ -292,7 +292,7 @@ bool CacheItem::Impl::loadImage()
{
LYXERR(Debug::GRAPHICS, "Loading image.");
- image_.reset(newImage());
+ image_ = newImage();
bool success = image_->load(file_to_load_);
string const text = success ? "succeeded" : "failed";
diff --git a/src/graphics/GraphicsImage.h b/src/graphics/GraphicsImage.h
index 5488a76..b0d93b4 100644
--- a/src/graphics/GraphicsImage.h
+++ b/src/graphics/GraphicsImage.h
@@ -25,6 +25,7 @@
#define GRAPHICSIMAGE_H
#include "Dimension.h"
+#include "support/shared_ptr.h"
namespace lyx {
@@ -40,7 +41,7 @@ public:
virtual ~Image() {}
/// Create a copy
- virtual Image * clone() const = 0;
+ virtual shared_ptr clone() const = 0;
/// Get the image width
virtual unsigned int width() const = 0;
@@ -66,7 +67,7 @@ public:
/// Only way to create a new Image.
/// Implemented in the frontend.
-Image * newImage();
+shared_ptr newImage();
} // namespace graphics
} // namespace lyx
diff --git a/src/graphics/GraphicsLoader.cpp b/src/graphics/GraphicsLoader.cpp
index 5260d50..89c1440 100644
--- a/src/graphics/GraphicsLoader.cpp
+++ b/src/graphics/GraphicsLoader.cpp
@@ -429,7 +429,7 @@ void Loader::Impl::createPixmap()
return;
}
- image_.reset(cached_item_->image()->clone());
+ image_ = cached_item_->image()->clone();
bool const success = image_->setPixmap(params_);
--
1.8.0.rc3.16.g8ead1bf
[PATCH 04/13] src/graphics/GraphicsCache: use boost::scoped_ptr to hold the pimpl
---
src/graphics/GraphicsCache.cpp | 1 -
src/graphics/GraphicsCache.h | 4 +++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/graphics/GraphicsCache.cpp b/src/graphics/GraphicsCache.cpp
index d508563..f9eee10 100644
--- a/src/graphics/GraphicsCache.cpp
+++ b/src/graphics/GraphicsCache.cpp
@@ -59,7 +59,6 @@ Cache::Cache()
Cache::~Cache()
{
- delete pimpl_;
}
diff --git a/src/graphics/GraphicsCache.h b/src/graphics/GraphicsCache.h
index e6d810f..c66f72f 100644
--- a/src/graphics/GraphicsCache.h
+++ b/src/graphics/GraphicsCache.h
@@ -22,6 +22,8 @@
#include "support/shared_ptr.h"
+#include
+
#include
#include
@@ -84,7 +86,7 @@ private:
/// Use the Pimpl idiom to hide the internals.
class Impl;
/// The pointer never changes although *pimpl_'s contents may.
- Impl * const pimpl_;
+ boost::scoped_ptr pimpl_;
};
} // namespace graphics
--
1.8.0.rc3.16.g8ead1bf
[PATCH 06/13] src/graphics/GraphicsLoader: use boost::scoped_ptr to hold the pimpl
---
src/graphics/GraphicsLoader.cpp | 1 -
src/graphics/GraphicsLoader.h | 3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/graphics/GraphicsLoader.cpp b/src/graphics/GraphicsLoader.cpp
index bd81a50..8f3a4cf 100644
--- a/src/graphics/GraphicsLoader.cpp
+++ b/src/graphics/GraphicsLoader.cpp
@@ -230,7 +230,6 @@ Loader::Loader(Loader const & other)
Loader::~Loader()
{
- delete pimpl_;
}
diff --git a/src/graphics/GraphicsLoader.h b/src/graphics/GraphicsLoader.h
index 6521850..3258726 100644
--- a/src/graphics/GraphicsLoader.h
+++ b/src/graphics/GraphicsLoader.h
@@ -27,6 +27,7 @@
#include "GraphicsTypes.h"
#include
+#include
namespace lyx {
@@ -105,7 +106,7 @@ private:
/// Use the Pimpl idiom to hide the internals.
class Impl;
/// The pointer never changes although *pimpl_'s contents may.
- Impl * const pimpl_;
+ boost::scoped_ptr pimpl_;
};
} // namespace graphics
--
1.8.0.rc3.16.g8ead1bf
[PATCH 02/13] WS cleanup, remove extraeneous spaces
---
src/BufferParams.h | 2 +-
src/CutAndPaste.cpp | 2 +-
src/LyX.h | 3 +--
src/graphics/GraphicsLoader.cpp | 5 ++---
src/tex2lyx/tex2lyx.cpp | 4 ++--
5 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/src/BufferParams.h b/src/BufferParams.h
index 306e5bc..98f79a5 100644
--- a/src/BufferParams.h
+++ b/src/BufferParams.h
@@ -134,7 +134,7 @@ public:
DocumentClass const & documentClass() const;
/// \return A pointer to the DocumentClass currently in use: the
BaseClass
/// as modified by modules.
- DocumentClassConstPtr documentClassPtr() const;
+ DocumentClassConstPtr documentClassPtr() const;
/// This bypasses the baseClass and sets the textClass directly.
/// Should be called with care and would be better not being here,
/// but it seems to be needed by CutAndPaste::putClipboard().
diff --git a/src/CutAndPaste.cpp b/src/CutAndPaste.cpp
index 4b95b9b..9a336a1 100644
--- a/src/CutAndPaste.cpp
+++ b/src/CutAndPaste.cpp
@@ -631,7 +631,7 @@ bool multipleCellsSelected(Cursor const & cur)
}
-void switchBetweenClasses(DocumentClassConstPtr oldone,
+void switchBetweenClasses(DocumentClassConstPtr oldone,
DocumentClassConstPtr newone, InsetText & in, ErrorList &
errorlist)
{
errorlist.clear();
diff --git a/src/LyX.h b/src/LyX.h
index af43edc..70b8b7e 100644
--- a/src/LyX.h
+++ b/src/LyX.h
@@ -144,7 +144,7 @@ private:
friend Messages const & getGuiMessages();
friend KeyMap & theTopLevelKeymap();
friend Movers & theMovers();
- friend Mover const & getMover(std::string const & fmt);
+ friend Mover const & getMover(std::string const & fmt);
friend void setMover(std::string const & fmt, std::string const &
command);
friend Movers & theSystemMovers();
friend frontend::Application * theApp();
@@ -180,4 +180,3 @@ void dispatch(FuncRequest const & action, DispatchResult &
dr);
} // namespace lyx
#endif // LYX_H
-
diff --git a/src/graphics/GraphicsLoader.cpp b/src/graphics/GraphicsLoader.cpp
index 36f2839..bd81a50 100644
--- a/src/graphics/GraphicsLoader.cpp
+++ b/src/graphics/GraphicsLoader.cpp
@@ -96,11 +96,10 @@ void LoaderQueue::loadNext()
if (ptr->status() == WaitingToLoad)
ptr->startLoading();
}
- if (!cache_queue_.empty()) {
+ if (!cache_queue_.empty())
startLoader();
- } else {
+ else
stopLoader();
- }
}
diff --git a/src/tex2lyx/tex2lyx.cpp b/src/tex2lyx/tex2lyx.cpp
index 360c126..7bac21e 100644
--- a/src/tex2lyx/tex2lyx.cpp
+++ b/src/tex2lyx/tex2lyx.cpp
@@ -254,7 +254,7 @@ bool checkModule(string const & name, bool command)
// This is needed since a module cannot be read on its own, only as
// part of a document class.
LayoutFile const & baseClass = LayoutFileList::get()[textclass.name()];
- typedef map ModuleMap;
+ typedef map ModuleMap;
static ModuleMap modules;
static bool init = true;
if (init) {
@@ -289,7 +289,7 @@ bool checkModule(string const & name, bool command)
continue;
if (findInsetLayoutWithoutModule(textclass, name, command))
continue;
- DocumentClassConstPtr c = it->second;
+ DocumentClassConstPtr c = it->second;
Layout const * layout = findLayoutWithoutModule(*c, name,
command);
InsetLayout const * insetlayout = layout ? 0 :
findInsetLayoutWithoutModule(*c, name, command);
--
1.8.0.rc3.16.g8ead1bf
[PATCH 01/13] Buffer.cpp: drop unused
--- src/Buffer.cpp | 1 - 1 file changed, 1 deletion(-) diff --git a/src/Buffer.cpp b/src/Buffer.cpp index 8b052ad..ebc5d3a 100644 --- a/src/Buffer.cpp +++ b/src/Buffer.cpp @@ -113,7 +113,6 @@ #include #include #include -#include #include using namespace std; -- 1.8.0.rc3.16.g8ead1bf
Re: branch warnings
Jean-Marc Lasgouttes writes: | Le 09/10/2012 20:49, Lars Gullik Bjønnes a écrit : >> Jürgen Spitzmüller writes: >> >> | Jean-Marc Lasgouttes wrote: >>>>> ../boost/boost/config/stdlib/libstdcpp3.hpp:42:0: warning: >>>>> "BOOST_DISABLE_THREADS" redefined [enabled by default] >>>>> In file included from BiblioInfo.cpp:13:0: >>>>> ../config.h:628:0: note: this is the location of the previous definition >>>> >>>> Is it only on branch? >>> >> | Yes, I only see it on branch. >> >> Is branch the only place where you do --without-included-boost? > | Actually, branch and trunk do not have the same boost version AFAIK | (1.43 vs 1.49). Then I think you should check the (generated) dependency files to see that you do not drag in unwanted (system) boost headers. Can be the case of missing files in the in-lyx boost copy. -- Lgb
Re: Press about LyX
Jürgen Spitzmüller writes: | Jerry wrote: >> Who among the LyX developers has the power to edit the press page, >> http://www.lyx.org/PressAboutLyX? Daniel has written an article about LyX >> for the HowToAnswer web site and would like to get it linked from the LyX >> press page. Surely this benefits the LyX community as well. > | I've added it. Thanks for the review. I put it on G+ as well. -- Lgb
Re: branch warnings
Jürgen Spitzmüller writes: | Lars Gullik Bjønnes wrote: >> Is branch the only place where you do --without-included-boost? > | I don't specify that explicitly. > | I compile trunk | --with-version-suffix=-svn --enable-maintainer-mode > | and branch with | --enable-build-type=rel > | whatever these switches do in details. The reason why I asked, that I have seen these warnings too, but only when I am or have been fiddling with --without-included-boost etc. first. -- Lgb
Re: branch warnings
Jürgen Spitzmüller writes: | Jean-Marc Lasgouttes wrote: >> > ../boost/boost/config/stdlib/libstdcpp3.hpp:42:0: warning: >> > "BOOST_DISABLE_THREADS" redefined [enabled by default] >> > In file included from BiblioInfo.cpp:13:0: >> > ../config.h:628:0: note: this is the location of the previous definition >> >> Is it only on branch? > | Yes, I only see it on branch. Is branch the only place where you do --without-included-boost? -- Lgb
Re: [patch] fix warning on branch
Scott Kostyshak writes:
| On Thu, Sep 27, 2012 at 3:53 PM, Scott Kostyshak wrote:
>> On Thu, Sep 27, 2012 at 1:51 PM, Julien Rioux
>> wrote:
>>> On 27/09/2012 7:17 AM, Scott Kostyshak wrote:
- ::write(pipefd, cmd.c_str(), cmd.length());
+if (::write(pipefd, cmd.c_str(), cmd.length()) < 0)
+LYXERR0("Cannot write to pipe!");
>>>
>>>
>>> You're space-indenting in a tab-indented file here.
>>>
>>
>> Good catch. I thought I had git set up to detect these white space
>> errors but I guess not.
>>
>> Attached is the updated patch.
>>
>
| Attached are the three patches for branch (they are the same as in the
| last two emails but I wanted to put them all in one place).
>
| Should they go in?
Not my call, so I just look at the patches by themselves.
| From 877398ce2faa5751a62639c9c20978eb3ff33c35 Mon Sep 17 00:00:00 2001
| From: Scott Kostyshak
| Date: Sun, 23 Sep 2012 04:58:19 -0400
| Subject: [PATCH 1/3] Remove unused function find_matching_brace
>
| find_matching_brace came over from a backport and is not being used.
This looks like a harmless change.
| From 35dcd7f6fb88a47bda9342e53d528cb521f34505 Mon Sep 17 00:00:00 2001
| From: Scott Kostyshak
| Date: Thu, 27 Sep 2012 06:29:27 -0400
| Subject: [PATCH] Use a return value to report an unsuccessful write
>
| Use a return value in LyXComm::loadFilesInOtherInstance to give an
| error for a failed write to pipe.
Not sure. Is the error handled any differently from the non-error path?
(except the message)?
We absolutely should check the return from ::write, but I am not sure if
it is enought to do _just_ that.
| From b7582fc12ac0b8130ff26f7a735b12e200e5a714 Mon Sep 17 00:00:00 2001
| From: Scott Kostyshak
| Date: Thu, 27 Sep 2012 06:26:46 -0400
| Subject: [PATCH 2/3] Get rid of unused variable to eliminate warning
>
| The variable 'c' in Lexer::Pimpl::setFile was not being used.
This seem obvious, and it is already done on trunk in ea50cd71
(Which should/could be mentioned in the commit message)
--
Lgb
Re: [PATCH (?)] add -Werror to autotools and cmake ?
André Pönitz writes: | On Sat, Sep 29, 2012 at 04:53:00AM -0400, Scott Kostyshak wrote: >> I have been thinking about compiler warnings because of the recent >> discussion here: >> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg175099.html >> >> >From that thread, I have the understanding that some developers think >> it's important to fix warnings, although not if it is risky. I don't >> have much experience programming so I wouldn't be surprised if there's >> something wrong with the following logic: >> >> It seems to me that warnings should either be fixed when they occur or >> just ignored. That is, if a warning is viewed to be a problem, it >> should be fixed right when it's introduced. Or, if it is not viewed as >> a problem, it should just be permanently ignored. I don't see any >> advantage to having warnings sit around. >> >> Thus, I wonder if it would be useful to specify "-Werror" in the >> development build, which would turn all warnings into errors and would >> alert the author to fix them right away. > | And as soon as the next version of a compiler decides to spit out | more warnings (and we know that not all warnings are warranted) What I know is that almost _all_ warnings _are_ warranted. And even when they are not, you can almost always fixup your code to not give the warning without making the code any uglier/more unclear. | the code base suddenly does not compile anymore, for no good reason, | and people will have to spend time to reconfigure or patch around | the problem, when all they want is just to get a fresh build. We certainly would not put that burden on our users, but for developers testing out new platforms haveing to do a --allow-warnings to configure would imho not be such a bad thing. | There's nothing wrong with keeping a -Werror enabling patch locally, | git makes this extremely easy. But it's nothing that should be on | by default. But we should perhaps have a configure switch for -Werror. Then we can argue later on what should be the default for it. -- Lgb
Re: [LyX 2.0.x] Fix bug #8349: Cannot compile 2.0.x: unresolved external symbol
Jean-Marc Lasgouttes writes: | Le 24/09/12 19:33, Vincent van Ravesteijn a écrit : >> Op 24-9-2012 16:28, Jean-Marc Lasgouttes schreef: >>> That's amusing. This is a patch from Stephan that I backported, and it >>> looks like Stephan did the backport, which does not help communication. >> >> Just get used to a more advanced form of communication. It is Stephan's >> code, which you committed. We just need to fix the e-mail send script if >> you really want to > | Actually, I understand that. My point is to get the correct answer to | "who pushed this thing?" >From a repo prespective that is a pointless question. OTOH, we have that information in the gitolite logs. It is not hard to make it part of the commit mail if you want it. > >> This is your own stupidity as well. First fetch and merge before you add >> your new commits to the branch. If you already commit something and the >> push fails, then you rebase onto the remote branch. You should merge or >> pull to avoid this no-op commits. > | Hmm, does this mean that I made modifications before doing a "pull"? | Maybe... > | Related question: are there reasons to use plain "git pull", or should | I always add --rebase ? Yes, there is. --rebase is often nice, but not always. | Nevertheless, what is there in this commit? If it is as empty as it | looks is is git's job to do something about it, instead of exposing | obscenely its guts. It is showing exactly what happend. How it happend and how that connects the world together. And it is not as empty as it looks, it brings the history (read: commit graph) together. Using the commit mails to get a feel of git graph/history is not the best, even git log will confuse you unless you also use git log --graph, to get a real feel for the git graph/history topology you should use gitk. Use it often, use it to look at what _you_ plan to push upstream. (also gitk --all got get a repo wide look with all branches.) (and learn to work on topic branches, even for small stuff.) -- Lgb
Re: [patch] fix warning on branch
Scott Kostyshak writes:
| On Thu, Sep 20, 2012 at 5:49 PM, Lars Gullik Bjønnes
wrote:
>> btw. std::string::c_str() should not be used here,
>> use std::string::data() instead.
>
| Lars, can you confirm that I made the right corrections? I changed
| c_str() to data() in two places. If they are right I will also make
| these changes to trunk.
The new one is not correct.
std::string::c_str will return the a const char * with a '\0' tacked on
to the end. So when a function expects to get a c-style string
std::string::c_str() will have to be used.
For functions that take a const char * + a length std::string::data() is
the right choice as that function just return the contents of
std::string as a byte string, without any '\0' at end.
>
| Also, should the following function be removed?
>
| lyxfind.cpp:568:15: warning: ‘size_t
| lyx::{anonymous}::find_matching_brace(const string&, size_t)’ defined
| but not used [-Wunused-function]
>
| I'm hesitant to do so because it was part of a backport so I'm not
| sure if other pieces of code that use this function were meant to be
| backported.
If a backport (master -> branch I guess), then there is no need to keep
this function on branch. Just get rid of it.
>
| Thanks,
>
| Scott
>
| diff --git a/src/Server.cpp b/src/Server.cpp
| index 7ec096e..b4a0d11 100644
| --- a/src/Server.cpp
| +++ b/src/Server.cpp
| @@ -1010,12 +1010,16 @@ bool LyXComm::loadFilesInOtherInstance()
| // Wait a while to allow time for the other
| // instance to reset the connection
| Sleep::millisec(200);
| - pipefd = ::open(pipe.toFilesystemEncoding().c_str(), O_WRONLY);
| + pipefd = ::open(pipe.toFilesystemEncoding().data(), O_WRONLY);
This is wrong.
| if (pipefd < 0)
| break;
| string const cmd = "LYXCMD:pipe:file-open:" +
| fname.absFileName() + '\n';
| - ::write(pipefd, cmd.c_str(), cmd.length());
| + if (::write(pipefd, cmd.data(), cmd.length()) < 0) {
This one is correct. As ::write does not expect nor require a '\0'
terminated const char *. And due to the cmd.length() we didn't write the
'\0' anyway.
| + char errbuf[80];
| + strerror_r(errno, errbuf, sizeof errbuf);
| + LYXERR0("Cannot write to pipe: " << errbuf);
| + }
The only thing open for "error" is if strerror_r is available on all
platforms.
| ::close(pipefd);
| ++loaded_files;
| it = theFilesToLoad().erase(it);
| diff --git a/src/frontends/qt4/GuiSpellchecker.cpp
b/src/frontends/qt4/GuiSpellchecker.cpp
| index 5dbdbbb..c428807 100644
| --- a/src/frontends/qt4/GuiSpellchecker.cpp
| +++ b/src/frontends/qt4/GuiSpellchecker.cpp
| @@ -403,9 +403,8 @@ void SpellcheckerWidget::Private::check()
| docstring_list suggestions;
|
| LYXERR(Debug::GUI, "Spellchecker: start check at " << from);
| - int progress;
| try {
| - progress = bv->buffer().spellCheck(from, to, word_lang,
suggestions);
| + bv->buffer().spellCheck(from, to, word_lang, suggestions);
| } catch (ExceptionMessage const & message) {
| if (message.type_ == WarningException) {
[ not related to this patch, but... this looks like a really strange
catch clause... catching an exception and having to lookup what kind of
exception it is in stead of just catching the correct one... and of
course I just looked at this 2-line snippet.]
| Alert::warning(message.title_, message.details_);
Shoulnd't this patch be split into three commits?
Yes, they change the same type of modifications, but to vastly different
parts of the code base.
You should perhaps use "git format-patch" or "git send-email" to
generate these patches. Then you also get the commit message as part of
the mail.
--
Lgb
Re: [patch] fix warning on branch
Scott Kostyshak writes:
| On Thu, Sep 20, 2012 at 4:05 PM, Scott Kostyshak wrote:
>>> This patch for branch fixes a warning that was fixed on master here:
>>> ea50cd71f9d
>>>
>>> Is it OK?
>>>
>>> Scott
>>
>> This updated patch fixes another warning on branch, which was also
>> fixed in master at that commit.
>>
>> Scott
>
| Sorry for the multiple emails -- I didn't expect there to be more than
| one (and then two) warnings on branch. This updated patch fixes
| another warning that was also fixed in trunk.
>
| Is it OK for branch?
>
| I am getting one more warning:
>
| lyxfind.cpp:568:15: warning: ‘size_t
| lyx::{anonymous}::find_matching_brace(const string&, size_t)’ defined
| but not used [-Wunused-function]
>
| Should this function be removed?
>
| Thanks,
>
| Scott
>
| diff --git a/src/Lexer.cpp b/src/Lexer.cpp
| index d824da0..664e1b9 100644
| --- a/src/Lexer.cpp
| +++ b/src/Lexer.cpp
| @@ -274,9 +274,9 @@ bool Lexer::Pimpl::setFile(FileName const & filename)
|
| // Skip byte order mark.
| if (is.peek() == 0xef) {
| - int c = is.get();
| + is.get();
| if (is.peek() == 0xbb) {
| - c = is.get();
| + is.get();
| LASSERT(is.get() == 0xbf, /**/);
| } else
| is.unget();
| diff --git a/src/Server.cpp b/src/Server.cpp
| index 7ec096e..09a8734 100644
| --- a/src/Server.cpp
| +++ b/src/Server.cpp
| @@ -1015,7 +1015,8 @@ bool LyXComm::loadFilesInOtherInstance()
| break;
| string const cmd = "LYXCMD:pipe:file-open:" +
| fname.absFileName() + '\n';
| - ::write(pipefd, cmd.c_str(), cmd.length());
| +if (::write(pipefd, cmd.c_str(), cmd.length()) < 0)
| +LYXERR0("Cannot write to pipe!");
A failed write also sets errno, so perhaps strerror also should be use
get the error string from the system?
if (::write(pipefd, cmd.c_str(), cmd.length()) < 0) {
char errbuf[80];
strerror_r(errno, errbuf, sizeof errbuf);
LYXERR0("Cannot write to pipe: %s", errbuf);
}
Or some such.
btw. std::string::c_str() should not be used here,
use std::string::data() instead.
--
Lgb
Re: [LyX master] Calibrate log file parser
Richard Heck writes: | On 09/17/2012 03:19 AM, Juergen Spitzmueller wrote: >> The branch, master, has been updated. >> >> - Log - >> >> commit e8a01d099a7ecbe5059cbdf0aa0aab16e9862cf6 >> Author: Juergen Spitzmueller >> Date: Mon Sep 17 08:59:41 2012 +0200 >> >> Calibrate log file parser >> Filenames embraced in <...> can occur anywhere on the line >> and multiple times. This fixes for me the case that graphics >> included via ERT were not tracked. It probably also fixes #8336. >> This is a candidate for branch. >> | Go ahead and put this in, Jurgen. But we should e on the lookout for | any issues. I'm planning to start the release process fairly soon | (string freeze, etc). > | Richard > >> diff --git a/src/LaTeX.cpp b/src/LaTeX.cpp >> index 110d21c..ecd255f 100644 >> --- a/src/LaTeX.cpp >> +++ b/src/LaTeX.cpp >> @@ -995,6 +995,68 @@ bool completeFilename(string const & ff, DepTable & >> head) >> return handleFoundFile(ff, head); >> } >> + >> +int iterateLine(string const token, regex const reg, string const closing, >> +int fragment_pos, DepTable & head) 'closing' - why not const ref? Are there contex issues here, that makes creating a copy required? -- Lgb
Re: Problem with command-sequence
Jean-Marc Lasgouttes writes: | Le 19/09/2012 12:25, Lars Gullik Bjønnes a écrit : >> Perhaps async LFUNS are not a good idea? > | This was the big discussion about asynchronous export... Right... but why now have LFUNS de async by default (when done as a script thingie), and a separate LFUN to make the async if wanted. Gui/Menu run LFUNS could still be async. Probably also part of that discussion which I completely missed. -- Lgb
Re: Problem with command-sequence
Jean-Marc Lasgouttes writes: | Le 19/09/2012 01:07, Andrew Parsloe a écrit : >> It was only a "wistful" suggestion -- it would allow a tinkerer like me >> to tinker a little more. > | I would try to use "repeat 1000 " in order | to continue tinkering. > > >> The real problem (in the original post) was >> that the command-sequence code doesn't wait for buffer-export to finish >> before invoking the next command in the sequence (buffer-reload). The >> GUI does know -- the greyed-out buffer-reload button becomes enabled >> only after buffer-export is complete. > | As I wrote in the ticket that got opened, I think the best way to | handle that is to implement a lfun that waits until the thread are | finished. Perhaps async LFUNS are not a good idea? -- Lgb
Re: lyx.org is down
| From: Richard Heck | Subject: Re: lyx.org is down | Newsgroups: gmane.editors.lyx.devel | To: Scott Kostyshak | Cc: lyx-devel@lists.lyx.org | Date: Mon, 17 Sep 2012 11:40:38 -0400 (17 hours, 59 minutes, 25 seconds ago) | | On 09/16/2012 02:05 PM, Scott Kostyshak wrote: | > lyx.org is down. | > | It seems to have rebooted again. I'm afraid I'm out of ideas about | what might be happening, or how to figure it out. The box has been live migrated, and we have some problems with that. (and after the admins brought it up again, I updated it and reboot once more.) Now... the server is down now as well, but that is mostly my doing. I have tried to do some changes that should make things better with future live migrations, but managed to botch up the default routes (or so I think) (automatically done when a interface is brought up...) So no I am waiting for some assistance by the admin. -- Lgb
Re: LyX.org Down?
Richard Heck writes: | On 08/02/2012 09:49 AM, Kornel Benko wrote: >> >> Am Donnerstag, 2. August 2012 um 20:05:42, schrieb John >> McCabe-Dansted >> >> > I've been having trouble accessing the LyX website. At first I >> thought it >> >> > was just the SVN server, but now I can't even get to www.lyx.org/. >> >> > >> >> > Anyone else having problems? >> >> Me too. >> >> The git server is available, but sooo slow. >> | We had been having this problem intermittently, but now it is becoming | constant. The issue is that httpd for some reason spawns a bazillion | processes, and we are basically out of memory. Each one only consumes | a few megs, but a bazillion times a few is too much. > | Lars suspected some issue with trac, but it's very hard to tell what's | going on. > | I can restart httpd again, but I'm not sure it will help. For long. This round of problems seems to be caused by something else. There are now only 500MB RAM, but we used to have 1.5GB RAM. We are not almost continually in a swapping storm. I'll contact the server admins and see if they can shed som light on this. -- Lgb
Re: Unable to Push New Tag
On 26 June 2012 20:32, Richard Heck wrote: > On 06/26/2012 12:20 PM, Vincent van Ravesteijn wrote: >> >> Op 26-6-2012 17:48, Richard Heck schreef: >>> >>> >>> Anyone know how to fix this? Or am I doing something wrong? >>> >>> Richard >>> >> >> You need to have permissions to "create a new branch". >> >> Find the gitolite.conf file in the gitolite-admin.git repo and give >> yourself rights (RW -> RWC). >> > I found one at ~git/.gitolite/conf/gitolite.conf, but changing it seems to > have no effect. Looks as if one is supposed to clone and then push that > repo, which only Lars seems to have the right to do. If you did changes there you might have broken everything. -- Lgb
[PATCH] comment out function to get rid of a compiler warning
-- Lgb 0001-TextMetrics.cpp-comment-out-addressBreakPoint-functi.patch Description: Binary data
Re: #8118: Unfinished transition to new server and git
On Sun, Apr 15, 2012 at 15:21, LyX Ticket Tracker wrote: > New description: > > Tracking things which remain unfinished from transation to new server and > git. > > 1. Trac browsing of source code does not point to master, so we browse > some old > state. That means that all links saved elsewhere points to wrong > places, > eg. http://www.lyx.org/trac/browser/lyxgit/lib/layouttranslations shows > 12 > months old revision. This is not what I see. Revision a2e8cb75, 34.5 KB checked in by Georg Baum , 5 days ago (diff) > > 2. changesets in lyx-...@lists.lyx.org show no more diffs I'll get around to do it. > 3. All links in LyX documentation pointing to our SVN tree are no more > correct, > see: git grep lyx.org/trac |grep browser I am not sure who you expect to do this work... > 4. Official web pages contain SVN instead of Git links, namely > http://www.lyx.org/HowToUseSVN Or this. > 5. Wiki uploader is broken and no-one can upload new files. I thought that the wiki was in good shape now? > 6. Keyword plugin does not work reliably. Care to expand on that. -- Lgb
Re: [lyx/refs/heads/2.0.x] status.20x for last commit.
Enrico Forestieri writes: | On Sun, Mar 25, 2012 at 04:36:40PM +0200, Vincent van Ravesteijn wrote: > >> Op 25-3-2012 15:52, for...@lyx.org schreef: >> >Author: Enrico Forestieri >> >Date: Sun, 25 Mar 2012 15:49:10 +0200 >> >New Commit: ae068255137f111c598e93f9a54a891ffdb4dafc >> >URL: >> >http://git.lyx.org/?p=lyx.git;a=commit;h=ae068255137f111c598e93f9a54a891ffdb4dafc >> > >> >Log: >> >status.20x for last commit. >> > >> >I first used cherry-pick, then tried to modify status.20x but there >> >was no way I found to proceed from there. >> >> git commit -a --amend >> >> This will add the current changes to the last commit, in this case >> the cherry-picked commit. > | Ok, thanks. But next time I will first get a diff with "git diff > file" | and then will use patch to apply the diff. If the patch does not apply | cleanly I know what to do, contrarily to using git in case of clashes. Goodie. Continue to not learn git. | Even the cherry-pick thing took almost a hour to figure out. I was using | a sha1 of the commit but git was complaining: Wonder what would have happend if you had _asked_ someone... | $ git cherry-pick -x d728575b | error: could not apply d728575... Punctuation + some shortcuts | hint: after resolving the conflicts, mark the corrected paths | hint: with 'git add ' or 'git rm ' | hint: and commit the result with 'git commit' > | Eh? what does that mean? It was such a simple one-liner that it is | difficult to imagine any problem could arise. After reading several | man pages and issuing some obscure commands I understood that the | wrong commit was being cherry-picked! You told git to cherry-pick d728575b and that is what did... |But I was said that the sha1 | uniquely determines a commit... In the end this worked: > | $ git cherry-pick -x master~2 > | but I had to fire up gitk for figuring out that I had to use ~2 and not | something else. Then the problem with status.20x. Wonder what would have happend if you had _asked_ someone... | It took me 10 minutes to master svn, the same is not true for git. In the | end, I lost almost 1 hour to do what would have taken 2 minutes with | svn. If you had used those 10 minues with git to read a tutorial instead of try/fail/try-again, perhaps it would have gone a bit faster... | I'm sorry but I'm not paid for mastering git and don't have a couple of | days for reading the git documentation to be able to do such simple things. I have no sympathies. I are exaggerating and plainly wrong in the estimation of the effort required to master these things. -- Lgb
Re: [patch] full support for table rotations
Uwe Stöhr writes: | Am 20.03.2012 09:31, schrieb Vincent van Ravesteijn: > >>> + if (tabular.rotate != 0) >>> + rotateTabularAngleSB->setValue(tabular.rotate); >>> + else >>> + rotateTabularAngleSB->setValue(90); >> >> rotateTabularAngleSB->setValue(tabular.rotate == 0 ? 90 : tabular.rotate); > | I never understood why this form is preferred. For me my version | consumes more lines but I can see faster what it is about. for me with at helper var for the arg that is not the case. that rotateTabularAngleSB->setValue is dublicated and that I have to use time to verify that the lines really are the same is worse. int const rot = tabular.rotate == 0 ? 90 : tabular.rotate: rotateTabularAngleSB->setValue(rot); solves that form me. -- Lgb
Re: Updates to gitolite progress
Pavel Sanda writes: | Jean-Marc Lasgouttes wrote: >> Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit : >>> There is also a 2.0.x branch in your first clone, so you can just >>> cherry-pick the commit to master directly onto this 2.0.x branch, and >>> push from there. >> >> But If I want to compile both the master and the branch without doing a >> full rebuild everytime, I have to have two checkouts living in different >> places, right? And moreover, I have to update satus.20x. > | I believe more repositories are necessary and while its possible to clone | locally one from the other (and thus save some disk space), it will bring | problems with cryptic error messages for newcomers as you could see. > | The simplest SVN-like scenario: > | 1. Checkout full repo | git clone g...@git.lyx.org:lyx trunk | 2. Full mirror of branch as well, not through clone | cp -r trunk branch; cd branch No... (perhaps... it does not seem optimal, does not take advantage that things are on same fs f.ex.)) -- Lgb
Re: Updates to gitolite progress
Vincent van Ravesteijn writes: >>> There has to be a simple way to commit a patch to branch (please >>> tell me there is!). >> > | I forgot to mention: Ideally, if we do it the git-way completely, you | would only have to commit a patch to the 2.0.x branch. Later, the | 2.0.x will automatically be merged into the master. This can be done, | because, in general, all fixes that go into 2.0.x are in master too. Hmm... that would be a very bad idea. And the premise is in general not true. -- Lgb
Re: [PATCH] Setup .gitignore for generated files
Pavel Sanda writes: | Lars Gullik Bj?nnes wrote: >> >> Setting up .gitignore or .git/info/excludes is something that should >> be done. Not doing it makes it a lot harder to see actual new files >> that should be added. >> >> Signed-off-by: Lars Gullik Bj?¸nnes >> --- >> .gitignore| 13 + > | IIRC it's doable through single file, or is such spread intention? P Yes. It is intentional. The generic stuff is handled from the top, more specifics, f.ex. moc_*.cpp is handled where it happens. If a file suddenly appears in a location where we did not expect we should now about it. -- Lgb
[PATCH] Setup .gitignore for generated files
Setting up .gitignore or .git/info/excludes is something that should be done. Not doing it makes it a lot harder to see actual new files that should be added. Signed-off-by: Lars Gullik Bjønnes --- .gitignore| 13 + boost/.gitignore |1 + config/.gitignore |6 ++ development/.gitignore|1 + development/MacOSX/.gitignore |2 ++ development/cygwin/.gitignore |1 + lib/.gitignore|4 lib/lyx2lyx/.gitignore|1 + po/.gitignore |5 + sourcedoc/.gitignore |1 + src/.gitignore|6 ++ src/client/.gitignore |2 ++ src/frontends/.gitignore |1 + src/frontends/qt4/.gitignore |5 + src/support/.gitignore|2 ++ src/tex2lyx/.gitignore|2 ++ 16 files changed, 53 insertions(+), 0 deletions(-) create mode 100644 .gitignore create mode 100644 boost/.gitignore create mode 100644 config/.gitignore create mode 100644 development/.gitignore create mode 100644 development/MacOSX/.gitignore create mode 100644 development/cygwin/.gitignore create mode 100644 lib/.gitignore create mode 100644 lib/lyx2lyx/.gitignore create mode 100644 po/.gitignore create mode 100644 sourcedoc/.gitignore create mode 100644 src/.gitignore create mode 100644 src/client/.gitignore create mode 100644 src/frontends/.gitignore create mode 100644 src/frontends/qt4/.gitignore create mode 100644 src/support/.gitignore create mode 100644 src/tex2lyx/.gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..dcaa06d --- /dev/null +++ b/.gitignore @@ -0,0 +1,13 @@ +*.o +.deps/ +Makefile +Makefile.in +aclocal.m4 +configure +autom4te.cache/ +config.h.in +config.h +config.log +config.status +lyx.1 +stamp-h1 diff --git a/boost/.gitignore b/boost/.gitignore new file mode 100644 index 000..4492822 --- /dev/null +++ b/boost/.gitignore @@ -0,0 +1 @@ +liblyxboost.a diff --git a/config/.gitignore b/config/.gitignore new file mode 100644 index 000..1fe03f8 --- /dev/null +++ b/config/.gitignore @@ -0,0 +1,6 @@ +config.guess +config.sub +depcomp +install-sh +missing +py-compile diff --git a/development/.gitignore b/development/.gitignore new file mode 100644 index 000..570c439 --- /dev/null +++ b/development/.gitignore @@ -0,0 +1 @@ +lyx.spec diff --git a/development/MacOSX/.gitignore b/development/MacOSX/.gitignore new file mode 100644 index 000..270c8e8 --- /dev/null +++ b/development/MacOSX/.gitignore @@ -0,0 +1,2 @@ +Info.plist +lyxrc.dist diff --git a/development/cygwin/.gitignore b/development/cygwin/.gitignore new file mode 100644 index 000..abceabf --- /dev/null +++ b/development/cygwin/.gitignore @@ -0,0 +1 @@ +lyxrc.dist diff --git a/lib/.gitignore b/lib/.gitignore new file mode 100644 index 000..4dc6dab --- /dev/null +++ b/lib/.gitignore @@ -0,0 +1,4 @@ +lyx.desktop +lyx.desktop-temp +lyx.png +lyx.svg diff --git a/lib/lyx2lyx/.gitignore b/lib/lyx2lyx/.gitignore new file mode 100644 index 000..fc74c0b --- /dev/null +++ b/lib/lyx2lyx/.gitignore @@ -0,0 +1 @@ +lyx2lyx_version.py diff --git a/po/.gitignore b/po/.gitignore new file mode 100644 index 000..b7acd9d --- /dev/null +++ b/po/.gitignore @@ -0,0 +1,5 @@ +POTFILES +POTFILES.in +lyx.pot +*.gmo +stamp-po diff --git a/sourcedoc/.gitignore b/sourcedoc/.gitignore new file mode 100644 index 000..3849810 --- /dev/null +++ b/sourcedoc/.gitignore @@ -0,0 +1 @@ +Doxyfile diff --git a/src/.gitignore b/src/.gitignore new file mode 100644 index 000..51eb62f --- /dev/null +++ b/src/.gitignore @@ -0,0 +1,6 @@ +lyx +liblyxcore.a +liblyxgraphics.a +liblyxinsets.a +liblyxmathed.a +moc_Compare.cpp diff --git a/src/client/.gitignore b/src/client/.gitignore new file mode 100644 index 000..d27dc51 --- /dev/null +++ b/src/client/.gitignore @@ -0,0 +1,2 @@ +lyxclient +lyxclient.1 diff --git a/src/frontends/.gitignore b/src/frontends/.gitignore new file mode 100644 index 000..2473004 --- /dev/null +++ b/src/frontends/.gitignore @@ -0,0 +1 @@ +liblyxfrontends.a diff --git a/src/frontends/qt4/.gitignore b/src/frontends/qt4/.gitignore new file mode 100644 index 000..14699e4 --- /dev/null +++ b/src/frontends/qt4/.gitignore @@ -0,0 +1,5 @@ +Resources.cpp +Resources.qrc +liblyxqt4.a +ui_*.h +moc_*.cpp diff --git a/src/support/.gitignore b/src/support/.gitignore new file mode 100644 index 000..222e5ec --- /dev/null +++ b/src/support/.gitignore @@ -0,0 +1,2 @@ +liblyxsupport.a +moc_SystemcallPrivate.cpp diff --git a/src/tex2lyx/.gitignore b/src/tex2lyx/.gitignore new file mode 100644 index 000..827ef2b --- /dev/null +++ b/src/tex2lyx/.gitignore @@ -0,0 +1,2 @@ +tex2lyx +tex2lyx.1 -- 1.7.7.6
