Re: Basic test of alpha1 tar

2016-06-03 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> Le 24/05/2016 23:37, Pavel Sanda a écrit :
 I only tried 2.2, so I did not really compare. I do not have 2.0 here. I
 can try to have a look at 2.1 vs 2.2 later.
>>>
>>> Please try, we should see whether the problem is reproducible at all...
>>
>> Since you were asking in different thread, ping :)
>
> When I looked at that, I did not find much. I'll have to return to it.

You mean, you couldn't reproduce the problem, correct? Pavel


Re: Basic test of alpha1 tar

2016-05-26 Thread Jean-Marc Lasgouttes

Le 24/05/2016 23:37, Pavel Sanda a écrit :

I only tried 2.2, so I did not really compare. I do not have 2.0 here. I
can try to have a look at 2.1 vs 2.2 later.


Please try, we should see whether the problem is reproducible at all...


Since you were asking in different thread, ping :)


When I looked at that, I did not find much. I'll have to return to it.

JMarc



Re: Basic test of alpha1 tar

2016-05-24 Thread Pavel Sanda
Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
> > Le 12/01/2016 10:15, Pavel Sanda a écrit :
> >> Jean-Marc Lasgouttes wrote:
>  More important is - can you reproduce the behaviour? It's pretty clear 
>  on my
>  machine without trying any special conditions, just high repeat rate of 
>  the
>  keyboard is needed.
> >
> > I only tried 2.2, so I did not really compare. I do not have 2.0 here. I 
> > can try to have a look at 2.1 vs 2.2 later.
> 
> Please try, we should see whether the problem is reproducible at all...

Since you were asking in different thread, ping :)

> Pavel


Re: Basic test of alpha1 tar

2016-01-12 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> Le 11/01/2016 10:59, Pavel Sanda a écrit :
>> Jean-Marc Lasgouttes wrote:
>>> I reproduce the svg you sent for 2.2, since it is not so large either :)
>>
>> More important is - can you reproduce the behaviour? It's pretty clear on my
>> machine without trying any special conditions, just high repeat rate of the
>> keyboard is needed.
>
> I tried to play with different profilers at the time.

Sorry, by reproducing I meant just seeing the problem visually without
really trying any profiling stuff. I'm just fearing I observe my graphic
card issue, it wouldn't be the first time...

> * I cannot get sysprof to give nice trees anymore. Are you on a 64bit 
> target? It seems to me that life was simpler when I was in 32 bits linux.

That was 32 bit. For trees you need to save file and then run:
gprof2dot  -f sysprof saved_file |dot -Tsvg -o sysprof.svg

Any better now?

> * I tried perf, but I am not sure what to do with it. Again, I do not get 
> nice trees.

IIRC I needed to compile with --enable-build-type=gprof, gmon.out is created
while running lyx, then you need to run
gprof src/lyx gmon.out > gprof.txt

For visualizing trees:
gprof2dot gmon.out |dot -Tsvg -o full.svg

I think sysprof is better choice because gprof will hide calls to 3rd
party libs which matter.

Not so long ago Guilliame added Callgrind section into wiki. I didn't
have time to try it but it look really cool on screenshots, you might
want to try that.

> At some time, I convinced my self that there is as much time spent in 
> toolbar updates than in painting itself. The reason is (would be) that it 
> uses BufferParams::isExportable which does a full graph search in 
> converters for each icon that we might want to enable.

I was quite surprised how much took macro updates, but I think it's both
cases, thus not culprit of our problem.

> I did not spend more time to investigate this, especially since we are 
> moving office to Paris center next Thursday.

>>> * is this a 2.2 built in release mode?
>>
>> 2.2 was build with O2 & enabled debug symbols, 2.0 was release mode (i.e.
>> including O2) but the completely stripped off the symbols after 
>> compilation.
>
> Yes, but did you use --disable-stdlib-debug? This slows down LyX quite a 
> bit. Using --enable_build-type=prof is nice because it uses the right flags 
> for profiling.

disable-stdlib-debug should have been off for both cases.

Pavel


Re: Basic test of alpha1 tar

2016-01-12 Thread Jean-Marc Lasgouttes

Le 12/01/2016 10:15, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

More important is - can you reproduce the behaviour? It's pretty clear on my
machine without trying any special conditions, just high repeat rate of the
keyboard is needed.


I only tried 2.2, so I did not really compare. I do not have 2.0 here. I 
can try to have a look at 2.1 vs 2.2 later.



I think sysprof is better choice because gprof will hide calls to 3rd
party libs which matter.


Yes, sysprof is better and I used to rely on it, but my luck is running 
out in amd64. Looks like google-perftools may be a good thing to try.



I was quite surprised how much took macro updates, but I think it's both
cases, thus not culprit of our problem.


Yes, macro updates are a big pain, especially since they also happen for 
documents that do not contain any macro :(


JMarc



Re: Basic test of alpha1 tar

2016-01-12 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> Le 12/01/2016 10:15, Pavel Sanda a écrit :
>> Jean-Marc Lasgouttes wrote:
 More important is - can you reproduce the behaviour? It's pretty clear 
 on my
 machine without trying any special conditions, just high repeat rate of 
 the
 keyboard is needed.
>
> I only tried 2.2, so I did not really compare. I do not have 2.0 here. I 
> can try to have a look at 2.1 vs 2.2 later.

Please try, we should see whether the problem is reproducible at all...
Pavel


Re: Basic test of alpha1 tar

2016-01-11 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> Le 07/01/2016 06:10, Pavel Sanda a écrit :
>> The way to reproduce:
>> my keyboard autorepeat:
>> 1.xset r rate 300 180
>> 2. launch lyx & tutorial & fullscreen
>> 3. hold right arrow key until you get to the end of the
>> first page and then left arrow until you get to first character.
>>
>> This test yields approx.:
>> 2.2: 32s
>> 2.1: 16s
>> 2.0: 14s
>>
>> I will send logs privately, they are not small.
>
> I reproduce the svg you sent for 2.2, since it is not so large either :) 

More important is - can you reproduce the behaviour? It's pretty clear on my
machine without trying any special conditions, just high repeat rate of the
keyboard is needed.

> And I think it can interest other people.
>
> Questions:
>
> * is this a 2.2 built in release mode?

2.2 was build with O2 & enabled debug symbols, 2.0 was release mode (i.e.
including O2) but the completely stripped off the symbols after compilation.

> * do the two lyx version use the same zoom and font settings?

Yes.

> * could you try to install some Qt dbg symbols so that we can see what is 
> happening in there?

Unf I'm short of time to play with this now. Maybe later.

> * how come that malloc does not appears in your 2.0 profile?

I can see three reasons
- the conversion from sysprof to readable output uses (adjustable) threshold
  for % of the routine to be included and malloc didn't make it for 2.0
- stripping debug symbols might affect sysprof
- malloc is not that much used in 2.0 :)


> * can you help me decipher what the % mean? For example, I see
>   [ Buffer::updateMacros 30.20% ] --15.07% --->[malloc 
> 30.21% ]
>
>   I read it as: update macros takes 30% of total time, malloc too, and half 
> of malloc time is due to updateMacros. Is that right?

Yep, sysprof should report % of total cpu usage (including other stuff running
in the machine) and percentage in the routine should include time of all its
subroutines (unlike gprof measurements IIRC).

Pavel


Re: Basic test of alpha1 tar

2016-01-11 Thread Jean-Marc Lasgouttes

Le 11/01/2016 10:59, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

I reproduce the svg you sent for 2.2, since it is not so large either :)


More important is - can you reproduce the behaviour? It's pretty clear on my
machine without trying any special conditions, just high repeat rate of the
keyboard is needed.


I tried to play with different profilers at the time.
* I cannot get sysprof to give nice trees anymore. Are you on a 64bit 
target? It seems to me that life was simpler when I was in 32 bits linux.
* I tried perf, but I am not sure what to do with it. Again, I do not 
get nice trees.


At some time, I convinced my self that there is as much time spent in 
toolbar updates than in painting itself. The reason is (would be) that 
it uses BufferParams::isExportable which does a full graph search in 
converters for each icon that we might want to enable.


I did not spend more time to investigate this, especially since we are 
moving office to Paris center next Thursday.



* is this a 2.2 built in release mode?


2.2 was build with O2 & enabled debug symbols, 2.0 was release mode (i.e.
including O2) but the completely stripped off the symbols after compilation.


Yes, but did you use --disable-stdlib-debug? This slows down LyX quite a 
bit. Using --enable_build-type=prof is nice because it uses the right 
flags for profiling.


JMarc


Re: Basic test of alpha1 tar

2016-01-11 Thread Richard Heck
On 01/11/2016 05:10 AM, Jean-Marc Lasgouttes wrote:
>
> At some time, I convinced my self that there is as much time spent in
> toolbar updates than in painting itself. The reason is (would be) that
> it uses BufferParams::isExportable which does a full graph search in
> converters for each icon that we might want to enable.

Surely this can be cached? It would have to be reset whenever
Preferences were updated, but that is not very often.

One easy way to test would be to have isExportable just return true.

Richard




Re: Basic test of alpha1 tar

2016-01-11 Thread Jean-Marc Lasgouttes

Le 11/01/2016 18:12, Richard Heck a écrit :

On 01/11/2016 05:10 AM, Jean-Marc Lasgouttes wrote:


At some time, I convinced my self that there is as much time spent in
toolbar updates than in painting itself. The reason is (would be) that
it uses BufferParams::isExportable which does a full graph search in
converters for each icon that we might want to enable.


Surely this can be cached? It would have to be reset whenever
Preferences were updated, but that is not very often.


It should be cached indeed. I gues it should be changed every time 
document settings are changed too. Are there other conditions?



One easy way to test would be to have isExportable just return true.


Yes, that's my plan for later. Currently I use my poor man's profiler to 
measure, but I never now how precise it is.


JMarc



Re: Basic test of alpha1 tar

