Re: timeout when using the Sweave module
Jean-Marc Lasgouttes lyx.org> writes: > > It is probably doable to set the timeout value per converter. This would > be the best solution IMO. I can be convinced that setting the timeout value on a chunk-by-chunk basis is excessive, but per converter is too coarse. Maybe per document?
Re: timeout when using the Sweave module
Le 01/02/12 22:18, Yihui Xie a écrit : Hi, I guess LyX should give the literate programming modules (e.g. Sweave/knitr) more time to run their code. Currently I see the time allowed is about 3 minutes, and LyX will raise an error after that. I tested it with the following chunk in Sweave: It is probably doable to set the timeout value per converter. This would be the best solution IMO. JMarc
Re: timeout when using the Sweave module
Yihui Xie yihui.name> writes: > > The time-out restriction is from LyX, so Sweave/knitr cannot do > anything about it. You're right; what I meant to say was that I'd want to tell LyX to allow longer Sweave/knitr runs for particular chunks.
Re: timeout when using the Sweave module
The time-out restriction is from LyX, so Sweave/knitr cannot do anything about it. My current workaround is to export Rnw from LyX, run knitr on it with cache turned on, and run LyX again since the time-consuming chunks have been calculated and cached. Regards, Yihui -- Yihui Xie Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Thu, Feb 2, 2012 at 3:16 PM, Jack Tanner wrote: > Liviu Andronic gmail.com> writes: > >> >> Can the 'timeout' be configured? Or is it possible to treat >> Sweave/knitr documents differently? Regards > > One Sweave/knitr computation is different from another. I'd expect 1+1 to be > computed quickly, but I also have some simulations that take hours, and I'd > love > to use knitr to include those results in a LyX document. I'd vote for a global > LyX setting that Sweave/knitr has a longer time-out by default, and a knitr > option that allows different time-outs per chunk. >
Re: timeout when using the Sweave module
Liviu Andronic gmail.com> writes: > > Can the 'timeout' be configured? Or is it possible to treat > Sweave/knitr documents differently? Regards One Sweave/knitr computation is different from another. I'd expect 1+1 to be computed quickly, but I also have some simulations that take hours, and I'd love to use knitr to include those results in a LyX document. I'd vote for a global LyX setting that Sweave/knitr has a longer time-out by default, and a knitr option that allows different time-outs per chunk.
Re: r40700 - lyx-devel/trunk/src/mathed
On 02/02/2012 08:39 AM, lasgout...@lyx.org wrote:
Author: lasgouttes
Date: Thu Feb 2 14:39:05 2012
New Revision: 40700
URL: http://www.lyx.org/trac/changeset/40700
Log:
* InsetMathScript::doDispatch : properly record undo information before
changing limits status (fixes bug #8007)
* InsetMathScript::getStatus (new) : handle properly status for
LFUN_MATH_LIMITS here, along with checkmark support for the menu)
Looks fine for branch, I'd say. If you feel comfortable with it, please
go ahead.
Richard
Modified:
lyx-devel/trunk/src/mathed/InsetMathNest.cpp
lyx-devel/trunk/src/mathed/InsetMathScript.cpp
lyx-devel/trunk/src/mathed/InsetMathScript.h
Modified: lyx-devel/trunk/src/mathed/InsetMathNest.cpp
==
--- lyx-devel/trunk/src/mathed/InsetMathNest.cppThu Feb 2 01:25:13
2012(r40699)
+++ lyx-devel/trunk/src/mathed/InsetMathNest.cppThu Feb 2 14:39:05
2012(r40700)
@@ -1368,7 +1368,6 @@
// we just need to be in math mode to enable that
case LFUN_MATH_SIZE:
case LFUN_MATH_SPACE:
- case LFUN_MATH_LIMITS:
case LFUN_MATH_EXTERN:
flag.setEnabled(true);
break;
Modified: lyx-devel/trunk/src/mathed/InsetMathScript.cpp
==
--- lyx-devel/trunk/src/mathed/InsetMathScript.cpp Thu Feb 2 01:25:13
2012(r40699)
+++ lyx-devel/trunk/src/mathed/InsetMathScript.cpp Thu Feb 2 14:39:05
2012(r40700)
@@ -14,6 +14,7 @@
#include "Cursor.h"
#include "DispatchResult.h"
#include "FuncRequest.h"
+#include "FuncStatus.h"
#include "InsetMathFont.h"
#include "InsetMathScript.h"
#include "InsetMathSymbol.h"
@@ -754,6 +755,7 @@
//LYXERR("InsetMathScript: request: "<< cmd);
if (cmd.action() == LFUN_MATH_LIMITS) {
+ cur.recordUndoInset();
if (!cmd.argument().empty()) {
if (cmd.argument() == "limits")
limits_ = 1;
@@ -772,6 +774,26 @@
}
+bool InsetMathScript::getStatus(Cursor& cur, FuncRequest const& cmd,
+ FuncStatus& flag) const
+{
+ if (cmd.action() == LFUN_MATH_LIMITS) {
+ if (!cmd.argument().empty()) {
+ if (cmd.argument() == "limits")
+ flag.setOnOff(limits_ == 1);
+ else if (cmd.argument() == "nolimits")
+ flag.setOnOff(limits_ == -1);
+ else
+ flag.setOnOff(limits_ == 0);
+ }
+ flag.setEnabled(true);
+ return true;
+ }
+
+ return InsetMathNest::getStatus(cur, cmd, flag);
+}
+
+
// the idea for dual scripts came from the eLyXer code
void InsetMathScript::validate(LaTeXFeatures& features) const
{
Modified: lyx-devel/trunk/src/mathed/InsetMathScript.h
==
--- lyx-devel/trunk/src/mathed/InsetMathScript.hThu Feb 2 01:25:13
2012(r40699)
+++ lyx-devel/trunk/src/mathed/InsetMathScript.hThu Feb 2 14:39:05
2012(r40700)
@@ -110,6 +110,9 @@
void validate(LaTeXFeatures&features) const;
protected:
virtual void doDispatch(Cursor& cur, FuncRequest& cmd);
+ /// do we want to handle this event?
+ bool getStatus(Cursor& cur, FuncRequest const& cmd,
+ FuncStatus& status) const;
private:
virtual Inset * clone() const;
/// returns x offset for main part
Re: timeout when using the Sweave module
On Wed, Feb 1, 2012 at 10:18 PM, Yihui Xie wrote: > I guess LyX should give the literate programming modules (e.g. > Sweave/knitr) more time to run their code. Currently I see the time > allowed is about 3 minutes, and LyX will raise an error after that. I > I've been bitten by this in the past, and it's not pretty: Sweave computations can take much longer than 3min, and this error makes LyX less useful. Can the 'timeout' be configured? Or is it possible to treat Sweave/knitr documents differently? Regards Liviu
Re: Import into LyX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/02/12 19:27, Liviu Andronic wrote: > On Thu, Feb 2, 2012 at 6:50 PM, Rob Oakes > wrote: >> very nice. Hearing your opinions about doc support (versus only >> docx support) would also be very helpful. >> > If .docx-only support simplifies your task and helps ensure that > your tool would support a good deal of functionality, then I'm all > for it. Support for .doc can be worked around, not least by > resaving the document in LibreOffice. +1 Rainer > > Liviu - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8q23YACgkQoYgNqgF2egoqZgCeODGYVqc4jZaEvQUMyvnaVNXX 8awAnRjij2X9+qCDqatbz7BiAxYcukh0 =HXNt -END PGP SIGNATURE-
Re: Import into LyX
On Thu, Feb 2, 2012 at 12:27 PM, Liviu Andronic wrote: > On Thu, Feb 2, 2012 at 6:50 PM, Rob Oakes wrote: >> very nice. Hearing your opinions about doc support (versus only docx >> support) would also be very helpful. >> > If .docx-only support simplifies your task and helps ensure that your > tool would support a good deal of functionality, then I'm all for it. > Support for .doc can be worked around, not least by resaving the > document in LibreOffice. > Absolutely. Go for docx. Converting between .doc and .docx is relatively painless. Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
Re: Import into LyX
On Thu, Feb 2, 2012 at 6:50 PM, Rob Oakes wrote: > very nice. Hearing your opinions about doc support (versus only docx > support) would also be very helpful. > If .docx-only support simplifies your task and helps ensure that your tool would support a good deal of functionality, then I'm all for it. Support for .doc can be worked around, not least by resaving the document in LibreOffice. Liviu
Re: Import into LyX
Thank you everyone for the comments so far. I really appreciate hearing from others as it helps me to build out a more detailed use-case. In addition to the earlier questions, I have one more: How important is support of .doc? I know that it is the standard upon which the publishing industry is built, but … It's a real pain to parse. In contrast, docx (the default file format in Word 2007 and 2010) is very parse. It's basically an XML document in a zipped folder with assets. I've already got a working prototype that can take a very simple LyX document and converts it to docx. Here's what supported: 1.) Syles 2.) Images/Figures Expanding this prototype is pretty easy. Trying to support doc is hard (painfully hard). There are pretty good import filters for OpenOffice and AbiWord for docx. docx is supported in Microsoft Word 2007 and 2010, and users of 2003 can download a plugin which is capable of reading it. If I go ahead with support for docx, I think I can write a full featured import/export plugin, including: 1.) Bibliographies using Word's native format and (maybe) Endnote (I've found a python library that can parse BibTeX and building export for these two formats is do-able) 2.) Cross-references (I still need to figure out how this is done in Word, but so-far, the docx standard is pretty easy to follow) 3.) Comments and Change Tracking How to deal with maths is still up in the air. LyX offers the ability to typeset nearly anything mathematical, which means there's a very large set of markup to support. Exporting to MathML might be one option, but that would require Word users to install a plugin. Exporting to Office Math Language (the new math language in Office 2007 and 2010) is another, but proprietary. Exporting to MathType is a third, which is both proprietary and requires that users install an add-in (which they have to pay for). I'm not particularly thrilled about any of the above. I'll continue to research and report what I find. In the meantime, hearing about what features should be supported would be very nice. Hearing your opinions about doc support (versus only docx support) would also be very helpful. Cheers, Rob
Re: Import into LyX
On 02/02/2012 11:37 AM, Rob Oakes wrote: I'm currently researching solutions for Math and I may have found one using MathML. We currently support MathML creation inside of LyX, do we have a way to import MathML? If so, how is that done? Is a native library or something that we handle with Python? So far as I know, we don't have any way to import MathML. Richard
Re: Import into LyX
Hello Rob To echo others, it's great that you'd like to work on this. On Wed, Feb 1, 2012 at 8:59 PM, Rob Oakes wrote: > What features would you consider essential? > > (Right now, styles based conversion looks pretty easy -- going from Heading > 1 in Word to Chapter, for example. But I'm not sure how well it would > convert maths. This is something I'll still need to look at, and may require > writing an additional module.) > Reasonably fussless import of .doc in LyX, and reasonably fussless export from LyX to .doc. > Does the script need to support special cases, such as importing Word "track > changes"? > Although I do appreciate others' arguments for having this, I would believe that it's more of a perk. If your tool can simply translate from Word to LyX, and vice-versa (I'm not talking of 'round-trip'), the it would already be a great achievement. Accepting track changes can be done in Word (and LibreOffice, I assume). > Just how important do you consider "round-tripping" a document, e.g., going > from LyX to Word and back to LyX. > I'm afraid this is more like chasing a wild goose. If LyX has a hard time to round-trip to LaTeX, as it currently is more or less, then I'm sceptical that round-trips to Word can be more reliable. It would be great, however, to be able to reasonably import .doc in LyX, and reasonably export from LyX to .doc. Reliable round-tripping should be more of a secondary goal. Regards Liviu
Re: Import into LyX
On Feb 2, 2012, at 8:55 AM, Richard Heck wrote: > On 02/01/2012 03:11 PM, Xu Wang wrote: >> Hey Rob, that sounds like quite a nice project you have in mind! >> >> My two cents: it's not worth carrying it out if you can't get the math to >> import somewhat well. That seems to be the biggest problem with most ways of >> converting doc to lyx. I understand it's very difficult, but I think it's >> also the most important. >> > As far as I remember, the main complaint about writer2latex has been that it > produces ugly LaTeX. In the latest versions of LibreOffice, however, there is > an option to export "Ultra-clean" LaTeX, which works pretty well. Of course, > this relies upon Libre's importing Word's math well. So for math heavy > documents, that seems a good way to go at the moment. That tracks with my experience, as well. You can set it for Ultra-clean, but even that has a lot of miscellaneous stuff that isn't really necessary and complicates import/export. I'm currently researching solutions for Math and I may have found one using MathML. We currently support MathML creation inside of LyX, do we have a way to import MathML? If so, how is that done? Is a native library or something that we handle with Python? Cheers, Rob
Re: Sweave manual pdf compilation fails
Le 01/02/2012 20:16, Yihui Xie a écrit : The patch is pretty simple: http://www.lyx.org/trac/ticket/8019 I removed Sweave.sty from texmf-local, so that LyX cannot find it that way, applied the patch, and the Sweave manual compiles now fine from the Help menu. No failure because of write permission needed to access the LyX tree, nor because Sweave.sty is not found in /usr/share/R/texmf/ -- Jean-Pierre
Re: Import into LyX
On 02/01/2012 03:11 PM, Xu Wang wrote: Hey Rob, that sounds like quite a nice project you have in mind! My two cents: it's not worth carrying it out if you can't get the math to import somewhat well. That seems to be the biggest problem with most ways of converting doc to lyx. I understand it's very difficult, but I think it's also the most important. As far as I remember, the main complaint about writer2latex has been that it produces ugly LaTeX. In the latest versions of LibreOffice, however, there is an option to export "Ultra-clean" LaTeX, which works pretty well. Of course, this relies upon Libre's importing Word's math well. So for math heavy documents, that seems a good way to go at the moment. Richard
Re: Sweave manual pdf compilation fails
On 02/01/2012 05:47 PM, Yihui Xie wrote: I'm pretty confident with this one. It does not have specific requirements on R versions, and users do not have to upgrade R. If you and JMarc agree, it can go into 2.0.3. I know nothing about this stuff. Richard Regards, Yihui -- Yihui Xie Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Wed, Feb 1, 2012 at 4:29 PM, Jean-Marc Lasgouttes wrote: Le 01/02/12 20:16, Yihui Xie a écrit : The patch is pretty simple: http://www.lyx.org/trac/ticket/8019 It looks like a reasnable thing to do, if it does what I think it does. How confident are you with this patch? Does it rely only on documented behaviour, assumed to be present in earlier R versions? We do not want to force people to upgrade to latest R. JMarc
