> By the way, when you are already digging into the internal workings of
> preview loader, would it be hard to allow mutliple threads loading
> graphics images in backgrounds instead of single one?
> Documents with lot of figures take a long time to load fully and most
> of nowadays machines have
On Sat, Dec 12, 2020 at 07:05:38PM +0200, Yuriy Skalko wrote:
> > By the way, when you are already digging into the internal workings of
> > preview loader, would it be hard to allow mutliple threads loading
> > graphics images in backgrounds instead of single one?
> > Documents with lot of
On Mon, Dec 28, 2020 at 07:21:59PM +0100, Jean-Marc Lasgouttes wrote:
> >BTW after all the boost related changes, what are the dependencies needed
> >for people using external boost?
> >E.g. current 2.3.x debian build dependencies are libboost-filesystem-dev,
> >libboost-iostreams-dev,
Le 27 décembre 2020 22:44:28 GMT+01:00, Pavel Sanda a écrit :
>On Sat, Dec 19, 2020 at 11:08:40PM +0200, Yuriy Skalko wrote:
>> Yes, boost's `assert` is not encapsulated, but `crc` and `any` are.
>>
>> I've moved all into `lyx` namespace. Really separate namespace for only 3
>> names is not
On Sat, Dec 19, 2020 at 11:08:40PM +0200, Yuriy Skalko wrote:
> Yes, boost's `assert` is not encapsulated, but `crc` and `any` are.
>
> I've moved all into `lyx` namespace. Really separate namespace for only 3
> names is not needed.
BTW after all the boost related changes, what are the
Boost is not, the others in 3rdparty are not encapsulated but used only in a
few place.
If you want to keep a header file, the best is probably to put everything in
namespace lyx.
JMarc
Yes, boost's `assert` is not encapsulated, but `crc` and `any` are.
I've moved all into `lyx`
Le 19/12/2020 à 20:05, Yuriy Skalko a écrit :
Since support/signals.h is pretty empty now, why not just use
nod/signal.h and nod::signal? Then we can get rid of the header file.
Patches 2 and 4 are fine.
JMarc
I think that it is better to leave such interfacing header to limit this
Since support/signals.h is pretty empty now, why not just use nod/signal.h and
nod::signal? Then we can get rid of the header file.
Patches 2 and 4 are fine.
JMarc
I think that it is better to leave such interfacing header to limit this
3rd-party dependency in one point (this already
Le 16/12/2020 à 20:37, Yuriy Skalko a écrit :
Great! It is now only 1.5 MB!
Using "signals" conflicts with Qt keyword, so I've used "signal". Also
moved now unneeded for signals class Trackable to the only place where
it is used.
Since support/signals.h is pretty empty now, why not just use
Am Sat, 19 Dec 2020 15:52:44 +0200
schrieb Yuriy Skalko :
> >> Just to be sure: Yuriy do you plan to get rid of this signals2
> >> namespace? It
> >> doe snot make much sense.
> >>
> >>
> >> JMarc
> >>
> >
> >
> > Using "signals" conflicts with Qt keyword, so I've used
Just to be sure: Yuriy do you plan to get rid of this signals2 namespace? It
doe snot make much sense.
JMarc
Using "signals" conflicts with Qt keyword, so I've used "signal". Also moved
now unneeded for signals class Trackable to the only place where it is used.
Yuriy
Hi I like the patch too. And boost is a lot thinner now :)
Just to be sure: Yuriy do you plan to get rid of this signals2 namespace? It
doe snot make much sense.
JMarc
Great! It is now only 1.5 MB!
Using "signals" conflicts with Qt keyword, so I've used "signal". Also
moved now unneeded
That's unreal ;)
I meant that we were trying to commit the same change at the same time ;)
--
Enrico
I understood ;) That was a reference to Musk's reaction to incredible event:
https://www.youtube.com/watch?v=BL4dnvBytLA
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
Le 13/12/2020 à 18:20, Enrico Forestieri a écrit :
On Sun, Dec 13, 2020 at 04:23:56PM +0200, Yuriy Skalko wrote:
So, is this patch ready to be committed into master to have wider testing
audience?
Please, note that your patch is incomplete for autotools. Attached you
can find a complementary
On Mon, Dec 14, 2020 at 01:20:31AM +0200, Yuriy Skalko wrote:
> > We collided on the fly ;)
> >
> > --
> > Enrico
>
>
> That's unreal ;)
I meant that we were trying to commit the same change at the same time ;)
--
Enrico
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
We collided on the fly ;)
--
Enrico
That's unreal ;)
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Sunday, December 13, 2020 11:03:40 PM WET Enrico Forestieri wrote:
> > Should work now. Seems like autotools don't like Unicode BOM that my
> > editor
> > silently inserted into the file.
>
> We collided on the fly
Thank you both. I can confirm that LyX is compiling fine now. :-)
--
José
On Mon, Dec 14, 2020 at 12:56:30AM +0200, Yuriy Skalko wrote:
> > No problem, I use it and I am not sure what is going on. :-D
> > --
> > José Abílio
>
> Should work now. Seems like autotools don't like Unicode BOM that my editor
> silently inserted into the file.
We collided on the fly ;)
--
On Sun, Dec 13, 2020 at 10:24:12PM +, José Abílio Matos wrote:
> On Sunday, December 13, 2020 10:06:01 PM WET Yuriy Skalko wrote:
> > Sorry José, I'm not sure what goes wrong with autotools since I'm not
> > using it. Hope Jean-Marc (or maybe Enrico) will be able to look at this.
>
> No
No problem, I use it and I am not sure what is going on. :-D
--
José Abílio
Should work now. Seems like autotools don't like Unicode BOM that my
editor silently inserted into the file.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Sunday, December 13, 2020 10:06:01 PM WET Yuriy Skalko wrote:
> Sorry José, I'm not sure what goes wrong with autotools since I'm not
> using it. Hope Jean-Marc (or maybe Enrico) will be able to look at this.
No problem, I use it and I am not sure what is going on. :-D
--
José Abílio--
Using autotools I get this:
$ make
Sorry José, I'm not sure what goes wrong with autotools since I'm not
using it. Hope Jean-Marc (or maybe Enrico) will be able to look at this.
Yuriy, sorry for not being very responsive on this subject. I may not be able
to look at that
On Sunday, December 13, 2020 9:43:59 PM WET Jean-Marc Lasgouttes wrote:
> Yuriy, sorry for not being very responsive on this subject. I may not be
> able to look at that tomorrow, but otherwise everything will be sorted
> out on tuesday.
>
> JMarc
FWIW I am in no hurry.
I just wanted to test
Le 13/12/2020 à 22:24, José Abílio Matos a écrit :
On Sunday, December 13, 2020 9:15:02 PM WET Yuriy Skalko wrote:
> OK. Now it is in master.
>
> Yuriy
Using autotools I get this:
$ make
Yuriy, sorry for not being very responsive on this subject. I may not be
able to look at that
On Sunday, December 13, 2020 9:15:02 PM WET Yuriy Skalko wrote:
> OK. Now it is in master.
>
> Yuriy
Using autotools I get this:
$ make
...
Making all in 3rdparty
make[2]: Entering directory '/home/jamatos/tmp/build/lyx/3rdparty'
Making all in nod
make[3]: Entering directory
I think you can go ahead.
Riki
OK. Now it is in master.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 12/13/20 1:27 PM, Yuriy Skalko wrote:
>> Please, note that your patch is incomplete for autotools. Attached you
>> can find a complementary patch that allows configuration and compilation
>> with autotools.
>>
>> The hunks for 3rdparty/Makefile.am and 3rdparty/nod/Makefile.am should
>> replace
Please, note that your patch is incomplete for autotools. Attached you
can find a complementary patch that allows configuration and compilation
with autotools.
The hunks for 3rdparty/Makefile.am and 3rdparty/nod/Makefile.am should
replace yours, while all other hunks are to be added to your
On Sun, Dec 13, 2020 at 04:23:56PM +0200, Yuriy Skalko wrote:
>
> So, is this patch ready to be committed into master to have wider testing
> audience?
Please, note that your patch is incomplete for autotools. Attached you
can find a complementary patch that allows configuration and compilation
Thanks, Kornel. Signals are also used in generating instant previews,
loading images and converting image formats, monitoring external file
changes. So at first enable generating instant previews, >
I have it regularly enabled ...
then open some
LyX document with many formulas and images in
Am Sun, 13 Dec 2020 13:57:23 +0200
schrieb Yuriy Skalko :
> > Compiles fine, and the export tests results are same as before. I am not
> > sure
> > 'signal' is
> > involved though.
> > Could you evaluate what else should be tested?
> >
> > Impressing work (not only here).
> >
> >
Compiles fine, and the export tests results are same as before. I am not sure
'signal' is
involved though.
Could you evaluate what else should be tested?
Impressing work (not only here).
Kornel
Thanks, Kornel. Signals are also used in generating instant previews,
loading images and
Am Sun, 13 Dec 2020 10:32:38 +0200
schrieb Yuriy Skalko :
> > Compiles fine adding
> > #include
> > in src/support/ForkedCalls.cpp
> > and
> > #include
> > in src/Sever.cpp
> >
> > Kornel
>
>
> Kornel, thanks for trying and fixing the patch!
>
> Seems like these
Compiles fine adding
#include
in src/support/ForkedCalls.cpp
and
#include
in src/Sever.cpp
Kornel
Kornel, thanks for trying and fixing the patch!
Seems like these headers were indirectly included via boost/signal.hpp
-- I've already had to add includes. I've moved
Am Sat, 12 Dec 2020 22:25:59 +0100
schrieb Kornel Benko :
> Am Sat, 12 Dec 2020 22:17:48 +0100
> schrieb Kornel Benko :
>
> > Am Sat, 12 Dec 2020 20:49:55 +
> > schrieb José Abílio Matos :
> >
Compiles fine adding
#include
in src/support/ForkedCalls.cpp
and
#include
in
Am Sat, 12 Dec 2020 22:17:48 +0100
schrieb Kornel Benko :
> Am Sat, 12 Dec 2020 20:49:55 +
> schrieb José Abílio Matos :
>
> > On Saturday, December 12, 2020 8:30:41 PM WET Kornel Benko wrote:
> > > This one is declared in "string.h" (so not c++?)
> > >
> > > Kornel
> >
> >
Am Sat, 12 Dec 2020 20:49:55 +
schrieb José Abílio Matos :
> On Saturday, December 12, 2020 8:30:41 PM WET Kornel Benko wrote:
> > This one is declared in "string.h" (so not c++?)
> >
> > Kornel
>
> #include "cstring"
>
> is the more C++-ish way to include it.
>
>
> The first
On Saturday, December 12, 2020 8:30:41 PM WET Kornel Benko wrote:
> This one is declared in "string.h" (so not c++?)
>
> Kornel
#include "cstring"
is the more C++-ish way to include it.
The first lines in gcc 10, the version I have here, corresponding file are
quite instructive:
Am Sat, 12 Dec 2020 19:05:16 +0200
schrieb Yuriy Skalko :
> >> To be frank I am not competent to review this.
> >>
> >> The code in the nod library seems well written and commented. It has
> >> not be touched for 2 years, but it is maybe because it does not need
> >> to. This code should be
By the way, when you are already digging into the internal workings of
preview loader, would it be hard to allow mutliple threads loading
graphics images in backgrounds instead of single one?
Documents with lot of figures take a long time to load fully and most
of nowadays machines have multiples
To be frank I am not competent to review this.
The code in the nod library seems well written and commented. It has
not be touched for 2 years, but it is maybe because it does not need
to. This code should be maintainable at worst.
The fact that Yuriy has researched all the possible
On 12/11/20 4:41 PM, José Abílio Matos wrote:
On Friday, December 11, 2020 8:14:59 PM WET Richard Kimberly Heck wrote:
> I'm not really competent, either. But if there were going to be
> problems, I think we would see them fairly quickly. Maybe it would be a
> good time, after this were
On Fri, Dec 11, 2020 at 04:26:05PM -0500, Richard Kimberly Heck wrote:
> That's a great idea. If we were able to do this, then it would probably be a
> good idea to have a preference setting for how many simultaneous loads to
> attempt. We don't want to overwhelm the CPU.
I think we could just
On Friday, December 11, 2020 8:14:59 PM WET Richard Kimberly Heck wrote:
> I'm not really competent, either. But if there were going to be
> problems, I think we would see them fairly quickly. Maybe it would be a
> good time, after this were committed, to do another alpha-ish release.
>
> Riki
On 12/11/20 3:34 PM, Pavel Sanda wrote:
On Fri, Dec 11, 2020 at 04:29:13PM +0200, Yuriy Skalko wrote:
The only issue left is concerning tracker_/trackable_ members of
Trackable class used in call to track_foreign. As I understand it is
some hack to have lifetime of slots be the same as of
On Fri, Dec 11, 2020 at 04:29:13PM +0200, Yuriy Skalko wrote:
> > The only issue left is concerning tracker_/trackable_ members of
> > Trackable class used in call to track_foreign. As I understand it is
> > some hack to have lifetime of slots be the same as of containing class
> >
On 12/11/20 1:10 PM, Jean-Marc Lasgouttes wrote:
> Le 11/12/2020 à 15:29, Yuriy Skalko a écrit :
>>> The only issue left is concerning tracker_/trackable_ members of
>>> Trackable class used in call to track_foreign. As I understand it is
>>> some hack to have lifetime of slots be the same as of
Le 11/12/2020 à 15:29, Yuriy Skalko a écrit :
The only issue left is concerning tracker_/trackable_ members of
Trackable class used in call to track_foreign. As I understand it is
some hack to have lifetime of slots be the same as of containing class
(PreviewLoader::Impl/Converter::Impl). Is
The only issue left is concerning tracker_/trackable_ members of Trackable class used in call to track_foreign. As I understand it is some hack to have lifetime of slots be the same as of containing class (PreviewLoader::Impl/Converter::Impl). Is it right?
I've resolved this issue. Looking at
I have been meaning to ask: how did you find this library? Is it somewhat
known, or did you just google for it?
What I am wondering is whether this library has many users. It has not been
updated for 2 years.
THere is some maybe interesting reading here:
Le 10/12/2020 à 21:53, Yuriy Skalko a écrit :
The compact signal library looks great, but I do not know how
polished, portable and widely used it is.
I'm trying to adapt the nod library (https://github.com/fr00b0/nod)
instead of boost::signals2. The only issue left is concerning
The compact signal library looks great, but I do not know how polished,
portable and widely used it is.
I'm trying to adapt the nod library (https://github.com/fr00b0/nod)
instead of boost::signals2. The only issue left is concerning
tracker_/trackable_ members of Trackable class used in
Le 10/12/2020 à 19:56, Richard Kimberly Heck a écrit :
On 12/10/20 1:33 PM, Yuriy Skalko wrote:
The is not much to gain with is IMO, until we are ready to ditch
boost. Note that, with all it problems, boost is highly portable and
used by many people. So there is value in just using it and
On 12/10/20 1:33 PM, Yuriy Skalko wrote:
The is not much to gain with is IMO, until we are ready to ditch
boost. Note that, with all it problems, boost is highly portable and
used by many people. So there is value in just using it and forget
about possible problems.
Yes, that was my plan ;)
The is not much to gain with is IMO, until we are ready to ditch boost. Note
that, with all it problems, boost is highly portable and used by many people.
So there is value in just using it and forget about possible problems.
Yes, that was my plan ;) Now, with C++11 features, Boost is not so
Le 10/12/2020 à 14:02, Yuriy Skalko a écrit :
And instead of `boost::any` we can use smaller C++11-compatible
implementation for older compilers (this is a patch for testing, I'm not
sure what will be the right place in 3rdparty to put the header).
The is not much to gain with is IMO, until
Le 10/12/2020 à 14:49, Yuriy Skalko a écrit :
Here is more recent page:
https://www.boost.org/doc/libs/1_74_0/doc/html/boost_lexical_cast/performance.html
As I checked to_string delegtes real work to vsnprintf (at least on
mingw). So it should be similar to the last column result. And
Patch 1 is fine.
Patch 2: did you try to determine whether to_string() is better than using
ostringstream<< ?
At least some time ago, performance was better with lexical_cast:
https://www.boost.org/doc/libs/1_49_0/doc/html/boost_lexical_cast/performance.html
JMarc
Here is more recent
Le 10/12/2020 à 14:16, Jean-Marc Lasgouttes a écrit :
Le 10/12/2020 à 13:42, Yuriy Skalko a écrit :
Note that, as shown in the new last line, removing lexical_cast _and_
signals2 is the big win here.
Here is the first step -- removing lexical_cast.
Patch 1 is fine.
Patch 2: did you try to
Le 10/12/2020 à 13:42, Yuriy Skalko a écrit :
Note that, as shown in the new last line, removing lexical_cast _and_
signals2 is the big win here.
Here is the first step -- removing lexical_cast.
Patch 1 is fine.
Patch 2: did you try to determine whether to_string() is better than
using
And instead of `boost::any` we can use smaller C++11-compatible
implementation for older compilers (this is a patch for testing, I'm not
sure what will be the right place in 3rdparty to put the header).
Yuriy
From 647535bd9a2c70634a5cdd437f8f603b04b14a70 Mon Sep 17 00:00:00 2001
From: Yuriy
Note that, as shown in the new last line, removing lexical_cast _and_ signals2
is the big win here.
JMarc
Here is the first step -- removing lexical_cast.
Yuriy
From 379ae9e7110b027c647aa4c34b906deeaa87a838 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 10 Dec 2020 14:32:55 +0200
Le 10/12/2020 à 10:35, Jean-Marc Lasgouttes a écrit :
Le 10/12/2020 à 09:31, Yuriy Skalko a écrit :
Only boost/any.hpp will be unused with C++17 compilers. Maybe we can
get rid of boost/lexical_cast.hpp as Jean-Marc suggested.
Then we will still have assert, crc and signal. I haven't looked
Le 10/12/2020 à 09:31, Yuriy Skalko a écrit :
Only boost/any.hpp will be unused with C++17 compilers. Maybe we can get
rid of boost/lexical_cast.hpp as Jean-Marc suggested.
Then we will still have assert, crc and signal. I haven't looked at
assert, but for the rest we can check these
On Wednesday, December 9, 2020 7:26:45 PM WET Jean-Marc Lasgouttes wrote:
I aml not sure we can do much more than that. The next possibility would
be to get rid of lexical_cast, used for convert<>(). On could use the
stream operator >> instead.
JMarc
I am just curious but if/when we change
On Wednesday, December 9, 2020 7:26:45 PM WET Jean-Marc Lasgouttes wrote:
> I aml not sure we can do much more than that. The next possibility would
> be to get rid of lexical_cast, used for convert<>(). On could use the
> stream operator >> instead.
>
> JMarc
I am just curious but if/when we
Le 09/12/2020 à 19:54, Yuriy Skalko a écrit :
Great cleanup, Jean-Marc!
Finally boost directory becomes less in size than main src directory :)
I aml not sure we can do much more than that. The next possibility would
be to get rid of lexical_cast, used for convert<>(). On could use the
67 matches
Mail list logo