2016-01-06 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> >Sadly, moving cursor in paragraph is considerably slower than
> >in my current 2.0 build :(
> 
> And how does this compare to a 2.1 build?
> 
> Could you provide a profile log for 2.2 being slow?

Ok, I made two profiles for sysprof.

The way to reproduce:
my keyboard autorepeat:
1.xset r rate 300 180
2. launch lyx & tutorial & fullscreen
3. hold right arrow key until you get to the end of the
   first page and then left arrow until you get to first character.

This test yields approx.:
2.2: 32s
2.1: 16s
2.0: 14s

I will send logs privately, they are not small.
Pavel


Re: Basic test of alpha1 tar

2016-01-03 Thread Scott Kostyshak
On Tue, Nov 17, 2015 at 07:03:46PM -0500, Scott Kostyshak wrote:
> On Tue, Nov 17, 2015 at 09:55:27PM +0100, Jean-Marc Lasgouttes wrote:

> > I thin that gcc5 does not work with --disable-cxx11-mode. But I did not have
> > time to look at it more closely.
> 
> Good to know.

I just tested with
gcc 5.1.1-4

and the compilation went fine. 'make check' passed. 'make distcheck' did
not but that is expected because of the lyx.pot error.

Scott


signature.asc
Description: PGP signature


Re: Basic test of alpha1 tar

2016-01-03 Thread Jean-Marc Lasgouttes

Le 03/01/2016 10:19, Scott Kostyshak a écrit :

I thin that gcc5 does not work with --disable-cxx11-mode. But I did not have
time to look at it more closely.


Good to know.


I just tested with
gcc 5.1.1-4

and the compilation went fine. 'make check' passed. 'make distcheck' did
not but that is expected because of the lyx.pot error.


OK, I will not complain about it working :)

JMarc



Re: Basic test of alpha1 tar

2015-11-17 Thread Kornel Benko
Am Montag, 16. November 2015 um 20:25:39, schrieb Scott Kostyshak 

> On Tue, Nov 17, 2015 at 12:49:02AM +0100, Uwe Stöhr wrote:
> > Am 14.11.2015 um 20:24 schrieb Scott Kostyshak:
> > 
> > >If you have time, please download the LyX 2.2.0alpha1 tar and test that
> > >it compiles/installs as expected.
> > 
> > It compiles but not as merged build. With
> > 
> > -DLYX_MERGE_REBUILD=1 -DLYX_MERGE_FILES=1
> > 
> > I get 40 errors, most of them due to a problem with apple script:
> 
> Thanks for testing. This is my fault for not testing compilation with
> monolithic build. I will (hopefully) not make the same mistake again.
> The monolithic build now succeeds for autotools.

Is it with autotools really compiling everything?
Or only files to be installed?

> I think there might
> still be an error for the CMake monolithic build that is being
> investigated.
> 
> Scott
...

> > \Master\compile-result\src\tests\check_ExternalTransforms.vcxproj]
...

> > regards Uwe

It looks like the same error as on linux if making a package.
This time while linking check_ExternalTransforms, while on linux it stopped at
linking check_convert.

Referenced on Uwe's check:
"lyx::FuncRequest::FuncRequest(class lyx::FuncRequest const &,class 
std::basic_string const &,enum lyx::FuncRequest::Origin)"

