d for some reason on this system. It's perhaps due
to the Intel Atom CPU or due to bad graphics card or to the
configuration of the X server or due to some other reason. Sometimes
switching between virtual screens takes many seconds. However, typing
text on this system was never slow until I tried
Hi,
I am using Ubuntu 9.x with Intel Atom 330 processor (quad core),
32-bit linux-2.6.28.9 with SMP, Intel Corporation 82945G/GZ Integrated
Graphics Controller, 2GB RAM. LyX 1.6.2 and LyX 1.5.5 are compiled
against Qt 4. LyX 1.4.4 is compiled against Qt 3 -mt.
I have an impression that the
On 2009-05-01, Paul Johnson wrote:
> On Fri, May 1, 2009 at 6:30 AM, Jean-Marc Lasgouttes
> wrote:
>> Le 01/05/2009 08:31, Paul Johnson a écrit :
>>> ... inside the LyX file, i find that language markers \lang_english
>>> are inserted in the middle of my equation.
>> Can you try to find out how
On Fri, May 1, 2009 at 6:30 AM, Jean-Marc Lasgouttes
wrote:
> Le 01/05/2009 08:31, Paul Johnson a écrit :
>>
>> I am having trouble with Noweb documents where R code is embedded in
>> ERT boxes. Characters that do not show on the screen are being
>> inserted into my document. When the Noweb proc
Le 01/05/2009 08:31, Paul Johnson a écrit :
I am having trouble with Noweb documents where R code is embedded in
ERT boxes. Characters that do not show on the screen are being
inserted into my document. When the Noweb processor tries to parse
the code, it finds errors. On screen, for example,
I'm using Ubuntu 9.04 with LyX 1.6.2 and I'm having some troubles I've
not had before.
I am having trouble with Noweb documents where R code is embedded in
ERT boxes. Characters that do not show on the screen are being
inserted into my document. When the Noweb processor tries to
On Thu, Apr 30, 2009 at 9:44 PM, Paul Johnson wrote:
I saw some discussion that the outline view is related to the crash in
Lyx 1.6.2, and I noticed the outline was open when the crash happened
that I reported a moment ago.
I closed the outline view and produced the crash again, this time the
I have run into some trouble editing documents with a newly installed
version of Lyx. The attached document produces crashes in lyx-1.62 on
Ubuntu 9.04. The crash is reproducible. Just hold down the arrow
keys for a while.
You won't be able to compile this document unless you have the
Sweave/R
On Thu, Apr 23, 2009 at 08:41:54AM +0200, Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
>
> >> It's in the LyX/Cygwin package here:
> >> ftp://ftp.lyx.org/pub/lyx/bin/1.6.2/lyx-1.6.2-cygwin.tar.gz
> >
> > i see. imho worth to add such file somewe
Pavel Sanda wrote:
>> It's in the LyX/Cygwin package here:
>> ftp://ftp.lyx.org/pub/lyx/bin/1.6.2/lyx-1.6.2-cygwin.tar.gz
>
> i see. imho worth to add such file somewere into development/.
Why not in the manuals?
>> I think that a button "Use src-special
On 2009-04-22, Pavel Sanda wrote:
> Enrico Forestieri wrote:
>> > i just asked if we can have (easily) something like View->DVI
>> > (reverse) in our output formats, which will work in normal lyx
>> > install, without any additional tweaks so xdvi works...
>> I think that a button "Use src-specia
Enrico Forestieri wrote:
> So, the bug is about "inverse DVI search", which is now implemented (and
> thus the bug should be either closed or renamed), but the last comments
> are about the "forward DVI search" feature.
i renamed the bug
pavel
ining everything.
> >
> > where is this file located? i just grepped our tree without success.
>
> It's in the LyX/Cygwin package here:
> ftp://ftp.lyx.org/pub/lyx/bin/1.6.2/lyx-1.6.2-cygwin.tar.gz
i see. imho worth to add such file somewere into development/.
> >
win package, explaining everything.
>
> where is this file located? i just grepped our tree without success.
It's in the LyX/Cygwin package here:
ftp://ftp.lyx.org/pub/lyx/bin/1.6.2/lyx-1.6.2-cygwin.tar.gz
> > > is your solution extendible for xdvi?
> >
> > What do
On Wed, Apr 22, 2009 at 11:33:18PM +0200, Pavel Sanda wrote:
> hmmm i recently studied this bug:
> http://www.lyx.org/trac/ticket/94
> and thought this is not possible OOTB.
Now that I read bug 94, I think that there's some confusion there.
Inverse DVI search is already implemented in LyX. What i
Enrico Forestieri wrote:
> > > > is this version patched somehow?
> > >
> > > No, it works OOTB on cygwin.
> >
> > hmmm i recently studied this bug:
> > http://www.lyx.org/trac/ticket/94
> > and thought this is not possible OOTB.
>
> I think this has always been possible OOTB with xdvi, provided
On Wed, Apr 22, 2009 at 11:33:18PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Wed, Apr 22, 2009 at 06:08:12PM +0200, Pavel Sanda wrote:
> >
> > > Enrico Forestieri wrote:
> > > > On Tue, Apr 21, 2009 at 07:27:46PM -0700, sykes wrote:
> &g
Enrico Forestieri wrote:
> On Wed, Apr 22, 2009 at 06:08:12PM +0200, Pavel Sanda wrote:
>
> > Enrico Forestieri wrote:
> > > On Tue, Apr 21, 2009 at 07:27:46PM -0700, sykes wrote:
> > >
> > > > I'm running LyX 1.6.2 on Windows XP. I would like to
On Wed, Apr 22, 2009 at 06:08:12PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Tue, Apr 21, 2009 at 07:27:46PM -0700, sykes wrote:
> >
> > > I'm running LyX 1.6.2 on Windows XP. I would like to perform inverse
> > > searches from Yap ba
Enrico Forestieri wrote:
> On Tue, Apr 21, 2009 at 07:27:46PM -0700, sykes wrote:
>
> > I'm running LyX 1.6.2 on Windows XP. I would like to perform inverse
> > searches from Yap back to the actual line in LyX. Is this possible?
>
> This is possible only with t
sykes wrote:
hi,
I'm running LyX 1.6.2 on Windows XP. I use the Tortoise SVN client for
subversion. I'm getting an error when I try to commit from within LyX:
"Some problem occured while running the command:
'svn commit -m " ... "
I'm assuming I ne
On Tue, Apr 21, 2009 at 07:27:46PM -0700, sykes wrote:
> I'm running LyX 1.6.2 on Windows XP. I would like to perform inverse
> searches from Yap back to the actual line in LyX. Is this possible?
This is possible only with the cygwin version of LyX.
--
Enrico
hi,
I'm running LyX 1.6.2 on Windows XP. I use the Tortoise SVN client for
subversion. I'm getting an error when I try to commit from within LyX:
"Some problem occured while running the command:
'svn commit -m " ... "
I'm assuming I need a command l
hi,
I'm running LyX 1.6.2 on Windows XP. I would like to perform inverse
searches from Yap back to the actual line in LyX. Is this possible?
Also, is there a better viewer than Yap that people could suggest?
Thanks,
Ed Sykes
--
View this message in context:
http://n2.nabble.co
Georg Baum wrote:
Abdelrazak Younes wrote:
I agree that we need two comparison methods. I am not sure though that
the operator==() should be lighter one. I 'd rather look at the all the
cases where it is used and replace them on a case by case with
equivalent() or isSimilarTo() as I suggeste
Abdelrazak Younes wrote:
> I agree that we need two comparison methods. I am not sure though that
> the operator==() should be lighter one. I 'd rather look at the all the
> cases where it is used and replace them on a case by case with
> equivalent() or isSimilarTo() as I suggested earlier. I fea
Andre Poenitz wrote:
On Tue, Mar 24, 2009 at 08:02:12AM -0400, rgheck wrote:
I had a similar concern. Just changing the semantics of operator== seems
dangerous. But another option would be, short term, to replace it by two
methods, get things working again, and then make one of them back i
On Tue, Mar 24, 2009 at 08:02:12AM -0400, rgheck wrote:
> I had a similar concern. Just changing the semantics of operator== seems
> dangerous. But another option would be, short term, to replace it by two
> methods, get things working again, and then make one of them back into
> operator==.
Abdelrazak Younes wrote:
Hi Georg,
Georg Baum wrote:
Even if you ignore the InsetInclude problem for a moment, there will
be more
performance problems caused by the current FileName implementation. The
reason is simple: FileName once was a lightweight wrapper around a
string,
and it is still
Hi Georg,
Georg Baum wrote:
Even if you ignore the InsetInclude problem for a moment, there will be more
performance problems caused by the current FileName implementation. The
reason is simple: FileName once was a lightweight wrapper around a string,
and it is still used in many places like tha
Vincent van Ravesteijn - TNW wrote:
>>Yes, that is the case I am aware of. I just tried, and the patch
> ensures
>>that you cannot open two buffers in that case. Note that there is still
>>a bug in setting path.d->name in FileName::onlyPath(), this needs to be
>>set from path.d->fi, not d->fi.
>
>> I could be wrong, but I think so, yes. The problem is that an
absolute
>> filename isn't the same as a canonical filename, i.e., one with
>> symlinks etc resolved. We don't want to open /home/me/file.lyx and
>> /tmp/file.lyx in different buffers if, in fact, they are the same
file.
>
>Yes, th
rgheck wrote:
> Georg Baum wrote:
>> rgheck wrote:
>>
>>> Unfortunately, the case where equivalence() is needed is one of the
>>> cases causing the performance problems.
>>>
>>
>> Honest question: Really?
>>
>>
> I could be wrong, but I think so, yes. The problem is that an absolute
> file
On Sun, Mar 22, 2009 at 01:48:39PM +0100, Georg Baum wrote:
> Apart from the performance changes, the patch corrects the following issues:
I can confirm that this patch solves the slowness problem with child
documents (I only checked it on Solaris). Well spotted Georg!
--
Enrico
Georg Baum wrote:
rgheck wrote:
Georg Baum wrote:
I believe that the performance problems could be solved quite easily by
basing FileName::operator==() on simple string comparison again and
implenting an equivalence() method that is used only when needed.
Unfortunately, the
rgheck wrote:
> Georg Baum wrote:
>> I believe that the performance problems could be solved quite easily by
>> basing FileName::operator==() on simple string comparison again and
>> implenting an equivalence() method that is used only when needed.
>>
>>
> Unfortunately, the case where equivale
Georg Baum wrote:
I believe that the performance problems could be solved quite easily by
basing FileName::operator==() on simple string comparison again and
implenting an equivalence() method that is used only when needed.
Unfortunately, the case where equivalence() is needed is one of the
Vincent van Ravesteijn - TNW wrote:
>>> Do we need a new class that we use internally. In this class we store
>
>>> a filename, which is case-sensitive on case-sensitive filesystem,
> that
>>> is guaranteed to be a long filename and not a short one (on Windows),
>
>>> that is not a symlink, that
Helge Hafting wrote:
rgheck wrote:
Vincent van Ravesteijn - TNW wrote:
Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, t
>Seems excessive indeed. Ideally, typing text should be fine
>even with a "sleep(1)" in every filesystem interface. Just a
>slight stop whenever the emergency save happens.
That's why I now use a test document that I access via WebDav. It is
very rewarding to see the speed up then.
>Helge Hafti
rgheck wrote:
Vincent van Ravesteijn - TNW wrote:
Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, that is
guaranteed to b
Hi all,
I'm not familar with the coding of LyX in any case - and so don't misinterpret
my comment as any kind of paternalism. LyX is a worthy successor of SciWord,
open source, and full of excellent ideas and work.
I have the same suspicion as Vincent: Each user input inside the master(not
onl
>> Do we need a new class that we use internally. In this class we store
>> a filename, which is case-sensitive on case-sensitive filesystem,
that
>> is guaranteed to be a long filename and not a short one (on Windows),
>> that is not a symlink, that is relative or absolute (pick one or
both).
>
Vincent van Ravesteijn - TNW wrote:
Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, that is
guaranteed to be a long file
> Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, that is
guaranteed to be a long filename and not a short one (on Windows), that
The previous == and != checks had just been against the file NAMES,
which meant you could get file1 != file2, >if the names were symlinks
pointing to the same file, and names with different capatalizations
would be seen >as different on Windows, VFAT, etc. So Abdel changed it
to call QFileInfo::
-Original Message-
From: rgheck [mailto:rgh...@bobjweil.com]
Sent: donderdag 19 maart 2009 20:46
To: Vincent van Ravesteijn - TNW
Cc: lyx-devel@lists.lyx.org
Subject: Re: LyX 1.6.2: possible performance issue inside master
document
Vincent van Ravesteijn - TNW wrote:
>
>
Vincent van Ravesteijn - TNW wrote:
So, if there are four filesystem-checks in Linux, there are at least
six on Windows and maybe the compiler does something smart when
os::internal_path does nothing.
That would make it worse. But enough worse that I see nothing
here? Is networ
Vincent van Ravesteijn - TNW wrote:
rgheck wrote:
By the way, can you remember what problem Bennet had which made you
adding the lhs.refresh() and rhs.refresh() lines to
FileName::operator==(). This solution looks a bit like "Abdel's
hammer".
Not right now, no, thou
>> So, if there are four filesystem-checks in Linux, there are at least
>> six on Windows and maybe the compiler does something smart when
>> os::internal_path does nothing.
>>
>>
>That would make it worse. But enough worse that I see nothing
>here? Is network file system performance much >s
rgheck wrote:
>>> By the way, can you remember what problem Bennet had which made you
>>> adding the lhs.refresh() and rhs.refresh() lines to
>>> FileName::operator==(). This solution looks a bit like "Abdel's
hammer".
>>>
>>>
>> Not right now, no, though it's probably on the list somewhere.
rgheck wrote:
By the way, can you remember what problem Bennet had which made you
adding the lhs.refresh() and rhs.refresh() lines to
FileName::operator==(). This solution looks a bit like "Abdel's hammer".
Not right now, no, though it's probably on the list somewhere. But I
think the proble
Vincent van Ravesteijn - TNW wrote:
As a data point, I don't see any slowdown in Linux, using latest
branch and Qt 4.4.3, under Fedora 8. UNLESS I open the View Source
window, when (unsurprisingly) I do. Same result if I put the files
on a network drive.
Is it possible that LaTeX is being genera
>As a data point, I don't see any slowdown in Linux, using latest
>branch and Qt 4.4.3, under Fedora 8. UNLESS I open the View Source
>window, when (unsurprisingly) I do. Same result if I put the files
>on a network drive.
>
>Is it possible that LaTeX is being generated, even though the window
>
Well list didn't accept the large files. Now with small ones. Slowness is the
same.
Thanks,
Zardoz
Original-Nachricht
> Datum: Thu, 19 Mar 2009 12:31:59 -0400
> Von: rgheck
> An: pseudo2...@gmx.at
> CC: lyx-devel@lists.lyx.org
> Betreff: Re: LyX 1.6.2: p
pseudo2...@gmx.at wrote:
Well, my attached zip-file has been rejected. I try the lyx-files.
An no, the latex "view source" window is not open.
OK, thanks.
As a data point, I don't see any slowdown in Linux, using latest branch
and Qt 4.4.3, under Fedora 8. UNLESS I open the View Source wi
pseudo2...@gmx.at wrote:
I've created some testdocument that reproduces the behaviour (where can files be uploaded?).
Just attach it.
rh
> If you are able to send me a test document (maybe privately) I'll have a
> look. Even better: put it in a new bugzilla entry.
>
I've created some testdocument that reproduces the behaviour (where can files
be uploaded?). (WinXP)
-> 1.6.1 (AltInstaller or Classic same behaviour): slow down in
r Debian? Or because
many people are editing the master less frequently than its children?
I see a slower response in a master than in a child also under Linux.
(Debian/testing, LyX 1.6.2-svn).
It is still usable but annoying. Maybe it gets worse with auto-completion
(which I turned off for performance resons).
Günter
Well, I'll keep the traffic to the devel-list.
> I wish I had some idea why this is happening only on certain platforms.
> Or is it only on certain platforms? I've not seen reports of this
> behavior under Linux, but maybe there are people with similar problems.
>
> Have there been other change
Vincent van Ravesteijn - TNW wrote:
I wish I had some idea why this is happening only on
certain platforms. Or is it only on certain platforms?
I've not seen reports of this behavior under Linux, but
maybe there are people with similar problems.
Have there been other changes to the Windows or Ma
>I wish I had some idea why this is happening only on
>certain platforms. Or is it only on certain platforms?
>I've not seen reports of this behavior under Linux, but
>maybe there are people with similar problems.
>
>Have there been other changes to the Windows or Mac distributions from
>1.6.1 to 1
pseudo2...@gmx.at wrote:
Child document opened alone or together with its parent?
Performance inside the child document is much better. Only the master is
concerned. It does not matter whether the master is opened or not. It even does
not make any difference if the master or the child is
Hi all,
thank Abdelrazak Younes for the prompt answer.
so I'm not the only one (see users list: Lyx 1.6.2 unusably slow on the Mac)
> Child document opened alone or together with its parent?
Performance inside the child document is much better. Only the master is
concerned. It
Vincent van Ravesteijn - TNW wrote:
> Any sign of life from Joost yet ?
no.
Jürgen
Any sign of life from Joost yet ?
Vincent
pseudo2...@gmx.at wrote:
Hi all,
has anybody noticed some performance issues while editing inside a master
document that includes a number (say about 5 or more) of long child docs. The
same large document caused no problems in LyX 1.5.6
indication: cursor movement is annoyingly slow, fast typ
Hi all,
has anybody noticed some performance issues while editing inside a master
document that includes a number (say about 5 or more) of long child docs. The
same large document caused no problems in LyX 1.5.6
indication: cursor movement is annoyingly slow, fast typing on keyboard-> you
can
Jean-Marc Lasgouttes wrote:
> They just fixed the problem.
Thanks, I reset the links.
Jürgen
On Sat, Mar 14, 2009 at 11:16 PM, Jürgen Spitzmüller wrote:
> LyX 1.6.2 is here:
> ftp://ftp.devel.lyx.org/pub/lyx/stable
FYI, I have put up binaries for the Eeepc 701.
http://www.ucc.asn.au/~mccabedj/eeepc/lyx-1.5.7-eeepc.tar.bz2
http://www.ucc.asn.au/~mccabedj/eeepc/lyx-1.6.2-eeepc.t
Le 15 mars 09 à 13:21, Jürgen Spitzmüller a écrit :
Jean-Marc Lasgouttes wrote:
I just sent a message to the ftp admins.
Thanks.
They just fixed the problem.
JMarc
On Sun, Mar 15, 2009 at 12:13:49PM +0100, Abdelrazak Younes wrote:
> On 15/03/2009 11:59, Jürgen Spitzmüller wrote:
>> Sven Hoexter wrote:
>>
>>> Now I just need to meet you to verify your key or find a trustpath to
>>> you. :) Hm no sigs on the key. Bad. But fair enough for the moment.
>>>
On Sun, Mar 15, 2009 at 2:02 PM, Anders Ekberg wrote:
> On 15 mar 2009, at 16.56, Jürgen Spitzmüller wrote:
>
>> BH wrote:
>>>
>>> The new version is now at:
>>>
>>> http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2.1-Mac-Universal.dmg
>>
>> It's online.
>
> Updated on http://www.apple.com/downloa
On Sun, Mar 15, 2009 at 11:56 AM, Jürgen Spitzmüller wrote:
> BH wrote:
>> The new version is now at:
>>
>> http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2.1-Mac-Universal.dmg
>
> It's online.
>
> Jürgen
>
Thanks.
Bennett
On 15 mar 2009, at 16.56, Jürgen Spitzmüller wrote:
BH wrote:
The new version is now at:
http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2.1-Mac-Universal.dmg
It's online.
Updated on http://www.apple.com/downloads/macosx/
It should show up in a day or two.
/Anders
BH wrote:
> The new version is now at:
>
> http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2.1-Mac-Universal.dmg
It's online.
Jürgen
On Sun, Mar 15, 2009 at 9:44 AM, Jürgen Spitzmüller wrote:
> BH wrote:
>> Can you remove the Mac binary for now? Uwe correctly identified that
>> problems I was having with typesetting the User's Guide are the result
>> of using Qt-4.5, and I'm currently recompiling with Qt-4.4. I'll post
>> a new
BH wrote:
> Can you remove the Mac binary for now? Uwe correctly identified that
> problems I was having with typesetting the User's Guide are the result
> of using Qt-4.5, and I'm currently recompiling with Qt-4.4. I'll post
> a new binary shortly.
OK. (I wouldn't have recommended Qt 4.5 for the
On Sun, Mar 15, 2009 at 7:31 AM, Jürgen Spitzmüller wrote:
> BH wrote:
>> I've put the Mac universal binary here:
>>
>> http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2-Mac-Universal.dmg
>>
>> Could you upload it to the server?
>>
>> ... And tha
Vincent van Ravesteijn wrote:
> But, that's probably because you don't have an installer from Joost yet..
exactly :-)
Jürgen
Public release of LyX version 1.6.2
===
We are pleased to announce the release of LyX 1.6.2. This is the second
maintenance release in the 1.6.x series. The release fixes a large number
of major and critical bugs that were reported by users of LyX 1.6.0 and
1.6.1
Vincent van Ravesteijn schreef:
Jürgen Spitzmüller schreef:
Jean-Marc Lasgouttes wrote:
I just sent a message to the ftp admins.
Thanks.
Note that the access via http
just works. We can use that as URLs.
Ah, excellent. Then I use that for the time being.
Jürgen
Please not
Jürgen Spitzmüller schreef:
Jean-Marc Lasgouttes wrote:
I just sent a message to the ftp admins.
Thanks.
Note that the access via http
just works. We can use that as URLs.
Ah, excellent. Then I use that for the time being.
Jürgen
Please note that in section 2.1 of http:
Jean-Marc Lasgouttes wrote:
> I just sent a message to the ftp admins.
Thanks.
> Note that the access via http
> just works. We can use that as URLs.
Ah, excellent. Then I use that for the time being.
Jürgen
Jürgen Spitzmüller writes:
> Vincent van Ravesteijn wrote:
>> But you did put it on the website ?
>
> Yes. I only realized that afterwards.
I just sent a message to the ftp admins. Note that the access via http
just works. We can use that as URLs.
JMarc
Vincent van Ravesteijn wrote:
> But you did put it on the website ?
Yes. I only realized that afterwards.
Jürgen
Jürgen Spitzmüller schreef:
BH wrote:
I've put the Mac universal binary here:
http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2-Mac-Universal.dmg
Could you upload it to the server?
... And thank you for your patience!
Thanks, Bennett, Uwe and Enrico,
your binaries are o
BH wrote:
> I've put the Mac universal binary here:
>
> http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2-Mac-Universal.dmg
>
> Could you upload it to the server?
>
> ... And thank you for your patience!
Thanks, Bennett, Uwe and Enrico,
your binaries are on the server o
On 15/03/2009 11:59, Jürgen Spitzmüller wrote:
Sven Hoexter wrote:
Now I just need to meet you to verify your key or find a trustpath to
you. :) Hm no sigs on the key. Bad. But fair enough for the moment.
Just tell me if there's anything I can do to make it more trustworthy.
You
Sven Hoexter wrote:
> Now I just need to meet you to verify your key or find a trustpath to
> you. :) Hm no sigs on the key. Bad. But fair enough for the moment.
Just tell me if there's anything I can do to make it more trustworthy.
Jürgen
> LyX 1.6.2 is here:
I've uploaded the alternative Windows installer here:
http://developer.berlios.de/project/showfiles.php?group_id=5117&release_id=15926
Can you please put it to ftp.lyx.org?
thanks and regards
Uwe
On Sat, Mar 14, 2009 at 03:16:24PM +0100, Jürgen Spitzmüller wrote:
> LyX 1.6.2 is here:
> ftp://ftp.devel.lyx.org/pub/lyx/stable
Please, find a cygwin binary here:
http://www.lyx.org/~forenr/lyx-1.6.2-cygwin.tar.gz
--
Enrico
On Sat, Mar 14, 2009 at 05:20:06PM +0100, Jürgen Spitzmüller wrote:
> Sven Hoexter wrote:
> > Is it possible to post the sha-/md5sum for the tarball on your
> > system?
>
> I intend to post the attached signatures on ftp.lyx.org. Would that be
> sufficient?
Sure. Thanks.
Now I just need to meet
On Sat, Mar 14, 2009 at 10:16 AM, Jürgen Spitzmüller wrote:
> LyX 1.6.2 is here:
> ftp://ftp.devel.lyx.org/pub/lyx/stable
>
> As usual, I will wait a bit with the announce, to give the packagers the time
> to set up the binaries. I hope ftp.lyx.org will be back until then (I can
Sven Hoexter wrote:
> Is it possible to post the sha-/md5sum for the tarball on your
> system?
I intend to post the attached signatures on ftp.lyx.org. Would that be
sufficient?
Jürgen
lyx-1.6.2.tar.gz.sig
Description: PGP signature
lyx-1.6.2.tar.bz2.sig
Description: PGP signature
On Sat, Mar 14, 2009 at 03:16:24PM +0100, Jürgen Spitzmüller wrote:
Hi Juergen,
> LyX 1.6.2 is here:
> ftp://ftp.devel.lyx.org/pub/lyx/stable
Is it possible to post the sha-/md5sum for the tarball on your
system?
Sven
--
If God passed a mic to me to speak
I'd say stay in bed, wor
LyX 1.6.2 is here:
ftp://ftp.devel.lyx.org/pub/lyx/stable
As usual, I will wait a bit with the announce, to give the packagers the time
to set up the binaries. I hope ftp.lyx.org will be back until then (I can log
into the server, but I cannot upload anything).
Thanks everybody for testing
Vincent van Ravesteijn wrote:
> I've committed the two fixes for Qt4.5.
thanks.
> Are we set now or are there still more issues open ?
no, we are ready now. I'll set up the final tarball now.
> By the way, note that ftp.lyx.org/pub/lyx is still not available, so
> before releasing 1.6.2, we'll
Jürgen Spitzmüller schreef:
The test tarball is available here:
http://www.lyx.org/~spitz/lyx-1.6.2rc1.tar.gz
If no regressions are reported, this will become LyX 1.6.2. Please test.
Meanwhile, branch remains frozen until the freeze lift is announced (probably
end of next week).
Thanks
Jürgen Spitzmüller wrote:
(I wonder, however, why no one noticed earlier; am I the only one who uses
branch for daily work?)
I always do, but I've had so much administrative stuff to do that that
kind of daily work hasn't been happening of late
rh
1 - 100 of 148 matches
Mail list logo
