Re: [LyX/master] Add move constructor and move assignment operator for FileName class
On Tue, Jan 19, 2021 at 11:17:25PM +0200, Yuriy Skalko wrote: > > The next step from my side should be clang installation and debugging > > this patch there. But it can happen not very soon. > > It happened sooner than I expected. I've got Clang 11 from winlibs.com (it > uses libstdc++, unfortunately libc++ is not available here). It compiles LyX > on Windows without any problems and the opening of the recent files doesn't > crash. So the problem is definitely in libc++, as Jean-Marc suspected from > the start. I've tried to reproduce on Linux with Clang and libc++ but cannot. However, one thing that I do not understand is that in the output from ldd, both libstdc++.so.6 and libc++.so.1 show up. See attached. Is this expected? Scott linux-vdso.so.1 (0x7ffd059e5000) libmythes-1.2.so.0 => /lib/x86_64-linux-gnu/libmythes-1.2.so.0 (0x7f990dad1000) libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x7f990d993000) libQt5X11Extras.so.5 => /lib/x86_64-linux-gnu/libQt5X11Extras.so.5 (0x7f990d98c000) libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x7f990d962000) libenchant-2.so.2 => /lib/x86_64-linux-gnu/libenchant-2.so.2 (0x7f990d954000) libmagic.so.1 => /lib/x86_64-linux-gnu/libmagic.so.1 (0x7f990d92c000) libQt5Concurrent.so.5 => /lib/x86_64-linux-gnu/libQt5Concurrent.so.5 (0x7f990d921000) libQt5Svg.so.5 => /lib/x86_64-linux-gnu/libQt5Svg.so.5 (0x7f990d8c5000) libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x7f990d229000) libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x7f990cb71000) libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 (0x7f990c633000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f990c616000) libc++.so.1 => /lib/x86_64-linux-gnu/libc++.so.1 (0x7f990c54e000) libc++abi.so.1 => /lib/x86_64-linux-gnu/libc++abi.so.1 (0x7f990c516000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f990c3c7000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f990c3ac000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f990c1c2000) /lib64/ld-linux-x86-64.so.2 (0x7f990dafb000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f990bfe1000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f990bfd9000) libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x7f990bfd3000) libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x7f990bfcb000) libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x7f990bfc5000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x7f990be93000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f990be6a000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f990be55000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f990be33000) libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x7f990bdab000) libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x7f990bd72000) libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x7f990bc91000) libmd4c.so.0 => /lib/x86_64-linux-gnu/libmd4c.so.0 (0x7f990bc7d000) libdouble-conversion.so.3 => /lib/x86_64-linux-gnu/libdouble-conversion.so.3 (0x7f990bc65000) libicui18n.so.67 => /lib/x86_64-linux-gnu/libicui18n.so.67 (0x7f990b953000) libicuuc.so.67 => /lib/x86_64-linux-gnu/libicuuc.so.67 (0x7f990b767000) libpcre2-16.so.0 => /lib/x86_64-linux-gnu/libpcre2-16.so.0 (0x7f990b6e4000) libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f990b614000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f990b607000) libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x7f990b5fd000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x7f990b5e3000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f990b57) libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x7f990b4b8000) libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x7f990b482000) libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x7f990b3bf000) libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3 (0x7f990b392000) libicudata.so.67 => /lib/x86_64-linux-gnu/libicudata.so.67 (0x7f9909879000) libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x7f990986b000) libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x7f9909846000) signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Feature Request from Doug Martin and Tom Philips
Paul,
Thanks for the question/suggestion.
It turns out that I used to use the chunks option cache = T, which I
understood to result in R code not being run
again unless something is changed in the code. But its behavior seemed to
be somewhat random, so I gave it
up for the book and always use cache = F, which means the code does run
every time. One thing I really like about
this (assuming no long-running Monte Carlos are involved) is that the
Figures in a Figure float update automatically
when I tweak the code to improve the figure.
However, the following with respect to "cache = T" is for what it's
worth. I have been twice bitten by using that
choice, in two different contexts, one while writing another paper.
Suddenly, I my compile would crash with
a message error that it was trying to load an R package that I no longer
use for the paper, but had used in the
not so recent past. And it was because somewhere the cache contained a
load instruction for that package.
The solution was simple - just empty the cache.
Your suggested fix could work, but we are hoping for a more efficient fix
that works like our current
use of kable/kableExtra works. Just change the code some and recompile and
you get the new table.
Doug
On Tue, Jan 19, 2021 at 10:27 AM Paul A. Rubin wrote:
> On 1/19/21 12:03 PM, Doug Martin wrote:
>
> Scott (and all),
>
> I have attached the LYX segment from one of our book chapters, along with
> a page from the compiled pdf file that contains
> the resulting Table TS-2.1.
>
> This tiny example illustrates how we currently make most of our tables
> using the kableExtra package (kable is included in knitr),
> and if we had an R script to produce an LYX Table with the data frame (or
> data.table) as input, we would surely use it.
>
> FYI, in case you want to compile the LYX file, you just need to strip out
> the Springer svmono (book templates) stuff, etc., in the
> LaTeX preamble, install knitr and kableExtra from CRAN, and install the
> optimalPsiRho package with:
>
> devtools::install_github("kjellpk/optimalRhoPsi").
>
> Just before sending this I noticed the several other emails on the topic,
> and will take a look at them.
>
> Thanks,
> Doug
>
> On Mon, Jan 18, 2021 at 11:27 AM Scott Kostyshak wrote:
>
>> On Mon, Jan 18, 2021 at 11:03:49AM -0800, Doug Martin wrote:
>> > On Mon, Jan 18, 2021 at 10:41 AM Scott Kostyshak
>> wrote:
>> >
>> > > On Mon, Jan 18, 2021 at 07:25:42PM +0100, Jean-Marc Lasgouttes wrote:
>> > > > Le 14/01/2021 à 05:34, Doug Martin a écrit :
>> > > > > JMarc and all,
>> > > > >
>> > > > > Tom and I use knitr extensively for R code chunks, and we mostly
>> use
>> > > > > kable with kableExtra to make tables.
>> > > > > The input to kable are R data frames, or data.tables, which are
>> the
>> > > > > result of model fitting and related calculations.
>> > > > > But we like to put mathematical expressions in selected cells of
>> > > tables,
>> > > > > which is so easy with LYX tables, and we currently
>> > > > > have to make the data entry into LYX by hand from data tables and
>> > > > > data.tables in order to make use of that feature.
>> > > > > So it would be great if we could import R data tables and
>> data.tables
>> > > > > into LYX tables, rather than using the kable/kableExtra
>> > > > > solution for our tables (maybe I didn't make that clear in my
>> earlier
>> > > > > email). Then we would probably would drop use of
>> > > > > kable/kableExtra.
>> > > >
>> > > > So you want to import as .tex the result of R processing. This can
>> be
>> > > done
>> > > > via "Paste from LaTeX". What would be missing for your intended
>> usage?
>> > >
>> > > From what I understand, they would like to import a .Rds file without
>> > > having to manually convert it to LaTeX.
>> > >
>> >
>> > Scott,
>> >
>> > Definitely correct on the "without" part. But we want to directly
>> import
>> > an R object
>> > of class data.frame or data.table into an LYX table.
>> >
>> > If we have to export such an object first, we would typically export it
>> to
>> > an .Rda object.
>> > But it would be far more convenient to not have to do that.
>>
>> Thanks for the clarification, Doug. It might help us to have a complete,
>> simple, example to play with. Can you give us the .lyx file and R
>> code/file? To make things perfectly clear to us, it might help to give
>> us a "before" version of the .lyx file and an "after" version of the
>> .lyx file. To create the "after" version you would have to do the steps
>> manually, but by seeing it we could make sure we understand what you
>> want to automate and what you expect the result to be.
>>
>> Thanks for your patience,
>>
>> Scott
>>
>
>
> --
> R. Douglas Martin
> Professor Emeritus in Applied Mathematics and Statistics
> Founder and Former Director of MS-CFRM Program
> depts.washington.edu/compfin/
> University of Washington
>
> Doug,
>
> If I am understanding your example correctly, you actually redo the R
> calculations each time you
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
The next step from my side should be clang installation and debugging this patch there. But it can happen not very soon. It happened sooner than I expected. I've got Clang 11 from winlibs.com (it uses libstdc++, unfortunately libc++ is not available here). It compiles LyX on Windows without any problems and the opening of the recent files doesn't crash. So the problem is definitely in libc++, as Jean-Marc suspected from the start. Yuriy -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compile LyX on Apple Silicon / arm64
Hi Stephan, looking around for a way to create universal binaries for arm64/x86_64 outside of XCode I've stumbled onto this project here: https://github.com/tpoechtrager/osxcross If it works the way the Readme makes it sound, it should be fairly simple to create a universal binary in the existing LyX build environment. I'll try to find some time to play around with it a little over the next few days! I only had to make the tiniest change in LyX-Mac-binary-release.sh to get it to run on Big Sur (macos SDK version 10.x vs. 11.x). I attached a patch for it. Best regards, Marcus On Sun, Jan 17, 2021 at 10:50 PM Stephan Witt wrote: > Hi Marcus, > > thank you for your message and the good news. > > I’d be very glad to see your changes to the build script for Mac. > > My plan regarding LyX for ARM CPU is to create a universal binary with > Intel and ARM architecture. In the past we did this with PowerPC and Intel. > I’d guess one can do this with the current Xcode and (cross) compile Qt and > LyX (plus all helper frameworks we’re using) on one system architecture for > both target systems. > > I’m not sure how difficult this is - but it should be doable. > > Best regards, > Stephan > > > Am 17.01.2021 um 21:36 schrieb Marcus Mikulcak < > marcus.mikul...@gmail.com>: > > > > Hi everybody, > > > > a few days ago I posted this message on lyx-users but was told that this > list might be the better place for it. Here goes: > > > > a few months ago (November, I think?) somebody raised the question of > LyX on Apple Silicon, how and whether it would run. As I've been using a > LyX version that I've compiled from source (with a feature included by > Jürgen Spitzmüller that's so far only in master - thanks again!), I was > anxious to find out whether LyX would compile for arm64. Long story short: > It does! > > > > I had to fiddle with the Mac development release script a bit to get it > to run on Big Sur, but no major problems there either. > > > > If I can be of any help in testing or during the release process, just > let me know! I'd be very happy to help. > > > > The last sentence stands: If I can be of any help in testing LyX on > Apple Silicon or even in preparing a universal binary for release or > anything like that, just me know! > > > > Best regards, > > Marcus > > > > -- > > lyx-devel mailing list > > lyx-devel@lists.lyx.org > > http://lists.lyx.org/mailman/listinfo/lyx-devel > > sdk_version.patch Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Feature Request from Doug Martin and Tom Philips
On 1/19/21 12:03 PM, Doug Martin wrote:
Scott (and all),
I have attached the LYX segment from one of our book chapters, along
with a page from the compiled pdf file that contains
the resulting Table TS-2.1.
This tiny example illustrates how we currently make most of our tables
using the kableExtra package (kable is included in knitr),
and if we had an R script to produce an LYX Table with the data frame
(or data.table) as input, we would surely use it.
FYI, in case you want to compile the LYX file, you just need to strip
out the Springer svmono (book templates) stuff, etc., in the
LaTeX preamble, install knitr and kableExtra from CRAN, and install
the optimalPsiRho package with:
devtools::install_github("kjellpk/optimalRhoPsi").
Just before sending this I noticed the several other emails on the
topic, and will take a look at them.
Thanks,
Doug
On Mon, Jan 18, 2021 at 11:27 AM Scott Kostyshak > wrote:
On Mon, Jan 18, 2021 at 11:03:49AM -0800, Doug Martin wrote:
> On Mon, Jan 18, 2021 at 10:41 AM Scott Kostyshak
mailto:skost...@lyx.org>> wrote:
>
> > On Mon, Jan 18, 2021 at 07:25:42PM +0100, Jean-Marc Lasgouttes
wrote:
> > > Le 14/01/2021 à 05:34, Doug Martin a écrit :
> > > > JMarc and all,
> > > >
> > > > Tom and I use knitr extensively for R code chunks, and we
mostly use
> > > > kable with kableExtra to make tables.
> > > > The input to kable are R data frames, or data.tables,
which are the
> > > > result of model fitting and related calculations.
> > > > But we like to put mathematical expressions in selected
cells of
> > tables,
> > > > which is so easy with LYX tables, and we currently
> > > > have to make the data entry into LYX by hand from data
tables and
> > > > data.tables in order to make use of that feature.
> > > > So it would be great if we could import R data tables and
data.tables
> > > > into LYX tables, rather than using the kable/kableExtra
> > > > solution for our tables (maybe I didn't make that clear
in my earlier
> > > > email). Then we would probably would drop use of
> > > > kable/kableExtra.
> > >
> > > So you want to import as .tex the result of R processing.
This can be
> > done
> > > via "Paste from LaTeX". What would be missing for your
intended usage?
> >
> > From what I understand, they would like to import a .Rds file
without
> > having to manually convert it to LaTeX.
> >
>
> Scott,
>
> Definitely correct on the "without" part. But we want to
directly import
> an R object
> of class data.frame or data.table into an LYX table.
>
> If we have to export such an object first, we would typically
export it to
> an .Rda object.
> But it would be far more convenient to not have to do that.
Thanks for the clarification, Doug. It might help us to have a
complete,
simple, example to play with. Can you give us the .lyx file and R
code/file? To make things perfectly clear to us, it might help to give
us a "before" version of the .lyx file and an "after" version of the
.lyx file. To create the "after" version you would have to do the
steps
manually, but by seeing it we could make sure we understand what you
want to automate and what you expect the result to be.
Thanks for your patience,
Scott
--
R. Douglas Martin
Professor Emeritus in Applied Mathematics and Statistics
Founder and Former Director of MS-CFRM Program
depts.washington.edu/compfin/
Home page: https://rubin.msu.domains/
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Feature Request from Doug Martin and Tom Philips
RiKi,
that is fortunately very easy to do on the Mac and Linux with the bang
and Rscript:
#!/usr/bin/env Rscript --vanilla
local({
r <- getOption("repos")
r["CRAN"] <- "https://cloud.r-project.org/;
options(repos = r)
})
update.packages()
I have no idea whether Rscript even exists on Windows and if so, how to
call it.
greetings, el
On 19/01/2021 00:12, Richard Kimberly Heck wrote:
[...]
> Presumably one could script the R session itself so that the needed
> object was exported? I.e., can one do that from the command line?
> That's the kind of thing that an external template would do.
[...]
--
To email me replace 'nospam' with 'el'
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