Referenced on my check:
`lyx::FuncRequest::FuncRequest(lyx::FuncRequest const&, std::string const&, 
lyx::FuncRequest::Origin)'

Kornel



signature.asc
Description: This is a digitally signed message part.


Re: Basic test of alpha1 tar

2015-11-17 Thread Kornel Benko
Am Dienstag, 17. November 2015 um 10:32:47, schrieb Scott Kostyshak 

> On Tue, Nov 17, 2015 at 01:12:56PM +0100, Kornel Benko wrote:
> > Am Montag, 16. November 2015 um 20:25:39, schrieb Scott Kostyshak 
> > 
> > > On Tue, Nov 17, 2015 at 12:49:02AM +0100, Uwe Stöhr wrote:
> > > > Am 14.11.2015 um 20:24 schrieb Scott Kostyshak:
> > > > 
> > > > >If you have time, please download the LyX 2.2.0alpha1 tar and test that
> > > > >it compiles/installs as expected.
> > > > 
> > > > It compiles but not as merged build. With
> > > > 
> > > > -DLYX_MERGE_REBUILD=1 -DLYX_MERGE_FILES=1
> > > > 
> > > > I get 40 errors, most of them due to a problem with apple script:
> > > 
> > > Thanks for testing. This is my fault for not testing compilation with
> > > monolithic build. I will (hopefully) not make the same mistake again.
> > > The monolithic build now succeeds for autotools.
> > 
> > Is it with autotools really compiling everything?
> > Or only files to be installed?
> 
> The following command exits without error for me:
> 
> ./autogen.sh && ./configure --enable-build-type=pre 
> --enable-monolithic-build=yes && make
> 
> Is there another make target I should check?

According to src/Makefile.am maybe
'make check'
I am not expert in autotools, but it looks promising. It should create 
check_ExternalTransforms, check_Length and check_layout
 
> Scott

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: Basic test of alpha1 tar

2015-11-17 Thread Jean-Marc Lasgouttes

Le 17/11/2015 16:32, Scott Kostyshak a écrit :

The following command exits without error for me:

./autogen.sh && ./configure --enable-build-type=pre --enable-monolithic-build=yes 
&& make

Is there another make target I should check?


Do you tun "make distcheck" too? (this is unrelated to monolithic builds).

JMarc



Re: Basic test of alpha1 tar

2015-11-17 Thread Scott Kostyshak
On Tue, Nov 17, 2015 at 04:55:03PM +0100, Kornel Benko wrote:
> Am Dienstag, 17. November 2015 um 10:32:47, schrieb Scott Kostyshak 
> 

> > > Is it with autotools really compiling everything?
> > > Or only files to be installed?
> > 
> > The following command exits without error for me:
> > 
> > ./autogen.sh && ./configure --enable-build-type=pre 
> > --enable-monolithic-build=yes && make
> > 
> > Is there another make target I should check?
> 
> According to src/Makefile.am maybe
>   'make check'
> I am not expert in autotools, but it looks promising. It should create 
> check_ExternalTransforms, check_Length and check_layout

With 'make check' I get the same failing I get with the non-monolithic
build I believe:

Testsuite summary for LyX 2.2.0dev

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See src/frontends/test-suite.log
Please report to lyx-devel@lists.lyx.org

Makefile:855: recipe for target 'test-suite.log' failed
make[6]: *** [test-suite.log] Error 1
make[6]: Leaving directory
'/home/scott/lyxbuilds/master/repo/src/frontends'
Makefile:961: recipe for target 'check-TESTS' failed
make[5]: *** [check-TESTS] Error 2
make[5]: Leaving directory
'/home/scott/lyxbuilds/master/repo/src/frontends'
Makefile:1059: recipe for target 'check-am' failed
make[4]: *** [check-am] Error 2
make[4]: Leaving directory
'/home/scott/lyxbuilds/master/repo/src/frontends'
Makefile:748: recipe for target 'check-recursive' failed
make[3]: *** [check-recursive] Error 1
make[3]: Leaving directory
'/home/scott/lyxbuilds/master/repo/src/frontends'
Makefile:2749: recipe for target 'check-recursive' failed
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory '/home/scott/lyxbuilds/master/repo/src'
Makefile:3070: recipe for target 'check' failed
make[1]: *** [check] Error 2
make[1]: Leaving directory '/home/scott/lyxbuilds/master/repo/src'
Makefile:545: recipe for target 'check-recursive' failed
make: *** [check-recursive] Error 1


When looking in the log it is because of the regex issue.

Scott


signature.asc
Description: PGP signature


Re: Basic test of alpha1 tar

2015-11-17 Thread Scott Kostyshak
On Tue, Nov 17, 2015 at 01:12:56PM +0100, Kornel Benko wrote:
> Am Montag, 16. November 2015 um 20:25:39, schrieb Scott Kostyshak 
> 
> > On Tue, Nov 17, 2015 at 12:49:02AM +0100, Uwe Stöhr wrote:
> > > Am 14.11.2015 um 20:24 schrieb Scott Kostyshak:
> > > 
> > > >If you have time, please download the LyX 2.2.0alpha1 tar and test that
> > > >it compiles/installs as expected.
> > > 
> > > It compiles but not as merged build. With
> > > 
> > > -DLYX_MERGE_REBUILD=1 -DLYX_MERGE_FILES=1
> > > 
> > > I get 40 errors, most of them due to a problem with apple script:
> > 
> > Thanks for testing. This is my fault for not testing compilation with
> > monolithic build. I will (hopefully) not make the same mistake again.
> > The monolithic build now succeeds for autotools.
> 
> Is it with autotools really compiling everything?
> Or only files to be installed?

The following command exits without error for me:

./autogen.sh && ./configure --enable-build-type=pre 
--enable-monolithic-build=yes && make

Is there another make target I should check?

Scott


signature.asc
Description: PGP signature


Re: Basic test of alpha1 tar

2015-11-17 Thread Scott Kostyshak
On Tue, Nov 17, 2015 at 05:09:03PM +0100, Jean-Marc Lasgouttes wrote:
> Le 17/11/2015 16:32, Scott Kostyshak a écrit :
> >The following command exits without error for me:
> >
> >./autogen.sh && ./configure --enable-build-type=pre 
> >--enable-monolithic-build=yes && make
> >
> >Is there another make target I should check?
> 
> Do you tun "make distcheck" too? (this is unrelated to monolithic builds).

Yes I will have this in my script that tests the builds. I just meant as
far as monolithic builds. My script does the following for a few
different configurations:


echo "testing autotools monolithic..."
git reset --hard
git clean -xdf
./autogen.sh && ./configure --enable-build-type=pre
--enable-monolithic-build=yes && make && make check && make distcheck &&
echo "ALL TESTS PASSED"

echo "testing without nls..."
git reset --hard
git clean -xdf
./autogen.sh && ./configure --enable-build-type=pre --disable-nls &&
make && make check && make distcheck && echo "ALL TESTS PASSED"


Any other configure options you think would be good to test? Any other
ways to test (in addition to make check and make distcheck)?

Scott


signature.asc
Description: PGP signature


Re: Basic test of alpha1 tar

2015-11-17 Thread Uwe Stöhr

Am 17.11.2015 um 21:31 schrieb Kornel Benko:


OK, cmake should now work.


Many thanks Kornel. Works now for me.

regards Uwe


Re: Basic test of alpha1 tar

2015-11-17 Thread Scott Kostyshak
On Tue, Nov 17, 2015 at 09:55:27PM +0100, Jean-Marc Lasgouttes wrote:
> Le 17/11/15 17:47, Scott Kostyshak a écrit :
> >On Tue, Nov 17, 2015 at 05:09:03PM +0100, Jean-Marc Lasgouttes wrote:
> >>Le 17/11/2015 16:32, Scott Kostyshak a écrit :
> >>>The following command exits without error for me:
> >>>
> >>>./autogen.sh && ./configure --enable-build-type=pre 
> >>>--enable-monolithic-build=yes && make
> >>>
> >>>Is there another make target I should check?
> >>
> >>Do you tun "make distcheck" too? (this is unrelated to monolithic builds).
> >
> >Yes I will have this in my script that tests the builds. I just meant as
> >far as monolithic builds. My script does the following for a few
> >different configurations:
> >
> >
> >echo "testing autotools monolithic..."
> >git reset --hard
> >git clean -xdf
> >./autogen.sh && ./configure --enable-build-type=pre
> >--enable-monolithic-build=yes && make && make check && make distcheck &&
> >echo "ALL TESTS PASSED"
> >
> >echo "testing without nls..."
> >git reset --hard
> >git clean -xdf
> >./autogen.sh && ./configure --enable-build-type=pre --disable-nls &&
> >make && make check && make distcheck && echo "ALL TESTS PASSED"
> >
> >
> >Any other configure options you think would be good to test? Any other
> >ways to test (in addition to make check and make distcheck)?
> 
> If you have time to waste, you can also compile with clang++. And also try
> --disable-cxx11-mode. Or try both.

I don't have time to waste, but my computer does :). I will test with
clang++ and also --disable-cxx11-mode. Should I test the monolithic
build with clang++ or is that not needed?

> I thin that gcc5 does not work with --disable-cxx11-mode. But I did not have
> time to look at it more closely.

Good to know.

Scott


signature.asc
Description: PGP signature


Re: Basic test of alpha1 tar

2015-11-17 Thread Georg Baum
Kornel Benko wrote:

> Now the problem is linking of lyxclient ...
> cd /usr/BUILD/BuildLyxGitQtlocal/src/client && /usr/bin/cmake -E
> cmake_link_script CMakeFiles/lyxclient2.2.dir/link.txt --verbose=1
> /usr/bin/c++   -Wall -Wunused-parameter --std=c++11 -fno-strict-aliasing 
> -Wall -Wunused-parameter --std=c++11 -fno-strict-aliasing -O0 -g3 -D_DEBUG
>   CMakeFiles/lyxclient2.2.dir/client.cpp.o
> CMakeFiles/lyxclient2.2.dir/boost.cpp.o
> CMakeFiles/lyxclient2.2.dir/__/TexRow.cpp.o  -o ../../bin/lyxclient2.2
> -rdynamic ../../lib/libsupport.a ../../lib/libboost_signals.a
> ../../lib/libboost_regex.a -lmagic -laspell
> /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.2.1
> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.2.1 -lz
> CMakeFiles/lyxclient2.2.dir/__/TexRow.cpp.o: In function
> `lyx::TexRow::rowEntryFromCursorSlice(lyx::CursorSlice const&)':
> /usr/src/lyx/lyx-git/src/TexRow.cpp:226: undefined reference to
> `lyx::CursorSlice::paragraph() const'
> /usr/src/lyx/lyx-git/src/TexRow.cpp:226: undefined reference to
> `lyx::Paragraph::id() const' CMakeFiles/lyxclient2.2.dir/__/TexRow.cpp.o:
> In function `lyx::TexRow::rowFromCursor(lyx::Cursor const&) const':
> /usr/src/lyx/lyx-git/src/TexRow.cpp:442: undefined reference to
> `lyx::Cursor::selectionBegin() const'
> /usr/src/lyx/lyx-git/src/TexRow.cpp:445: undefined reference to
> `lyx::Cursor::selectionEnd() const'
> /usr/src/lyx/lyx-git/src/TexRow.cpp:452: undefined reference to
> `lyx::CursorSlice::backwardPos()'
> CMakeFiles/lyxclient2.2.dir/__/TexRow.cpp.o: In function
> `lyx::Cursor::selIsMultiCell() const':
> /usr/src/lyx/lyx-git/src/Cursor.h:173: undefined reference to
> `lyx::Cursor::selBegin() const' /usr/src/lyx/lyx-git/src/Cursor.h:173:
> undefined reference to `lyx::Cursor::selEnd() const'
> 
> This one has nothing with Apple to do.

No, but it is very similar: Stuff is compiled for client that is not needed. 
client needs src/support/, src/client/boost.cpp and src/client/client.cpp (+ 
the libs like boost, Qt etc). Thats all, nothing from src/. If you remove 
src/*.cpp for client then it should link as well.


Georg




Re: Basic test of alpha1 tar

2015-11-17 Thread Georg Baum
Kornel Benko wrote:

> Am Dienstag, 17. November 2015 um 10:32:47, schrieb Scott Kostyshak
> 
>> On Tue, Nov 17, 2015 at 01:12:56PM +0100, Kornel Benko wrote:
>> > 
>> > Is it with autotools really compiling everything?
>> > Or only files to be installed?
>> 
>> The following command exits without error for me:
>> 
>> ./autogen.sh && ./configure --enable-build-type=pre
>> --enable-monolithic-build=yes && make
>> 
>> Is there another make target I should check?
> 
> According to src/Makefile.am maybe
> 'make check'
> I am not expert in autotools, but it looks promising. It should create
> check_ExternalTransforms, check_Length and check_layout

I does.

The problem with cmake is (as I wrote yestderday): It always includes the 
apple stuff (src/support/AppleScriptProxy.cpp etc) in the unit tests if 
monolithic build is used. The correct behaviour would be to compile this 
only on OS X.

I briefly looked into the CmakeLists.txt, but this goes far beyond my very 
limited cmake knowledge, so I did not find out how to fix this.


Georg





Re: Basic test of alpha1 tar

2015-11-17 Thread Kornel Benko
Am Dienstag, 17. November 2015 um 20:31:59, schrieb Georg Baum 

> Kornel Benko wrote:
>
> > Am Dienstag, 17. November 2015 um 10:32:47, schrieb Scott Kostyshak
> > 
> >> On Tue, Nov 17, 2015 at 01:12:56PM +0100, Kornel Benko wrote:
> >> >
> >> > Is it with autotools really compiling everything?
> >> > Or only files to be installed?
> >>
> >> The following command exits without error for me:
> >>
> >> ./autogen.sh && ./configure --enable-build-type=pre
> >> --enable-monolithic-build=yes && make
> >>
> >> Is there another make target I should check?
> >
> > According to src/Makefile.am maybe
> > 'make check'
> > I am not expert in autotools, but it looks promising. It should create
> > check_ExternalTransforms, check_Length and check_layout
>
> I does.
>
> The problem with cmake is (as I wrote yestderday): It always includes the
> apple stuff (src/support/AppleScriptProxy.cpp etc) in the unit tests if
> monolithic build is used. The correct behaviour would be to compile this
> only on OS X.

Thanks, this helped me.
Compilation makes now up to 93%.

Now the problem is linking of lyxclient ...
cd /usr/BUILD/BuildLyxGitQtlocal/src/client && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/lyxclient2.2.dir/link.txt --verbose=1
/usr/bin/c++   -Wall -Wunused-parameter --std=c++11 -fno-strict-aliasing  -Wall 
-Wunused-parameter --std=c++11 -fno-strict-aliasing -O0 -g3 -D_DEBUG   
CMakeFiles/lyxclient2.2.dir/client.cpp.o 
CMakeFiles/lyxclient2.2.dir/boost.cpp.o 
CMakeFiles/lyxclient2.2.dir/__/TexRow.cpp.o  -o ../../bin/lyxclient2.2 
-rdynamic ../../lib/libsupport.a ../../lib/libboost_signals.a 
../../lib/libboost_regex.a -lmagic -laspell 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.2.1 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.2.1 -lz
CMakeFiles/lyxclient2.2.dir/__/TexRow.cpp.o: In function 
`lyx::TexRow::rowEntryFromCursorSlice(lyx::CursorSlice const&)':
/usr/src/lyx/lyx-git/src/TexRow.cpp:226: undefined reference to 
`lyx::CursorSlice::paragraph() const'
/usr/src/lyx/lyx-git/src/TexRow.cpp:226: undefined reference to 
`lyx::Paragraph::id() const'
CMakeFiles/lyxclient2.2.dir/__/TexRow.cpp.o: In function 
`lyx::TexRow::rowFromCursor(lyx::Cursor const&) const':
/usr/src/lyx/lyx-git/src/TexRow.cpp:442: undefined reference to 
`lyx::Cursor::selectionBegin() const'
/usr/src/lyx/lyx-git/src/TexRow.cpp:445: undefined reference to 
`lyx::Cursor::selectionEnd() const'
/usr/src/lyx/lyx-git/src/TexRow.cpp:452: undefined reference to 
`lyx::CursorSlice::backwardPos()'
CMakeFiles/lyxclient2.2.dir/__/TexRow.cpp.o: In function 
`lyx::Cursor::selIsMultiCell() const':
/usr/src/lyx/lyx-git/src/Cursor.h:173: undefined reference to 
`lyx::Cursor::selBegin() const'
/usr/src/lyx/lyx-git/src/Cursor.h:173: undefined reference to 
`lyx::Cursor::selEnd() const'

This one has nothing with Apple to do.

> I briefly looked into the CmakeLists.txt, but this goes far beyond my very
> limited cmake knowledge, so I did not find out how to fix this.
>
>
> Georg

Kornel


signature.asc
Description: This is a digitally signed message part.
diff --git a/src/support/CMakeLists.txt b/src/support/CMakeLists.txt
index 0091329..d93fbe4 100644
--- a/src/support/CMakeLists.txt
+++ b/src/support/CMakeLists.txt
@@ -12,6 +12,8 @@ list(REMOVE_ITEM support_sources ${moc_files} .)
 if(APPLE)
 	list(APPEND dont_merge ${TOP_SRC_DIR}/src/support/AppleSpeller.m)
 	list(APPEND dont_merge ${TOP_SRC_DIR}/src/support/AppleScript.m)
+else()
+	list(REMOVE_ITEM support_sources "${TOP_SRC_DIR}/src/support/AppleScriptProxy.cpp")
 endif()
 
 file(GLOB support_headers ${TOP_SRC_DIR}/src/support/${LYX_HPP_FILES})


Re: Basic test of alpha1 tar

2015-11-17 Thread Georg Baum
Kornel Benko wrote:

> OK, cmake should now work.

Thanks, it works fine now!


Georg



Re: Basic test of alpha1 tar

2015-11-17 Thread Kornel Benko
Am Dienstag, 17. November 2015 um 20:55:15, schrieb Kornel Benko 

> Am Dienstag, 17. November 2015 um 20:31:59, schrieb Georg Baum 
> 
> > Kornel Benko wrote:
> > 
> > > Am Dienstag, 17. November 2015 um 10:32:47, schrieb Scott Kostyshak
> > > 
> > >> On Tue, Nov 17, 2015 at 01:12:56PM +0100, Kornel Benko wrote:
> > >> > 
> > >> > Is it with autotools really compiling everything?
> > >> > Or only files to be installed?
> > >> 
> > >> The following command exits without error for me:
> > >> 
> > >> ./autogen.sh && ./configure --enable-build-type=pre
> > >> --enable-monolithic-build=yes && make
> > >> 
> > >> Is there another make target I should check?
> > > 
> > > According to src/Makefile.am maybe
> > > 'make check'
> > > I am not expert in autotools, but it looks promising. It should create
> > > check_ExternalTransforms, check_Length and check_layout
> > 
> > I does.
> > 
> > The problem with cmake is (as I wrote yestderday): It always includes the 
> > apple stuff (src/support/AppleScriptProxy.cpp etc) in the unit tests if 
> > monolithic build is used. The correct behaviour would be to compile this 
> > only on OS X.
> 
> Thanks, this helped me.
> Compilation makes now up to 93%.
> 

OK, cmake should now work.
Before rebuilding, one has to remove all '_allinone_const.C' files from the 
build directory
# find . -name _allinone_const.C | xargs rm
because unfortunately cmake does not recreate these files if they are already 
there.

Then reconfigure
# make rebuild_cache
This will recreate them.

Now everything is ready to use
# make package

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: Basic test of alpha1 tar

2015-11-17 Thread Jean-Marc Lasgouttes

Le 17/11/15 17:47, Scott Kostyshak a écrit :

On Tue, Nov 17, 2015 at 05:09:03PM +0100, Jean-Marc Lasgouttes wrote:

Le 17/11/2015 16:32, Scott Kostyshak a écrit :

The following command exits without error for me:

./autogen.sh && ./configure --enable-build-type=pre --enable-monolithic-build=yes 
&& make

Is there another make target I should check?


Do you tun "make distcheck" too? (this is unrelated to monolithic builds).


Yes I will have this in my script that tests the builds. I just meant as
far as monolithic builds. My script does the following for a few
different configurations:


echo "testing autotools monolithic..."
git reset --hard
git clean -xdf
./autogen.sh && ./configure --enable-build-type=pre
--enable-monolithic-build=yes && make && make check && make distcheck &&
echo "ALL TESTS PASSED"

echo "testing without nls..."
git reset --hard
git clean -xdf
./autogen.sh && ./configure --enable-build-type=pre --disable-nls &&
make && make check && make distcheck && echo "ALL TESTS PASSED"


Any other configure options you think would be good to test? Any other
ways to test (in addition to make check and make distcheck)?


If you have time to waste, you can also compile with clang++. And also 
try --disable-cxx11-mode. Or try both.


I thin that gcc5 does not work with --disable-cxx11-mode. But I did not 
have time to look at it more closely.


JMarc





Re: Basic test of alpha1 tar

2015-11-16 Thread Jean-Marc Lasgouttes

Le 15/11/2015 03:14, Pavel Sanda a écrit :

Pavel Sanda wrote:

non harmful, but warnings:


Apart from that I was able to build and run it on gentoo system.

Sadly, moving cursor in paragraph is considerably slower than
in my current 2.0 build :(



Could it be related to the following ticket?
http://www.lyx.org/trac/ticket/9783

JMarc


Re: Basic test of alpha1 tar

2015-11-16 Thread Scott Kostyshak
On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote:
> Am 14.11.2015 um 20:24 schrieb Scott Kostyshak :
> 
> > Dear all,
> > 
> > If you have time, please download the LyX 2.2.0alpha1 tar and test that
> > it compiles/installs as expected. It is located here:
> > 
> > ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/
> > 
> > Also if you can, please check that it verifies correctly. This is my
> > first time signing a tar ball.
> 
> The signature is ok. The build on Mac OS X works.

Thanks for checking these.

> I've uploaded the result here:
> 
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
> 
> I've used Qt 5.5.1 to build it.

Good choice.

The key you used to sign expired a year and a half ago:

$ gpg --verify *sig
gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg'
gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID
EE614DC4
gpg: Good signature from "LyX on Mac OS X (Signing LyX disk images)
"
gpg: Note: This key has expired!
Primary key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61
4DC4
$

Is this a problem?
I imagine it is not a problem for alpha, and that I should go ahead and
upload your .dmg but I wanted to check first.

Scott


signature.asc
Description: PGP signature


Re: Basic test of alpha1 tar

2015-11-16 Thread Scott Kostyshak
On Mon, Nov 16, 2015 at 05:48:03PM -0500, Richard Heck wrote:
> On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
> > On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
> > 14.11.2015 um 20:24 schrieb Scott Kostyshak :
> >> >>> Dear all, >>> >>> If you have time, please download the LyX
> 2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
> is located here: >>> >>>
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
> you can, please check that it verifies correctly. This is my >>> first
> time signing a tar ball. >> >> The signature is ok. The build on Mac OS
> X works. > > Thanks for checking these. > >> I've uploaded the result
> here: >> >>
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
> >>
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
> >> >> I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
> used to sign expired a year and a half ago: > > $ gpg --verify *sig >
> gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
> gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
> EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
> images) > " > gpg: Note: This key has expired! > Primary
> key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
> $ > > Is this a problem? > I imagine it is not a problem for alpha, and
> that I should go ahead and > upload your .dmg but I wanted to check first.
> 
> Just to be clear: You should resign this with the LyX key. Stephan's
> signature is only to guarantee to you that the binary is valid and from him.

Ah thanks for pointing this out. I actually did not know that. I will
resign.

Scott


signature.asc
Description: PGP signature


Re: Basic test of alpha1 tar

2015-11-16 Thread Richard Heck
On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
> On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
> 14.11.2015 um 20:24 schrieb Scott Kostyshak :
>> >>> Dear all, >>> >>> If you have time, please download the LyX
2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
is located here: >>> >>>
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
you can, please check that it verifies correctly. This is my >>> first
time signing a tar ball. >> >> The signature is ok. The build on Mac OS
X works. > > Thanks for checking these. > >> I've uploaded the result
here: >> >>
https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
>>
https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
>> >> I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
used to sign expired a year and a half ago: > > $ gpg --verify *sig >
gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
images) > " > gpg: Note: This key has expired! > Primary
key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
$ > > Is this a problem? > I imagine it is not a problem for alpha, and
that I should go ahead and > upload your .dmg but I wanted to check first.

Just to be clear: You should resign this with the LyX key. Stephan's
signature is only to guarantee to you that the binary is valid and from him.

Richard




Re: Basic test of alpha1 tar

2015-11-16 Thread Stephan Witt
Am 16.11.2015 um 23:50 schrieb Scott Kostyshak :

> On Mon, Nov 16, 2015 at 05:48:03PM -0500, Richard Heck wrote:
>> On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
>>> On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
>>> 14.11.2015 um 20:24 schrieb Scott Kostyshak :
>>> Dear all, >>> >>> If you have time, please download the LyX
>> 2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
>> is located here: >>> >>>
>> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
>> you can, please check that it verifies correctly. This is my >>> first
>> time signing a tar ball. >> >> The signature is ok. The build on Mac OS
>> X works. > > Thanks for checking these. > >> I've uploaded the result
>> here: >> >>
>> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
 
>> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
>> I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
>> used to sign expired a year and a half ago: > > $ gpg --verify *sig >
>> gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
>> gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
>> EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
>> images) > " > gpg: Note: This key has expired! > Primary
>> key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
>> $ > > Is this a problem? > I imagine it is not a problem for alpha, and
>> that I should go ahead and > upload your .dmg but I wanted to check first.
>> 
>> Just to be clear: You should resign this with the LyX key. Stephan's
>> signature is only to guarantee to you that the binary is valid and from him.
> 
> Ah thanks for pointing this out. I actually did not know that. I will
> resign.

Yes, please. At the time I made the key I gave it a time limit. Then I've
published it. Later - after the expiration, I made a new one and Vincent
"complained" that this key isn't published. I realized then that I can extend
the period of validity and did that. But now the key servers don't accept this.
I don't know how to deal with that, sorry :(

Stephan



Re: Basic test of alpha1 tar

2015-11-16 Thread Stephan Witt
Am 17.11.2015 um 00:06 schrieb Scott Kostyshak :

> On Tue, Nov 17, 2015 at 12:01:16AM +0100, Stephan Witt wrote:
>> Am 16.11.2015 um 23:50 schrieb Scott Kostyshak :
>> 
>>> On Mon, Nov 16, 2015 at 05:48:03PM -0500, Richard Heck wrote:
 On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
> On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
> 14.11.2015 um 20:24 schrieb Scott Kostyshak :
> Dear all, >>> >>> If you have time, please download the LyX
 2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
 is located here: >>> >>>
 ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
 you can, please check that it verifies correctly. This is my >>> first
 time signing a tar ball. >> >> The signature is ok. The build on Mac OS
 X works. > > Thanks for checking these. > >> I've uploaded the result
 here: >> >>
 https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
>> 
 https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
 I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
 used to sign expired a year and a half ago: > > $ gpg --verify *sig >
 gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
 gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
 EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
 images) > " > gpg: Note: This key has expired! > Primary
 key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
 $ > > Is this a problem? > I imagine it is not a problem for alpha, and
 that I should go ahead and > upload your .dmg but I wanted to check first.
 
 Just to be clear: You should resign this with the LyX key. Stephan's
 signature is only to guarantee to you that the binary is valid and from 
 him.
>>> 
>>> Ah thanks for pointing this out. I actually did not know that. I will
>>> resign.
>> 
>> Yes, please. At the time I made the key I gave it a time limit. Then I've
>> published it. Later - after the expiration, I made a new one and Vincent
>> "complained" that this key isn't published. I realized then that I can extend
>> the period of validity and did that. But now the key servers don't accept 
>> this.
>> I don't know how to deal with that, sorry :(
> 
> Not a problem at all for me. I just wanted to double-check.
> 
> Indeed, it is nice if the key is published. This should be easy with the
> command
> 
>  gpg --send-keys B6470BEB
> 
> where B6470BEB is the ID you want to publish. It seems you have tried
> something like that and the keyserver gave an error? What is the error
> from that command?


I've sent it already anno 2011.

This is my current attempt to follow your advice:
$ gpg --send-keys EE614DC4
gpg: sende Schlüssel EE614DC4 auf den hkp-Server keys.gnupg.net
gpg: Schlüsselserver-Zeitüberschreitung
gpg: Senden an Schlüsselserver fehlgeschlagen: Schlüsselserverfehler
$ LANG=C gpg --send-keys EE614DC4
gpg: sending key EE614DC4 to hkp server keys.gnupg.net
$ LANG=C gpg --search-keys sw...@lyx.org
gpg: searching for "sw...@lyx.org" from hkp server keys.gnupg.net
(1) LyX on Mac OS X (Signing LyX disk images) 
  2048 bit RSA key EE614DC4, created: 2011-03-09, expires: 2014-03-08 
(expired)
(2) Stephan Witt 
LyX on Mac OS X (Signing LyX disk images) 
  2048 bit RSA key F7BCC31C, created: 2011-03-09
Keys 1-2 of 2 for "sw...@lyx.org".  Enter number(s), N)ext, or Q)uit > q
$

Note the missing error message while trying to send the key with LANG=C.

Stephan

Re: Basic test of alpha1 tar

2015-11-16 Thread Uwe Stöhr

Am 14.11.2015 um 20:24 schrieb Scott Kostyshak:


If you have time, please download the LyX 2.2.0alpha1 tar and test that
it compiles/installs as expected.


It compiles but not as merged build. With

-DLYX_MERGE_REBUILD=1 -DLYX_MERGE_FILES=1

I get 40 errors, most of them due to a problem with apple script:

  support.lib(_allinone_const.obj) : error LNK2019: link to unresolved 
external symbol ""class lyx::frontend::Application * __cdecl 
lyx::theApp(void)" (?theApp@lyx@@YAPAVApplication@frontend@1@XZ)" in 
Funktion "_applescript_execute_command". 
[D:\LyXGit\Master\compile-result\src\tests\check_ExternalTransforms.vcxproj]
  support.lib(_allinone_const.obj) : error LNK2019: Verweis auf nicht 
aufgel÷stes externes Symbol ""public: __thiscall 
lyx::FuncRequest::FuncRequest(class lyx
::FuncRequest const &,class std::basic_string const &,enum 
lyx::FuncRequest::Origin)" (??0Func

Request@lyx@@QAE@ABV01@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@
2@@std@@W4Origin@01@@Z)" in Funktion "_applescript_execute_command". 
[D:\LyXGit

\Master\compile-result\src\tests\check_ExternalTransforms.vcxproj]

.

regards Uwe


Re: Basic test of alpha1 tar

2015-11-16 Thread Scott Kostyshak
On Tue, Nov 17, 2015 at 01:03:21AM +0100, Stephan Witt wrote:
> Am 17.11.2015 um 00:50 schrieb Stephan Witt :
> 
> > Am 17.11.2015 um 00:06 schrieb Scott Kostyshak :
> > 
> >> On Tue, Nov 17, 2015 at 12:01:16AM +0100, Stephan Witt wrote:
> >>> Am 16.11.2015 um 23:50 schrieb Scott Kostyshak :
> >>> 
>  On Mon, Nov 16, 2015 at 05:48:03PM -0500, Richard Heck wrote:
> > On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
> >> On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
> >> 14.11.2015 um 20:24 schrieb Scott Kostyshak :
> >> Dear all, >>> >>> If you have time, please download the LyX
> > 2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
> > is located here: >>> >>>
> > ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
> > you can, please check that it verifies correctly. This is my >>> first
> > time signing a tar ball. >> >> The signature is ok. The build on Mac OS
> > X works. > > Thanks for checking these. > >> I've uploaded the result
> > here: >> >>
> > https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
> >>> 
> > https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
> > I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
> > used to sign expired a year and a half ago: > > $ gpg --verify *sig >
> > gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
> > gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
> > EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
> > images) > " > gpg: Note: This key has expired! > Primary
> > key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
> > $ > > Is this a problem? > I imagine it is not a problem for alpha, and
> > that I should go ahead and > upload your .dmg but I wanted to check 
> > first.
> > 
> > Just to be clear: You should resign this with the LyX key. Stephan's
> > signature is only to guarantee to you that the binary is valid and from 
> > him.
>  
>  Ah thanks for pointing this out. I actually did not know that. I will
>  resign.
> >>> 
> >>> Yes, please. At the time I made the key I gave it a time limit. Then I've
> >>> published it. Later - after the expiration, I made a new one and Vincent
> >>> "complained" that this key isn't published. I realized then that I can 
> >>> extend
> >>> the period of validity and did that. But now the key servers don't accept 
> >>> this.
> >>> I don't know how to deal with that, sorry :(
> >> 
> >> Not a problem at all for me. I just wanted to double-check.
> >> 
> >> Indeed, it is nice if the key is published. This should be easy with the
> >> command
> >> 
> >> gpg --send-keys B6470BEB
> >> 
> >> where B6470BEB is the ID you want to publish. It seems you have tried
> >> something like that and the keyserver gave an error? What is the error
> >> from that command?
> > 
> > 
> > I've sent it already anno 2011.
> > 
> > This is my current attempt to follow your advice:
> > $ gpg --send-keys EE614DC4
> > gpg: sende Schlüssel EE614DC4 auf den hkp-Server keys.gnupg.net
> > gpg: Schlüsselserver-Zeitüberschreitung
> > gpg: Senden an Schlüsselserver fehlgeschlagen: Schlüsselserverfehler
> > $ LANG=C gpg --send-keys EE614DC4
> > gpg: sending key EE614DC4 to hkp server keys.gnupg.net
> > $ LANG=C gpg --search-keys sw...@lyx.org
> > gpg: searching for "sw...@lyx.org" from hkp server keys.gnupg.net
> > (1) LyX on Mac OS X (Signing LyX disk images) 
> >   2048 bit RSA key EE614DC4, created: 2011-03-09, expires: 2014-03-08 
> > (expired)
> > (2) Stephan Witt 
> > LyX on Mac OS X (Signing LyX disk images) 
> >   2048 bit RSA key F7BCC31C, created: 2011-03-09
> > Keys 1-2 of 2 for "sw...@lyx.org".  Enter number(s), N)ext, or Q)uit > q
> > $
> > 
> > Note the missing error message while trying to send the key with LANG=C.
> 
> Wow, now it's updated! Another example of giving preference to english :)

Sorry :)

> $ LANG=C gpg --search-keys sw...@lyx.org
> gpg: searching for "sw...@lyx.org" from hkp server keys.gnupg.net
> (1)   LyX on Mac OS X (Signing LyX disk images) 
> 2048 bit RSA key EE614DC4, created: 2011-03-09, expires: 2017-03-25
> (2)   Stephan Witt 
>   LyX on Mac OS X (Signing LyX disk images) 
> 2048 bit RSA key F7BCC31C, created: 2011-03-09
> Keys 1-2 of 2 for "sw...@lyx.org".  Enter number(s), N)ext, or Q)uit > q

Just did a 'gpg --recv-keys' and it looks good.

Scott


signature.asc
Description: PGP signature


Re: Basic test of alpha1 tar

2015-11-16 Thread Scott Kostyshak
On Tue, Nov 17, 2015 at 12:01:16AM +0100, Stephan Witt wrote:
> Am 16.11.2015 um 23:50 schrieb Scott Kostyshak :
> 
> > On Mon, Nov 16, 2015 at 05:48:03PM -0500, Richard Heck wrote:
> >> On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
> >>> On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
> >>> 14.11.2015 um 20:24 schrieb Scott Kostyshak :
> >>> Dear all, >>> >>> If you have time, please download the LyX
> >> 2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
> >> is located here: >>> >>>
> >> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
> >> you can, please check that it verifies correctly. This is my >>> first
> >> time signing a tar ball. >> >> The signature is ok. The build on Mac OS
> >> X works. > > Thanks for checking these. > >> I've uploaded the result
> >> here: >> >>
> >> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
>  
> >> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
> >> I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
> >> used to sign expired a year and a half ago: > > $ gpg --verify *sig >
> >> gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
> >> gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
> >> EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
> >> images) > " > gpg: Note: This key has expired! > Primary
> >> key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
> >> $ > > Is this a problem? > I imagine it is not a problem for alpha, and
> >> that I should go ahead and > upload your .dmg but I wanted to check first.
> >> 
> >> Just to be clear: You should resign this with the LyX key. Stephan's
> >> signature is only to guarantee to you that the binary is valid and from 
> >> him.
> > 
> > Ah thanks for pointing this out. I actually did not know that. I will
> > resign.
> 
> Yes, please. At the time I made the key I gave it a time limit. Then I've
> published it. Later - after the expiration, I made a new one and Vincent
> "complained" that this key isn't published. I realized then that I can extend
> the period of validity and did that. But now the key servers don't accept 
> this.
> I don't know how to deal with that, sorry :(

Not a problem at all for me. I just wanted to double-check.

Indeed, it is nice if the key is published. This should be easy with the
command

  gpg --send-keys B6470BEB

where B6470BEB is the ID you want to publish. It seems you have tried
something like that and the keyserver gave an error? What is the error
from that command?

Scott


signature.asc
Description: PGP signature


Re: Basic test of alpha1 tar

2015-11-16 Thread Stephan Witt
Am 17.11.2015 um 00:50 schrieb Stephan Witt :

> Am 17.11.2015 um 00:06 schrieb Scott Kostyshak :
> 
>> On Tue, Nov 17, 2015 at 12:01:16AM +0100, Stephan Witt wrote:
>>> Am 16.11.2015 um 23:50 schrieb Scott Kostyshak :
>>> 
 On Mon, Nov 16, 2015 at 05:48:03PM -0500, Richard Heck wrote:
> On 11/16/2015 05:39 PM, Scott Kostyshak wrote:
>> On Mon, Nov 16, 2015 at 10:59:09AM +0100, Stephan Witt wrote: >> Am 
>> 14.11.2015 um 20:24 schrieb Scott Kostyshak :
>> Dear all, >>> >>> If you have time, please download the LyX
> 2.2.0alpha1 tar and test that >>> it compiles/installs as expected. It
> is located here: >>> >>>
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/ >>> >>> Also if
> you can, please check that it verifies correctly. This is my >>> first
> time signing a tar ball. >> >> The signature is ok. The build on Mac OS
> X works. > > Thanks for checking these. > >> I've uploaded the result
> here: >> >>
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
>>> 
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig
> I've used Qt 5.5.1 to build it. > > Good choice. > > The key you
> used to sign expired a year and a half ago: > > $ gpg --verify *sig >
> gpg: assuming signed data in `LyX-2.2.0alpha1+qt5-x86_64-cocoa.dmg' >
> gpg: Signature made Mon 16 Nov 2015 04:09:30 AM EST using RSA key ID >
> EE614DC4 > gpg: Good signature from "LyX on Mac OS X (Signing LyX disk
> images) > " > gpg: Note: This key has expired! > Primary
> key fingerprint: 4154 4A61 DBB7 7561 47C1  DD4F A149 7996 EE61 > 4DC4 >
> $ > > Is this a problem? > I imagine it is not a problem for alpha, and
> that I should go ahead and > upload your .dmg but I wanted to check first.
> 
> Just to be clear: You should resign this with the LyX key. Stephan's
> signature is only to guarantee to you that the binary is valid and from 
> him.
 
 Ah thanks for pointing this out. I actually did not know that. I will
 resign.
