Jürgen Spitzmüller writes:
> Jean-Marc Lasgouttes wrote:
>
>> Removing it is fine (I did it for some other components). The result is
>> that the component is kept in old bugs, but cannot be used for new ones.
>
> OK, if it is kept, I have certainly no objections.
I did it.
JMarc
Jean-Marc Lasgouttes wrote:
> Removing it is fine (I did it for some other components). The result is
> that the component is kept in old bugs, but cannot be used for new ones.
OK, if it is kept, I have certainly no objections.
Jürgen
Jürgen Spitzmüller writes:
> Pavel Sanda wrote:
>> we forgot to kill guii component and people are trying
>> to assign to it wrongly. could you remove it now
>
> We cannot remove it, for the sake of bug tracking history. Maybe we can make
> it unselectable?
Removing
Pavel Sanda wrote:
> frontend-* except qt4
I missed this step. No good idea IMHO.
Jürgen
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > i dont think its worth to preserve it, in the same way as we havent
> > preserved another components deleted last time.
>
> as for example?
frontend-* except qt4
vspace
pavel
Pavel Sanda wrote:
> i dont think its worth to preserve it, in the same way as we havent
> preserved another components deleted last time.
as for example?
Jürgen
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > we forgot to kill guii component and people are trying
> > to assign to it wrongly. could you remove it now
>
> We cannot remove it, for the sake of bug tracking history. Maybe we can make
> it unselectable?
i dont thi
Pavel Sanda wrote:
> we forgot to kill guii component and people are trying
> to assign to it wrongly. could you remove it now
We cannot remove it, for the sake of bug tracking history. Maybe we can make
it unselectable?
Jürgen
JMarc,
we forgot to kill guii component and people are trying
to assign to it wrongly. could you remove it now?
pavel
On Mon, Oct 23, 2006 at 07:00:18AM -0500, Bo Peng wrote:
> >Ah, here is the official request. ;)
> >
> >First: Is it worth the effort? How big is the speedup?
>
> MSVC seems to benefit from pch more than gcc. I never had any first
> hand experience though.
>
> >Second: Was there not another endle
Peter Kümmel wrote:
Abdelrazak Younes wrote:
no-undefined symbols work well with C++. However I don't
see what you'd link to make this usable.
We have (1) core + frontend (without Qt)
(2) frontend + frontend/qt (without core)
But linking-wise both depend on the 'without' stuff
Wit
Abdelrazak Younes wrote:
>> no-undefined symbols work well with C++. However I don't
>> see what you'd link to make this usable.
>>
>> We have (1) core + frontend (without Qt)
>> (2) frontend + frontend/qt (without core)
>>
>> But linking-wise both depend on the 'without' stuff
>
> Wit
Andre Pönitz wrote:
Quoting Peter Kümmel <[EMAIL PROTECTED]>:
The fact that there's now only one frontend left to care about
should not lead to the conclusion that's now suddenly fine to
mix core and GUI.
As a matter of fact I will strongly oppose any change that will
lead to
(a) using any QW
I've added support for precompiled headers on msvc.
You could enable it with the option -Dpch=1.
Interesting, all without touching the code? I will have to have a look.
Cheers,
Bo
Peter Kümmel wrote:
Asger Ottar Alstrup wrote:
Andre Pönitz wrote:
Quoting Peter Kümmel <[EMAIL PROTECTED]>:
[Use precompiled headers for VS]
Ah, here is the official request. ;)
I've added support for precompiled headers on msvc.
You could enable it with the option -Dpch=1.
I've added mo
Asger Ottar Alstrup wrote:
> Andre Pönitz wrote:
>> Quoting Peter Kümmel <[EMAIL PROTECTED]>:
>>
[Use precompiled headers for VS]
>>>
>>> Ah, here is the official request. ;)
I've added support for precompiled headers on msvc.
You could enable it with the option -Dpch=1.
I've added most head
Ah, here is the official request. ;)
First: Is it worth the effort? How big is the speedup?
MSVC seems to benefit from pch more than gcc. I never had any first
hand experience though.
Second: Was there not another endless discussion about
precompiled headers between Bo and Lars? Is it now
pos
Andre Pönitz wrote:
The fact that there's now only one frontend left to care about
should not lead to the conclusion that's now suddenly fine to
mix core and GUI.
As a matter of fact I will strongly oppose any change that will
lead to
(a) using any QWhateverStuff in src/*, src/inset/* src/mathe
Oh, one more thing:
You need to add something like
/Fp"\build\bin\debug\lyx-qt4.pch"
as well, to make sure all projects use the same precompiled header.
Regards,
Asger
Andre Pönitz wrote:
Quoting Peter Kümmel <[EMAIL PROTECTED]>:
>>> [Use precompiled headers for VS]
Ah, here is the official request. ;)
First: Is it worth the effort? How big is the speedup?
I did a test. Use the attached config.h.cmake. Make a config.cpp file
with just one line:
#inc
Quoting Peter Kümmel <[EMAIL PROTECTED]>:
Andre Pönitz wrote:
Since you are online, Peter:
How difficult would it be to make use of precompiled headers
with cmake/win?
Can't you just abuse config.h for that?
That's included in every .C file anyway...
Ah, here is the official request. ;)
F
Andre Pönitz wrote:
>
> Since you are online, Peter:
>
> How difficult would it be to make use of precompiled headers
> with cmake/win?
>
> Can't you just abuse config.h for that?
> That's included in every .C file anyway...
>
> Andre'
>
>
Ah, here is the official request. ;)
First: Is it w
Andre Pönitz wrote:
> Quoting Peter Kümmel <[EMAIL PROTECTED]>:
>
>>> The fact that there's now only one frontend left to care about
>>> should not lead to the conclusion that's now suddenly fine to
>>> mix core and GUI.
>>>
>>> As a matter of fact I will strongly oppose any change that will
>>> l
Quoting Peter Kümmel <[EMAIL PROTECTED]>:
The fact that there's now only one frontend left to care about
should not lead to the conclusion that's now suddenly fine to
mix core and GUI.
As a matter of fact I will strongly oppose any change that will
lead to
(a) using any QWhateverStuff in src/*
Since you are online, Peter:
How difficult would it be to make use of precompiled headers
with cmake/win?
Can't you just abuse config.h for that?
That's included in every .C file anyway...
Andre'
Quoting [EMAIL PROTECTED]:
On Mon, 23 Oct 2006, Andre Pönitz wrote:
PS: I really should have brought beer to Denmark. It's far to risky to
come here without...
What do you mean... no good beer in Denmark? (or to little of it?)
Beer was good, and so were the other beverages.
And with hinds
>The fact that there's now only one frontend left to care about
>should not lead to the conclusion that's now suddenly fine to
>mix core and GUI.
>
>As a matter of fact I will strongly oppose any change that will
>lead to
>
>(a) using any QWhateverStuff in src/*, src/inset/* src/mathed/*
>src/s
[EMAIL PROTECTED] wrote:
> On Mon, 23 Oct 2006, Andre Pönitz wrote:
>
>> PS: I really should have brought beer to Denmark. It's far to risky to
>> come here without...
>
> What do you mean... no good beer in Denmark? (or to little of it?)
See the mind map: they ran out of beer last night.
--
On Mon, 23 Oct 2006, Andre Pönitz wrote:
> PS: I really should have brought beer to Denmark. It's far to risky to
> come here without...
What do you mean... no good beer in Denmark? (or to little of it?)
/C
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
The fact that there's now only one frontend left to care about
should not lead to the conclusion that's now suddenly fine to
mix core and GUI.
As a matter of fact I will strongly oppose any change that will
lead to
(a) using any QWhateverStuff in src/*, src/inset/* src/mathed/*
src/support/*
> "John" == John Spray <[EMAIL PROTECTED]> writes:
Hi John,
John> Hi, Attached patch does the following: * Remove the 'Footnote'
John> and 'Marginal Note' entries, since they don't seem to correspond
John> to any dialog in any frontend. * Mark Ref, Citation and
John> Thesaurus as complete for
Hi,
Attached patch does the following:
* Remove the 'Footnote' and 'Marginal Note' entries, since they
don't seem to correspond to any dialog in any frontend.
* Mark Ref, Citation and Thesaurus as complete for GTK frontend.
(I don't have permissions to apply this myself)
John
On Thu, Nov 07, 2002 at 10:19:49PM +0100, Pierre-Olivier Gaillard wrote:
> Did I get the wrong branch with this command :
>
> cvs co -r BRANCH_GUII -d lyx-guii lyx-devel
Oh. Yes. the GUII stuff is integrated into the main trunk CVS months
ago. Try again with a normal checkout ;)
reg
On Thu, 7 Nov 2002 21:08:49 +
John Levon <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 07, 2002 at 10:03:55PM +0100, Pierre-Olivier Gaillard wrote:
>
> > This seems very strange, I simply did :
> > cd lyx-guii
> > ./autogen.sh
> > ./configure --with-frontend
On Thu, Nov 07, 2002 at 10:03:55PM +0100, Pierre-Olivier Gaillard wrote:
> This seems very strange, I simply did :
> cd lyx-guii
> ./autogen.sh
> ./configure --with-frontend=qt2
--with-frontend=qt
> make -j 5 # to use my 2 Celeron chips.
I really doubt this is safe.
> Gra
Hello,
I just checked out the GUII branch to have a look at the Qt2 interface but the build
fails in src/graphics/GraphicsImageXPM.C because of undefined references to FLTK
(?!!!??!!) variables such as fl_screen or fl_state.
This seems very strange, I simply did :
cd lyx-guii
./autogen.sh
On Sat, Jun 15, 2002 at 08:49:29PM +0200, Asger Kunuk Alstrup Nielsen wrote:
> OK, we have a plan now.
Cool.
> We have introduced a LyXKeySym class
Ah, lkey, except it's untypable ... only kidding :)
> The point is that the LyX core only needs this functionality from the
> KeySym:
>
> - Stor
On Sat, 15 Jun 2002, John Levon wrote:
> Anyway, I don't understand how the old code worked very well either.
> Feel lucky that I cleaned it up a while ago :))
>
> If there is some obscure bit of kb*.[hC] ... I /might/ know the answer;
> there's no harm in asking !
OK, we have a plan now.
We ha
On Sat, Jun 15, 2002 at 06:43:51PM +0200, Asger Kunuk Alstrup Nielsen wrote:
> We have had a beer or two now, and still no reply.
>
> It seems the British are only fast with the feet, not
> their minds.
Give us a chance I only went to the shop !
> We'll have another beer to celebrate this litt
Hi again,
We have had a beer or two now, and still no reply.
It seems the British are only fast with the feet, not
their minds.
We'll have another beer to celebrate this little victory.
Cheers,
Asger!
Dear John,
We practically committed the Screen patch you sent the 12th.
We did the merge ourselves, and changed a few names here and there,
but basically, it's the same patch.
However, as mentioned, we are not ready to merge the next bits, because
they break the kbmap stuff. We will spend some t
Some people have mentioned they're planning to do some GUII work
at the meeting..
I had hoped to get some of the core changes from my GUII branch in
before the meeting but Lars' obstructionism has prevented that, so
instead I'll just make a couple of comments about BRANCH_GUII
1
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> It claims to be qute portable, also when on a platform that does
Lars> not support dynamic linking, this is "forged" by using static
Lars> linking instead.
That seems OK, then.
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> lyx --frontend xforms lyx --frontend qt lyx --frontend gnome
>
| Lars> without recompiles.
>
| Lars> This is actually easier than you might think.
>
| It would be nice indee
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> lyx --frontend xforms lyx --frontend qt lyx --frontend gnome
Lars> without recompiles.
Lars> This is actually easier than you might think.
It would be nice indeed.
Lars> We need a clear API into the frontends, much like the
lyx --frontend xforms
lyx --frontend qt
lyx --frontend gnome
without recompiles.
This is actually easier than you might think.
We need a clear API into the frontends, much like the signal setup
today, but in the opposite direction.
This also means that using boost::function or boost::signal i
On Sun, May 26, 2002 at 08:28:53PM -0700, Kayvan A. Sylvan wrote:
> Shouldn't those P's be PS, PPS, PPPS, etc. instead?
Depending on your localization of 'P' and 'S' I suppose ;-}
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve,
On Mon, May 27, 2002 at 02:52:44AM +0200, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | OK we clearly need a GUII branch now, so people can see how the whole
> | thing hangs together (this means you Lars ;)
> >
> | Can you make one Lars
>
John Levon <[EMAIL PROTECTED]> writes:
| Post Script Script ?? The blood must be causing oxygen deprivation or
| something...
hmmm... yes.. my vision is a bit blurred
(and my mind to it seems)
--
Lgb
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, May 27, 2002 at 02:52:44AM +0200, Lars Gullik Bjønnes wrote:
>
>> If this is so that you can skip explaining stuff and just ponder on,
>> then no.
>
| It's not. It's easier to read a branch than it is to read a patch.
| And also it would be good to
On Mon, May 27, 2002 at 02:52:44AM +0200, Lars Gullik Bjønnes wrote:
> If this is so that you can skip explaining stuff and just ponder on,
> then no.
It's not. It's easier to read a branch than it is to read a patch.
And also it would be good to have help on some tedious things like
the fact kb
John Levon <[EMAIL PROTECTED]> writes:
| OK we clearly need a GUII branch now, so people can see how the whole
| thing hangs together (this means you Lars ;)
>
| Can you make one Lars
If this is so that you can skip explaining stuff and just ponder on,
then no.
What you cannot expect
OK we clearly need a GUII branch now, so people can see how the whole
thing hangs together (this means you Lars ;)
Can you make one Lars
thanks
john
--
"Time is a great teacher, but unfortunately it kills all its pupils."
- Hector Louis Berlioz
John Levon <[EMAIL PROTECTED]> writes:
| On Sat, May 25, 2002 at 06:02:43PM +0200, Lars Gullik Bjønnes wrote:
>
>> Button1
>
| Hmm, I much prefer button1, less strain on the keyboard...
>
| I have to enumerate them explicitly to get 1,2,4,8,16, no ?
>
>> write a operator|= for key_modifier::state
On Sat, May 25, 2002 at 06:02:43PM +0200, Lars Gullik Bjønnes wrote:
> Button1
Hmm, I much prefer button1, less strain on the keyboard...
I have to enumerate them explicitly to get 1,2,4,8,16, no ?
> write a operator|= for key_modifier::state;
How about this (less code than I thought it would
John Levon <[EMAIL PROTECTED]> writes:
| On Sat, May 25, 2002 at 05:49:25PM +0200, Lars Gullik Bjønnes wrote:
>
>> Is this the obviosu thing:
>
| Ah CRAP. Now I remember why I have the typedef int !!!
>
| case 's': case 'S':
| mod |= key_mod
John Levon <[EMAIL PROTECTED]> writes:
| On Sat, May 25, 2002 at 10:56:08AM +0200, Lars Gullik Bjønnes wrote:
>
>> It looks a lot better, but why the enum values in all CAPS?
>
| OK. button1 etc, fine by me. I'll change this.
Or perhaps cap the first char: Button1, Button2
(this one is up for di
On Sat, May 25, 2002 at 05:49:25PM +0200, Lars Gullik Bjønnes wrote:
> Is this the obviosu thing:
Ah CRAP. Now I remember why I have the typedef int !!!
case 's': case 'S':
mod |= key_modifier::shift;
i += 2
On Sat, May 25, 2002 at 05:49:25PM +0200, Lars Gullik Bjønnes wrote:
> Is this the obviosu thing:
>
> namespace button_event {
>
> enum state {
>None,
>Button1,
>Button2,
>...
> };
> }
Yes, except I have "butto
John Levon <[EMAIL PROTECTED]> writes:
| On Sat, May 25, 2002 at 10:56:08AM +0200, Lars Gullik Bjønnes wrote:
>
>> instead of using a named enum?
>
| On second thoughts, what the hell am I talking about ?
>
| D'oh.
| I'll fix it this to do the obvious thing and commit this after the
| changes yo
On Sat, May 25, 2002 at 10:56:08AM +0200, Lars Gullik Bjønnes wrote:
> instead of using a named enum?
On second thoughts, what the hell am I talking about ?
D'oh.
I'll fix it this to do the obvious thing and commit this after the
changes you mention
regards
john
--
"Time is a great teacher,
On Sat, May 25, 2002 at 10:56:08AM +0200, Lars Gullik Bjønnes wrote:
> It looks a lot better, but why the enum values in all CAPS?
OK. button1 etc, fine by me. I'll change this.
> and why include config.h here:
This is for a future change where kbsequence.h includes a string
So it doesn't make
John Levon <[EMAIL PROTECTED]> writes:
| Interesting that the wishlist thread on comp.lang.c++.moderated
| was talking about the exact same problem I had with
| key_state/mouse_state
>
| A further refinement might be a typedef int button; in mouse_state
| to clearly separate state vs. event of a
Interesting that the wishlist thread on comp.lang.c++.moderated
was talking about the exact same problem I had with
key_state/mouse_state
A further refinement might be a typedef int button; in mouse_state
to clearly separate state vs. event of a mouse button, but it's not
worth it right now.
OK
John Levon <[EMAIL PROTECTED]> writes:
| On Fri, May 24, 2002 at 07:40:06PM +0200, Lars Gullik Bjønnes wrote:
>
>> No Changelogs?
>
| I'll add them when I commit (in fact I have already written them).
then go ahead.
--
Lgb
On Fri, May 24, 2002 at 07:40:06PM +0200, Lars Gullik Bjønnes wrote:
> No Changelogs?
I'll add them when I commit (in fact I have already written them).
regards
john
--
"This is playing, not work, therefore it's not a waste of time."
- Zath
John Levon <[EMAIL PROTECTED]> writes:
| same old same old
>
| This is the last of the big "move stuff" patches. Soon there
| will be some actual patches.
>
| OK to commit ?
No Changelogs?
--
Lgb
same old same old
This is the last of the big "move stuff" patches. Soon there
will be some actual patches.
OK to commit ?
thanks
john
--
"This is playing, not work, therefore it's not a waste of time."
- Zath
fontload.diff.bz2
Description: Binary data
John Levon <[EMAIL PROTECTED]> writes:
| This one prepares for GUII font metrics stuff, so ignore the weird
| forwarding of frontends/font_metrics.h for now
>
| I got very confused when first looking at font stuff, I think
| font_metrics is a much better name for the namespace
>
|
Still looking for an OK ... please don't make the merge harder for me !
john
--
"This is playing, not work, therefore it's not a waste of time."
- Zath
This one prepares for GUII font metrics stuff, so ignore the weird
forwarding of frontends/font_metrics.h for now
I got very confused when first looking at font stuff, I think
font_metrics is a much better name for the namespace
OK to apply ?
The good news: there is only the unsigned int
sense to me. But I feel really queasy
| about a setWindowTitle() method in core code, and the fact that it will
| be the only case in a simple GUII inheritance hierarchy where the
| toolkit-specific versions inherit from something in core code. Source
| discoverability is good, and code to upda
On Thu, May 23, 2002 at 12:21:03PM +0100, Angus Leeming wrote:
> of course, if you used namespace front, then you could even rename it as
> Screen...
, true...
john
--
"This is playing, not work, therefore it's not a waste of time."
- Zath
On Thursday 23 May 2002 11:06 am, John Levon wrote:
> http://movementarian.org/q8.diff.bz2
>
> I've written a short summary below of what the patch has done so far.
> I'm not sure what I should merge next - there are still some "move this"
> things to be done, but they get more tricky ...
>
> 2. s
tle() method in core code, and the fact that it will
be the only case in a simple GUII inheritance hierarchy where the
toolkit-specific versions inherit from something in core code. Source
discoverability is good, and code to update the environment combo truly
belongs in frontends/
The important thing
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, May 23, 2002 at 12:22:16PM +0200, Lars Gullik Bjønnes wrote:
>
>> | 19,000 lines of diff ... yipes
>>
>> Are you able to break this one up?
>
| Heh, I'm not being very clear today am I. The URL is just for reference,
| not a patch submission.
>
>>
On Thu, May 23, 2002 at 12:26:47PM +0200, Andre Poenitz wrote:
> Does it work, John?
Not really. And it will be split.
Angus is dead right that it must be done in small logical changes,
compiling all the time. It will triple the work load but it is the only
honest way.
If Al Viro can rewrite t
On Thu, May 23, 2002 at 12:22:16PM +0200, Lars Gullik Bjønnes wrote:
> | 19,000 lines of diff ... yipes
>
> Are you able to break this one up?
Heh, I'm not being very clear today am I. The URL is just for reference,
not a patch submission.
> It is a tiny bit larger than what I am confortable w
On Thu, May 23, 2002 at 12:22:16PM +0200, Lars Gullik Bjønnes wrote:
> Are you able to break this one up?
>
> It is a tiny bit larger than what I am confortable with.
>
> breaking into say ... 17 patches would be good.
If it works you don't win by splitting...
Does it work, John?
Andre'
--
John Levon <[EMAIL PROTECTED]> writes:
| Against current CVS (modulo removed file clashes I still haven't
| fixed) :
>
| http://movementarian.org/q8.diff.bz2
>
| 19,000 lines of diff ... yipes
Are you able to break this one up?
It is a tiny bit larger than what I am confortable with.
breaking
ot;move this"
things to be done, but they get more tricky ...
1. Move Painter/PainterBase into frontends, and make various changes to
allow GUII [PART MERGED]
2. s/LyXScreen/LScreen/ There was some grumbling about this, I'm happy
to change it back if really wanted. Also move
On Thu, May 23, 2002 at 11:44:51AM +0200, Lars Gullik Bjønnes wrote:
> Go eat scearn!
Well you learn a new word every day.
"My father still reads the dictionary every day. He says that
your life depends on your power to master words."
- Arthur Scargill
Must be why I crapped up mine th
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, May 23, 2002 at 11:15:44AM +0200, Lars Gullik Bjønnes wrote:
>
>> BS!
>
| Ha ! You think you can hide your error with scatology ??
Go eat scearn!
--
Lgb
On Thu, May 23, 2002 at 11:15:44AM +0200, Lars Gullik Bjønnes wrote:
> BS!
Ha ! You think you can hide your error with scatology ??
john
--
"This is playing, not work, therefore it's not a waste of time."
- Zath
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, May 23, 2002 at 10:51:30AM +0200, Lars Gullik Bjønnes wrote:
>
>> | Again, no logic changes. Please apply to trunk
>
| -ENOKARMA
>
| Access denied: Insufficient Karma (levon|lyx-devel/src)
| cvs server: Pre-commit check failed
BS!
--
On Thu, May 23, 2002 at 10:51:30AM +0200, Lars Gullik Bjønnes wrote:
> | Again, no logic changes. Please apply to trunk
-ENOKARMA
Access denied: Insufficient Karma (levon|lyx-devel/src)
cvs server: Pre-commit check failed
I feel like the Lawnmower Man
john
--
"This is playing, not wor
nter" is no
longer used anywhere.
Painter
|
|| |
QtPainterXPainter GnomePainter
... seems nicer to me.
The patch sent does not make things very clear, merely because it just
moves files, and doesn't really show
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, May 23, 2002 at 10:36:10AM +0200, Lars Gullik Bjønnes wrote:
>
>> This looks ok to me, apply it.
>
| Applier needs this file too, sorry.
do it yourself.
--
Lgb
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Thursday 23 May 2002 7:55 am, John Levon wrote:
>> Take 2. This one will actually produce a useful diff for the next stage.
>>
>> Again, no logic changes. Please apply to trunk
>>
>> thanks
>> john
>
| THis is a bit lazy isn't it:
| diff -N src/front
On Thursday 23 May 2002 9:41 am, Andre Poenitz wrote:
> On Thu, May 23, 2002 at 09:29:09AM +0100, Angus Leeming wrote:
> > Request for new compiler please.
>
> I've heard of gcc running on toasters...
>
> Andre'
I have bad experiences of gcc on a DEC. It's the linking stage that fails and
unfort
John Levon <[EMAIL PROTECTED]> writes:
| Take 2. This one will actually produce a useful diff for the next stage.
>
| Again, no logic changes. Please apply to trunk
--- src/ColorHandler.h 22 May 2002 01:16:35 - 1.10
+++ src/ColorHandler.h 23 May 2002 06:25:55 -
@@ -15,7 +15,7 @@
On Thu, May 23, 2002 at 10:36:10AM +0200, Lars Gullik Bjønnes wrote:
> This looks ok to me, apply it.
Applier needs this file too, sorry.
(frontends/Painter.C)
john
--
"This is playing, not work, therefore it's not a waste of time."
- Zath
/* This file is part of
* ===
On Thu, May 23, 2002 at 09:29:09AM +0100, Angus Leeming wrote:
> Request for new compiler please.
I've heard of gcc running on toasters...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
John Levon <[EMAIL PROTECTED]> writes:
| also some minor cleanup
This looks ok to me, apply it.
--
Lgb
On Thu, May 23, 2002 at 09:29:09AM +0100, Angus Leeming wrote:
> > Take 2. This one will actually produce a useful diff for the next stage.
Take heed of this comment ...
> THis is a bit lazy isn't it:
No. This diff is /only/ so that the /real/ changes produce a useful diff
that shows the actua
On Thursday 23 May 2002 7:55 am, John Levon wrote:
> Take 2. This one will actually produce a useful diff for the next stage.
>
> Again, no logic changes. Please apply to trunk
>
> thanks
> john
THis is a bit lazy isn't it:
diff -N src/frontends/Painter.h
...
+#ifndef PAINTERBASE_H
+#define PAINT
Take 2. This one will actually produce a useful diff for the next stage.
Again, no logic changes. Please apply to trunk
thanks
john
--
"This is playing, not work, therefore it's not a waste of time."
- Zath
paintermove2.diff.bz2
Description: Binary data
On Thu, May 23, 2002 at 06:40:22AM +0100, John Levon wrote:
> This is simply to make later patches more readable, and should be
> applied to the trunk. No logic changes are included.
>
> thanks
> john
Sigh, not an auspicious start. Of course this needs to add Painter.h /
Painter.C to frontends/
This is simply to make later patches more readable, and should be
applied to the trunk. No logic changes are included.
thanks
john
--
"This is playing, not work, therefore it's not a waste of time."
- Zath
Index: src/ChangeLog
=
On Mon, Mar 18, 2002 at 01:16:02PM +0100, Asger K. Alstrup Nielsen wrote:
> This is neat.
It's a lot neater now.
> I looked at the patch, and can see that there still is a long way
> to go, but I'm impressed that you got as far as you have.
Actually there is not so far now, really. And if I go
1 - 100 of 196 matches
Mail list logo
