GToolbar.C: In member function `void GToolbar::onLayoutSelected()':
GToolbar.C:163: error: request for member `getLyXTextClass' in `
this->GToolbar::view_->LyXView::buffer() const()->params', which is of
non-aggregate type `'
GToolbar.C: In member function `virtual void GToolbar::setLayout(
Index: src/boost.C
===
RCS file: /cvs/lyx/lyx-devel/src/boost.C,v
retrieving revision 1.4
diff -u -r1.4 boost.C
--- src/boost.C 2003/09/09 17:25:17 1.4
+++ src/boost.C 2003/09/10 05:06:32
@@ -51,7 +51,7 @@
lyxerr << "Asse
One of the major reasons that we have to #include header files in header files
is because we cannot forward declare enums. Witness the fact that LColor.h
has the greatest number of dependencies in the entire project. And all
because LColor::color is passed as an argument to functions.
I would l
Kayvan A. Sylvan wrote:
> My prior committee chair (for Cub Scouts) needs an update
> to an old document, except I can't read it with the lyx from CVS.
>
> Can someone take a look at it?
Looks Ok to me. Attached is the 225 format version that has been through
lyx2lyx
--
Angus
kayvan225.dvi
D
Kayvan A. Sylvan wrote:
> This looks like another "make dist" issue.
>
> make[1]: Entering directory `/home/kayvan/src/lyx/src'
> make[1]: *** No rule to make target `ParagraphList.h', needed by `distdir'.
>
Sheesh! I guess that's because life is too short to wait for distdir to do its
stuff!
Attached is a plot of number of dependencies on each header file, ordered wrt
to this number for each of the dirs src, insets, mathed, frontends, graphics,
frontends, frontends/controllers, frontends/qt, frontends/xforms
As you can see, most of these plots are pretty sharp. Ie, there are only a
This looks like another "make dist" issue.
make[1]: Entering directory `/home/kayvan/src/lyx/src'
make[1]: *** No rule to make target `ParagraphList.h', needed by `distdir'.
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc. | Laura Isabella Sylv
My prior committee chair (for Cub Scouts) needs an update
to an old document, except I can't read it with the lyx from CVS.
Can someone take a look at it?
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yel
This script now replaces
using namespace abc;
with the appropriate
using abc::xyz;
function calls.
It's ability is due entirely to its ability to parse the compiler error
messages, so it is tied intimately to g++.
It doesn't pick up things like atoi, getcwd where the lyx::suppor
On Tue, Sep 09, 2003 at 03:13:03PM -0400, Kuba Ober spake thusly:
...
> > Thanks for the link! IIRC Micro$oft Extended Color Basic used
> > precisely COW for its string heap (yes I'm *that* old :-)
>
> So you did interface to the string heap from assembly or C, right? peeking and
> poking was
Next little shell script is designed to remove those nasty 'using namespace'
directives that Lars shoved in when introducing namespace lyx::support. (No
I'm not blaming anyone.)
It currently removes 'em all and then parses the error messages:
$ namespace.sh insetbibtex.C
insetbibtex.C needed '
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
>>> I got confused since you had a '^' in the first mail.
>>
> | Granted. That would have just stripped lines that were empty apart from
> | the presence of whitespace.
>>
>>> one or more... '+
> > The Loki library certainly has one, but I think that this one is
> > perfectly acceptable. It was written by Yonat Sharon:
> > http://ootips.org/yonat/ I just used boost::shared_ptr internally rather
> > than his hand-written equivalent. I have changed the authorship of the
> > file appropriate
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> I got confused since you had a '^' in the first mail.
>
| Granted. That would have just stripped lines that were empty apart from the
| presence of whitespace.
>
>> one or more... '+' does that...
>> s/[\t ]+$//
>> is what
Lars Gullik Bjønnes wrote:
> I got confused since you had a '^' in the first mail.
Granted. That would have just stripped lines that were empty apart from the
presence of whitespace.
> one or more... '+' does that...
> s/[\t ]+$//
> is what you meant then?
Yes. But POSIX sed doesn't support eit
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> | Not from me. Looks entirely reasonable. I'm getting pissed off with all
>> | these whitespace changes though. I'm going to run this over the source
>> | tree after I commit the BufferParams pimpl patch.
>>>
>> | find src -
Lars Gullik Bjønnes wrote:
> | Not from me. Looks entirely reasonable. I'm getting pissed off with all
> | these whitespace changes though. I'm going to run this over the source
> | tree after I commit the BufferParams pimpl patch.
>>
> | find src -name "*" | while read file; do
> | sed 's/
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> BOOST_ASSERT can give us filename, function name, and linenumber as
>> well as the expression that asserts in the assert message.
>>
>> Also boost/assert.hpp is already used by a lot of boost headers so we
>> don't have t
Lars Gullik Bjønnes wrote:
> BOOST_ASSERT can give us filename, function name, and linenumber as
> well as the expression that asserts in the assert message.
>
> Also boost/assert.hpp is already used by a lot of boost headers so we
> don't have to add the include all over.
>
> From diffstat:
>
On Tue, Sep 09, 2003 at 05:22:58PM +, Angus Leeming spake thusly:
...
> The Loki library certainly has one, but I think that this one is perfectly
> acceptable. It was written by Yonat Sharon: http://ootips.org/yonat/
> I just used boost::shared_ptr internally rather than his hand-written
Angus Leeming <[EMAIL PROTECTED]> writes:
| Anyway, can I apply the patch?
If you comment on my assert patch.
--
Lgb
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | This patch is a 'pragmatic pimpl-ing' of BufferParams. It moves into Impl
> | only those member variables that currently drag in header files into
> | bufferparams.h.
>>
> | I had two choices when implementing it.
> | *
Angus Leeming <[EMAIL PROTECTED]> writes:
| This patch is a 'pragmatic pimpl-ing' of BufferParams. It moves into Impl only
| those member variables that currently drag in header files into
| bufferparams.h.
>
| I had two choices when implementing it.
| * Explicitly define a copy constructor and
This patch is a 'pragmatic pimpl-ing' of BufferParams. It moves into Impl only
those member variables that currently drag in header files into
bufferparams.h.
I had two choices when implementing it.
* Explicitly define a copy constructor and assignment operator for
BufferParams.
* Define a smar
Lars Gullik Bjønnes wrote:
> | Is there any enthusiasm for this? Shall I just do it?
> if you move any, you should move all.
> I know that not all likes the pimpls, but I am mostly indifferent.
> (bad thing is that inlining is harder when/if needed.
Exactly. As there is a price to pay for this (n
Angus Leeming <[EMAIL PROTECTED]> writes:
| Moves bufferparams.h, lyxvc.h, texrow.h out of buffer.h.
| Ok to go in?
IMHO yes.
--
Lgb
Angus Leeming <[EMAIL PROTECTED]> writes:
| Moves bufferparams.h, lyxvc.h, texrow.h out of buffer.h.
| Ok to go in?
>
| You'll see that the patch adds #include "bufferparams.h" to lots of .C files.
| Looking at bufferparams.h itself, I see that adding an Impl class for those
| member variables t
Moves bufferparams.h, lyxvc.h, texrow.h out of buffer.h.
Ok to go in?
You'll see that the patch adds #include "bufferparams.h" to lots of .C files.
Looking at bufferparams.h itself, I see that adding an Impl class for those
member variables that drag in header files would allow us to remove thes
Martin Vermeer <[EMAIL PROTECTED]> writes:
| 323} else {
| 324FuncRequest cmd1 = cmd;
| 325if (!bv->lockInset(this))
| 326return DISPATCHED;
| 327if (cmd.y <= button_dim.y2) {
| 328cmd1.y
On Tue, Sep 09, 2003 at 11:13:56AM +0200, Lars Gullik Bjønnes spake thusly:
>
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | On Tue, Sep 09, 2003 at 10:33:35AM +0200, Lars Gullik Bjønnes spake thusly:
> |
> >> Martin Vermeer <[EMAIL PROTECTED]> writes:
> >>
> >> | The last one was indeed c
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Tue, Sep 09, 2003 at 10:33:35AM +0200, Lars Gullik Bjønnes spake thusly:
|
>> Martin Vermeer <[EMAIL PROTECTED]> writes:
>>
>> | The last one was indeed close to trivial. Here's the patch.
>>
>> This is ok.
>>
>> --
>> Lgb
>
| And the firs
On Tue, Sep 09, 2003 at 10:33:35AM +0200, Lars Gullik Bjønnes spake thusly:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | The last one was indeed close to trivial. Here's the patch.
>
> This is ok.
>
> --
> Lgb
And the first one? There is a change in functionality there (bug fix)
Martin Vermeer <[EMAIL PROTECTED]> writes:
| The last one was indeed close to trivial. Here's the patch.
This is ok.
--
Lgb
Angus Leeming <[EMAIL PROTECTED]> writes:
| ...and providing the outside world with accessor functions.
| Ok to go in?
This looks ok to me.
--
Lgb
34 matches
Mail list logo