>>> 
>>> Yes, please. At the time I made the key I gave it a time limit. Then I've
>>> published it. Later - after the expiration, I made a new one and Vincent
>>> "complained" that this key isn't published. I realized then that I can 
>>> extend
>>> the period of validity and did that. But now the key servers don't accept 
>>> this.
>>> I don't know how to deal with that, sorry :(
>> 
>> Not a problem at all for me. I just wanted to double-check.
>> 
>> Indeed, it is nice if the key is published. This should be easy with the
>> command
>> 
>> gpg --send-keys B6470BEB
>> 
>> where B6470BEB is the ID you want to publish. It seems you have tried
>> something like that and the keyserver gave an error? What is the error
>> from that command?
> 
> 
> I've sent it already anno 2011.
> 
> This is my current attempt to follow your advice:
> $ gpg --send-keys EE614DC4
> gpg: sende Schlüssel EE614DC4 auf den hkp-Server keys.gnupg.net
> gpg: Schlüsselserver-Zeitüberschreitung
> gpg: Senden an Schlüsselserver fehlgeschlagen: Schlüsselserverfehler
> $ LANG=C gpg --send-keys EE614DC4
> gpg: sending key EE614DC4 to hkp server keys.gnupg.net
> $ LANG=C gpg --search-keys sw...@lyx.org
> gpg: searching for "sw...@lyx.org" from hkp server keys.gnupg.net
> (1)   LyX on Mac OS X (Signing LyX disk images) 
> 2048 bit RSA key EE614DC4, created: 2011-03-09, expires: 2014-03-08 
> (expired)
> (2)   Stephan Witt 
>   LyX on Mac OS X (Signing LyX disk images) 
> 2048 bit RSA key F7BCC31C, created: 2011-03-09
> Keys 1-2 of 2 for "sw...@lyx.org".  Enter number(s), N)ext, or Q)uit > q
> $
> 
> Note the missing error message while trying to send the key with LANG=C.

