On Fri, 27 Oct 2006, Dov Feldstern wrote:
I'd also like to know some of the stuff Dov is asking about...
cheers
/Christian
> I've been lurking on the newsgroup for the past month or so (I submitted a
> small patch and there are a few more I hope to work on), and I found the
> recent uproar regar
Uwe Stöhr wrote:
> Can we get get rid of horizontal box content alignment in box dialog?
Don't think so.
> This is in any case greyed out
No. Chose "Type: Rectangular Box" and "Inner Box: None", for instance.
> and the horizontal alignment of the box
> content is set by the paragraph dialog (
> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes:
Dov> Thanks. I'll try to do this soon. Just to make sure I understand,
Dov> 1.5.0svn is the main trunk, namely
Dov> svn://svn.lyx.org/lyx/lyx-devel/trunk ?
Yes.
JMarc
Thanks. I'll try to do this soon. Just to make sure I understand,
1.5.0svn is the main trunk, namely svn://svn.lyx.org/lyx/lyx-devel/trunk ?
Jean-Marc Lasgouttes wrote:
In the case of this particular bug, I have targeted it to 1.4.4
already. Unfortunately I am a bit slow at processing bugs the
> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes:
Dov> For example, the patch I submitted (for chars-transpose), which
Dov> is now pointed to from bugzilla
Dov> (http://bugzilla.lyx.org/show_bug.cgi?id=2939) --- should I be
Dov> picking it up, or I guess it has to be someone with svn
Dov> c
On Fri, Oct 13, 2006 at 12:07:27PM +0200, Abdelrazak Younes wrote:
> Question for Andre I guess:
>
> This TextPainter class is used nowhere in the code except in a dead code
> (note the if (0 ):
>
> int InsetMathHull::plaintext(Buffer const &, lyx::odocstream & os,
> Output
On Sun, Sep 17, 2006 at 11:06:05AM +0200, Abdelrazak Younes wrote:
> Hello,
>
> I would like to move the Intl member from LyXView to BufferView as this
> is more a kernel thing IMHO.
>
> Any objection?
Not really.
Andre'
On Fri, Sep 15, 2006 at 12:02:05PM +0200, Abdelrazak Younes wrote:
> Georg Baum wrote:
> >Abdelrazak Younes wrote:
> >
> >>If only Lars and Georg work on this, I am afraid that it will take some
> >>time before all the corner cases are worked out step by step.
> >
> >I don't think that I am going t
Georg Baum wrote:
Abdelrazak Younes wrote:
Well, I hope you don't include me in this group because I did some work
on the unicode front.
No, I do not include you.
Good... no... I can resist!
I disagree with you about how the uncide things
should go, but I don't want to force you to do thi
Abdelrazak Younes wrote:
> Well, I hope you don't include me in this group because I did some work
> on the unicode front.
No, I do not include you. I disagree with you about how the uncide things
should go, but I don't want to force you to do things in a way that you
personally think is wrong.
Georg Baum wrote:
Abdelrazak Younes wrote:
If only Lars and Georg work on this, I am afraid that it will take some
time before all the corner cases are worked out step by step.
I don't think that I am going to do any further unicode work. I'll just sit
and wait what happens.
Welcome to the
Georg Baum wrote:
> Abdelrazak Younes wrote:
>
>> If only Lars and Georg work on this, I am afraid that it will take some
>> time before all the corner cases are worked out step by step.
>
> I don't think that I am going to do any further unicode work. I'll just sit
> and wait what happens. These
Abdelrazak Younes wrote:
> If only Lars and Georg work on this, I am afraid that it will take some
> time before all the corner cases are worked out step by step.
I don't think that I am going to do any further unicode work. I'll just sit
and wait what happens. These endless discussions about how
Andre Poenitz wrote:
On Thu, Sep 14, 2006 at 02:09:01PM +0200, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Then I suggest that you don't get involved anymore in the converting
business, that will be easier for all of us.
I might do that indeed.
Just a final note about
On Wed, Sep 13, 2006 at 04:30:08PM +0200, Abdelrazak Younes wrote:
> >Performance is not the most important thing in this case IMO. The most
> >important thing is code that is easy to understand.
>
> In this case, I think the format should be an enum instead.
>
> enum FileFormat {
> jpg,
> lyx,
>
On Thu, Sep 14, 2006 at 02:09:01PM +0200, Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
> >Georg Baum wrote:
>
> >>Then I suggest that you don't get involved anymore in the converting
> >>business, that will be easier for all of us.
> >
> >I might do that indeed.
>
> Just a final note about
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Then I suggest that you don't get involved anymore in the converting
business, that will be easier for all of us.
I might do that indeed.
Just a final note about this transition: I've spent many hours already
trying to c
Abdelrazak Younes wrote:
Georg Baum wrote:
Then I suggest that you don't get involved anymore in the converting
business, that will be easier for all of us.
I might do that indeed.
Just a final note about this transition: I've spent many hours already
trying to convert filetools to docstr
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
It looks to me as if you want to convert almost everything to docstring.
That would have been better done with some global search/replace.
I really think we should have done just that. We are just complicating
our life for no real b
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> It looks to me as if you want to convert almost everything to docstring.
>> That would have been better done with some global search/replace.
>
> I really think we should have done just that. We are just complicating
> our life for no real benefit.
Abdelrazak Younes wrote:
> For win/MSVC, boost::uint32_t is fine. The real problem as I understand
> is mingw and cygwin. But I guess even those will be OK to use
> boost::uin32_t when used with STLPort. If I am right (Georg, could you
> confirm that?)
No, STLPort does not help as Enrico found ou
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| This back and forth conversion tp/from utf8 during this transition
| phase is a real hassle. Taking this decision now will simplify and
| speed-up greatly the transition. We also need quickly the operator
| that Georg is
Georg Baum wrote:
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| class MenuId: public KeyString {};
|
| class DialogId: public KeyString {};
|
|
| We need to take a decision now!
No we don't.
That's your opinion.
We are not in such a
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| This back and forth conversion tp/from utf8 during this transition
| phase is a real hassle. Taking this decision now will simplify and
| speed-up greatly the transition. We also need quickly the operator
| that Georg is working on (+=, streams, etc)
Abdelrazak Younes wrote:
> Lars Gullik Bjønnes wrote:
>> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
>> | class MenuId: public KeyString {};
>> |
>> | class DialogId: public KeyString {};
>> |
>> |
>> | We need to take a decision now!
>>
>> No we don't.
>
> That's your opinion.
>
>> We
On Thu, Sep 14, 2006 at 09:59:01AM +0200, Lars Gullik Bjønnes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> | Andre Poenitz wrote:
> | > On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
> | >> I am tempted to convert everything even when a std::string would
> | >> su
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| class MenuId: public KeyString {};
|
| class DialogId: public KeyString {};
|
|
| We need to take a decision now!
No we don't.
That's your opinion.
We are not in such a hurry.
This back and forth conversion
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
| >> I am tempted to convert everything even when a std::string would
| >> suffice. For example getFormatFromContents(), should that be:
| >>
| >> lyx::docstr
Andre Poenitz wrote:
On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
I am tempted to convert everything even when a std::string would
suffice. For example getFormatFromContents(), should that be:
lyx::docstring const getFormatFromContents(lyx::docstring const & name);
or
s
On Wed, Sep 13, 2006 at 04:17:15PM +0200, Lars Gullik Bjønnes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> | > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> | > | Am I right that all of the filetools.h API should be converted to
> | > docstring?
> | >
On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
> I am tempted to convert everything even when a std::string would
> suffice. For example getFormatFromContents(), should that be:
>
> lyx::docstring const getFormatFromContents(lyx::docstring const & name);
>
> or
>
> std::stri
Georg Baum wrote:
Am Mittwoch, 13. September 2006 17:41 schrieb Abdelrazak Younes:
Angus Leeming wrote:
Note that keeping std::string for the format name will enable you to
enforce
the distinction at compile time. Even clearer if you follow Georg's
suggestion
of
typedef std::string lyx:
Am Mittwoch, 13. September 2006 17:41 schrieb Abdelrazak Younes:
> Angus Leeming wrote:
> > Note that keeping std::string for the format name will enable you to
enforce
> > the distinction at compile time. Even clearer if you follow Georg's
suggestion
> > of
> > typedef std::string lyx::asc
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
No, all is as it should be. NTFS uses UTF-16 (thanks again, Joost), so that
can be stored reasonably well in std::wstring although there will be corner
cases where two wchar_ts are required to represent a single unicode charac
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > | > I'd prefere is most of this work tried to leverage boost::filesystem
> > | > as much as possible.
> > |
> > | Yes, I think I've read somewhere that boost::filesystem will support
> > | the default encoding of the system in 1.34.
> >
> > Note t
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| I don't like much asciistring because docstring can be ascii also.
No... it cannot it has 4-byte chars remember.
orrh I am not stupid!
I mean ascii is a subset of ucs4 using the first byte...
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Am I right that all of the filetools.h API should be converted to
| > docstring?
| > | | I have started the conversion already so please t
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| I don't like much asciistring because docstring can be ascii also.
No... it cannot it has 4-byte chars remember.
--
Lgb
Angus Leeming wrote:
Abdelrazak Younes writes:
Georg Baum wrote:
Abdelrazak Younes wrote:
Then we need docstring as we don't know which kind of extension a user
could create.
Please: format name != file extension!!! I fixed several bugs
resulting from this misunderstanding.
format names are
Abdelrazak Younes writes:
> Georg Baum wrote:
> > Abdelrazak Younes wrote:
>>> Then we need docstring as we don't know which kind of extension a user
>>> could create.
>> Please: format name != file extension!!! I fixed several bugs
>> resulting from this misunderstanding.
>> format names are uniq
Georg Baum wrote:
Abdelrazak Younes wrote:
Then we need docstring as we don't know which kind of extension a user
could create.
Please: format name != file extension!!! I fixed several bugs resulting from
this misunderstanding. format names are unique, file extensions not.
Sure... I meant f
Abdelrazak Younes wrote:
> Then we need docstring as we don't know which kind of extension a user
> could create.
Please: format name != file extension!!! I fixed several bugs resulting from
this misunderstanding. format names are unique, file extensions not.
Georg
Georg Baum wrote:
Abdelrazak Younes wrote:
So you would be OK if I change also all code that deals with format names?
The question is: Do non-ASCII format names make sense? I really don't know.
Me neither but probably not. Unless a Chinese user for example use a
format is not defined in AS
Joost Verburg wrote:
> Originally, all Unicode Windows features and the NTFS file system
> used UCS-2 encoding. After Unicode 3.0 became available this has
> been upgraded. Windows 2000 and later support UTF-16.
Thanks, Joost.
Angus
Abdelrazak Younes wrote:
> So you would be OK if I change also all code that deals with format names?
The question is: Do non-ASCII format names make sense? I really don't know.
If the answer to that question is yes and it does not create problems
elsewhere, then it would be OK with me.
> In thi
Angus Leeming wrote:
You reckon? I think that it was pretty farsighted. NTFS was designed in about
1992.
For the pedantically-minded, I believe that NTFS is encoded in UCS-2, a fixed-
length 16 bit subset of UTF-16. See http://en.wikipedia.org/wiki/UTF-16.
Originally, all Unicode Windows feat
Georg Baum wrote:
Abdelrazak Younes wrote:
I plan to first encapsulate the conversion to/from ascii inside each of
the filetools functions. Then I will look at how boost::filesystem can
handle unicode, if at all possible...
I am tempted to convert everything even when a std::string would
suffi
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> | I think NTFS is UFT16...
> Hmm... strange choice imho.
You reckon? I think that it was pretty farsighted. NTFS was designed in about
1992.
For the pedantically-minded, I believe that NTFS is encoded in UCS-2, a fixed-
length 16 bit subset of UT
Abdelrazak Younes wrote:
> I plan to first encapsulate the conversion to/from ascii inside each of
> the filetools functions. Then I will look at how boost::filesystem can
> handle unicode, if at all possible...
>
> I am tempted to convert everything even when a std::string would
> suffice. For e
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Am I right that all of the filetools.h API should be converted to
| > docstring?
| > | | I have started the conversion already so please tell me quick if
| > | that's
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Am I right that all of the filetools.h API should be converted to docstring?
|
| I have started the conversion already so please tell me quick if
| that's not the case.
Filesystems and unicode is tricky.
And I am not s
Lars Gullik Bjønnes wrote:
> Filesystems and unicode is tricky.
> And I am not sure if a "blind" conversion is the way to go.
>
> But, yes, I think we should allow for utf-8 filesystem (I do not think
> anyone uses utf-16 in the filesystem?)
>
> I'd prefere is most of this work tried to leverage
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Am I right that all of the filetools.h API should be converted to docstring?
|
| I have started the conversion already so please tell me quick if
| that's not the case.
Filesystems and unicode is tricky.
And I am not s
Georg Baum wrote:
Abdelrazak Younes wrote:
Am I right that all of the filetools.h API should be converted to
docstring?
If filenames with non-ASCII characters should be supported, then yes.
I think we should support that indeed.
I have started the conversion already so please tell me qu
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Am I right that all of the filetools.h API should be converted to docstring?
|
| I have started the conversion already so please tell me quick if
| that's not the case.
Filesystems and unicode is tricky.
And I am not sure if a "blind" conversion is
Abdelrazak Younes wrote:
> Am I right that all of the filetools.h API should be converted to
> docstring?
If filenames with non-ASCII characters should be supported, then yes.
> I have started the conversion already so please tell me quick if that's
> not the case.
You will probably need to add
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| While re-compiling LyX, I noticed the following warning:
|
| ..\..\..\src\lyxfunc.C(218) : warning C4244: 'initializing' :
| conversion from 'lyx::char_type' to 'char', possible loss of data
|
| in
|
| void LyXFunc::handleKeyFunc(kb_action actio
[EMAIL PROTECTED] writes:
| Due to a discussion on the PmWiki list, I'd like to check if I've gotten
| it correct that LyX 1.5 will be unicode, and 1.6 will use an XML-based
| file format?
Yes. This is correct.
--
Lgb
Bennett Helm <[EMAIL PROTECTED]> writes:
| On Jul 16, 2006, at 3:22 AM, Georg Baum wrote:
|
| > Am Samstag, 15. Juli 2006 21:45 schrieb
| > [EMAIL PROTECTED]:
| >
| >> AFAIK, it's just a matter of placing stuff in some directory
| >> (which) and
| >> then you should perhaps tell someone (who?).
|
On Jul 16, 2006, at 3:22 AM, Georg Baum wrote:
Am Samstag, 15. Juli 2006 21:45 schrieb
[EMAIL PROTECTED]:
AFAIK, it's just a matter of placing stuff in some directory
(which) and
then you should perhaps tell someone (who?).
You should put it in ftp.devel.lyx.org/pub/incoming and then tel
Lars Gullik Bjønnes wrote:
> Others will need to use ftp.devel.lyx.org or place the files somehwere
> we can get it.
When I need to send large files (for whatever reason), I use YouSendIt
(http://www.yousendit.com/), which has worked well for me in the past.
Dan
[EMAIL PROTECTED] writes:
| > When comitting a patch that has been discussed on the list, would it
| > make sense to let the *comitted* patch contain link or reference to
| > the discussion?
|
| Still wondering about this one though. I'm guessing it's better to
| have the information in the log.
[EMAIL PROTECTED] writes:
| > source tree, and provide binaries in ftp.lyx.org/pub/lyx/contrib.
|
| Is the procedure for uploading to ftp.lyx.org documented somewhere?
|
| AFAIK, it's just a matter of placing stuff in some directory (which)
| and then you should perhaps tell someone (who?).
We
Am Samstag, 15. Juli 2006 21:45 schrieb [EMAIL PROTECTED]:
> AFAIK, it's just a matter of placing stuff in some directory (which) and
> then you should perhaps tell someone (who?).
You should put it in ftp.devel.lyx.org/pub/incoming and then tell Jean-Marc
or Lars. The inxcoming directory on ft
On Sat, 15 Jul 2006, [EMAIL PROTECTED] wrote:
I'm back from two weeks in Sveti Constantine, Bulgary (very nice btw) and I'm
trying to catch up... Since I'm now at post 200 out of 900 I'd like to take a
break and inject a question.
Well, having finished the posts I managed to answer some of my
Georg Baum wrote:
Am Samstag, 3. Juni 2006 12:49 schrieb Abdelrazak Younes:
Georg Baum wrote:
Abdelrazak Younes wrote:
AFAIS, wa_ptr is equivalent to "this" and is not used anywhere else.
It is used in lyxX11EventFilter
Could be replaced by "this".
Only if you make lyxX11EventFilter a mem
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Georg Baum wrote:
| > Abdelrazak Younes wrote:
| >
| >> AFAIS, wa_ptr is equivalent to "this" and is not used anywhere else.
| > It is used in lyxX11EventFilter
|
| Could be replaced by "this".
Not just like that
Am Samstag, 3. Juni 2006 13:11 schrieb Lars Gullik Bjønnes:
> the plan it to have more than one workarea...
Ah, therefore wa_ptr is set in QWorkArea::haveSelection. That should be
documented.
Georg
Am Samstag, 3. Juni 2006 12:49 schrieb Abdelrazak Younes:
> Georg Baum wrote:
> > Abdelrazak Younes wrote:
> >
> >> AFAIS, wa_ptr is equivalent to "this" and is not used anywhere else.
> >
> > It is used in lyxX11EventFilter
>
> Could be replaced by "this".
Only if you make lyxX11EventFilter a
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Georg Baum wrote:
| > Abdelrazak Younes wrote:
| >
| >> AFAIS, wa_ptr is equivalent to "this" and is not used anywhere else.
| > It is used in lyxX11EventFilter
|
| Could be replaced by "this".
Not just like that
| > and checkAppleEventForMis
Georg Baum wrote:
Abdelrazak Younes wrote:
AFAIS, wa_ptr is equivalent to "this" and is not used anywhere else.
It is used in lyxX11EventFilter
Could be replaced by "this".
and checkAppleEventForMissingParams (only in
OS X).
and handleOpenDocuments, I _know_. I plan to move these functi
Abdelrazak Younes wrote:
> AFAIS, wa_ptr is equivalent to "this" and is not used anywhere else.
It is used in lyxX11EventFilter and checkAppleEventForMissingParams (only in
OS X). Figuring out the reason why it is needed there is left as an
exercise for the reader.
> So, can I remove it?
No. Bu
Abdelrazak Younes wrote:
AFAIS, wa_ptr is equivalent to "this" and is not used anywhere else.
So, can I remove it?
Sure. Feel free to experiment.
Angus
On Wed, May 24, 2006 at 07:45:25PM +0200, Michael Gerz wrote:
> Martin,
>
> given the fact that you are not allowed to revert logical deletions within
> the inset (otherwise you run into an inconsistent state), I am tempted to
> remove linebreaks without CT marking. I.e. setAutoBreakRow does not
Martin,
given the fact that you are not allowed to revert logical deletions within
the inset (otherwise you run into an inconsistent state), I am tempted to
remove linebreaks without CT marking. I.e. setAutoBreakRow does not consider
the buffer's change tracking mode. Does this make sense to y
On Wed, May 24, 2006 at 08:19:33PM +0300, Martin Vermeer wrote:
> On Wed, May 24, 2006 at 06:26:18PM +0200, Michael Gerz wrote:
...
> In non-ct mode, you irreversibly lose the newlines. It would be nice to
> mark them "blue" under ct.
s/blue/red/
- martin
pgp4c4CqndxJe.pgp
Description: PGP s
Michael Gerz wrote:
> Does it make sense that setAutoBreakRows marks linebreaks as (logically)
> deleted if they are disallowed? Is the user allowed to revert the deletion
> later?
No, he is not. Actually I did not think about that case.
> This may lead to inconsistent states.
Yes. It should on
I am asking because setAutoBreakRows calls Paragraph::erase() which
requires a trackChanges flags in the new CT code. I guess that the buffer
parameter (ct on/off) has to be passed to setAutoBreakRows but I would
like to know your opinion first.
Yes, it has to be passed. LyXText::autoBreakRows_
On Wed, May 24, 2006 at 06:26:18PM +0200, Michael Gerz wrote:
> Hello,
>
> could somebody please tell me the purpose of method
> InsetText::setAutoBreakRows?
>
> I am asking because setAutoBreakRows calls Paragraph::erase() which requires
> a trackChanges flags in the new CT code. I guess that
Michael Gerz wrote:
> Hello,
>
> could somebody please tell me the purpose of method
> InsetText::setAutoBreakRows?
It sets the corresponding flag of LyXText, but I guess you knew that.
> I am asking because setAutoBreakRows calls Paragraph::erase() which
> requires a trackChanges flags in the
Abdelrazak Younes wrote:
Well, let's be even more pragmatic: help me polishing the Qt4 port!
I mean it, compiling lyx without debug info requires a maximum of 50
Megs and is very fast!
Frankly speaking, I think I have to retire for a while (not forever)
once the work on change tracking is co
Michael Gerz a écrit :
I have 512 MB and building a shared library is still no fun. Let's be
pragmatic. Shared vs. static is not a religuous question.
By the way, did you try to build with my recent change to cygwin.m4?
Here, it cuts down memory and time consumption by half for dynamic
linkin
Michael Gerz a écrit :
Abdelrazak Younes wrote:
[Lots of very good reasons to use Cygwin]
You don't have to convince me Enrico I am already on your side ;-)
My question was about the general windows user. For this kind of user,
I think installing cygwin is I think a no-go; using native packag
Abdelrazak Younes wrote:
[Lots of very good reasons to use Cygwin]
You don't have to convince me Enrico I am already on your side ;-)
My question was about the general windows user. For this kind of user,
I think installing cygwin is I think a no-go; using native package
(python, etc) is the
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
| My automated daily builds on my Redhat FC4 system are getting
| those damnable linker errors or the python lyx2lyx module issue
| (see ftp://ftp.sylvan.com/pub/lyx/devel/log for the latest).
Did you try compiling without the precompiled headers?
-
On Mon, Apr 17, 2006 at 11:42:21AM -0700, Kayvan A. Sylvan wrote:
> On Thu, Apr 13, 2006 at 10:28:59AM +0200, Jean-Marc Lasgouttes wrote:
> >
> > Hi Kayvan,
> >
> > Did you see this message? We need your input on why this special
> > cygwin code was needed...
>
> All I remember is that it was n
me. I'm going to upgrade that machine
to Redhat FC5 in the next week or so, after which I will try again.
---Kayvan
> To: lyx-devel@lists.lyx.org
> From: Abdelrazak Younes <[EMAIL PROTECTED]>
> Subject: [Patch] reduce linking time under windows (was R
On Sat, Apr 15, 2006 at 06:12:57PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri a écrit :
> > On Sat, Apr 15, 2006 at 05:02:09PM +0200, Abdelrazak Younes wrote:
> >
> >> Enrico Forestieri a écrit :
> >
> [...]
> > Thanks a lot, Abdel.
>
> You're welcome.
>
> >>> Anyway, I don't think th
Enrico Forestieri a écrit :
On Sat, Apr 15, 2006 at 05:02:09PM +0200, Abdelrazak Younes wrote:
Enrico Forestieri a écrit :
[...]
Thanks a lot, Abdel.
You're welcome.
Anyway, I don't think that it is a so great pain having to specify
some variables on the configure command line. You can
On Sat, Apr 15, 2006 at 05:02:09PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri a écrit :
> > I mean that you know that you should use -mno-cygwin only after
> > ascertaining that you want windows packaging. Until this point,
> > the configure script has already performed many checks using
Enrico Forestieri a écrit :
On Sat, Apr 15, 2006 at 02:33:39PM +0200, Abdelrazak Younes wrote:
Enrico Forestieri a écrit :
On Fri, Apr 14, 2006 at 06:02:25PM +0200, Abdelrazak Younes wrote:
[...]
Abdel,
I have come up with the attached cygwin.m4, but I am sorry to say
that the -mno-cygwin t
On Sat, Apr 15, 2006 at 03:07:16PM +0200, Abdelrazak Younes wrote:
> Abdelrazak Younes a écrit :
> > Enrico Forestieri a écrit :
> [...]
> >
> >> CPPFLAGS="${CPPFLAGS} -IC:/MinGW/include"
> >> LDFLAGS="${LDFLAGS} -LC:/MinGW/lib"
> >
> > We should maybe inverse the order in or
On Sat, Apr 15, 2006 at 10:28:25AM +0200, Lars Gullik Bjønnes wrote:
> Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> | I also was kidding, of course
> | I think they are a bit biased against me given that I admitted to
> | be a C++ newbie
> | In a sense, I feel at home with cygwin, as it co
On Sat, Apr 15, 2006 at 02:33:39PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri a écrit :
> > On Fri, Apr 14, 2006 at 06:02:25PM +0200, Abdelrazak Younes wrote:
> [...]
> > Abdel,
> >
> > I have come up with the attached cygwin.m4, but I am sorry to say
> > that the -mno-cygwin thing doesn
Abdelrazak Younes a écrit :
Enrico Forestieri a écrit :
[...]
CPPFLAGS="${CPPFLAGS} -IC:/MinGW/include"
LDFLAGS="${LDFLAGS} -LC:/MinGW/lib"
We should maybe inverse the order in order to make sure that the mingw
headers and libs are used first:
CPPFLAGS="$-I
Enrico Forestieri a écrit :
On Fri, Apr 14, 2006 at 06:02:25PM +0200, Abdelrazak Younes wrote:
[...]
Abdel,
I have come up with the attached cygwin.m4, but I am sorry to say
that the -mno-cygwin thing doesn't work when done this way.
Notice that it kicks in when --with-packaging=windows is spe
Enrico Forestieri <[EMAIL PROTECTED]> writes:
| I also was kidding, of course
| I think they are a bit biased against me given that I admitted to
| be a C++ newbie
| In a sense, I feel at home with cygwin, as it compares to Windows as
| the ixemul.library was comparing to the Amiga
| It was a j
On Fri, Apr 14, 2006 at 06:02:25PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri a écrit :
> > On Fri, Apr 14, 2006 at 05:07:47PM +0200, Abdelrazak Younes wrote:
> >>> I am no m4 expert, but could see what I can do. Anyway, this is not
> >>> strictly necessary as that define can be set throu
On Fri, Apr 14, 2006 at 06:02:25PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri a écrit :
> > Actually, it is quite simple. You should set CC, CPP, CXX, and CXXPP
> > when invoking configure, like this:
> >
> > cd build
> > ../configure CC='gcc -mno-cygwin' CPP='gcc -mno-cygwin -E' \
> >
Enrico Forestieri a écrit :
On Fri, Apr 14, 2006 at 05:07:47PM +0200, Abdelrazak Younes wrote:
I am no m4 expert, but could see what I can do. Anyway, this is not
strictly necessary as that define can be set through CPPFLAGS.
I would prefer something that is ready to compile out of the box so
l
301 - 400 of 652 matches
Mail list logo
