Release management dissertation
Hi, See http://www.cyrius.com/publications/michlmayr-phd.pdf for a dissertation about the role of release management in open source projects. I have not read all of it, but it does contain some interesting thoughts about whether to use feature based releases, or time based releases. Also, it touches on what practices and tools seem to make release processes work better in terms of helping the resulting quality of the release. It should be an interesting read at this point, where plans are being made for the process for 1.6. Regards, Asger
Re: LyX 1.5.0 is released
On Wed, Aug 01, 2007 at 08:21:19PM -0600, Bob Lounsbury wrote: > On 8/1/07, Charles de Miramon <[EMAIL PROTECTED]> wrote: > > Jean-Marc Lasgouttes wrote: > > > > > > > > Public release of LyX version 1.5.0 > > > === > > > > > > We are pleased to announce the release of LyX 1.5.0. > > > I just tried to download 1.5.0 and noticed that it is temporarily > unavailable. Is the compression problem solely related to Windoze? Right now it looks like it. However, there's no guarantee that the boost zip code that we currently blame for the corruption and that's essentially the same on Windows and Linux does not cause corruption on non-Windows machines. > If so, why should everyone else that uses the program be punished? > Couldn't the windoze installers be temporarily unavailable, but the > tar.gz files still be available for those of us running Linux? If you really want to use 1.5.0 you can get the sources from svn. People valuing their work should wait for 1.5.1. > If the compression problem is related to Linux and Mac also, couldn't > we just be warned not to use the compression feature? Which I haven't > ever used anyway. We had reports on unrecoverable files, the first ones for ages actually. People don't like losing their work. Andre'
Re: Crashes caused child document and Toc panel.
> Still tracing...
The problem is found:
1. updateToc is triggered by signal structureChange, which is needed
to validate references in the Toc dialog.
2. signal structureChange is connected to the master buffer at first
3. when the first child is loaded, the master buffer is still
connected, and updateToc is called correctly
4. however, in lyxview::setBuffer(), the master is disconnected after
the first child is loaded
if (oldBuffer) {
parentfilename = oldBuffer->fileName();
disconnectBuffer();
}
5. when the second child is loaded,
updateLabels(*newBuffer->getMasterBuffer()); (line 228, lyxview.cpp)
does not update toc, because the master buffer is disconnected.
6. then, when the toc dialog is used, invalidated reference is used,
and msvc asserts.
I can confirm that if I comment out the above disconnectBuffer() call,
lyx will not crash. Now I need to know why we disconnectBuffer()
their, and what would be a proper fix. Another possible fix is not
call setBuffer until all child documents are loaded.
Cheers,
Bo
Re: Crashes caused child document and Toc panel.
I traced this problem and found something strange. When the child documents are loaded, after LoadLyxFile, updateLabels are called, and release a structureChanged() signal, which calls LyXView::updateToc() to update the Toc dialog (QToc::update()). It is strange to me that after the second child document is loaded, the signal does not trigger updateToc and lead to invalid iterators in the Toc dialog If you set breakpoints at LyXView::updateToc(), and updateLabels, you will see what I meant. Still tracing... Bo
Re: LyX 1.5.0 is released
> I just tried to download 1.5.0 and noticed that it is temporarily > unavailable. Is the compression problem solely related to Windoze? If > so, why should everyone else that uses the program be punished? > Couldn't the windoze installers be temporarily unavailable, but the > tar.gz files still be available for those of us running Linux? If the > compression problem is related to Linux and Mac also, couldn't we just > be warned not to use the compression feature? Which I haven't ever > used anyway. JMarc, could you allow downloading of lyx 1.5.0 binaries except for the windows installers? Because the compression problem only happens under windows, it is safe to distribute lyx for other platforms. Cheers, Bo
Re: LyX 1.5.0 is released
On 8/1/07, Charles de Miramon <[EMAIL PROTECTED]> wrote: > Jean-Marc Lasgouttes wrote: > > > > > Public release of LyX version 1.5.0 > > === > > > > We are pleased to announce the release of LyX 1.5.0. I just tried to download 1.5.0 and noticed that it is temporarily unavailable. Is the compression problem solely related to Windoze? If so, why should everyone else that uses the program be punished? Couldn't the windoze installers be temporarily unavailable, but the tar.gz files still be available for those of us running Linux? If the compression problem is related to Linux and Mac also, couldn't we just be warned not to use the compression feature? Which I haven't ever used anyway. Bob Lounsbury
Re: No pdf export in lyx1.5.0rc2
Gerard Bekking wrote: Hello It seems not possible to export lyx documents to pdf. Using the acrobat icon gives a view but the file goes to the tmp directory if you save it. Your PDF viewer does not have something like File -> Save As? (Acrobat Reader has File -> Save a copy, which opens a file dialog where you can specify the location.) This should not be necessary, though. Only opening DVI-view and saving as pdf gives the resul needed. In LyX, File -> Export does not list PDF (pdflatex), PDF (dvipdfm) and/or PDF (ps2pdf) as options? Usually, if they are missing, it means LyX does not know a conversion path from LaTeX to PDF; but in such a case, there is also no View -> PDF option? /Paul
No pdf export in lyx1.5.0rc2
Hello It seems not possible to export lyx documents to pdf. Using the acrobat icon gives a view but the file goes to the tmp directory if you save it. Only opening DVI-view and saving as pdf gives the resul needed. -- Groeten, Gerard Bekking
Re: [PATCH-updated] Bug 3676--Citation Bug
On Wed, Aug 01, 2007 at 03:12:20PM -0400, Richard Heck wrote: > > >>>Passing a std::map by value seems wrong. > >>> > >>Yes. Made it const &. This required a const_cast, but that seems ok. > >> > >Not really. > > > It's necessary because I want to use operator[] on the map later, and > that has no const version. That seems better than making it just &, > without the const. > >>+ KeyValMap & data2 = const_cast(data); > >>+ return data2[key]; > >> > > return data.find(key)->second; > > > >Maybe even with ASSERETing on != data.end(). > > > No, we don't want to do that. If the year field isn't given in a > particular entry, say, then there won't be a year key in the map. But > that's OK, and getValueForKey(data, "year") can just return docstring(). So 'find', no const cast and some_iter it = data.find(key); return it == data.end() ? docstring() : it->second; Andre'
Re: Crashes caused child document and Toc panel.
> Note that there's no crash under MacOS (Intel Mac OS X.4.10). gcc will not crash. The assertion is from MSVC 8's "debug iterator support" feature. Basically, when a container is changed, all its iterators will be invalidated. In this case, I suspect that the opening of the child document, and the added sections and float type, invalidated TocIterators so they can not be searched in TocModels. Maybe Toc, TocModel etc should be completely regenerated after a child document is read. Bo
Re: Collapsable CharStyles [Beyond 1.5]
Martin Vermeer wrote: I think this is the way to go. A layout item Inset, from which CharStyle is only one of many applications. Requires careful thinking through of what configurability we want to allow in the layout file. I would love the inset to have a dialog with user-defined menu entries e.g. But this "mini-language" requires careful design. Yes indeed. But let me suggest that we take this in stages. There's something easily within reach here that will be very useful and then there's something that will take a lot more thought and a lot more time. We don't want to do anything now that will make the longer-term thing any harder, but I don't want to have to wait on something really useful while we figure out all these details and potentially re-design much of the layout and inset system. I'll make a more concrete sort of suggestion in a while. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH-updated] Bug 3676--Citation Bug
Andre Poenitz wrote:
On Wed, Aug 01, 2007 at 12:19:33AM -0400, Richard Heck wrote:
Yes, I agree. This is needed, IIRC (I did this a while ago), for certain
constants, e.g.:
static const docstring
TheBibliographyRef(from_ascii("TheBibliographyRef"));
which was in frontends/controllers/frontend_helpers.cpp and which I've
moved (in effect) to the header.
So why not move it in the core if it is used there?
I tend to be cautious about that sort of thing, as I'm still new to
this. But if you think that is best, I'll do it. Which you do, so I will.
-docstring const parseBibTeX(docstring data, std::string const & findkey);
+docstring const getValueForKey(KeyValMap data, std::string const &
findkey);
Passing a std::map by value seems wrong.
Yes. Made it const &. This required a const_cast, but that seems ok.
Not really.
It's necessary because I want to use operator[] on the map later, and
that has no const version. That seems better than making it just &,
without the const.
+ KeyValMap & data2 = const_cast(data);
+ return data2[key];
return data.find(key)->second;
Maybe even with ASSERETing on != data.end().
No, we don't want to do that. If the year field isn't given in a
particular entry, say, then there won't be a year key in the map. But
that's OK, and getValueForKey(data, "year") can just return docstring().
That's pretty much how BibTeX does it, too.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Crashes caused child document and Toc panel.
Selon Bo Peng <[EMAIL PROTECTED]>: > Abdel, > > Could you confirm this bug? > > 1. open the attached test.lyx > 2. document -> outline > 3. click on child2.lyx, and load > > lyx crashes. Note that there's no crash under MacOS (Intel Mac OS X.4.10). Mael.
Re: Keymaps
Andre Poenitz wrote: On Fri, Jul 27, 2007 at 05:20:27PM +0300, Dov Feldstern wrote: [...] But anyhow, I'm not sure how much any of this is really relevant to the issue of keymaps. What I'm suggesting is that generally, if the user has the "use keymaps" option marked, then by switching the language, the keymap will also automatically be switched to the appropriate keymap. I explicitly stated that (a) the user will still be able to choose not to use keymaps at all, indeed, that should remain the default behavior, as it currently is, and (b) the user should still be able to explicitly switch the keymap without switching the language. So I don't think that the use-case that you're presenting will be adversely affected by my suggestion, would it? I won't. I just wanted you present with some corner case scenarios before hard decisions are made. Andre' Right, thanks. I'll make sure to take these cases into account when I get to this... Dov
Re: Use Computer Algebra System with LyX
On Wed, Aug 01, 2007 at 02:05:27PM +0200, Andreas Karlsson wrote: > Does this menu entry works? I works for toy problems only. Andre'
Re: Crashes caused child document and Toc panel.
Abdel, Could you confirm this bug? 1. open the attached test.lyx 2. document -> outline 3. click on child2.lyx, and load lyx crashes. This only happens on windows with msvc. Because scons is not great for msvc debugging, I have not figure out what is going on Cheers, Bo test.lyx Description: application/lyx child1.lyx Description: application/lyx child2.lyx Description: application/lyx
Re: Compress file corrupted
On Aug 1, 2007, at 11:26 AM, Jean-Marc Lasgouttes wrote: "Bo Peng" <[EMAIL PROTECTED]> writes: OK. Please apply to trunk and branch. Frankly, I am too tired to debug boost::iostreams. Agreed. I would have liked to upgrade to boost 1.34.1 too, but this will be for 1.5.2. The patches are in now, but I did not take much time to test them. People, please test on your respective architectures. Won't compile for me on Mac: Making all in . /bin/sh ../libtool --tag=CXX --mode=link g++ -g -Os -framework Carbon -framework OpenGL -framework AGL -framework QuickTime - framework Cocoa -o lyx-qt4 main.o ISpell.o SpellBase.o Author.o Bidi.o boost.o Box.o BranchList.o Buffer.o buffer_funcs.o BufferList.o BufferParams.o BufferView.o bufferview_funcs.o Bullet.o Changes.o Chktex.o Color.o ConverterCache.o Converter.o CoordCache.o Counters.o Cursor.o CursorSlice.o CutAndPaste.o debug.o DepTable.o Dimension.o DocIterator.o Encoding.o ErrorList.o Exporter.o factory.o Floating.o FloatList.o Font.o FontIterator.o Format.o FuncRequest.o FuncStatus.o gettext.o Graph.o Importer.o InsetIterator.o InsetList.o Intl.o KeyMap.o KeySequence.o Language.o LaTeX.o LaTeXFeatures.o Layout.o Length.o lengthcommon.o Lexer.o LyXAction.o callback.o LyX.o lyxfind.o LyXFunc.o LyXRC.o Server.o ServerSocket.o LyXVC.o MenuBackend.o Messages.o MetricsInfo.o Mover.o output.o output_docbook.o output_latex.o OutputParams.o output_plaintext.o Paragraph.o paragraph_funcs.o ParagraphMetrics.o ParagraphParameters.o ParIterator.o PrinterParams.o Row.o rowpainter.o Session.o sgml.o Spacing.o TexRow.o Text.o Text2.o Text3.o TextClass.o TextClassList.o TextMetrics.o Thesaurus.o TocBackend.o toc.o ToolbarBackend.o Trans.o Undo.o VCBackend.o version.o VSpace.o mathed/libmathed.la insets/libinsets.la frontends/ libfrontends.la frontends/qt4/libqt4.la frontends/controllers/ libcontrollers.la graphics/libgraphics.la support/libsupport.la ../ boost/libs/regex/src/libboost_regex.la ../boost/libs/signals/src/ libboost_signals.la ../boost/libs/filesystem/src/ libboost_filesystem.la ../boost/libs/iostreams/src/ libboost_iostreams.la ../intl/libintl.a -liconv -lm -liconv -lz g++ -g -Os -framework Carbon -framework OpenGL -framework AGL - framework QuickTime -framework Cocoa -o lyx-qt4 main.o ISpell.o SpellBase.o Author.o Bidi.o boost.o Box.o BranchList.o Buffer.o buffer_funcs.o BufferList.o BufferParams.o BufferView.o bufferview_funcs.o Bullet.o Changes.o Chktex.o Color.o ConverterCache.o Converter.o CoordCache.o Counters.o Cursor.o CursorSlice.o CutAndPaste.o debug.o DepTable.o Dimension.o DocIterator.o Encoding.o ErrorList.o Exporter.o factory.o Floating.o FloatList.o Font.o FontIterator.o Format.o FuncRequest.o FuncStatus.o gettext.o Graph.o Importer.o InsetIterator.o InsetList.o Intl.o KeyMap.o KeySequence.o Language.o LaTeX.o LaTeXFeatures.o Layout.o Length.o lengthcommon.o Lexer.o LyXAction.o callback.o LyX.o lyxfind.o LyXFunc.o LyXRC.o Server.o ServerSocket.o LyXVC.o MenuBackend.o Messages.o MetricsInfo.o Mover.o output.o output_docbook.o output_latex.o OutputParams.o output_plaintext.o Paragraph.o paragraph_funcs.o ParagraphMetrics.o ParagraphParameters.o ParIterator.o PrinterParams.o Row.o rowpainter.o Session.o sgml.o Spacing.o TexRow.o Text.o Text2.o Text3.o TextClass.o TextClassList.o TextMetrics.o Thesaurus.o TocBackend.o toc.o ToolbarBackend.o Trans.o Undo.o VCBackend.o version.o VSpace.o -Wl,-bind_at_load mathed/.libs/libmathed.a insets/.libs/libinsets.a frontends/.libs/libfrontends.a frontends/ qt4/.libs/libqt4.a -L/Users/bennett/lyx/qt-4.3-install/lib -lQtGui frontends/controllers/.libs/libcontrollers.a graphics/.libs/ libgraphics.a support/.libs/libsupport.a -lQtCore ../boost/libs/regex/ src/.libs/libboost_regex.a ../boost/libs/signals/src/.libs/ libboost_signals.a ../boost/libs/filesystem/src/.libs/ libboost_filesystem.a ../boost/libs/iostreams/src/.libs/ libboost_iostreams.a ../intl/libintl.a -lm /usr/lib/libiconv.dylib -lz /usr/bin/ld: Undefined symbols: gz::gzstreambase::gzstreambase(char const*, int) gz::gzstreambase::~gzstreambase() gz::gzstreambase::~gzstreambase() gz::gzstreambase::~gzstreambase() typeinfo for gz::gzstreambase virtual thunk to gz::gzstreambase::~gzstreambase() virtual thunk to gz::gzstreambase::~gzstreambase() gz::gzstreambuf::open(char const*, int) gz::gzstreambuf::close() vtable for gz::gzstreambuf collect2: ld returned 1 exit status make[3]: *** [lyx-qt4] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 Bennett
Re: Compress file corrupted
"Bo Peng" <[EMAIL PROTECTED]> writes: > OK. Please apply to trunk and branch. Frankly, I am too tired to debug > boost::iostreams. Agreed. I would have liked to upgrade to boost 1.34.1 too, but this will be for 1.5.2. The patches are in now, but I did not take much time to test them. People, please test on your respective architectures. > Is there any chance to fix middle-button paste (and a newly > table-cut-paste issue) before 1.5.1? There is also a TOC crash problem > that I am trying to sort out. It depends whether we find good patches soon :) JMarc
Re: Compress file corrupted
> To be more precise, here is the patch that I propose to apply > (slightly cleaned up version of Bo's). I added automake stuff, what > needs to be done for cmake? OK. Please apply to trunk and branch. Frankly, I am too tired to debug boost::iostreams. Is there any chance to fix middle-button paste (and a newly table-cut-paste issue) before 1.5.1? There is also a TOC crash problem that I am trying to sort out. Bo
Re: Compress file corrupted
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Huh? > http://marc.info/?l=lyx-devel&m=118595157304160&w=2 Just when I thought you were gone already... Have a nice vacation, JMarc
Re: Compress file corrupted
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> I propose to apply the patch to 1.5.1svn now, wait a bit to see what
> happens and then release 1.5.1 as it stands. Would it make sense?
To be more precise, here is the patch that I propose to apply
(slightly cleaned up version of Bo's). I added automake stuff, what
needs to be done for cmake?
JMarc
Index: src/support/gzstream.h
===
--- src/support/gzstream.h (révision 0)
+++ src/support/gzstream.h (révision 0)
@@ -0,0 +1,123 @@
+//
+// gzstream, C++ iostream classes wrapping the zlib compression library.
+// Copyright (C) 2001 Deepak Bandyopadhyay, Lutz Kettner
+//
+// This library is free software; you can redistribute it and/or
+// modify it under the terms of the GNU Lesser General Public
+// License as published by the Free Software Foundation; either
+// version 2.1 of the License, or (at your option) any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+// Lesser General Public License for more details.
+//
+// You should have received a copy of the GNU Lesser General Public
+// License along with this library; if not, write to the Free Software
+// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+//
+//
+// File : gzstream.h
+// Revision : $Revision: 1.2 $
+// Revision_date : $Date: 2005/04/26 10:30:24 $
+// Author(s) : Deepak Bandyopadhyay, Lutz Kettner
+//
+// Standard streambuf implementation following Nicolai Josuttis, "The
+// Standard C++ Library".
+//
+
+#ifndef GZSTREAM_H
+#define GZSTREAM_H 1
+
+// standard C++ with new header file names and std:: namespace
+#include
+#include
+#include
+
+// For LyX
+#define GZSTREAM_NAMESPACE gz
+
+#ifdef GZSTREAM_NAMESPACE
+namespace GZSTREAM_NAMESPACE {
+#endif
+
+//
+// Internal classes to implement gzstream. See below for user classes.
+//
+
+class gzstreambuf : public std::streambuf {
+private:
+static const int bufferSize = 47+256;// size of data buff
+// totals 512 bytes under g++ for igzstream at the end.
+
+gzFile file; // file handle for compressed file
+char buffer[bufferSize]; // data buffer
+char opened; // open/close state of stream
+int mode; // I/O mode
+
+int flush_buffer();
+public:
+gzstreambuf() : opened(0) {
+setp( buffer, buffer + (bufferSize-1));
+setg( buffer + 4, // beginning of putback area
+ buffer + 4, // read position
+ buffer + 4);// end position
+// ASSERT: both input & output capabilities will not be used together
+}
+int is_open() { return opened; }
+gzstreambuf* open( const char* name, int open_mode);
+gzstreambuf* close();
+~gzstreambuf() { close(); }
+
+virtual int overflow( int c = EOF);
+virtual int underflow();
+virtual int sync();
+};
+
+class gzstreambase : virtual public std::ios {
+protected:
+gzstreambuf buf;
+public:
+gzstreambase() { init(&buf); }
+gzstreambase( const char* name, int open_mode);
+~gzstreambase();
+void open( const char* name, int open_mode);
+void close();
+gzstreambuf* rdbuf() { return &buf; }
+};
+
+//
+// User classes. Use igzstream and ogzstream analogously to ifstream and
+// ofstream respectively. They read and write files based on the gz*
+// function interface of the zlib. Files are compatible with gzip compression.
+//
+
+class igzstream : public gzstreambase, public std::istream {
+public:
+igzstream() : std::istream( &buf) {}
+igzstream( const char* name, int open_mode = std::ios::in)
+: gzstreambase( name, open_mode), std::istream( &buf) {}
+gzstreambuf* rdbuf() { return gzstreambase::rdbuf(); }
+void open( const char* name, int open_mode = std::ios::in) {
+gzstreambase::open( name, open_mode);
+}
+};
+
+class ogzstream : public gzstreambase, public std::ostream {
+public:
+ogzstream() : std::ostream( &buf) {}
+ogzstream( const char* name, int mode = std::ios::out)
+: gzstreambase( name, mode), std::ostream( &buf) {}
+gzstreambuf* rdbuf() { return gzstreambase::rdbuf(); }
+void open( const char* name, int
Re: Compress file corrupted
Jean-Marc Lasgouttes wrote: > I propose to apply the patch to 1.5.1svn now, wait a bit to see what > happens and then release 1.5.1 as it stands. Would it make sense? > > I agree this is a delay, but we cannot afford to be wrong another time. FWIW, I agree. > I see that Jose and Juergen carefully avoid to tell what to do :) Huh? http://marc.info/?l=lyx-devel&m=118595157304160&w=2 Jürgen
Re: Compress file corrupted
"Bo Peng" <[EMAIL PROTECTED]> writes: >> I tested the compression feature on all kinds of documents including 1.4 >> documents and the Linux document from Bo. I did not find any problems. >> The same code has also been used in many 1.4 releases and works fine there. > > Did you upload this installer? I think this is the best we can do for > now so JMarc, please replace the previous windows installers with this > one, and re-allow downloading. I do not like much to have two different beasts named 1.5.0. We need to get 1.5.1 out rsn instead. JMarc
Re: Compress file corrupted
Andre Poenitz <[EMAIL PROTECTED]> writes: >> With this patch things seem to work fine. I can open your file and save >> & open files with compression enabled. I'm uploading 1.5.0-2 installers >> right now. > > Please do not distribute new stuff unless this is _thoroughly_ tested. I propose to apply the patch to 1.5.1svn now, wait a bit to see what happens and then release 1.5.1 as it stands. Would it make sense? I agree this is a delay, but we cannot afford to be wrong another time. I see that Jose and Juergen carefully avoid to tell what to do :) JMarc
Offline
I'm offline for three weeks as of tomorrow. Until I'm back, Jean-Marc and José maintain the stable branch, so you can keep on committing fixes with their permission. If releasing 1.5.1 turns out to be necessary due to the compression bug or some other severe issue, don't let anything stop you ;-) Have a nice time everybody (especially the Finland cowboys). Jürgen
Re: Compress file corrupted
> I tested the compression feature on all kinds of documents including 1.4 > documents and the Linux document from Bo. I did not find any problems. > The same code has also been used in many 1.4 releases and works fine there. Did you upload this installer? I think this is the best we can do for now so JMarc, please replace the previous windows installers with this one, and re-allow downloading. Cheers, Bo
Re: [Cvslog] r19269 - /lyx-devel/branches/BRANCH_1_5_X/status.15x
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Am Mittwoch, 1. August 2007 schrieb [EMAIL PROTECTED]: >> forgot that > > Too bad. I just was about to admonish you. I know. The worse is that I spent a lot of time drafting this miserable line of text, so you have had ample time. JMarc
Re: [Cvslog] r19269 - /lyx-devel/branches/BRANCH_1_5_X/status.15x
Am Mittwoch, 1. August 2007 schrieb [EMAIL PROTECTED]: > forgot that Too bad. I just was about to admonish you. Jürgen
Re: [PATCH] Re: Current svn: Crash with pdfsync
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Jean-Marc Lasgouttes wrote: >> José, Jürgen, can I apply to trunk and branch. It is truly trivial. > > OK. Done. JMarc
Re: 1.5.0 "slowness"
On Wed, Aug 01, 2007 at 09:39:03AM +0200, Jean-Marc Lasgouttes wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > >> "The figure float box is roughly the full width of the window, but > >> in fact it is changing a small amount with every keypress. This > >> causes the figures to move because they are in a centred > >> paragraph." > > > > Yes, I have noticed this too over a slow line. If the graphic > > is re-placed, it is re-drawn, pixel by pixel. This is > > unfortunate. Perhaps we should get rid of the centering > > on-screen. > > No, we should make sure that the size of the figure float does not > change. Why does that happen? That is a very good question. If this did not happen, we also wouldn't need the wide() thing. It seems to be because the metric of an inset finds the narrowest width that encloses its content. I don't know precisely where this happens, but it would be so much better if, for insets containing multi-row paragraphs at least, it would take a standard text width instead. I have looked at this and failed. - Martin
w2l parameters (odt->lyx)
hi, i tried to import odt to lyx via w2l (05beta3) convertor and the conversion didnt suceeded because of parameters given by lyx when reconfiguring. this was set by default by lyx w2l -clean $$i when i change it to w2l -clean -latex $$i it starts to import, however i'm not sure whether this is the correct solution because intermediate .tex file remain in the current directory. did the previous parameter worked for you or is this bug ? pavel
Re: Use Computer Algebra System with LyX
> Does this menu entry works? I have tried it but not got it to work. Is there > any plans to develop this feature? i remember some time ago i used it with maxima and it worked for me. pavel
Use Computer Algebra System with LyX
Dear LyX developers, Under the Edit > Math menu in LyX there is an entry Use Computer Algebra System. Does this menu entry works? I have tried it but not got it to work. Is there any plans to develop this feature? Compared with LyX's commercial counterpart Scientific WorkPlace, which is integrated with the CAS software MuPAD, a working CAS is one of the few features missing in LyX. What are your thoughts about this? Ideally, there should be an open source CAS that is integrated and bundled together with LyX just as Scientific WorkPlace and MuPAD are integrated and bundled together, but still could be used independently. One possible candidate for this is the Yacas (http://yacas.sourceforge.net/) CAS, which is written in C++, just as LyX is, and has the same license (GNU GPL) as LyX. There may be other good candidates, but this is the most advanced open source CAS I have found that is written in C++ just as LyX is, which is a great advantage. Best regards, Andreas Karlsson _ Ta en titt på de nya onlinetjänsterna på Windows Live Betas -- så nya att de ännu inte har lanserats officiellt. http://get.live.com/betas
Re: Compress file corrupted
Andre Poenitz wrote: With this patch things seem to work fine. I can open your file and save & open files with compression enabled. I'm uploading 1.5.0-2 installers right now. Please do not distribute new stuff unless this is _thoroughly_ tested. I tested the compression feature on all kinds of documents including 1.4 documents and the Linux document from Bo. I did not find any problems. The same code has also been used in many 1.4 releases and works fine there. Joost
Re: LyX 1.5.0 is released
Jean-Marc Lasgouttes wrote: > > Public release of LyX version 1.5.0 > === > > We are pleased to announce the release of LyX 1.5.0. Congratulations for all. It was great to see all this energy going into LyX lately. Riding my hobby horse, I would say that the qt port brought new platforms, new users and new developers. Cheers, Charles -- http://www.kde-france.org
Re: 1.5.0 "slowness"
Martin Vermeer <[EMAIL PROTECTED]> writes: >> "The figure float box is roughly the full width of the window, but >> in fact it is changing a small amount with every keypress. This >> causes the figures to move because they are in a centred >> paragraph." > > Yes, I have noticed this too over a slow line. If the graphic > is re-placed, it is re-drawn, pixel by pixel. This is > unfortunate. Perhaps we should get rid of the centering > on-screen. No, we should make sure that the size of the figure float does not change. Why does that happen? JMarc