Wow, now it's updated! Another example of giving preference to english :)

$ LANG=C gpg --search-keys sw...@lyx.org
gpg: searching for "sw...@lyx.org" from hkp server keys.gnupg.net
(1) LyX on Mac OS X (Signing LyX disk images) 
  2048 bit RSA key EE614DC4, created: 2011-03-09, expires: 2017-03-25
(2) Stephan Witt 
LyX on Mac OS X (Signing LyX disk images) 
  2048 bit RSA key F7BCC31C, created: 2011-03-09
Keys 1-2 of 2 for "sw...@lyx.org".  Enter number(s), N)ext, or Q)uit > q

Stephan

Re: Basic test of alpha1 tar

2015-11-16 Thread Scott Kostyshak
On Tue, Nov 17, 2015 at 12:49:02AM +0100, Uwe Stöhr wrote:
> Am 14.11.2015 um 20:24 schrieb Scott Kostyshak:
> 
> >If you have time, please download the LyX 2.2.0alpha1 tar and test that
> >it compiles/installs as expected.
> 
> It compiles but not as merged build. With
> 
> -DLYX_MERGE_REBUILD=1 -DLYX_MERGE_FILES=1
> 
> I get 40 errors, most of them due to a problem with apple script:

Thanks for testing. This is my fault for not testing compilation with
monolithic build. I will (hopefully) not make the same mistake again.
The monolithic build now succeeds for autotools. I think there might
still be an error for the CMake monolithic build that is being
investigated.

