Hi,
thank you very much for investigation, the 2.5.dev output
The ipv6calc Homepage
pb at bieringer dot de
Peter
Bieringer
pb at bieringer dot de
12.0.0
2025-01-28
PB
General
looks like in this part mostly identical again with LyX 2.3
https
" in same directory.
The one worked with LyX 2.3 is here:
https://github.com/pbiering/ipv6calc/tree/4.2.2/doc
Thank you for digging into.
Regards,
Peter
Am 06.02.25 um 04:00 schrieb Thibaut Cuvelier:
On Wed, 5 Feb 2025 at 05:42, Peter Bieringer <mailto:p...@bieringer.de>>
6calc.lyx
Tweak#2: using Perl to reactivate the content
=> see https://latex.org/forum/viewtopic.php?t=36140
Then the conversion to HTML is proper working and the revision history
box appears in HTML.
Run conversion:
xsltproc -o ipv6calc.html db2xhtml-ipv6calc.xsl ipv6calc.xml
Hi everyone,
There is a typo on line 6490 of LatexConfig.lyx: "appaerance" should be
"appearance".
Peter
***
Peter J. Puchyr
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
.
I’ll experiment some more. If I find other crashes I’ll report. But
on the whole, so far, this seems a pretty robust and capable
environment.
Best,
Peter
On 24 Jan 2018, at 19:53, LyX Ticket Tracker wrote:
#10994: Lyx 2.3.3 crash report (on tex file import
Apologies. I meant 2.3.0 rc1
On 24 Jan 2018, at 19:44, LyX Ticket Tracker wrote:
> #10994: Lyx 2.3.3 crash report (on tex file import)
> -+--
> Reporter: pwgallagher | Owner: lasgouttes
> Type: defect | Status: new
> Pri
interest rate annually.
Let us know if you have a good project which requires funding.
Also, you can earn one (1) percent Agents / Brokers fee if you refer project
owners in need of finance.
I wait your reply.
Sincerely,
Peter Karl
Am 18. April 2016 22:56:06 MESZ, schrieb Richard Heck :
>On 04/18/2016 04:32 PM, Peter Kümmel wrote:
>> Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel"
>:
>>> I also think these branches are overkill.
>>>
>>> I would only use master and 2.
Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" :
>Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum
>:
>>Richard Heck wrote:
>>
>>> We now have three staging branches. These are:
>>>
>>> 2.3-staging
>>> 2.2.1-st
Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" :
>Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum
>:
>>Richard Heck wrote:
>>
>>> We now have three staging branches. These are:
>>>
>>> 2.3-staging
>>> 2.2.1-st
t
>need backporting.
>
>
>Georg
I also think these branches are overkill.
I would only use master and 2.2. No 2.3, it is so far away that it could be in
master.
2.2 should be always stable so that at any time a short living 2.2.x could be
branched until the release is done. After the tag 2.2.x will be deleted then.
Similar to
https://wiki.qt.io/Branch_Guidelines
Peter
+1200, Andrew Parsloe wrote:
On 3/04/2016 2:44 a.m., Peter Kümmel wrote:
I've downloaded a more recent version, and the console window is absent,
which is good. However, there is a problem with \lyxformat numbers. I see
that a new document in bleeding-edge LyX is format 507. Documents in beta2
ar
Am 2. April 2016 18:48:12 MESZ, schrieb Scott Kostyshak :
>On Sat, Apr 02, 2016 at 11:11:33AM +0200, Peter Kümmel wrote:
>>
>> I've found a solution for the strange crashes, strfwd.h must always
>included first, if not the compiler makes assumption which are wrong.
>&
Am 2. April 2016 11:26:06 MESZ, schrieb Andrew Parsloe :
>Hullo Peter,
>I've tried twice now to get a working bleeding-edge LyX (on a windows 7
>
>machine), since there have been occasions recently when it would have
>been helpful to have someone testing latest commits on
Am 27.03.2016 um 21:38 schrieb Uwe Stöhr:
Am 20.03.2016 um 21:48 schrieb Scott Kostyshak:
Peter stated [1] that the patch is not necessary for compilation with
MSVC 2010.
But it doesn't harm then, see my today's post in the plans thread.
It seems the majority opinion is to r
Am 27.03.2016 um 21:33 schrieb Uwe Stöhr:
Am 19.03.2016 um 08:18 schrieb Scott Kostyshak:
Uwe, are you OK with shipping the official RC1 with 5.5.1 and MSVC 2010?
From what I understand, that's the recommendation of Georg and Peter and
it seems like the safest approach.
This is not
Am 11.03.2016 um 04:49 schrieb Scott Kostyshak:
On Thu, Mar 10, 2016 at 12:50:25AM +0100, Uwe Stöhr wrote:
Am 09.03.2016 um 04:37 schrieb Scott Kostyshak:
8. What am I missing?
- I need for Qt 5.6 this patch from Peter to be applied:
https://github.com/syntheticpp/lyx/commit
hub.com/syntheticpp/lyx/commit/2470fb442cb2b04a69b2030f28f1da60221556a7?diff=unified
Peter
outside because the target is missing.
I get the same problem with MSVC2010. In LyX's 2.1.x branch the target is
there, but not in master.
thanks and regards
Uwe
You've passed -G two times.
Peter
Am 21.02.2016 um 17:59 schrieb Scott Kostyshak:
On Mon, Feb 15, 2016 at 05:06:19PM +0100, Kornel Benko wrote:
Am Sonntag, 14. Februar 2016 um 23:39:00, schrieb Pavel Sanda
Peter Kümmel wrote:
Uwe still gets the following errors from the tar I sent to him:
D:\LyXGit\LyX22beta3\3rdparty
Am 16.02.2016 um 20:08 schrieb Georg Baum:
Peter Kümmel wrote:
Am 15.02.2016 um 22:06 schrieb Georg Baum:
Done .
Thanks.
What about the unused files libs/regex/regex.vcproj,
libs/signals/signals.vcproj, libs/regex/src/icu.cpp,
libs/regex/src/usinstances.cpp and libs/regex/src
Am 15.02.2016 um 22:06 schrieb Georg Baum:
Peter Kümmel wrote:
commit 6de524e6cf2d13636b04b9bb850d0a8b1eaa398b
Author: Peter Kümmel
Date: Sat Feb 13 18:34:08 2016 +0100
Add missing boost files to source package
and remove Visual Studio files, we build with CMake on Windows
trivial.
Scott
I would say: release tag 2.2.0beta2.
There is only the problem with untaring on Windows
For beta3:
- add zip to lyxdist
- some cleanup in boost
Peter
Am 15.02.2016 um 22:06 schrieb Georg Baum:
Peter Kümmel wrote:
commit 6de524e6cf2d13636b04b9bb850d0a8b1eaa398b
Author: Peter Kümmel
Date: Sat Feb 13 18:34:08 2016 +0100
Add missing boost files to source package
and remove Visual Studio files, we build with CMake on Windows
Am 14.02.2016 um 21:27 schrieb Jean-Marc Lasgouttes:
Le 14/02/16 19:54, Georg Baum a écrit :
Peter Kümmel wrote:
Am 14.02.2016 um 19:03 schrieb Scott Kostyshak:
Why is numeric_cast_traits_common.hpp not being found?
Have you checked if it's part of the tar you send to Uwe?
The fi
Am 14.02.2016 um 19:03 schrieb Scott Kostyshak:
Why is numeric_cast_traits_common.hpp not being found?
Have you checked if it's part of the tar you send to Uwe?
The files I listed above are part of the tar. I will send the tar to you
privately.
When I unpack with WinRAR it looks like this
Am 14.02.2016 um 19:03 schrieb Scott Kostyshak:
On Sun, Feb 14, 2016 at 06:36:15PM +0100, Peter Kümmel wrote:
Am 14.02.2016 um 17:17 schrieb Scott Kostyshak:
On Sat, Feb 13, 2016 at 01:44:30PM -0500, Scott Kostyshak wrote:
On Sat, Feb 13, 2016 at 01:24:20PM -0500, Scott Kostyshak wrote
:
Thanks for testing, Peter. I'll wait for a fix, and then I suppose we
move to beta3?
Sorry, but why do we act like beginners?
I wrote what is missing in the tarball. So why not add these files, send me
the tarball by private mail to check and then announce a new beta
You are right that this is
Am 13.02.2016 um 18:01 schrieb Scott Kostyshak:
On Sat, Feb 13, 2016 at 12:34:26PM +0100, Peter Kümmel wrote:
Am 13.02.2016 um 10:57 schrieb Georg Baum:
Scott Kostyshak wrote:
I agree that it would be nice to remove unnecessary files. As far as
figuring out which files are unnecessary, I
/conversion/detail/preprocessed/numeric_cast_traits_common.hpp
3rdparty/boost/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp
Peter
Georg
Just for the record:
When configuring LyX on Windows with cmake-gui,
CMAKE_PREFIX_PATH must point to a Qt installation like
"C:/Qt/Qt5.5.1/5.5/msvc2010".
Peter
Am 19.01.2016 um 22:09 schrieb Uwe Stöhr:
Am 19.01.2016 um 17:15 schrieb Peter Kümmel:
I'll move them again out of the source tree.
But then users might have a problem. For example my git older for master
is D:\LyXGit\Master. It is forbidden to create a new folder in
D:\LyXGit to a
Am 19.01.2016 um 02:24 schrieb Uwe Stöhr:
Am 18.01.2016 um 10:18 schrieb Peter Kümmel:
Maybe there is still a Qt 4 qmake.exe in PATH.
No, the solution are path changes:
- Qt is installed here in
C:\Qt\Qt5-5-1-2010\5.5\msvc2010\bin
Ah, this explains all problems!
not in
C:\Qt
ibgit2 instead of the system git? Was it
evaluated? I assume then there we have much more control over the git files.
Peter
Am 18. Januar 2016 09:33:17 MEZ, schrieb "Uwe Stöhr" :
>
>
> Original Message
>From: Peter Kümmel
>Sent: Montag, 18. Januar 2016 03:49
>To: Uwe Stöhr; Scott Kostyshak; LyX Developers
>Subject: Re: Beta hopefully soon, only waiting on Windows installer(s)
>
Am 18. Januar 2016 09:17:01 MEZ, schrieb "Uwe Stöhr" :
>
>
>From: Peter Kümmel
>
>Sent: Montag, 18. Januar 2016 03:18
>
>
>> Something is different on your system, there should be no problem
>with finding Qt 5. How actual is your cmake installation?
>
Am 18. Januar 2016 09:20:32 MEZ, schrieb "Uwe Stöhr" :
>
>
>From: Peter Kümmel
>
>Sent: Montag, 18. Januar 2016 03:26
>
>
>> Do you mean you have to specify the Qt pathes in the installer
>script?
>
>
>No, in CMake as I wrote. My Script works fin
gain withj
>your
>> current way of calling cmake).
>
>OK, now with Qt 5 there are only 6 Qt paths to be specified. But I
>think
>that this can still be reduced to one, since all Qt installations on
>Windows have the same structure. So it should be sufficient to specify
>And to repeat myself, building the installer was never a problem,
Great! And it looks like necessary stuff is committet by you to the repository.
Ideally all files needed for the installer would be part of the repository, but
this would mean to add multiple MB of Windows binaries which is not
Am 18. Januar 2016 01:32:15 MEZ, schrieb "Uwe Stöhr" :
>Am 16.01.2016 um 16:58 schrieb Scott Kostyshak:
>
>> Uwe, I know you do not have much time but are you willing to make
>both
>> installers? It seems there is help available for both the MSVC and
>mingw
>> if you get stuck.
>
>To repeat, the in
Am 18. Januar 2016 01:10:41 MEZ, schrieb "Uwe Stöhr" :
>Am 17.01.2016 um 18:59 schrieb Peter Kümmel:
>
> > as you told, you have big problems in settings up clean build.
>> Therefore I've changed the build5-2010.bat file you added for
>building
>> with MSV
Am 18. Januar 2016 01:24:38 MEZ, schrieb "Uwe Stöhr" :
>Am 17.01.2016 um 03:22 schrieb Peter Kümmel:
>
>> I would release the beta with the available Windows installer, but
>would also mention, that because of men power this time on Windows
>there will be nothing bet
>
>I miss in your script a method to select to build a devel or an install
We need a reliable script for the installer input, which only builds lyx
nothing else, this is the intention. No parameters no choice.
>Moreover
>-DLYX_MERGE_REBUILD=1
This flag is only needed when you rebuild again,
gain withj
>your
>> current way of calling cmake).
>
>OK, now with Qt 5 there are only 6 Qt paths to be specified. But I
>think
>that this can still be reduced to one, since all Qt installations on
>Windows have the same structure. So it should be sufficient to specify
Am 18. Januar 2016 01:10:41 MEZ, schrieb "Uwe Stöhr" :
>Am 17.01.2016 um 18:59 schrieb Peter Kümmel:
>
> > as you told, you have big problems in settings up clean build.
>> Therefore I've changed the build5-2010.bat file you added for
>building
>> with MSV
Am 17.01.2016 um 08:06 schrieb Scott Kostyshak:
I would release the beta with the available Windows installer, but would also
mention, that because of men power this time on Windows there will be nothing
better that beta quality.
In the announcement you could mention that we are busy improvin
7;t have to touch it before you execute it.
I really hope this improves the current installer chaos.
Peter
it would be great to build both
>an
>MSVC installer and an MinGW installer. We all understand that Uwe does
>not have much time, but it also seems that it might not require too
>much
>of his time, thanks to the help from Georg, Peter, and Kornel for build
>and CMake issues.
>
>Aft
Am 15.01.2016 um 22:33 schrieb Georg Baum:
And these problems do exist. The 2.2 alpha is not the first windows
binary that turned out to be built from different sources than
originally thought (http://www.lyx.org/trac/ticket/9878). I remember a
similar issue from several years ago, might be 1.
Am 13.01.2016 um 00:21 schrieb Uwe Stöhr:
CMake. As soon as I create a new folder and copy there code, I need to
run CMake from scratch and specify about 40 paths (most of them to Qt).
If I make a mistake there I get strange builds.
Uwe, why do you waste you time with such a msvc2010 fiddling?
Am 15.01.2016 um 22:39 schrieb Georg Baum:
Peter Kümmel wrote:
I also don't see a problem to build from a clean git repository.
Only thing I would ensure is to "sit" on tagged release.
I agree that building from a clean git directory is not a problem concerning
the res
Am 15.01.2016 um 16:19 schrieb Stephan Witt:
Am 15.01.2016 um 15:48 schrieb Peter Kümmel :
Am 15.01.2016 um 15:01 schrieb Stephan Witt:
Am 15.01.2016 um 14:41 schrieb Peter Kümmel :
Am 14.01.2016 um 23:32 schrieb Uwe Stöhr:
Am 14.01.2016 um 21:22 schrieb Georg Baum:
So I still think
Am 15.01.2016 um 15:01 schrieb Stephan Witt:
Am 15.01.2016 um 14:41 schrieb Peter Kümmel :
Am 14.01.2016 um 23:32 schrieb Uwe Stöhr:
Am 14.01.2016 um 21:22 schrieb Georg Baum:
So I still think that creating a new git branch and copying the files
from the tar there is the quickest and also
Am 14.01.2016 um 23:32 schrieb Uwe Stöhr:
Am 14.01.2016 um 21:22 schrieb Georg Baum:
So I still think that creating a new git branch and copying the files
from the tar there is the quickest and also safest way - no need to
fiddle around with any path.
Here I strongly disagree. By doing this
Am 12.01.2016 um 20:21 schrieb Peter Kümmel:
Hi Uwe, could you try development/cmake/mingw.bat.
Call it from any path. The script creates the build folder
"compile-mingw". Only requirement is that msvc2010-deps
is on the same level as the lyx source dir (and the C:\Qt
installation)
Am 13.01.2016 um 09:43 schrieb Stephan Witt:
What do others think?
Under these conditions I’d prefer the use of Qt 5.5.1 over a 5.6.0 too.
OK, I updated the batch script to use Qt 5.5.1.
Perhaps one relevant point here is that we have often released a new
minor version pretty quickly. On
Am 13. Januar 2016 05:27:22 MEZ, schrieb "Peter Kümmel" :
>Am 13. Januar 2016 05:19:09 MEZ, schrieb "Peter Kümmel"
>:
>>
>>>> It is a warning only committed from me today to fix a linker error.
>>>You tried it with msvc 2010? And it worked?
>
Am 13. Januar 2016 05:19:09 MEZ, schrieb "Peter Kümmel" :
>
>>> It is a warning only committed from me today to fix a linker error.
>>You tried it with msvc 2010? And it worked?
>>
>>Yes. I can now compile with MSVC 2010 and Qt 5.5.1. The compilation of
&
Am 13. Januar 2016 01:46:35 MEZ, schrieb Scott Kostyshak :
>On Wed, Jan 13, 2016 at 01:31:59AM +0100, Peter Kümmel wrote:
>> Am 13. Januar 2016 00:32:11 MEZ, schrieb Scott Kostyshak
>:
>> >Dear all,
>> >
>> >There is a question of whether we should relea
Am 13. Januar 2016 01:18:12 MEZ, schrieb "Uwe Stöhr" :
>Am 12.01.2016 um 11:16 schrieb Peter Kümmel:
>
>> Yes, no Dlls any more (only the Qt related ones).
>
>OK.
>
>However I get now man times this warning:
>
>D:\LyXGit\Master\compile-2010\zconf.h
Am 13. Januar 2016 00:32:11 MEZ, schrieb Scott Kostyshak :
>Dear all,
>
>There is a question of whether we should release our binary for Windows
>compiled against Qt 5.5.1 or 5.6.0.
>
It is not very complicated to switch between these two versions. So just let
see how the timing becomes.
>My opi
Am 13. Januar 2016 00:21:52 MEZ, schrieb "Uwe Stöhr" :
>Am 12.01.2016 um 19:43 schrieb Georg Baum:
>
>>> For now I also need the info about Qt 5. What is the expected build
>>> target for beta1? My time is limited and I have to focus on one Qt
>>> version. I installed Qt 5.6 beta for mingw and ming
My time is limited and I have to focus onone Qt
>>> version. I installed Qt 5.6 beta for mingw and mingw itself. Is this
>the way I should go?
>>
>> Yes, that would be great!
>
>Hi Peter,
>
>OK, I will try this. Since I never used MinGW I expect some obstacl
Am 12. Januar 2016 20:24:38 MEZ, schrieb Georg Baum
:
>Am 12.01.2016 um 00:37 schrieb Uwe Stöhr:
>> I did this now as I wrote in the
>> Questions for Uwe once you are back
>> thread.
>> I had to delete CMake's cache first and re-run it from scratch. The
>> 3rd party programs are compiled (with 13
r with the
files which you should pass to NSIS. If any file is
missing in LYX_INSTALLED we should fix cmake.
I really hope this simplifies the Windows build.
Peter
The cache needs to be deleted (as you discovered already).
I'll push a script which deletes the complete build dir, cleanest way.
For now I also need the info about Qt 5. What is the expected build
target for beta1? My time is limited and I have to focus on one Qt
version. I installed Qt 5.6
For now I also need the info about Qt 5. What is the expected build
target for beta1? My time is limited and I have to focus on one Qt
version. I installed Qt 5.6 beta for mingw and mingw itself. Is this the
way I should go?
Yes, that would be great!
It looks like the paths will also not change
Am 12.01.2016 um 00:37 schrieb Uwe Stöhr:
I had to delete CMake's cache first and re-run it from scratch. The 3rd
party programs are compiled (with 134 warnings) but I don't get a DLL.
Is this the plan - not to rely anymore on DLLs?
Yes, no Dlls any more (only the Qt related ones).
thanks
r includes?
Stephan
I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include“.
Yes, but what’s the gain of having "src/tex2lyx“ before other includes?
Don't know. Not my doing, ask Peter. I suspected, he had a reason introducing
it.
Peter, is the attached patch ok?
Re
m the sources Peter added, using exactly the same
compiler as is used to build LyX.
If Uwe tries to build the installer with the mingw build
from the build bot, and it makes no problems, then a mingw
based installer isn't far away.
S6. Can you still reproduce these two tickets?
http://www.ly
Am 28.12.2015 um 14:48 schrieb Scott Kostyshak:
Ah, the cmakebin variable is not set, a rest of the bot script. Replacing the
variable by cmake should fix it.
committed this.
Yes this was the problem. There seem to be several unset variables. Can
we use
set -u
with /bin/sh or is that only
Am 06.01.2016 um 13:32 schrieb Peter Kümmel:
4. Do we also want to try releasing an installer built
with mingw?
(Does that build an installer? or just LyX?)
It builds just LyX. Building an installer needs a built
LyX, it should not
matter whether it was built by MSVC or mingw (except for
the
Am 06.01.2016 um 14:45 schrieb Jean-Marc Lasgouttes:
Le 06/01/2016 13:25, Peter Kümmel a écrit :
Am 05.01.2016 um 12:28 schrieb Jean-Marc Lasgouttes:
Le 20/12/2015 15:07, Peter Kümmel a écrit :
Recently I gave away the computer which I've used when I
was
very busy on LyX. It was an A
Am 06.01.2016 um 14:35 schrieb Kornel Benko:
Am Mittwoch, 6. Januar 2016 um 14:27:24, schrieb Peter Kümmel
Am 03.01.2016 um 17:09 schrieb Kornel Benko:
It creates LyX22-2.2.0-win32.zip.
Probably not an installer like used in windows.
Yes, only the files generated my "make install
Am 06.01.2016 um 14:23 schrieb Kornel Benko:
Am Mittwoch, 6. Januar 2016 um 14:15:22, schrieb Stephan Witt
Am 06.01.2016 um 13:35 schrieb Peter Kümmel :
Am 03.01.2016 um 20:05 schrieb Georg Baum:
So far we have never released any 64bit windows binary. This is fine, since
64bit windows
Am 06.01.2016 um 14:15 schrieb Stephan Witt:
Am 06.01.2016 um 13:35 schrieb Peter Kümmel :
Am 03.01.2016 um 20:05 schrieb Georg Baum:
So far we have never released any 64bit windows binary. This is fine, since
64bit windows can execute 32bit binaries, and nobody complained yet about
LyX
Am 03.01.2016 um 17:09 schrieb Kornel Benko:
It creates LyX22-2.2.0-win32.zip.
Probably not an installer like used in windows.
Yes, only the files generated my "make install".
I added "make install" to the script, and the NSIS
installer should use the files in LYX_INSTALLED/
Kornel
Am 03.01.2016 um 20:05 schrieb Georg Baum:
So far we have never released any 64bit windows binary. This is fine, since
64bit windows can execute 32bit binaries, and nobody complained yet about
LyX hitting the 32bit memory limit (around 3.5 GB on windows). I would not
switch to 64bit at this ti
installed for mingw builds).
NSIS also runs on Ubuntu, so in principle it is possible to
build a installer on Linux.
Peter
$ apt-cache show nsis
Package: nsis
Priority: optional
Section: universe/devel
Installed-Size: 629
Maintainer: Ubuntu Developers
Original-Maintainer: Thomas Gaugler
Am 05.01.2016 um 12:28 schrieb Jean-Marc Lasgouttes:
Le 20/12/2015 15:07, Peter Kümmel a écrit :
Recently I gave away the computer which I've used when I was
very busy on LyX. It was an Athlon XP 2GHz singlecore.
I was interested how the hardware progress looks like from
the LyX perspe
Am 28. Dezember 2015 11:41:02 MEZ, schrieb Kornel Benko :
>Am Montag, 28. Dezember 2015 um 05:24:59, schrieb Scott Kostyshak
>
>> On Mon, Dec 28, 2015 at 11:07:18AM +0100, Peter Kümmel wrote:
>> > Am 28. Dezember 2015 07:28:55 MEZ, schrieb Scott Kostyshak
>:
>> &g
Am 20.12.2015 um 21:01 schrieb Pavel Sanda:
Georg Baum wrote:
Did you run configure after autogen.sh? I assume the error happens when
calling make?
Here 3rdparty/libiconv/Makefile.in is already generated by autogen.sh.
Maybe some old files in the source tree?
Yes, also there is error whe
full HD)
Haswell 4Ghz : 8s (full HD window)
Haswell 4Ghz : 3s (4k fullscreen)
Raspberry Pi 2: 34s (Ubuntu Mate, full HD)
Especially I was in interested in the Raspberry Pi 2 numbers,
and it looks like the Rasp could at least be used for editing
lyx files.
Peter
ompiled Qt 5.5.1 version, and starts
compiling.
Peter
Am 20.12.2015 um 12:31 schrieb Kornel Benko:
Am Sonntag, 20. Dezember 2015 um 12:10:19, schrieb Peter Kümmel
Am 20.12.2015 um 11:29 schrieb Georg Baum:
Kornel Benko wrote:
Setting SRC_LIBCHARSET in the patch might be guarded by:
if(UNIX AND NOT MINGW)
endif()
But since I cannot test
on Linux
2. LYX_3RDPARTY_BUILD triggers only hunspell build and usage on Linux,
even when there is a system version of hunspell
Or is it better to disable all three libs on Linux?
Is there any benefit to use the bundled libs?
Peter
VC 10: Microsoft Visual Studio 2010 Don't be mislead by the nice fit!
MSVC 11: Microsoft Visual Studio 2012 From here on we are "one off"!
MSVC 12: Microsoft Visual Studio 2013
MSVC 14: Microsoft Visual Studio 2015
Peter added a workaround for mixing code compiled by MSVC 12 and MSVC 10
nja ..\lyx -DLYX_USE_QT=QT5 -DLYX_3RDPARTY_BUILD=1 -DLYX_RELEASE=1
ninja
ninja install/strip
Peter
Here are patches needed for a Wimdow 64 build done with msvc2015 :
https://github.com/syntheticpp/lyx/commits/msvc15-amd64
Most changes because long is only 32bit on Windows.
http://www.viva64.com/en/t/0012/
Having a look at the tabe it seems nobody toke the coutage to make int 64 bit
wide on
https://github.com/syntheticpp/lyx/commits/3rdparty
I would like to merge above Branch which adds src/3rdparty with stripped down
sources of zlib iconv and hunspell.
Build and usage of these libs is controlled by LYX_3RDPARTY_BUILD and has been
trdted with mingw-cross, msvc2013 and msvc2015.
The automatic build now also builds iconv, hunspell, and zlib.
Uwe, could you check if the downloadable zip is good enough as basis for a real
installer?
https://github.com/syntheticpp/LyX-bleeding-edge/blob/LyX-master-win32/README.md
If this works, then we could even try to build the installer
? msvc2013 and msvc2015 have C++11 enabled by
default.
Not much to do in the cmake files, and whan something has to be changed just use
cmake variables MSVC2012/MSVC2014. Or have I missed something?
Peter
t knowing gtest (also integrating into a existing project)
is also good for other non-Qt projects.
Peter
#ctest -N
Test project C:/Users/Vincent/Documents/LyX/build/lyx/tests
Test #1: unit_test/src/BufferTest
Total Tests: 1
#ctest -R
Test project C:/Users/Vincent/Documents/LyX/build/lyx/tests
Am 02.11.2015 um 11:40 schrieb Jean-Marc Lasgouttes:
Le 01/11/2015 16:51, Scott Kostyshak a écrit :
On Sat, Oct 31, 2015 at 11:08:51PM +0100, Peter Kümmel wrote:
Am 25.10.2015 um 06:19 schrieb Scott Kostyshak:
On Fri, Oct 23, 2015 at 06:13:03PM +0200, Vincent van Ravesteijn wrote:
I have it
Am 01.11.2015 um 22:02 schrieb Georg Baum:
Peter Kümmel wrote:
For iconv and hunspell one can find some CMakeLists.txt at github, not
ready for MSVC but usable as starting point. AFAIk zlib already ships
with cmake files.
Would it be an option to add tripped down iconv, hunspell and zlib
Using bcp from older boost releases also works, so the one from your package
manager should be enough.
Peter
Am 1. November 2015 17:42:51 MEZ, schrieb Vincent van Ravesteijn :
>On Sun, Nov 1, 2015 at 4:51 PM, Scott Kostyshak
>wrote:
>> On Sat, Oct 31, 2015 at 11:08:51PM +0100,
Am 29.10.2015 um 20:17 schrieb Georg Baum:
BTW, I wanted to try the cross-compiling myself for several montsh now,
because I am curious, but did not find the time up to now.
The build-bot already cross-compiles for Windows, it is NOT a Windows machine.
Recently travis updated their bots to to
Am 25.10.2015 um 06:19 schrieb Scott Kostyshak:
On Fri, Oct 23, 2015 at 06:13:03PM +0200, Vincent van Ravesteijn wrote:
I have it documented somewhere. Should I put it in development.lyx ?
If you are able to find it easily then I would say yes, please do. Even
though Peter already did the
Am 14.10.2015 um 21:52 schrieb Georg Baum:
David Hyde wrote:
I'm interested in looking into this at least a bit (may become deterred
if some dependency nightmare occurs!). I've looked at the current MSVC
dependencies that are in the archive on sourceforge. Which of these
are things that shoul
Am 24.10.2015 um 20:25 schrieb Uwe Stöhr:
Am 24.10.2015 um 07:26 schrieb Peter Kümmel:
Do you think the warning is too extreme?
No, this is sadly true. Just replacing LyX files will break
LyX's functions. One need to set the PATH prefix in LyX etc.
to keep it running. So it OK to
1 - 100 of 2415 matches
Mail list logo