Scott

>   support.lib(_allinone_const.obj) : error LNK2019: link to unresolved
> external symbol ""class lyx::frontend::Application * __cdecl
> lyx::theApp(void)" (?theApp@lyx@@YAPAVApplication@frontend@1@XZ)" in
> Funktion "_applescript_execute_command".
> [D:\LyXGit\Master\compile-result\src\tests\check_ExternalTransforms.vcxproj]
>   support.lib(_allinone_const.obj) : error LNK2019: Verweis auf nicht
> aufgel÷stes externes Symbol ""public: __thiscall
> lyx::FuncRequest::FuncRequest(class lyx
> ::FuncRequest const &,class std::basic_string std::char_traits,class std::allocator > const &,enum
> lyx::FuncRequest::Origin)" (??0Func
> Request@lyx@@QAE@ABV01@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@
> 2@@std@@W4Origin@01@@Z)" in Funktion "_applescript_execute_command".
> [D:\LyXGit
> \Master\compile-result\src\tests\check_ExternalTransforms.vcxproj]
> 
> .
> 
> regards Uwe


signature.asc
Description: PGP signature


Re: Basic test of alpha1 tar

2015-11-16 Thread Stephan Witt
Am 14.11.2015 um 20:24 schrieb Scott Kostyshak :

> Dear all,
> 
> If you have time, please download the LyX 2.2.0alpha1 tar and test that
> it compiles/installs as expected. It is located here:
> 
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0alpha1/
> 
> Also if you can, please check that it verifies correctly. This is my
> first time signing a tar ball.

The signature is ok. The build on Mac OS X works.

I've uploaded the result here:

https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg
https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0alpha1%2Bqt5-x86_64-cocoa.dmg.sig

I've used Qt 5.5.1 to build it.

Stephan

Re: Basic test of alpha1 tar

2015-11-15 Thread Jürgen Spitzmüller
Am Sonntag 15 November 2015, 14:44:40 schrieb Kornel Benko:
> Cmake build: Using '-DLYX_MERGE_FILES=ON' I get this error:
> 
> [ 46%] Building CXX object
> src/support/CMakeFiles/support.dir/_allinone_const.C.o cd
> /usr/BUILD/BuildLyxGitQtlocal/src/support && /usr/bin/c++  
> -DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DQT_CORE_LIB -DQT_GUI_LIB
> -I/usr/BUILD/BuildLyxGitQtlocal -I/usr/src/lyx/lyx-git/src
> -I/usr/include/enchant -I/usr/src/lyx/lyx-git/boost
> -I/usr/src/lyx/lyx-git/src/support
> -I/usr/BUILD/BuildLyxGitQtlocal/src/support
> -I/usr/src/lyx/lyx-git/src/support/mythes -isystem /usr/include/qt5
> -isystem /usr/include/qt5/QtCore -isystem
> /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -isystem
> /usr/include/qt5/QtGui  -Wall -Wunused-parameter --std=c++11
> -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++11
> -fno-strict-aliasing -O0 -g3 -D_DEBUG -fPIC  
> -DBOOST_USER_CONFIG="" -o
> CMakeFiles/support.dir/_allinone_const.C.o -c
> /usr/BUILD/BuildLyxGitQtlocal/src/support/_allinone_const.C In file
> included from /usr/src/lyx/lyx-git/src/support/AppleScriptProxy.cpp:17:0,
> from /usr/BUILD/BuildLyxGitQtlocal/src/support/_allinone_const.C:48:
> /usr/src/lyx/lyx-git/src/LyX.h:124:18: error: reference to ‘ErrorItem’ is
> ambiguous void printError(ErrorItem const &);
>   ^
> /usr/src/lyx/lyx-git/src/LyX.h:27:7: note: candidates are: class
> lyx::ErrorItem class ErrorItem;
>^

This is completely unrelated to my patch.

Try if the attached patch helps.

Jürgen


diff --git a/src/support/debug.cpp b/src/support/debug.cpp
index f44f7fc..538b487 100644
--- a/src/support/debug.cpp
+++ b/src/support/debug.cpp
@@ -31,14 +31,14 @@ namespace lyx {
 
 namespace {
 
-struct ErrorItem {
+struct DebugErrorItem {
 	Debug::Type level;
 	char const * name;
 	char const * desc;
 };
 
 
-ErrorItem errorTags[] = {
+DebugErrorItem errorTags[] = {
 	{ Debug::NONE,  "none",  N_("No debugging messages")},
 	{ Debug::INFO,  "info",  N_("General information")},
 	{ Debug::INIT,  "init",  N_("Program initialisation")},


Re: Basic test of alpha1 tar

2015-11-15 Thread Jürgen Spitzmüller
Am Sonntag 15 November 2015, 16:16:35 schrieb Kornel Benko:
> It does, in this case. But as the compilation proceeds, I get lot of errors
> and warnings. Is the attached too big for list?

That's at least definitely too much for my agenda.

Let's see first if we can get monolithic build working again for autotools.

I don't know if it ever worked with CMake.

Jürgen

> > Jürgen
> 
>   Kornel




Re: Basic test of alpha1 tar

2015-11-15 Thread Kornel Benko
Am Sonntag, 15. November 2015 um 14:30:21, schrieb Jürgen Spitzmüller 

> Am Samstag 14 November 2015, 21:34:43 schrieb Scott Kostyshak:
> > On Sat, Nov 14, 2015 at 04:31:55PM -0800, Pavel Sanda wrote:
> > > Scott Kostyshak wrote:
> > > > Dear all,
> > > > 
> > > > If you have time, please download the LyX 2.2.0alpha1 tar and test that
> > > 
> > > > it compiles/installs as expected. It is located here:
> > > Monolithic build seems to be broken:
> > I can reproduce but I'm not sure how to fix it. Should I do a git
> > bisect?
> 
> This probably points to 
> http://www.lyx.org/trac/changeset/7f1d33efc1d0b4302875706ba85d42c2a8f35a67/lyxgit/
> 
> Please try the attached patch.
> 
> Jürgen
> 
> > 
> > Scott

Cmake build: Using '-DLYX_MERGE_FILES=ON' I get this error:

[ 46%] Building CXX object 
src/support/CMakeFiles/support.dir/_allinone_const.C.o
cd /usr/BUILD/BuildLyxGitQtlocal/src/support && /usr/bin/c++   
-DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DQT_CORE_LIB -DQT_GUI_LIB 
-I/usr/BUILD/BuildLyxGitQtlocal -I/usr/src/lyx/lyx-git/src 
-I/usr/include/enchant -I/usr/src/lyx/lyx-git/boost 
-I/usr/src/lyx/lyx-git/src/support -I/usr/BUILD/BuildLyxGitQtlocal/src/support 
-I/usr/src/lyx/lyx-git/src/support/mythes -isystem /usr/include/qt5 -isystem 
/usr/include/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -isystem 
/usr/include/qt5/QtGui  -Wall -Wunused-parameter --std=c++11 
-fno-strict-aliasing  -Wall -Wunused-parameter --std=c++11 -fno-strict-aliasing 
-O0 -g3 -D_DEBUG -fPIC   -DBOOST_USER_CONFIG="" -o 
CMakeFiles/support.dir/_allinone_const.C.o -c 
/usr/BUILD/BuildLyxGitQtlocal/src/support/_allinone_const.C
In file included from 
/usr/src/lyx/lyx-git/src/support/AppleScriptProxy.cpp:17:0,
 from 
/usr/BUILD/BuildLyxGitQtlocal/src/support/_allinone_const.C:48:
/usr/src/lyx/lyx-git/src/LyX.h:124:18: error: reference to ‘ErrorItem’ is 
ambiguous
  void printError(ErrorItem const &);
  ^
/usr/src/lyx/lyx-git/src/LyX.h:27:7: note: candidates are: class lyx::ErrorItem
 class ErrorItem;
   ^
In file included from 
/usr/BUILD/BuildLyxGitQtlocal/src/support/_allinone_const.C:43:0:
/usr/src/lyx/lyx-git/src/support/debug.cpp:34:8: note: struct 
lyx::{anonymous}::ErrorItem
 struct ErrorItem {
^
In file included from 
/usr/src/lyx/lyx-git/src/support/AppleScriptProxy.cpp:17:0,
 from 
/usr/BUILD/BuildLyxGitQtlocal/src/support/_allinone_const.C:48:
/usr/src/lyx/lyx-git/src/LyX.h:124:18: error: ‘ErrorItem’ has not been declared
  void printError(ErrorItem const &);
  ^
make[2]: *** [src/support/CMakeFiles/support.dir/_allinone_const.C.o] Chyba 1
make[2]: Leaving directory `/usr/BUILD/BuildLyxGitQtlocal'
make[1]: *** [src/support/CMakeFiles/support.dir/all] Chyba 2
make[1]: Leaving directory `/usr/BUILD/BuildLyxGitQtlocal'

Normally I never use monolithic build, so maybe it was always erroneous.
Looks like disabling it would be a good idea.

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: Basic test of alpha1 tar

2015-11-15 Thread Guillaume Munch

Le 15/11/2015 01:18, Pavel Sanda a écrit :

Scott Kostyshak wrote:

Dear all,

If you have time, please download the LyX 2.2.0alpha1 tar and test that
it compiles/installs as expected. It is located here:


non harmful, but warnings:

GuiViewSource.cpp:174:9: warning: 'QString 
lyx::frontend::{anonymous}::prependTexRow(const lyx::TexRow&, const QString&)' 
defined but not used [-Wunused-function]
  QString prependTexRow(TexRow const & texrow, QString const & content)
   ^



Fixed now.


insets/InsetListingsParams.cpp: In constructor 
'lyx::{anonymous}::ParValidator::ParValidator()':
insets/InsetListingsParams.cpp:298:1: note: variable tracking size limit 
exceeded with -fvar-tracking-assignments, retrying without
  ParValidator::ParValidator()

(gcc 4.9.3)
P






Re: Basic test of alpha1 tar

2015-11-15 Thread Jürgen Spitzmüller
Am Samstag 14 November 2015, 21:34:43 schrieb Scott Kostyshak:
> On Sat, Nov 14, 2015 at 04:31:55PM -0800, Pavel Sanda wrote:
> > Scott Kostyshak wrote:
> > > Dear all,
> > > 
> > > If you have time, please download the LyX 2.2.0alpha1 tar and test that
> > 
> > > it compiles/installs as expected. It is located here:
> > Monolithic build seems to be broken:
> I can reproduce but I'm not sure how to fix it. Should I do a git
> bisect?

This probably points to 
http://www.lyx.org/trac/changeset/7f1d33efc1d0b4302875706ba85d42c2a8f35a67/lyxgit/

Please try the attached patch.

Jürgen

> 
> Scott

diff --git a/src/frontends/qt4/GuiBox.cpp b/src/frontends/qt4/GuiBox.cpp
index 0999039..e4d4256 100644
--- a/src/frontends/qt4/GuiBox.cpp
+++ b/src/frontends/qt4/GuiBox.cpp
@@ -103,16 +103,6 @@ static QList colors()
 }
 
 
-namespace {
-
-bool ColorSorter(ColorCode lhs, ColorCode rhs)
-{
-	return support::compare_no_case(lcolor.getGUIName(lhs), lcolor.getGUIName(rhs)) < 0;
-}
-
-} // namespace anon
-
-
 GuiBox::GuiBox(QWidget * parent) : InsetParamsWidget(parent)
 {
 	setupUi(this);
diff --git a/src/frontends/qt4/GuiCharacter.cpp b/src/frontends/qt4/GuiCharacter.cpp
index c673d2d..e016876 100644
--- a/src/frontends/qt4/GuiCharacter.cpp
+++ b/src/frontends/qt4/GuiCharacter.cpp
@@ -192,12 +192,6 @@ void fillComboColor(QComboBox * combo, QList const & list)
 	combo->addItem(qt_("Reset"), "inherit");
 }
 
-
-bool ColorSorter(ColorCode lhs, ColorCode rhs)
-{
-	return support::compare_no_case(lcolor.getGUIName(lhs), lcolor.getGUIName(rhs)) < 0;
-}
-
 } // namespace anon
 
 GuiCharacter::GuiCharacter(GuiView & lv)
diff --git a/src/frontends/qt4/GuiPrefs.cpp b/src/frontends/qt4/GuiPrefs.cpp
index a076402..2c99dee 100644
--- a/src/frontends/qt4/GuiPrefs.cpp
+++ b/src/frontends/qt4/GuiPrefs.cpp
@@ -1115,19 +1115,6 @@ void PrefScreenFonts::selectTypewriter(const QString & name)
 /
 
 
-namespace {
-
-struct ColorSorter
-{
-	bool operator()(ColorCode lhs, ColorCode rhs) const {
-		return
-			compare_no_case(lcolor.getGUIName(lhs), lcolor.getGUIName(rhs)) < 0;
-	}
-};
-
-} // namespace anon
-
-
 PrefColors::PrefColors(GuiPreferences * form)
 	: PrefModule(catLookAndFeel, N_("Colors"), form)
 {
@@ -1164,7 +1151,7 @@ PrefColors::PrefColors(GuiPreferences * form)
 			continue;
 		lcolors_.push_back(lc);
 	}
-	sort(lcolors_.begin(), lcolors_.end(), ColorSorter());
+	qSort(lcolors_.begin(), lcolors_.end(), ColorSorter);
 	vector::const_iterator cit = lcolors_.begin();
 	vector::const_iterator const end = lcolors_.end();
 	for (; cit != end; ++cit) {
diff --git a/src/frontends/qt4/qt_helpers.cpp b/src/frontends/qt4/qt_helpers.cpp
index 4eacaca..c1294e5 100644
--- a/src/frontends/qt4/qt_helpers.cpp
+++ b/src/frontends/qt4/qt_helpers.cpp
@@ -213,6 +213,12 @@ QString formatLocFPNumber(double d)
 }
 
 
+bool ColorSorter(ColorCode lhs, ColorCode rhs)
+{
+	return compare_no_case(lcolor.getGUIName(lhs), lcolor.getGUIName(rhs)) < 0;
+}
+
+
 void setValid(QWidget * widget, bool valid)
 {
 	if (valid) {
diff --git a/src/frontends/qt4/qt_helpers.h b/src/frontends/qt4/qt_helpers.h
index fcdcd53..d4afc78 100644
--- a/src/frontends/qt4/qt_helpers.h
+++ b/src/frontends/qt4/qt_helpers.h
@@ -13,6 +13,7 @@
 #ifndef QTHELPERS_H
 #define QTHELPERS_H
 
+#include "ColorSet.h"
 #include "Length.h"
 #include "support/qstring_helpers.h"
 #include "support/filetools.h"
@@ -73,6 +74,9 @@ void doubleToWidget(QLineEdit * input, std::string const & value,
  */
 QString formatLocFPNumber(double d);
 
+/// Method to sort colors by GUI name in combo widgets
+bool ColorSorter(ColorCode lhs, ColorCode rhs);
+
 /// colors a widget red if invalid
 void setValid(QWidget * widget, bool valid);
 


Re: Basic test of alpha1 tar

2015-11-15 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> And how does this compare to a 2.1 build?

2.1 seems to be the same as 2.0.

> Could you provide a profile log for 2.2 being slow?

Not now, but i will try get to it, it's pretty annoying.

BTW my defaults are:
xset r rate 300 180
maybe you can see it with this autorepeat rate as well?

Pavel


Re: Basic test of alpha1 tar

2015-11-15 Thread Pavel Sanda
Scott Kostyshak wrote:
> Same Qt version?

Yes, 4.8.5. P


Re: Basic test of alpha1 tar

2015-11-15 Thread Pavel Sanda
Jürgen Spitzmüller wrote:
> This probably points to 
> http://www.lyx.org/trac/changeset/7f1d33efc1d0b4302875706ba85d42c2a8f35a67/lyxgit/
> 
> Please try the attached patch.

Yep, this fixes it. Pavel


Re: Basic test of alpha1 tar

2015-11-15 Thread Jean-Marc Lasgouttes

Le 15/11/2015 03:14, Pavel Sanda a écrit :

Pavel Sanda wrote:

non harmful, but warnings:


Apart from that I was able to build and run it on gentoo system.

Sadly, moving cursor in paragraph is considerably slower than
in my current 2.0 build :(


And how does this compare to a 2.1 build?

Could you provide a profile log for 2.2 being slow?

JMarc



Re: Basic test of alpha1 tar

2015-11-15 Thread Georg Baum
Works fine here (Debian jessie).


Georg



Re: Basic test of alpha1 tar

2015-11-14 Thread Scott Kostyshak
On Sat, Nov 14, 2015 at 04:31:55PM -0800, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > Dear all,
> > 
> > If you have time, please download the LyX 2.2.0alpha1 tar and test that
> > it compiles/installs as expected. It is located here:
> 
> Monolithic build seems to be broken:

I can reproduce but I'm not sure how to fix it. Should I do a git
bisect?

Scott


signature.asc
Description: PGP signature


Re: Basic test of alpha1 tar

2015-11-14 Thread Pavel Sanda
Pavel Sanda wrote:
> non harmful, but warnings:

Apart from that I was able to build and run it on gentoo system.

Sadly, moving cursor in paragraph is considerably slower than 
in my current 2.0 build :(

Pavel


Re: Basic test of alpha1 tar

2015-11-14 Thread Scott Kostyshak
On Sat, Nov 14, 2015 at 06:14:44PM -0800, Pavel Sanda wrote:
> Pavel Sanda wrote:
> > non harmful, but warnings:
> 
> Apart from that I was able to build and run it on gentoo system.
> 
> Sadly, moving cursor in paragraph is considerably slower than 
> in my current 2.0 build :(

Same Qt version?

Scott


signature.asc
Description: PGP signature


Re: Basic test of alpha1 tar

2015-11-14 Thread Pavel Sanda
Scott Kostyshak wrote:
> Also if you can, please check that it verifies correctly. This is my
> first time signing a tar ball.

Sigs are correct. P


Re: Basic test of alpha1 tar

2015-11-14 Thread Pavel Sanda
Scott Kostyshak wrote:
> Dear all,
> 
> If you have time, please download the LyX 2.2.0alpha1 tar and test that
> it compiles/installs as expected. It is located here:

Monolithic build seems to be broken:

In file included from liblyxqt4.cpp:27:0:
GuiCharacter.cpp: In function 'bool 
lyx::frontend::{anonymous}::ColorSorter(lyx::ColorCode, lyx::ColorCode)':
GuiCharacter.cpp:196:6: error: redefinition of 'bool 
lyx::frontend::{anonymous}::ColorSorter(lyx::ColorCode, lyx::ColorCode)'
 bool ColorSorter(ColorCode lhs, ColorCode rhs)
  ^
In file included from liblyxqt4.cpp:23:0:
GuiBox.cpp:108:6: note: 'bool 
lyx::frontend::{anonymous}::ColorSorter(lyx::ColorCode, lyx::ColorCode)' 
previously defined here
 bool ColorSorter(ColorCode lhs, ColorCode rhs)
  ^
In file included from liblyxqt4.cpp:64:0:
GuiPrefs.cpp: In constructor 
'lyx::frontend::PrefColors::PrefColors(lyx::frontend::GuiPreferences*)':
GuiPrefs.cpp:1167:53: error: too few arguments to function 'bool 
lyx::frontend::{anonymous}::ColorSorter(lyx::ColorCode, lyx::ColorCode)'
  sort(lcolors_.begin(), lcolors_.end(), ColorSorter());
 ^
In file included from liblyxqt4.cpp:23:0:
GuiBox.cpp:108:6: note: declared here
 bool ColorSorter(ColorCode lhs, ColorCode rhs)
  ^
In file included from liblyxqt4.cpp:84:0:
GuiView.cpp: At global scope:
GuiView.cpp:272:16: warning: 'lyx::frontend::GuiView::GuiViewPrivate' has a 
field 'lyx::frontend::GuiView::GuiViewPrivate::bg_widget_' whose type uses the 
anonymous namespace
 class GuiView::GuiViewPrivate
^
In file included from liblyxqt4.cpp:98:0:
Menus.cpp:1704:14: warning: 'lyx::frontend::Menu::Impl' has a field 
'lyx::frontend::Menu::Impl::top_level_menu' whose type uses the anonymous 
namespace
 struct Menu::Impl
  ^
Menus.cpp:1829:15: warning: 'lyx::frontend::Menus::Impl' has a field 
'lyx::frontend::Menus::Impl::menulist_' whose type uses the anonymous namespace
 struct Menus::Impl {
   ^
Menus.cpp:1829:15: warning: 'lyx::frontend::Menus::Impl' has a field 
'lyx::frontend::Menus::Impl::menubar_' whose type uses the anonymous namespace
In file included from /usr/include/qt4/QtCore/qchar.h:45:0,
 from /usr/include/qt4/QtCore/qstring.h:45,
 from /usr/include/qt4/QtCore/QString:1,
 from Dialog.h:21,
 from Dialog.cpp:13,
 from liblyxqt4.cpp:4:
Resources.cpp:64999:44: warning: 'qInitResources_Resources__init_variable__' 
defined but not used [-Wunused-variable]
 Q_CONSTRUCTOR_FUNCTION(QT_MANGLE_NAMESPACE(qInitResources_Resources))
^
/usr/include/qt4/QtCore/qglobal.h:826:21: note: in definition of macro 
'Q_CONSTRUCTOR_FUNCTION0'
static const int AFUNC ## __init_variable__ = AFUNC();
 ^
Resources.cpp:64999:1: note: in expansion of macro 'Q_CONSTRUCTOR_FUNCTION'
 Q_CONSTRUCTOR_FUNCTION(QT_MANGLE_NAMESPACE(qInitResources_Resources))
 ^
Resources.cpp:64999:24: note: in expansion of macro 'QT_MANGLE_NAMESPACE'
 Q_CONSTRUCTOR_FUNCTION(QT_MANGLE_NAMESPACE(qInitResources_Resources))
^
In file included from liblyxqt4.cpp:85:0:
GuiViewSource.cpp:174:9: warning: 'QString 
lyx::frontend::{anonymous}::prependTexRow(const lyx::TexRow&, const QString&)' 
defined but not used [-Wunused-function]
 QString prependTexRow(TexRow const & texrow, QString const & content)
 ^
Makefile:967: recipe for target 'liblyxqt4.o' failed
make[6]: *** [liblyxqt4.o] Error 1
make[6]: Leaving directory 
'/var/tmp/portage/app-office/lyx-2.2.0_alpha1/work/lyx-2.2.0alpha1/src/frontends/qt4'


Pavel


Re: Basic test of alpha1 tar

2015-11-14 Thread Pavel Sanda
Scott Kostyshak wrote:
> Dear all,
> 
> If you have time, please download the LyX 2.2.0alpha1 tar and test that
> it compiles/installs as expected. It is located here:

non harmful, but warnings:

GuiViewSource.cpp:174:9: warning: 'QString 
lyx::frontend::{anonymous}::prependTexRow(const lyx::TexRow&, const QString&)' 
defined but not used [-Wunused-function]
 QString prependTexRow(TexRow const & texrow, QString const & content)
  ^

insets/InsetListingsParams.cpp: In constructor 
'lyx::{anonymous}::ParValidator::ParValidator()':
insets/InsetListingsParams.cpp:298:1: note: variable tracking size limit 
exceeded with -fvar-tracking-assignments, retrying without
 ParValidator::ParValidator()

(gcc 4.9.3)
P