Re: Tentative schedule for 2.3.0 release

[Jean-Marc Lasgouttes]

Le 30/05/2017 à 21:12, Richard Heck a écrit :

Richard, this is about using QTextlayout caching for MacOS with Qt5.
Qt5 is supposed to do caching, but it is very inefficient on MacOS
with ancient Hebrew. OK for 2.2.4?


Sure.


Thanks. I just did it.

JMarc

Re: Tentative schedule for 2.3.0 release

[Richard Heck]

On 05/30/2017 08:39 AM, Jean-Marc Lasgouttes wrote:
> Le 04/05/2017 à 11:26, Stephan Witt a écrit :
 I liked to use it since then for anything Hebrew.
 Performance was quite noticeably improved.
 With Hebrew this was not perfect but much,  much better.
>>>
>>> So we might want to include it. Stephan, what do you think. It would
>>> be nice for 2.2.3 too.
>>
>> I propose to include it (that’s why I CCed the lyx-devel list).
>> It would be good for 2.2.3 probably. I hope to compare it with
>> Instruments soon.
>
> Richard, this is about using QTextlayout caching for MacOS with Qt5.
> Qt5 is supposed to do caching, but it is very inefficient on MacOS
> with ancient Hebrew. OK for 2.2.4?

Sure.

Richard

Re: Tentative schedule for 2.3.0 release

[Jean-Marc Lasgouttes]

Le 04/05/2017 à 11:26, Stephan Witt a écrit :

I liked to use it since then for anything Hebrew.
Performance was quite noticeably improved.
With Hebrew this was not perfect but much,  much better.


So we might want to include it. Stephan, what do you think. It would be nice 
for 2.2.3 too.


I propose to include it (that’s why I CCed the lyx-devel list).
It would be good for 2.2.3 probably. I hope to compare it with Instruments soon.


Richard, this is about using QTextlayout caching for MacOS with Qt5. Qt5 
is supposed to do caching, but it is very inefficient on MacOS with 
ancient Hebrew. OK for 2.2.4?


JMarc

Re: Tentative schedule for 2.3.0 release

[mn]

On 15.05.17 10:44, Jean-Marc Lasgouttes wrote:
> Le 14/05/2017 à 21:23, Stephan Witt a écrit :
>> I tried to get some numbers. The numbers I got with Instruments were unclear.
>> The time to go through the english users guide with and w/o the patch is the 
>> same.
>> The time to go through the hebrew tutorial is not very different.
>> I’ll attach the profiler runs focussing on QTextLayout::endLayout for hebrew.
> 
> I happened to push the commit by inadvertance. This is probably a good 
> idea, let's see.
> 
> I'd like neverthless to understand the precise problem. Mike, did the 
> problem exist for you only for Ancient Hebrew? Can you describe for us 
> what is so special about ancient Hebrew? Do you know of other languages 
> that should create similar problems?
> 
> What I have in mind is that we might be able to restrict the use of 
> caching to some specific fonts. How would I recognize a font used for 
> ancient Hebrew?
> 

First line to tackle would appear to be that LyX on OS X is just slower.
But I do not know how much Qt or LyX itself are to blame for this.
Boot linux on the same machine and see a faster and smoother LyX.
Use it in a linux-VM and see a faster LyX, despite the overhead.
This is not restricted to any special language needs or scripts.
But then again in my experience other Qt-apps also suffer from this to
varying degrees. None of which, I suppose, I use to type text on OS X.
Maybe that's why I come to feel LyX as the worst offender there on OS X.

What it makes so special – from a technical or programming view – to try
to use ancient Hebrew I can only guess:
Ancient Hebrew is RTL, uses special and imperfect unicode features to
generate ַand place the vocals and accents on, in, under and around the
consonants.
Modern Hebrew usually does not use the vocals. So this would not appear
as much of a problem there.
If you try to emulate the exact massoretic vocalization of certain parts
of the text there are some portions so seemingly arbitrarily vocalized
(and too complex for unicode) that even ancient and modern scribes have
had  difficulties placing the dots and strokes the right way. But these
problems are few, the slowness starts without them.

 Perhaps these documents may help you understand a bit better:
http://www.brill.com/files/brill.nl/special_scripts_hebrew_transliteration_scholarly.pdf
https://www.sbl-site.org/fonts/biblicalhebrewtiromanual.pdf

Since I also find Arabic to be quite painful to use in LyX and this
script is also RTL and relies on context-sensitive letter-forms, my
further guesses in this direction would suggest to look for all
languages that might do something similar, like Sanskrit, Gujarat,
Chinese, Hangul, Devanagari and so on (as far as they are claimed to be
supported by LyX)

Interestingly I just tried to set a latin OpenType font with complex
contextual alternatives as a screen font that emulates handwriting and
found that LyX just ignores all of these otf features. So it might be
unicode and/or OpenType related?

Since I struggled just yesterday to do something reasonable with the
Arabic docs:
I noticed that Sheherazade font works so easily for the LyX-docs is
because it contains glyphs for Arabic and Latin; while my other fonts
are usually one or the other.
After much trial and only errors I just failed to declare proper fonts,
scripts and languages in LyX for use with XeTeX and Arabic and gave up
the fight for another day.
What is ultimately needed there was discussed a while ago:
LyX should be better at providing for multilingual documents and offer a
way to declare different fonts for different scripts.
A glimpse of what's needed can be seen here:
https://www.guyrutenberg.com/2015/03/21/creating-a-hebrew-document-in-lyx-2-1-with-xetex/
Then you just have to recognize that the user tells you that it is text
intended for a certain language/script and that he calls for that font.


greetings
Mike

Re: Tentative schedule for 2.3.0 release

[Jean-Marc Lasgouttes]

Le 14/05/2017 à 21:23, Stephan Witt a écrit :

I tried to get some numbers. The numbers I got with Instruments were unclear.
The time to go through the english users guide with and w/o the patch is the 
same.
The time to go through the hebrew tutorial is not very different.
I’ll attach the profiler runs focussing on QTextLayout::endLayout for hebrew.


I happened to push the commit by inadvertance. This is probably a good 
idea, let's see.


I'd like neverthless to understand the precise problem. Mike, did the 
problem exist for you only for Ancient Hebrew? Can you describe for us 
what is so special about ancient Hebrew? Do you know of other languages 
that should create similar problems?


What I have in mind is that we might be able to restrict the use of 
caching to some specific fonts. How would I recognize a font used for 
ancient Hebrew?


JMarc

Re: Tentative schedule for 2.3.0 release

[Stephan Witt]

Am 04.05.2017 um 11:26 schrieb Stephan Witt :
> 
> Am 04.05.2017 um 10:21 schrieb Jean-Marc Lasgouttes :
>> 
>> Le 02/05/2017 à 22:26, mn a écrit :
 Mike, did ever get a chance to test with the patch that I sent? I am a
 bit lost whether this restores the performance. Is there a big
 difference in terms of memory use?
>>> 
>>> I tested that build.
>>> I wrote about it on April 19.
>> 
>> I somehow missed this message.
>> 
>>> I liked to use it since then for anything Hebrew.
>>> Performance was quite noticeably improved.
>>> With Hebrew this was not perfect but much,  much better.
>> 
>> So we might want to include it. Stephan, what do you think. It would be nice 
>> for 2.2.3 too.
> 
> I propose to include it (that’s why I CCed the lyx-devel list). 
> It would be good for 2.2.3 probably. I hope to compare it with Instruments 
> soon. 

I tried to get some numbers. The numbers I got with Instruments were unclear.
The time to go through the english users guide with and w/o the patch is the 
same.
The time to go through the hebrew tutorial is not very different.
I’ll attach the profiler runs focussing on QTextLayout::endLayout for hebrew.

Stephan

> 
> Stephan
> 
>> 
>>> But with Arabic it seemed too unstable overall to do anything meaningful.
>>> That meant for me: long running tests in regard of memory usage were not
>>> really feasible.
>> 
>> What do you mean by unstable? Is it related to this patch or to LyX in 
>> general.
>> 
>>> Since my main mac machine is a traveling laptop it is also quite
>>> inconvenient to have LyX sitting there idling at >0% CPU with not even a
>>> document open.
>> 
>> This is unfortunate indeed. Is it possible to get a trace of what is 
>> hapening with Instruments?
>> 
>>> I shelved that more rigorous looking-at-memory-thing in longer runs
>>> until the official alpha would be out.
>>> Searching the threads, I am confused now.
>>> As I read Stephan announced some binary 'for later' quite a while ago,
>>> but they are not on ftp?
>> 
>> Note that the patch we are discussing here is not in alpha1.
>> 
>>> That and my second line in this mail and snippets on the ML seemingly
>>> citing stuff I never got through the list and also cannot find on the
>>> archives on the net: Is there something wrong with the list?
>>> Although, that might just be spillover from off-list talk or my memory
>>> fooling me.
>>> Are there binaries for alpha out that were announced?
>> 
>> I do not think so.
>> 
>> JMarc
-- Cache disabled - scroll through the Tutorial
Weight  Self Weight Symbol Name
4.84 s  100.0%  0 s LyX (60480)
4.37 s   90.3%  0 s  Main Thread  0x72766c
4.34 s   89.7%  0 s   start
4.33 s   89.6%  0 smain
4.33 s   89.6%  0 s lyx::LyX::exec(int&, char**)
3.89 s   80.5%  0 s  QCoreApplication::exec()
3.89 s   80.3%  0 s   
QEventLoop::exec(QFlags)
3.89 s   80.3%  0 s
QCocoaEventDispatcher::processEvents(QFlags)
3.89 s   80.3%  0 s -[NSApplication run]
3.85 s   79.6%  0 s  -[NSApplication 
_nextEventMatchingEventMask:untilDate:inMode:dequeue:]
3.85 s   79.6%  0 s   _DPSNextEvent
3.69 s   76.3%  0 s
_BlockUntilNextEventMatchingListInModeWithFilter
3.69 s   76.3%  0 s ReceiveNextEventCommon
3.69 s   76.2%  0 s  RunCurrentEventLoopInMode
3.68 s   76.0%  0 s   CFRunLoopRunSpecific
3.08 s   63.7%  0 s__CFRunLoopRun
3.06 s   63.2%  0 s __CFRunLoopDoSources0
3.06 s   63.2%  0 s  
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
3.04 s   62.9%  0 s   
QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*)
2.78 s   57.5%  0 s
QWindowSystemInterface::sendWindowSystemEvents(QFlags)
2.78 s   57.4%  0 s 
QGuiApplicationPrivate::processKeyEvent(QWindowSystemInterfacePrivate::KeyEvent*)
2.78 s   57.4%  0 s  
QCoreApplication::notifyInternal2(QObject*, QEvent*)
2.78 s   57.4%  0 s   
lyx::frontend::GuiApplication::notify(QObject*, QEvent*)
2.78 s   57.4%  0 s
QApplication::notify(QObject*, QEvent*)
2.78 s   57.4%  0 s 
QApplicationPrivate::notify_helper(QObject*, QEvent*)
2.78 s   57.4%  0 s  
QWidgetWindow::event(QEvent*)
2.78 s   57.4%  0 s   
QCoreApplication::notifyInternal2(QObject*, QEvent*)
2.78 s   57.4%  0 s
lyx::frontend::GuiApplication::notify(QObject*, QEvent*)
2.78 s   57.4%  0 s 

Re: Tentative schedule for 2.3.0 release

[Stephan Witt]

Am 04.05.2017 um 10:21 schrieb Jean-Marc Lasgouttes :
> 
> Le 02/05/2017 à 22:26, mn a écrit :
>>> Mike, did ever get a chance to test with the patch that I sent? I am a
>>> bit lost whether this restores the performance. Is there a big
>>> difference in terms of memory use?
>> 
>> I tested that build.
>> I wrote about it on April 19.
> 
> I somehow missed this message.
> 
>> I liked to use it since then for anything Hebrew.
>> Performance was quite noticeably improved.
>> With Hebrew this was not perfect but much,  much better.
> 
> So we might want to include it. Stephan, what do you think. It would be nice 
> for 2.2.3 too.

I propose to include it (that’s why I CCed the lyx-devel list). 
It would be good for 2.2.3 probably. I hope to compare it with Instruments 
soon. 

Stephan

> 
>> But with Arabic it seemed too unstable overall to do anything meaningful.
>> That meant for me: long running tests in regard of memory usage were not
>> really feasible.
> 
> What do you mean by unstable? Is it related to this patch or to LyX in 
> general.
> 
>> Since my main mac machine is a traveling laptop it is also quite
>> inconvenient to have LyX sitting there idling at >0% CPU with not even a
>> document open.
> 
> This is unfortunate indeed. Is it possible to get a trace of what is hapening 
> with Instruments?
> 
>> I shelved that more rigorous looking-at-memory-thing in longer runs
>> until the official alpha would be out.
>> Searching the threads, I am confused now.
>> As I read Stephan announced some binary 'for later' quite a while ago,
>> but they are not on ftp?
> 
> Note that the patch we are discussing here is not in alpha1.
> 
>> That and my second line in this mail and snippets on the ML seemingly
>> citing stuff I never got through the list and also cannot find on the
>> archives on the net: Is there something wrong with the list?
>> Although, that might just be spillover from off-list talk or my memory
>> fooling me.
>> Are there binaries for alpha out that were announced?
> 
> I do not think so.
> 
> JMarc

Re: Tentative schedule for 2.3.0 release

[mn]

On 18.04.17 14:10, Jean-Marc Lasgouttes wrote:
> Le 17/04/2017 à 22:17, mn a écrit :
>> This zip-file contains info applied to the same situation as described above.
>> I hope that it shows enough indention for your purposes?
> 
> This is very useful. The interesting lines are:
> 13028.0ms   50.0% 3,0  
> lyx::frontend::GuiFontMetrics::getTextLayout(std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&, 
> bool, double) const
> 1482.0ms5.6%  0,0  
> lyx::frontend::GuiFontMetrics::getTextLayout(std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&, 
> bool, double) const
> 378.0ms1.4%   0,0  
> lyx::frontend::GuiFontMetrics::getTextLayout(std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&, 
> bool, double) const
> 
> There are a few others, I think that GuiFontMetrics::getTextLayout 
> counts fr 60% of the time. Fortunately, we have a caching mechanism in 
> place for Qt4 (Qt5 is supposed t do its own caching).
> 
> Stephan, could you make a new build with the following patch applied? It 
> enables TextLayout caching with Qt5. If it works, we will have to understand
> * whether it is a Mac-only problem
> * whether it is a Hebrew/Bidi-only problem
> 
> Mike, could you please
> - send to us your example Hebrew file so that we can experiment
> - try to load the Arabic examples/docs and report about performance
> - Have a go at the new build if Stephan can make one. You could also 
> have a look at the memory footprint, especially in long-running experiments.

The Arabic file Tutorial.lyx (old build 11fe3727):

Scrolling performance is noticeably better than Hebrew, once the images
are all loaded and displayed. Still not stellar.

There seems to be something odd concerning the contents:
Arabic is displayed RTL but e.g. LyX is rendered XYL. WYSIYM etc are
also reversed.
Why isn't this properly declared as foreign language?
I mean: no complaints there from Arabic speaking users?


Unfortunately, the experiment is cut short when I try to copy and paste
a slightly biggish passage.

I see an error about sections already declared

"The label sec:Document-Classes already exists,
it will be changed to sec:Document-Classes-1."

and then LyX crashes.

Following are the two crash logs, the first, when only the Apple-style
appeared, the second was from a repeat experiment when LyX brought its
bug-dialogue up:


Process:   lyx [89351]
Path:  /Applications/3rdp/LyX.app/Contents/MacOS/lyx
Identifier:org.lyx.lyx
Version:   2.3.0dev (???)
Code Type: X86-64 (Native)
Parent Process:??? [1]
Responsible:   lyx [89351]



OS Version:Mac OS X 10.10.5 (14F2315)
Report Version:11


Time Awake Since Boot: 27000 seconds
Time Since Wake:   7200 seconds

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_CRASH (SIGABRT)
Exception Codes:   0x, 0x

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib  0x7fff850fb286 __pthread_kill + 10
1   libsystem_c.dylib   0x7fff8e6ed9a3 abort + 129
2   org.lyx.lyx 0x00010d82fc7a lyx::lyx_exit(int)
+ 18
3   org.lyx.lyx 0x00010daad09f
lyx::frontend::GuiApplication::notify(QObject*, QEvent*) + 803
4   org.qt-project.QtCore   0x00010ecc4ce4
QCoreApplication::notifyInternal2(QObject*, QEvent*) + 164
5   org.qt-project.QtCore   0x00010ed1f96a
QTimerInfoList::activateTimers() + 1322
6   libqcocoa.dylib 0x000111896e52
QCocoaEventDispatcherPrivate::activateTimersSourceCallback(void*) + 18
7   com.apple.CoreFoundation0x7fff8b751a01
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
8   com.apple.CoreFoundation0x7fff8b743c5c
__CFRunLoopDoSources0 + 476
9   com.apple.CoreFoundation0x7fff8b7431bf __CFRunLoopRun + 927
10  com.apple.CoreFoundation0x7fff8b742bd8
CFRunLoopRunSpecific + 296
11  com.apple.HIToolbox 0x7fff84c4256f
RunCurrentEventLoopInMode + 235
12  com.apple.HIToolbox 0x7fff84c421ee
ReceiveNextEventCommon + 179
13  com.apple.HIToolbox 0x7fff84c4212b
_BlockUntilNextEventMatchingListInModeWithFilter + 71
14  com.apple.AppKit0x7fff86f2d8ab _DPSNextEvent + 978
15  com.apple.AppKit0x7fff86f2ce58 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
16  com.apple.AppKit0x7fff86f22af3 -[NSApplication
run] + 594
17  libqcocoa.dylib 0x000111897a5f
QCocoaEventDispatcher::processEvents(QFlags)
+ 2191
18  

Re: Tentative schedule for 2.3.0 release

[Stephan Witt]

Am 15.04.2017 um 15:06 schrieb mn :
> 
> On 15.04.17 14:29, Stephan Witt wrote:
>> 
>>> Am 15.04.2017 um 10:08 schrieb mn :
>>> 
>>> On 14.04.17 22:31, Stephan Witt wrote:
 Am 12.04.2017 um 21:51 schrieb mn :
>>> 
>> SVGs are already compressed. What procedure do you propose at
>>> shipping time?
> 
> 
> To use for example this: https://github.com/RazrFalcon/svgcleaner
 
 I don’t think such things belong to the packaging process. 
>>> 
>>> 
>>> That it is postponeed to shippping time was a concern regarding
>>> editability of the files.
>>> It seems nobody edits them in the lyx-git, they are imported?
>>> So it would be just as good to recompress them now.
>> 
>> You can offer to do that yourself, can’t you?
>> 
> 
> Were do I have to send them?

IMO the icons were provided by different developers. I don’t know
who cares - perhaps it would be best to pick one and post your change
with an explanation to the list. Later a GPL-statement would be
required to include your work in LyX if we don’t have one already.

Stephan

Re: Tentative schedule for 2.3.0 release

[Jean-Marc Lasgouttes]

Le 17/04/2017 à 10:56, mn a écrit :

On 15.04.17 19:35, Jean-Marc Lasgouttes wrote:

Le 12/04/2017 à 12:31, mn a écrit :

While editing spellchecker is always off, as are insets closed (well
most) and source view and the like. 2.2.2 is still slow and grows slower
over time. Any improvement in that department thrills me.


Is it related to ancient Hebrew slowness you mentioned a few months ago?
There have been some performance work in master and 2.2.3dev, but I am
not sure it will be enough.

Stephan, can you make a debug build of master available to Mike?

Mike, are you able to run LyX under the macOS xcode profiler
(Instruments)? This would give us more information about what goes wrong.


Just tested 2.3-dev with the first verses of Genesis, c%p 5 times,
declaring verse numbers as English and the text as Hebrew.
It is not good in the performance department.
Cursor movement is much saner now, though.

Using Instruments Version 7.2.1 (7C1002) to attach the Time Profiler I
digged down to:

[snip]

What we would need is a hierarchical tree showing who calls who on the 
hot path (?). Unfortnately I do not know well enough the recent versions 
of Instrument.


If you find this tree-view, just open the tree leave with the highest 
load, and go down like that until the percentage frops too much (am I 
clear?). In your trace, the last interesting entry is this one:

> 15743.0ms   60.4%  0,0 lyx::frontend::GuiWorkArea::redraw(bool)

The question is to know where the time is spent after this.

If you are able to make a text file where the indentation shows the 
nesting of the different functions, you can send it privately (zipped) 
to Stephan and myself.


JMarc

JMarc

Re: Tentative schedule for 2.3.0 release

[Jean-Marc Lasgouttes]

Le 16/04/2017 à 13:43, mn a écrit :

The problem seems to be at least two-fold:

- Using two much Hebrew it decelerates quickly.

- But using only one (latin) language and just leaving the app open (by
accident leaving the app open for three days hidden) also causes a
massive slow down, so that I had to quit and restart the application.




Being still on Yosemite I am limited to XCode 7.2.1.
There I found that running Instruments and attaching it to sample LyX
quickly accumulates massive data sets.
Part one of the observed effect might be doable.
Part two seems unpractical.


Let a LyX instance open for a few days. Then attach Instrument to it and 
ask for some data.


JMarc

Re: Tentative schedule for 2.3.0 release

[mn]

On 15.04.17 22:47, Stephan Witt wrote:>
>> Am 15.04.2017 um 19:35 schrieb Jean-Marc Lasgouttes
>> :
>> Le 12/04/2017 à 12:31, mn a écrit :
>>> While editing spellchecker is always off, as are insets closed
>>> (well most) and source view and the like. 2.2.2 is still slow and
>>> grows slower over time. Any improvement in that department
>>> thrills me.
>>
>> Is it related to ancient Hebrew slowness you mentioned a few months
>> ago? There have been some performance work in master and 2.2.3dev,
>> but I am not sure it will be enough.

The problem seems to be at least two-fold:

- Using two much Hebrew it decelerates quickly.

- But using only one (latin) language and just leaving the app open (by
accident leaving the app open for three days hidden) also causes a
massive slow down, so that I had to quit and restart the application.

>> Stephan, can you make a debug build of master available to Mike?
>
> Yes, I sent him a link already.
>
>> Mike, are you able to run LyX under the macOS xcode profiler
>> (Instruments)? This would give us more information about what goes
>> wrong.
>
> Are you able to describe how to use it? I tried it and didn’t
> understand the latest version anymore. :(

Being still on Yosemite I am limited to XCode 7.2.1.
There I found that running Instruments and attaching it to sample LyX
quickly accumulates massive data sets.
Part one of the observed effect might be doable.
Part two seems unpractical.
I am quite space constrained so any suggestion on to how to limit the
generated output might be helpful.

greetings
Mike

Re: Tentative schedule for 2.3.0 release

[Stephan Witt]

> Am 15.04.2017 um 19:35 schrieb Jean-Marc Lasgouttes :
> 
> Le 12/04/2017 à 12:31, mn a écrit :
>> While editing spellchecker is always off, as are insets closed (well
>> most) and source view and the like. 2.2.2 is still slow and grows slower
>> over time. Any improvement in that department thrills me.
> 
> Is it related to ancient Hebrew slowness you mentioned a few months ago? 
> There have been some performance work in master and 2.2.3dev, but I am not 
> sure it will be enough.
> 
> Stephan, can you make a debug build of master available to Mike?

Yes, I sent him a link already.

> Mike, are you able to run LyX under the macOS xcode profiler (Instruments)? 
> This would give us more information about what goes wrong.

Are you able to describe how to use it? I tried it and didn’t understand the 
latest version anymore. :(

Stephan

Re: Tentative schedule for 2.3.0 release

[Jean-Marc Lasgouttes]

Le 12/04/2017 à 12:31, mn a écrit :

While editing spellchecker is always off, as are insets closed (well
most) and source view and the like. 2.2.2 is still slow and grows slower
over time. Any improvement in that department thrills me.


Is it related to ancient Hebrew slowness you mentioned a few months ago? 
There have been some performance work in master and 2.2.3dev, but I am 
not sure it will be enough.


Stephan, can you make a debug build of master available to Mike?

Mike, are you able to run LyX under the macOS xcode profiler 
(Instruments)? This would give us more information about what goes wrong.


JMarc

Re: Tentative schedule for 2.3.0 release

[mn]

On 15.04.17 14:29, Stephan Witt wrote:
> 
>> Am 15.04.2017 um 10:08 schrieb mn :
>>
>> On 14.04.17 22:31, Stephan Witt wrote:
>>> Am 12.04.2017 um 21:51 schrieb mn :
>>
> SVGs are already compressed. What procedure do you propose at
>> shipping time?


 To use for example this: https://github.com/RazrFalcon/svgcleaner
>>>
>>> I don’t think such things belong to the packaging process. 
>>
>>
>> That it is postponeed to shippping time was a concern regarding
>> editability of the files.
>> It seems nobody edits them in the lyx-git, they are imported?
>> So it would be just as good to recompress them now.
> 
> You can offer to do that yourself, can’t you?
> 

Were do I have to send them?


> I don’t think there are any superfluous Qt frameworks
> bundled.
>> But I’ll
> check that. In any case I’m not sure it makes a big
> difference.

 As I said, I am neither sure they are superfluous nor
 convinced LyX needs e.g. multimedia-frameworks or
 DBus-support on OS X.
>>>
>>> The internal dependencies of Qt I cannot change. You’re
>> speculating here.
>>
>> Hm, yeah. As I said. But speculating with reason:
>>
>> Deleting most of the qt-plugins, and frameworks, like those I
>> mentioned and audio and dbus and so on: LyX launches, works,
>> does everything I routinely do.
>>
>> Now I thought it maybe that I missed some usage scenario (like 
>> lyx-server and the like) that I just didn't use. But this way,
>> I doubt if they are really all necessary. If I delete
>> GUI-framework or image-plugins, then it's in trouble, but 
>> playlist-support, camera, gestures?

> Let’s see how it goes.

 to quote: "Prior to codesigning the application bundle, use
 macdeployqt to copy the Qt frameworks and plug-ins into the bundle.
 If you know that your application does not use certain Qt
 frameworks or plug-ins, you can remove them from the bundle to
 reduce its total size." From:


>> http://blog.qt.io/blog/2012/04/03/how-to-publish-qt-applications-in-the-mac-app-store-2/

 As far as I am convinced remembering it, there was a quite recent 
 posting regarding improvements on that front in one of the latest 
 releases of Qt but I cannot find it right now.
>>>
>>> I think I know of one unused framework in LyX deployment. It’s
>>> QtDBus and I’ve removed it.
>>> I don’t know anything about the plugins - I’ll leave them in the
>> deployment.

>> Half of the plugins seem to be superfluous.
> 
> Perhaps. But I’m unable to test any possible combination.
> 

My tests so far gave me apparently safe results for removing from an
installed 2.2.2 these plugins:
audio
bearer
canbus
mediaservice
playlistformats
printsupport
sensorgestures
sensors
sqldrivers

Interestingly also the NetworkFramework can be removed
but not the
PrintsupportFramework
This despite the PrintSupport being removed and the plugin deleted.

>> Have you checked with otool against the binary?
> 
> Yes, I’m using otool regularly. But how does it help to find out
> dependencies like plugins? They are loaded dynamically and in case
> of missing plugins you miss the functionality at best.
> 

OK.
Took it as an indicator. My mistake then.


greetings
Mike

Re: Tentative schedule for 2.3.0 release

[Stephan Witt]

> Am 15.04.2017 um 10:08 schrieb mn :
> 
> On 14.04.17 22:31, Stephan Witt wrote:
>> Am 12.04.2017 um 21:51 schrieb mn :
> 
 SVGs are already compressed. What procedure do you propose at
> shipping time?
>>> 
>>> 
>>> To use for example this: https://github.com/RazrFalcon/svgcleaner
>> 
>> I don’t think such things belong to the packaging process. 
> 
> 
> That it is postponeed to shippping time was a concern regarding
> editability of the files.
> It seems nobody edits them in the lyx-git, they are imported?
> So it would be just as good to recompress them now.

You can offer to do that yourself, can’t you?

 I don’t think there are any superfluous Qt frameworks
 bundled.
> But I’ll
 check that. In any case I’m not sure it makes a big
 difference.
>>> 
>>> As I said, I am neither sure they are superfluous nor
>>> convinced LyX needs e.g. multimedia-frameworks or
>>> DBus-support on OS X.
>> 
>> The internal dependencies of Qt I cannot change. You’re
> speculating here.
> 
> Hm, yeah. As I said. But speculating with reason:
> 
> Deleting most of the qt-plugins, and frameworks, like those I
> mentioned and audio and dbus and so on: LyX launches, works,
> does everything I routinely do.
> 
> Now I thought it maybe that I missed some usage scenario (like 
> lyx-server and the like) that I just didn't use. But this way,
> I doubt if they are really all necessary. If I delete
> GUI-framework or image-plugins, then it's in trouble, but 
> playlist-support, camera, gestures?
>>> 
 Let’s see how it goes.
>>> 
>>> to quote: "Prior to codesigning the application bundle, use
>>> macdeployqt to copy the Qt frameworks and plug-ins into the bundle.
>>> If you know that your application does not use certain Qt
>>> frameworks or plug-ins, you can remove them from the bundle to
>>> reduce its total size." From:
>>> 
>>> 
> http://blog.qt.io/blog/2012/04/03/how-to-publish-qt-applications-in-the-mac-app-store-2/
>>> 
>>> As far as I am convinced remembering it, there was a quite recent 
>>> posting regarding improvements on that front in one of the latest 
>>> releases of Qt but I cannot find it right now.
>> 
>> I think I know of one unused framework in LyX deployment. It’s
>> QtDBus and I’ve removed it.
>> I don’t know anything about the plugins - I’ll leave them in the
> deployment.
>> The debug libraries were shipped accidentally - I’ve changed this. 
>> HFS+ compression seems to work and I’ll use it for alpha releases.
>> 
> 
> Half of the plugins seem to be superfluous.

Perhaps. But I’m unable to test any possible combination.

> Have you checked with otool against the binary?

Yes, I’m using otool regularly. But how does it help to find out
dependencies like plugins? They are loaded dynamically and in case
of missing plugins you miss the functionality at best.

>> In case you’re interested I’ll send you a link for a download of the
> latest disk image.
> 
> I am interested.

Ok, I’ve uploaded it and sent you a link for accessing it.

Stephan

Re: Tentative schedule for 2.3.0 release

[mn]

On 14.04.17 22:31, Stephan Witt wrote:
> Am 12.04.2017 um 21:51 schrieb mn :

>>> SVGs are already compressed. What procedure do you propose at
shipping time?
>> 
>> 
>> To use for example this: https://github.com/RazrFalcon/svgcleaner
> 
> I don’t think such things belong to the packaging process. 


That it is postponeed to shippping time was a concern regarding
editability of the files.
It seems nobody edits them in the lyx-git, they are imported?
So it would be just as good to recompress them now.

>>> I don’t think there are any superfluous Qt frameworks
>>> bundled.
But I’ll
>>> check that. In any case I’m not sure it makes a big
>>> difference.
>> 
>> As I said, I am neither sure they are superfluous nor
>> convinced LyX needs e.g. multimedia-frameworks or
>> DBus-support on OS X.
> 
> The internal dependencies of Qt I cannot change. You’re
speculating here.
 
 Hm, yeah. As I said. But speculating with reason:
 
 Deleting most of the qt-plugins, and frameworks, like those I
 mentioned and audio and dbus and so on: LyX launches, works,
 does everything I routinely do.
 
 Now I thought it maybe that I missed some usage scenario (like 
 lyx-server and the like) that I just didn't use. But this way,
 I doubt if they are really all necessary. If I delete
 GUI-framework or image-plugins, then it's in trouble, but 
 playlist-support, camera, gestures?
>> 
>>> Let’s see how it goes.
>> 
>> to quote: "Prior to codesigning the application bundle, use
>> macdeployqt to copy the Qt frameworks and plug-ins into the bundle.
>> If you know that your application does not use certain Qt
>> frameworks or plug-ins, you can remove them from the bundle to
>> reduce its total size." From:
>> 
>> 
http://blog.qt.io/blog/2012/04/03/how-to-publish-qt-applications-in-the-mac-app-store-2/
>> 
>> As far as I am convinced remembering it, there was a quite recent 
>> posting regarding improvements on that front in one of the latest 
>> releases of Qt but I cannot find it right now.
> 
> I think I know of one unused framework in LyX deployment. It’s
> QtDBus and I’ve removed it.
> I don’t know anything about the plugins - I’ll leave them in the
deployment.
> The debug libraries were shipped accidentally - I’ve changed this. 
> HFS+ compression seems to work and I’ll use it for alpha releases.
> 

Half of the plugins seem to be superfluous.
Have you checked with otool against the binary?

> In case you’re interested I’ll send you a link for a download of the
latest disk image.

I am interested.

greetings
Mike

Re: Tentative schedule for 2.3.0 release

[Scott Kostyshak]

On Wed, Apr 12, 2017 at 11:36:11AM +0200, Kornel Benko wrote:
> Am Dienstag, 11. April 2017 um 23:53:56, schrieb Pavel Sanda 
> > Scott Kostyshak wrote:
> > > I hope others join this conversation. To alpha or not to alpha?
> > 
> > If I was manager I would do aplha, do it quickly with very low 
> > reuirements for bugs solved or fetures yet-to-be-delivered
> > and clearly state that in announcement.
> > No matter how better we became with autmated testing i bet that
> > windows/mac releases will bring some surprises you rather don't
> > want to see in beta.
> > 
> > Pavel
> 
> +1

OK let's go forward with an alpha then.

Scott


signature.asc
Description: PGP signature

Re: Tentative schedule for 2.3.0 release

[Scott Kostyshak]

On Wed, Apr 12, 2017 at 12:11:11AM +0200, Uwe Stöhr wrote:
> El 10.04.2017 a las 05:40, Scott Kostyshak escribió:
> 
> > Uwe and Stephan, do you know if you will be available around these dates
> > to produce binaries?
> 
> I'm sorry, I cannot plan longer than about a week. I'll try to build a
> binary as soon as possible after you send me the link to the release ZIP
> file.

Indeed I should have asked if you happen to know specifically if any of
the dates are bad. I understand if something comes up.

Scott


signature.asc
Description: PGP signature

Re: Tentative schedule for 2.3.0 release

[Stephan Witt]

Am 12.04.2017 um 21:51 schrieb mn :
> 
> On 12.04.17 18:52, Stephan Witt wrote:
> 
>> What are some of the present bugs / missing features you're
>> referring to? I wonder if some workarounds are available...
>>> - that apparently almost nobody was interested in reducing the filesize
>>> of the shipped images.
> 
> PNG could and should be recompressed right now, in git. It's lossless
> and the final visible image is just identical. They remain editable
> (since this was a concern a while ago)
>>> 
 We are talking about 268 files with 1141222 bytes.
>>> 
>>> Which can be stored and transmitted more efficiently for almost no cost.
>>> And that cost is a one time effort.
>>> (repeated at shipping time, for svg).
>> 
>> SVGs are already compressed. What procedure do you propose at shipping time?
> 
> 
> To use for example this:
> https://github.com/RazrFalcon/svgcleaner

I don’t think such things belong to the packaging process.

>> I don’t think there are any superfluous Qt frameworks bundled. But I’ll
>> check that. In any case I’m not sure it makes a big difference.
> 
> As I said, I am neither sure they are superfluous nor convinced LyX
> needs e.g. multimedia-frameworks or DBus-support on OS X.
 
 The internal dependencies of Qt I cannot change. You’re speculating here.
>>> 
>>> Hm, yeah. As I said. But speculating with reason:
>>> 
>>> Deleting most of the qt-plugins, and frameworks, like those I mentioned
>>> and audio and dbus and so on: LyX launches, works, does everything I
>>> routinely do.
>>> 
>>> Now I thought it maybe that I missed some usage scenario (like
>>> lyx-server and the like) that I just didn't use.
>>> But this way, I doubt if they are really all necessary.
>>> If I delete GUI-framework or image-plugins, then it's in trouble, but
>>> playlist-support, camera, gestures?
> 
>> Let’s see how it goes.
> 
> to quote:
> "Prior to codesigning the application bundle, use macdeployqt to copy
> the Qt frameworks and plug-ins into the bundle. If you know that your
> application does not use certain Qt frameworks or plug-ins, you can
> remove them from the bundle to reduce its total size."   From:
> 
> http://blog.qt.io/blog/2012/04/03/how-to-publish-qt-applications-in-the-mac-app-store-2/
> 
> As far as I am convinced remembering it, there was a quite recent
> posting regarding improvements on that front in one of the latest
> releases of Qt but I cannot find it right now.

I think I know of one unused framework in LyX deployment. It’s QtDBus and I’ve 
removed it.
I don’t know anything about the plugins - I’ll leave them in the deployment.
The debug libraries were shipped accidentally - I’ve changed this.
HFS+ compression seems to work and I’ll use it for alpha releases.

In case you’re interested I’ll send you a link for a download of the latest 
disk image.

Stephan

Re: Tentative schedule for 2.3.0 release

[mn]

On 12.04.17 18:52, Stephan Witt wrote:

> What are some of the present bugs / missing features you're
> referring to? I wonder if some workarounds are available...
>> - that apparently almost nobody was interested in reducing the filesize
>> of the shipped images.

 PNG could and should be recompressed right now, in git. It's lossless
 and the final visible image is just identical. They remain editable
 (since this was a concern a while ago)
>>
>>> We are talking about 268 files with 1141222 bytes.
>>
>> Which can be stored and transmitted more efficiently for almost no cost.
>> And that cost is a one time effort.
>> (repeated at shipping time, for svg).
> 
> SVGs are already compressed. What procedure do you propose at shipping time?


To use for example this:
https://github.com/RazrFalcon/svgcleaner

> I don’t think there are any superfluous Qt frameworks bundled. But I’ll
> check that. In any case I’m not sure it makes a big difference.

 As I said, I am neither sure they are superfluous nor convinced LyX
 needs e.g. multimedia-frameworks or DBus-support on OS X.
>>>
>>> The internal dependencies of Qt I cannot change. You’re speculating here.
>>
>> Hm, yeah. As I said. But speculating with reason:
>>
>> Deleting most of the qt-plugins, and frameworks, like those I mentioned
>> and audio and dbus and so on: LyX launches, works, does everything I
>> routinely do.
>>
>> Now I thought it maybe that I missed some usage scenario (like
>> lyx-server and the like) that I just didn't use.
>> But this way, I doubt if they are really all necessary.
>> If I delete GUI-framework or image-plugins, then it's in trouble, but
>> playlist-support, camera, gestures?

> Let’s see how it goes.

to quote:
"Prior to codesigning the application bundle, use macdeployqt to copy
the Qt frameworks and plug-ins into the bundle. If you know that your
application does not use certain Qt frameworks or plug-ins, you can
remove them from the bundle to reduce its total size."   From:

http://blog.qt.io/blog/2012/04/03/how-to-publish-qt-applications-in-the-mac-app-store-2/

As far as I am convinced remembering it, there was a quite recent
posting regarding improvements on that front in one of the latest
releases of Qt but I cannot find it right now.

greetings
Mike

Re: Tentative schedule for 2.3.0 release

[Stephan Witt]

Am 12.04.2017 um 17:51 schrieb mn :
> 
> On 12.04.17 16:13, Stephan Witt wrote:
 What are some of the present bugs / missing features you're
 referring to? I wonder if some workarounds are available...
> - that apparently almost nobody was interested in reducing the filesize
> of the shipped images.
>>> 

…

> 
>>> PNG could and should be recompressed right now, in git. It's lossless
>>> and the final visible image is just identical. They remain editable
>>> (since this was a concern a while ago)
> 
>> We are talking about 268 files with 1141222 bytes.
> 
> Which can be stored and transmitted more efficiently for almost no cost.
> And that cost is a one time effort.
> (repeated at shipping time, for svg).

SVGs are already compressed. What procedure do you propose at shipping time?

> 
>>> SVGs lose (some of) the editing capability, so maybe that needs to be
>>> done only for shipping pictures/icons not those "originals" in the dev-tree.
>>> For SVGs it is precisely the one step before copying them onto the dmg
>>> where I see the reduction to be placed best.
>> 
>> I don’t understand - the SVGs are in fact svgz files… except one clipart 
>> file.
> 
> Their internal structure can be cleaned up and the z-level increased.
> See my post from October last year.

Perhaps, this is not my turn. I read about it and it’s some work I don’t know 
how
to do. I’ll left this as an exercise for others.

> 
>>> - that the download and installation size of LyX is generally really huge
 Yes, 120 MByte.
 Leaving out the spell checker dictionaries will save approximately 
 200 MByte on your disk resp. 50 MByte for the disk image.
> 
> -- because it ships all language files at once
> (this is slightly different with e.g. LibreOffice)
> 
 This is because there is no language add-on package download concept for 
 LyX.
 But it may be an option to provide a „pure“ LyX-package for those ones 
 using
 native spell checker only.
> 
>>> I second that.
>>> Now I do not know how this is handled on Windows, but I strongly prefer
>>> an English only build that has an easy way to extend it with language
>>> capabilities.
> 
>> There is no coincidence with Windows here.
>>> But I need it just for document languages not the UI.
>> This is a matter of your TeX installation.
> 
> What I meant there: spellchecking and the like from within in LyX.
> And I do not know how all that is handled on windows.

Again, we’re talking about Mac packaging. Not Windows and not Linux.
 
> On linux sometimes there are independently installable language packages.
> Having that kind of support, to download and extend the languages to be
> worked with from within the app would be the most convenient.

As I said already - there is no concept for doing this in a safe and clean 
way with the LyX application. Outside the application I don’t know of some
concept for this on Mac. We’re not talking about package managers and the
like. LyX is and should stay a self-contained package, IMO.

…

 
 I don’t think there are any superfluous Qt frameworks bundled. But I’ll
 check that. In any case I’m not sure it makes a big difference.
 
>>> 
>>> As I said, I am neither sure they are superfluous nor convinced LyX
>>> needs e.g. multimedia-frameworks or DBus-support on OS X.
>> 
>> The internal dependencies of Qt I cannot change. You’re speculating here.
>> 
> 
> Hm, yeah. As I said. But speculating with reason:
> 
> Deleting most of the qt-plugins, and frameworks, like those I mentioned
> and audio and dbus and so on: LyX launches, works, does everything I
> routinely do.
> 
> Now I thought it maybe that I missed some usage scenario (like
> lyx-server and the like) that I just didn't use.

Let’s see how it goes.

Stephan

> 
> But this way, I doubt if they are really all necessary.
> If I delete GUI-framework or image-plugins, then it's in trouble, but
> playlist-support, camera, gestures?

Re: Tentative schedule for 2.3.0 release

[mn]

On 12.04.17 16:13, Stephan Witt wrote:
>>> What are some of the present bugs / missing features you're
>>> referring to? I wonder if some workarounds are available...
 - that apparently almost nobody was interested in reducing the filesize
 of the shipped images.

>>> That’s not true. The disk image is compressed by approximately 75%.
>> We are talking different "images" here.
>> It is not primarily about the dmg (although it also benefits in the end)
>> I am talking about images, pictures and icons within the LyX (.app)
>> package. Those used for the GUI, the docs etc.

> Feel free to report a enhancement request then if is not there already.

 Low hanging fruit, easily done. For PNG without
 any side effects, for SVG better be done only for the final image.

>>> Here I didn’t understand your proposal. Now should the package build know
>>> your screen resolution? And what do you propose for SVG? There is nothing
>>> the packaging step can do with the SVG files except copying them.

>> It's about all those pictures inside the package, that is the
>> Application itself.
>> They would keep their resolution (in-)dependence as they are.
>> They can be recompressed in situ inside the package.

>> PNG could and should be recompressed right now, in git. It's lossless
>> and the final visible image is just identical. They remain editable
>> (since this was a concern a while ago)

> We are talking about 268 files with 1141222 bytes.

Which can be stored and transmitted more efficiently for almost no cost.
And that cost is a one time effort.
(repeated at shipping time, for svg).

>> SVGs lose (some of) the editing capability, so maybe that needs to be
>> done only for shipping pictures/icons not those "originals" in the dev-tree.
>> For SVGs it is precisely the one step before copying them onto the dmg
>> where I see the reduction to be placed best.
> 
> I don’t understand - the SVGs are in fact svgz files… except one clipart file.

Their internal structure can be cleaned up and the z-level increased.
See my post from October last year.

>> - that the download and installation size of LyX is generally really huge
>>> Yes, 120 MByte.
>>> Leaving out the spell checker dictionaries will save approximately 
>>> 200 MByte on your disk resp. 50 MByte for the disk image.

 -- because it ships all language files at once
  (this is slightly different with e.g. LibreOffice)

>>> This is because there is no language add-on package download concept for 
>>> LyX.
>>> But it may be an option to provide a „pure“ LyX-package for those ones using
>>> native spell checker only.

>> I second that.
>> Now I do not know how this is handled on Windows, but I strongly prefer
>> an English only build that has an easy way to extend it with language
>> capabilities.

> There is no coincidence with Windows here.
>> But I need it just for document languages not the UI.
> This is a matter of your TeX installation.

What I meant there: spellchecking and the like from within in LyX.
And I do not know how all that is handled on windows.
On linux sometimes there are independently installable language packages.
Having that kind of support, to download and extend the languages to be
worked with from within the app would be the most convenient.

>> If this is implemented, both, document and GUI, should be taken into
>> consideration.
> 
> GUI I18N costs 11MByte.
> 

Trying to tackle all angles of space saving and filesize efficiency
seems to die a death by a thousand tiny cuts.

 -- because it ships all debug binaries for a final build
  (this is again strictly on topic, because I think that's what alphas
  and betas are for?)
>>>
>>> I’m not sure if you get meaningful crash reports otherwise.
>>>
>>
>> This holds true AFAIK only if you actually run the debug-build.
>> What a Mac-user sees is first the "report this to Apple screen" (and the
>> contents was deemed unhelpful for LyX anyway?)
> 
> No, in the past there we got crash reports from normal users which were 
> useful sometimes.

Wrong memory on my part.
OK then.

>> So only if you run into something that needs debugging you need that
>> build and run it specifically.
>> I guess at least 80% of all LyX-users simply do not do this. Ever.
>> I further estimate that 95% of Mac LyX users shriek at the thought of
>> how to invoke the debug-build.
>>
>> And the need for this kind of debug should really be dealt with in alpha
>> and beta.
>>
>> In debian I only install the final binaries, the packages with -dbg at
>> the end are kept off the disk, except for very special purposes.
>>
>> So I guess most of the time a non-Dev user needs a debug build, he needs
>> to be told that he does and he also needs instructions what to do next.
>> That instruction should entail:
>> "to really dig deeper, we first need you to download and install a build
>> with debug enabled" or something like that.
> 
> Perhaps, but I don’t find that convenient.

Convenience and 

Re: Tentative schedule for 2.3.0 release

[Stephan Witt]

Am 12.04.2017 um 14:34 schrieb mn :
> 
> On 12.04.17 12:59, Stephan Witt wrote:
>> What are some of the present bugs / missing features you're
>> referring to? I wonder if some workarounds are available...
> 
 The part below I don’t understand. What exactly is the message?
 
> 
>>> - that apparently almost nobody was interested in reducing the filesize
>>> of the shipped images.
>> 
>> That’s not true. The disk image is compressed by approximately 75%.
>> 
> 
> We are talking different "images" here.
> It is not primarily about the dmg (although it also benefits in the end)
> I am talking about images, pictures and icons within the LyX (.app)
> package. Those used for the GUI, the docs etc.

Feel free to report a enhancement request then if is not there already.

> 
>>> Low hanging fruit, easily done. For PNG without
>>> any side effects, for SVG better be done only for the final image.
>> 
>> Here I didn’t understand your proposal. Now should the package build know
>> your screen resolution? And what do you propose for SVG? There is nothing
>> the packaging step can do with the SVG files except copying them.
>> 
> 
> It's about all those pictures inside the package, that is the
> Application itself.
> They would keep their resolution (in-)dependence as they are.
> They can be recompressed in situ inside the package.
> 
> PNG could and should be recompressed right now, in git. It's lossless
> and the final visible image is just identical. They remain editable
> (since this was a concern a while ago)

We are talking about 268 files with 1141222 bytes.

> 
> SVGs lose (some of) the editing capability, so maybe that needs to be
> done only for shipping pictures/icons not those "originals" in the dev-tree.
> For SVGs it is precisely the one step before copying them onto the dmg
> where I see the reduction to be placed best.

I don’t understand - the SVGs are in fact svgz files… except one clipart file.

> - that the download and installation size of LyX is generally really huge
>> 
>> Yes, 120 MByte.
>> 
>> Leaving out the spell checker dictionaries will save approximately 
>> 200 MByte on your disk resp. 50 MByte for the disk image.
>> 
> 
> That is just my point.
> 
>>> 
>>> -- because it ships all language files at once
>>>  (this is slightly different with e.g. LibreOffice)
>> 
>> This is because there is no language add-on package download concept for LyX.
>> But it may be an option to provide a „pure“ LyX-package for those ones using
>> native spell checker only.
>> 
> 
> I second that.
> Now I do not know how this is handled on Windows, but I strongly prefer
> an English only build that has an easy way to extend it with language
> capabilities.

There is no coincidence with Windows here.

> But I need it just for document languages not the UI.

This is a matter of your TeX installation.

> If this is implemented, both, document and GUI, should be taken into
> consideration.

GUI I18N costs 11MByte.

> (I would also be content to have those packages just on ftp with a wiki
> page instructing me on where to copy them. Userfriendliness would then
> be encompassed with the all-in package.)
> 
>>> -- because it ships all debug binaries for a final build
>>>  (this is again strictly on topic, because I think that's what alphas
>>>  and betas are for?)
>> 
>> I’m not sure if you get meaningful crash reports otherwise.
>> 
> 
> This holds true AFAIK only if you actually run the debug-build.
> What a Mac-user sees is first the "report this to Apple screen" (and the
> contents was deemed unhelpful for LyX anyway?)

No, in the past there we got crash reports from normal users which were useful 
sometimes.

> So only if you run into something that needs debugging you need that
> build and run it specifically.
> I guess at least 80% of all LyX-users simply do not do this. Ever.
> I further estimate that 95% of Mac LyX users shriek at the thought of
> how to invoke the debug-build.
> 
> And the need for this kind of debug should really be dealt with in alpha
> and beta.
> 
> In debian I only install the final binaries, the packages with -dbg at
> the end are kept off the disk, except for very special purposes.
> 
> So I guess most of the time a non-Dev user needs a debug build, he needs
> to be told that he does and he also needs instructions what to do next.
> That instruction should entail:
> "to really dig deeper, we first need you to download and install a build
> with debug enabled" or something like that.

Perhaps, but I don’t find that convenient.

>>> -- because I think it ships lots of Qt-stuff that might not be needed
>>>  for LyX at all(libqtmultimedia), but I may be wrong on this.
>> 
>> I don’t think there are any superfluous Qt frameworks bundled. But I’ll
>> check that. In any case I’m not sure it makes a big difference.
>> 
> 
> As I said, I am neither sure they are superfluous nor convinced LyX
> needs e.g. multimedia-frameworks or DBus-support on OS X.

The internal 

Re: Tentative schedule for 2.3.0 release

[mn]

On 12.04.17 12:59, Stephan Witt wrote:
> What are some of the present bugs / missing features you're
> referring to? I wonder if some workarounds are available...

>>> The part below I don’t understand. What exactly is the message?
>>>

>> - that apparently almost nobody was interested in reducing the filesize
>> of the shipped images.
> 
> That’s not true. The disk image is compressed by approximately 75%.
> 

We are talking different "images" here.
It is not primarily about the dmg (although it also benefits in the end)
I am talking about images, pictures and icons within the LyX (.app)
package. Those used for the GUI, the docs etc.

>> Low hanging fruit, easily done. For PNG without
>> any side effects, for SVG better be done only for the final image.
> 
> Here I didn’t understand your proposal. Now should the package build know
> your screen resolution? And what do you propose for SVG? There is nothing
> the packaging step can do with the SVG files except copying them.
> 

It's about all those pictures inside the package, that is the
Application itself.
They would keep their resolution (in-)dependence as they are.
They can be recompressed in situ inside the package.

PNG could and should be recompressed right now, in git. It's lossless
and the final visible image is just identical. They remain editable
(since this was a concern a while ago)

SVGs lose (some of) the editing capability, so maybe that needs to be
done only for shipping pictures/icons not those "originals" in the dev-tree.
For SVGs it is precisely the one step before copying them onto the dmg
where I see the reduction to be placed best.

>> - that the download and installation size of LyX is generally really huge
> 
> Yes, 120 MByte.
> 
> Leaving out the spell checker dictionaries will save approximately 
> 200 MByte on your disk resp. 50 MByte for the disk image.
> 

That is just my point.

>>
>> -- because it ships all language files at once
>>   (this is slightly different with e.g. LibreOffice)
> 
> This is because there is no language add-on package download concept for LyX.
> But it may be an option to provide a „pure“ LyX-package for those ones using
> native spell checker only.
> 

I second that.
Now I do not know how this is handled on Windows, but I strongly prefer
an English only build that has an easy way to extend it with language
capabilities. But I need it just for document languages not the UI.
If this is implemented, both, document and GUI, should be taken into
consideration.
(I would also be content to have those packages just on ftp with a wiki
page instructing me on where to copy them. Userfriendliness would then
be encompassed with the all-in package.)

>> -- because it ships all debug binaries for a final build
>>   (this is again strictly on topic, because I think that's what alphas
>>   and betas are for?)
> 
> I’m not sure if you get meaningful crash reports otherwise.
> 

This holds true AFAIK only if you actually run the debug-build.
What a Mac-user sees is first the "report this to Apple screen" (and the
contents was deemed unhelpful for LyX anyway?)
So only if you run into something that needs debugging you need that
build and run it specifically.
I guess at least 80% of all LyX-users simply do not do this. Ever.
I further estimate that 95% of Mac LyX users shriek at the thought of
how to invoke the debug-build.

And the need for this kind of debug should really be dealt with in alpha
and beta.

In debian I only install the final binaries, the packages with -dbg at
the end are kept off the disk, except for very special purposes.

So I guess most of the time a non-Dev user needs a debug build, he needs
to be told that he does and he also needs instructions what to do next.
That instruction should entail:
"to really dig deeper, we first need you to download and install a build
with debug enabled" or something like that.

>> -- because I think it ships lots of Qt-stuff that might not be needed
>>   for LyX at all(libqtmultimedia), but I may be wrong on this.
> 
> I don’t think there are any superfluous Qt frameworks bundled. But I’ll
> check that. In any case I’m not sure it makes a big difference.
> 

As I said, I am neither sure they are superfluous nor convinced LyX
needs e.g. multimedia-frameworks or DBus-support on OS X.
Thanks for investigating and then, perhaps clearing that up.

>> As for the images I offered a solution.
>> The debug builds should be separated into a different download, as maybe
>> the full language support.
>> Lacking the expertise for Qt I wanted to  know what it is with that.
>> Why ship empty folders (that are not and never filled i.e. used)?
> 
> Which one? And an empty folder is not a big problem space-wise.
> 

Space-wise, you are right. That is just a bad omen.
The .lproj folders are all empty, since LyX/Qt handles language-support
differently as is OS X standard. But still. Why ship them?

>> And finally as a possible improvement in the future or a workaround now
>> I 

Re: Tentative schedule for 2.3.0 release

[Stephan Witt]

Am 12.04.2017 um 12:31 schrieb mn :
> 
> On 12.04.17 11:43, Stephan Witt wrote:
> 
 What are some of the present bugs / missing features you're
 referring to? I wonder if some workarounds are available...
>>> 
>>> The biggest bug imho is the slowness, worst on OS X.
>>> That's supposed to get a little bit better.
>> 
>> In case you have continuously spell-checking active perhaps you can speedup
>> drawing by disabling it.
>> 
> 
> While editing spellchecker is always off, as are insets closed (well
> most) and source view and the like. 2.2.2 is still slow and grows slower
> over time. Any improvement in that department thrills me.
> 
>> The part below I don’t understand. What exactly is the message?
>> 
> 
> Being asked about bugs/quirks and possible workarounds I recapitulated
> several things:
> 
> - that apparently almost nobody was interested in reducing the filesize
> of the shipped images.

That’s not true. The disk image is compressed by approximately 75%.

> Low hanging fruit, easily done. For PNG without
> any side effects, for SVG better be done only for the final image.

Here I didn’t understand your proposal. Now should the package build know
your screen resolution? And what do you propose for SVG? There is nothing
the packaging step can do with the SVG files except copying them.

> - that the download and installation size of LyX is generally really huge

Yes, 120 MByte.

Leaving out the spell checker dictionaries will save approximately 
200 MByte on your disk resp. 50 MByte for the disk image.

> 
> -- because it ships all language files at once
>   (this is slightly different with e.g. LibreOffice)

This is because there is no language add-on package download concept for LyX.
But it may be an option to provide a „pure“ LyX-package for those ones using
native spell checker only.

> -- because it ships all debug binaries for a final build
>   (this is again strictly on topic, because I think that's what alphas
>   and betas are for?)

I’m not sure if you get meaningful crash reports otherwise.

> -- because I think it ships lots of Qt-stuff that might not be needed
>   for LyX at all(libqtmultimedia), but I may be wrong on this.

I don’t think there are any superfluous Qt frameworks bundled. But I’ll
check that. In any case I’m not sure it makes a big difference.

> As for the images I offered a solution.
> The debug builds should be separated into a different download, as maybe
> the full language support.
> Lacking the expertise for Qt I wanted to  know what it is with that.
> Why ship empty folders (that are not and never filled i.e. used)?

Which one? And an empty folder is not a big problem space-wise.

> And finally as a possible improvement in the future or a workaround now
> I suggested that HFS-Filesystem compression could be activated on
> installation. Either as a script on the disk image, if accepted. Or done
> by the user afterwards. This would at least mitigate some of the
> filesize worries. (Apple still sells preposterously tiny, non-upgradable
> SSDs as the default.)

Here it is compressed, IMO.

$ file lyx-build/LyX-2.3.0dev-1a95f92+qt5-x86_64-cocoa.dmg
lyx-build/LyX-2.3.0dev-1a95f92+qt5-x86_64-cocoa.dmg: bzip2 compressed data, 
block size = 100k

> While I get it that a comprehensive language support package might be
> the consensus here, I fail to see the advantage of not considering the
> other options. Imagesize would benefit every platform equally.
> 
> greetings
> Mike
> 
>>> 
>>> Huge download and suboptimal to wasteful installation are presumably
>>> tolerated.
>>> (this is optimal and lossless PNG-crushing in general and SVG-cleaning
>>> to shipout pictures for included graphics;
>>> [these workarounds can be applied to the package after installation]
>>> and then the static build on Mac that ships not only debug builds, all
>>> dictionaries and thesaurus files, but also Qt-related stuff that's of
>>> little use for LyX: empty folders, audio, print-support, libqtmultimedia?)
>>> 
>>> Another workaround for this might be to use HFS-compression.
>>> This gives me on an otherwise cleaned and optimized package:
>>> 
>>> /Applications/LyX.app:
>>> Number of HFS+ compressed files: 3171
>>> Total number of files: 3348
>>> Total number of folders: 246
>>> Total number of items (number of files + number of folders): 3594
>>> Folder size (uncompressed; reported size by Mac OS 10.6+ Finder):
>>> 473816843 bytes / 484 MB (megabytes) / 461.6 MiB (mebibytes)
>>> Folder size (compressed - decmpfs xattr; reported size by Mac OS
>>> 10.0-10.5 Finder): 149100062 bytes / 150.8 MB (megabytes) / 143.8 MiB
>>> (mebibytes)
>>> Folder size (compressed): 151100680 bytes / 152.8 MB (megabytes) / 145.7
>>> MiB (mebibytes)
>>> Compression savings: 68.1%
>>> Approximate total folder size (files + file overhead + folder overhead):
>>> 155264330 bytes / 155.3 MB (megabytes) / 148.1 MiB (mebibytes)

Re: Tentative schedule for 2.3.0 release

[mn]

On 12.04.17 11:43, Stephan Witt wrote:

>>> What are some of the present bugs / missing features you're
>>> referring to? I wonder if some workarounds are available...
>>
>> The biggest bug imho is the slowness, worst on OS X.
>> That's supposed to get a little bit better.
> 
> In case you have continuously spell-checking active perhaps you can speedup
> drawing by disabling it.
> 

While editing spellchecker is always off, as are insets closed (well
most) and source view and the like. 2.2.2 is still slow and grows slower
over time. Any improvement in that department thrills me.

> The part below I don’t understand. What exactly is the message?
> 

Being asked about bugs/quirks and possible workarounds I recapitulated
several things:

- that apparently almost nobody was interested in reducing the filesize
of the shipped images. Low hanging fruit, easily done. For PNG without
any side effects, for SVG better be done only for the final image.

- that the download and installation size of LyX is generally really huge

-- because it ships all language files at once
   (this is slightly different with e.g. LibreOffice)
-- because it ships all debug binaries for a final build
   (this is again strictly on topic, because I think that's what alphas
   and betas are for?)
-- because I think it ships lots of Qt-stuff that might not be needed
   for LyX at all(libqtmultimedia), but I may be wrong on this.

As for the images I offered a solution.
The debug builds should be separated into a different download, as maybe
the full language support.
Lacking the expertise for Qt I wanted to  know what it is with that.
Why ship empty folders (that are not and never filled i.e. used)?
And finally as a possible improvement in the future or a workaround now
I suggested that HFS-Filesystem compression could be activated on
installation. Either as a script on the disk image, if accepted. Or done
by the user afterwards. This would at least mitigate some of the
filesize worries. (Apple still sells preposterously tiny, non-upgradable
SSDs as the default.)

While I get it that a comprehensive language support package might be
the consensus here, I fail to see the advantage of not considering the
other options. Imagesize would benefit every platform equally.

greetings
Mike

>>
>> Huge download and suboptimal to wasteful installation are presumably
>> tolerated.
>> (this is optimal and lossless PNG-crushing in general and SVG-cleaning
>> to shipout pictures for included graphics;
>> [these workarounds can be applied to the package after installation]
>> and then the static build on Mac that ships not only debug builds, all
>> dictionaries and thesaurus files, but also Qt-related stuff that's of
>> little use for LyX: empty folders, audio, print-support, libqtmultimedia?)
>>
>> Another workaround for this might be to use HFS-compression.
>> This gives me on an otherwise cleaned and optimized package:
>>
>> /Applications/LyX.app:
>> Number of HFS+ compressed files: 3171
>> Total number of files: 3348
>> Total number of folders: 246
>> Total number of items (number of files + number of folders): 3594
>> Folder size (uncompressed; reported size by Mac OS 10.6+ Finder):
>> 473816843 bytes / 484 MB (megabytes) / 461.6 MiB (mebibytes)
>> Folder size (compressed - decmpfs xattr; reported size by Mac OS
>> 10.0-10.5 Finder): 149100062 bytes / 150.8 MB (megabytes) / 143.8 MiB
>> (mebibytes)
>> Folder size (compressed): 151100680 bytes / 152.8 MB (megabytes) / 145.7
>> MiB (mebibytes)
>> Compression savings: 68.1%
>> Approximate total folder size (files + file overhead + folder overhead):
>> 155264330 bytes / 155.3 MB (megabytes) / 148.1 MiB (mebibytes)

Re: Tentative schedule for 2.3.0 release

[Stephan Witt]

Am 11.04.2017 um 18:46 schrieb mn :
> 
> On 11.04.17 14:58, Joel Kulesza wrote:
>> On Tue, Apr 11, 2017 at 3:38 AM, mn > 
>>> Right now, I am struggling with bugs and also features lacking in
>>> the latest stable LyX. And for some at least I know they are supposed
>>> to be fixed or added in the next release so far, far on the horizon.
>> 
>> What are some of the present bugs / missing features you're
>> referring to? I wonder if some workarounds are available...
> 
> The biggest bug imho is the slowness, worst on OS X.
> That's supposed to get a little bit better.

In case you have continuously spell-checking active perhaps you can speedup
drawing by disabling it.

> 
> The missing features I need are mainly complicated bibliographies, biber
> and biblatex support, properly working natively together; targeted for 2.3?
> I use workarounds as per the wiki for that for a long time now, but this
> is ugly and easily breaks and slows the editor down further because of
> the complicated structure of it all.
> But there is this workaround at least.
> 
> One of the bugs presumably fixed is #10424, as mentioned also here on
> the list last December. There may be more, but I can't find them right now.
> 
> The window/cursor focus problems are apparently not fixed AFAIK.
> (concerning e.g. search/replace, spellchecker and preamble-field in
> doc-prefs)
> My workaround there is to click the preamble field even though the
> blinking cursor signals focus.
> For the two other window focus bugs basically I try to use some yoga and
> chamomile.
> 
> In general language-support, Hebrew or bidi improvements are under
> watch, as I understand it.
> But for me, the editing situation there is dire.
> My workaround for now is to type the passages in another editor and only
> copy and pasting entire blocks into LyX.
> Concerning slowness: this quickly aggravates the situation.

The part below I don’t understand. What exactly is the message?

Stephan

> 
> Huge download and suboptimal to wasteful installation are presumably
> tolerated.
> (this is optimal and lossless PNG-crushing in general and SVG-cleaning
> to shipout pictures for included graphics;
> [these workarounds can be applied to the package after installation]
> and then the static build on Mac that ships not only debug builds, all
> dictionaries and thesaurus files, but also Qt-related stuff that's of
> little use for LyX: empty folders, audio, print-support, libqtmultimedia?)
> 
> Another workaround for this might be to use HFS-compression.
> This gives me on an otherwise cleaned and optimized package:
> 
> /Applications/LyX.app:
> Number of HFS+ compressed files: 3171
> Total number of files: 3348
> Total number of folders: 246
> Total number of items (number of files + number of folders): 3594
> Folder size (uncompressed; reported size by Mac OS 10.6+ Finder):
> 473816843 bytes / 484 MB (megabytes) / 461.6 MiB (mebibytes)
> Folder size (compressed - decmpfs xattr; reported size by Mac OS
> 10.0-10.5 Finder): 149100062 bytes / 150.8 MB (megabytes) / 143.8 MiB
> (mebibytes)
> Folder size (compressed): 151100680 bytes / 152.8 MB (megabytes) / 145.7
> MiB (mebibytes)
> Compression savings: 68.1%
> Approximate total folder size (files + file overhead + folder overhead):
> 155264330 bytes / 155.3 MB (megabytes) / 148.1 MiB (mebibytes)
> 
> greetings
> Mike

Re: Tentative schedule for 2.3.0 release

[Kornel Benko]

Am Dienstag, 11. April 2017 um 23:53:56, schrieb Pavel Sanda 
> Scott Kostyshak wrote:
> > I hope others join this conversation. To alpha or not to alpha?
> 
> If I was manager I would do aplha, do it quickly with very low 
> reuirements for bugs solved or fetures yet-to-be-delivered
> and clearly state that in announcement.
> No matter how better we became with autmated testing i bet that
> windows/mac releases will bring some surprises you rather don't
> want to see in beta.
> 
> Pavel

+1

Kornel

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

Re: Tentative schedule for 2.3.0 release

[Pavel Sanda]

Scott Kostyshak wrote:
> I hope others join this conversation. To alpha or not to alpha?

If I was manager I would do aplha, do it quickly with very low 
reuirements for bugs solved or fetures yet-to-be-delivered
and clearly state that in announcement.
No matter how better we became with autmated testing i bet that
windows/mac releases will bring some surprises you rather don't
want to see in beta.

Pavel

Re: Tentative schedule for 2.3.0 release

[Uwe Stöhr]

El 10.04.2017 a las 05:40, Scott Kostyshak escribió:


Uwe and Stephan, do you know if you will be available around these dates
to produce binaries?


I'm sorry, I cannot plan longer than about a week. I'll try to build a 
binary as soon as possible after you send me the link to the release ZIP 
file.


regards Uwe

Re: Tentative schedule for 2.3.0 release

[Jürgen Spitzmüller]

Am Dienstag, den 11.04.2017, 18:46 +0200 schrieb mn:
> The missing features I need are mainly complicated bibliographies,
> biber
> and biblatex support, properly working natively together; targeted
> for 2.3?

Yes, and already implemented in the master branch, as a matter of fact.

Jürgen

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

Re: Tentative schedule for 2.3.0 release

[mn]

On 11.04.17 14:58, Joel Kulesza wrote:
> On Tue, Apr 11, 2017 at 3:38 AM, mn  
>> Right now, I am struggling with bugs and also features lacking in
>> the latest stable LyX. And for some at least I know they are supposed
>> to be fixed or added in the next release so far, far on the horizon.
> 
> What are some of the present bugs / missing features you're
> referring to? I wonder if some workarounds are available...

The biggest bug imho is the slowness, worst on OS X.
That's supposed to get a little bit better.

The missing features I need are mainly complicated bibliographies, biber
and biblatex support, properly working natively together; targeted for 2.3?
I use workarounds as per the wiki for that for a long time now, but this
is ugly and easily breaks and slows the editor down further because of
the complicated structure of it all.
But there is this workaround at least.

One of the bugs presumably fixed is #10424, as mentioned also here on
the list last December. There may be more, but I can't find them right now.

The window/cursor focus problems are apparently not fixed AFAIK.
(concerning e.g. search/replace, spellchecker and preamble-field in
doc-prefs)
My workaround there is to click the preamble field even though the
blinking cursor signals focus.
For the two other window focus bugs basically I try to use some yoga and
chamomile.

In general language-support, Hebrew or bidi improvements are under
watch, as I understand it.
But for me, the editing situation there is dire.
My workaround for now is to type the passages in another editor and only
copy and pasting entire blocks into LyX.
Concerning slowness: this quickly aggravates the situation.

Huge download and suboptimal to wasteful installation are presumably
tolerated.
(this is optimal and lossless PNG-crushing in general and SVG-cleaning
to shipout pictures for included graphics;
[these workarounds can be applied to the package after installation]
and then the static build on Mac that ships not only debug builds, all
dictionaries and thesaurus files, but also Qt-related stuff that's of
little use for LyX: empty folders, audio, print-support, libqtmultimedia?)

Another workaround for this might be to use HFS-compression.
This gives me on an otherwise cleaned and optimized package:

/Applications/LyX.app:
Number of HFS+ compressed files: 3171
Total number of files: 3348
Total number of folders: 246
Total number of items (number of files + number of folders): 3594
Folder size (uncompressed; reported size by Mac OS 10.6+ Finder):
473816843 bytes / 484 MB (megabytes) / 461.6 MiB (mebibytes)
Folder size (compressed - decmpfs xattr; reported size by Mac OS
10.0-10.5 Finder): 149100062 bytes / 150.8 MB (megabytes) / 143.8 MiB
(mebibytes)
Folder size (compressed): 151100680 bytes / 152.8 MB (megabytes) / 145.7
MiB (mebibytes)
Compression savings: 68.1%
Approximate total folder size (files + file overhead + folder overhead):
155264330 bytes / 155.3 MB (megabytes) / 148.1 MiB (mebibytes)

greetings
Mike

Re: Tentative schedule for 2.3.0 release

[Joel Kulesza]

On Tue, Apr 11, 2017 at 3:38 AM, mn  wrote:

> Right now, I am struggling with bugs and also features lacking in the
> latest stable LyX. And for some at least I know they are supposed to be
> fixed or added in the next release so far, far on the horizon.
>

Mike,

What are some of the present bugs / missing features you're referring to?
I wonder if some workarounds are available...

- Joel

Re: Tentative schedule for 2.3.0 release

[mn]

On 11.04.17 04:45, Scott Kostyshak wrote:


> The requirements and expectations of an alpha are low. I think it is 
> understood that there should not be any big features right before
> the feature freeze. But doing it this way allows us to get an alpha
> out quickly and get testing on 99% of the features that will go into
> the final release.> I am inclined to keep the alpha but am open to more 
> discussion.
>
> One reason for keeping the alpha is that we do not have strong 
> requirements to get it out. It is a way to start the ball rolling. 
> Requirements to release a beta are more strict, and it is nice to
> break up a big task into smaller more achievable tasks.
> 
> A second reason to keep the alpha is that very few Windows and Mac
> users can compile a development version. An alpha is nice in
> situations where we cannot reproduce a bug. We can ask users if they
> can still reproduce e.g. a serious crash that they reported. This can
> let us know if that issue is something we need to focus on fixing
> before a beta.
> 
> On Mon, Apr 10, 2017 at 11:58:51AM +0200, Jean-Marc Lasgouttes
> wrote:

>> Seriously, I am not sure about the alpha release. It is serious 
>> work, and I am not sure what we will gain from it (how many user
>> would try it, but not try nightlies, for example).


> Have we produced nightlies before? Doesn't that require an automatic
>  build system for Mac and Windows?
> 
> I hope others join this conversation. To alpha or not to alpha?
> 

The automated build system would be a plus.

As a longtime Mac-user I am now on a seriously underpowered machine.
Therefore, always compiling LyX and all the dependencies gets more and
more futile every day.
Also, I am personally stuck on OS X 10.10.
This means, because of planned obsolescence, the latest developer tools
from Apple will not be available to me.
And keep in mind: Apple has not a single affordable and reasonably
specced (pro-level) computer on sale now and will not for the
foreseeable future.
Users willing and able to regularly build from source are not exactly a
growing base under these circumstances.

Right now, I am struggling with bugs and also features lacking in the
latest stable LyX. And for some at least I know they are supposed to be
fixed or added in the next release so far, far on the horizon.

I am quite hungry for an alpha and beta versions.
These are more stable than nightlies (psychologically!).
Due to the looong release cycle: alas, not just for testing.


So: to alpha, and beyond.

greetings
Mike

Re: Tentative schedule for 2.3.0 release

[Andrew Parsloe]

On 11/04/2017 2:45 p.m., Scott Kostyshak wrote:



A second reason to keep the alpha is that very few Windows and Mac users
can compile a development version. An alpha is nice in situations where
we cannot reproduce a bug. We can ask users if they can still reproduce
e.g. a serious crash that they reported. This can let us know if that
issue is something we need to focus on fixing before a beta.


On Mon, Apr 10, 2017 at 11:58:51AM +0200, Jean-Marc Lasgouttes wrote:


Seriously, I am not sure about the alpha release. It is serious work, and I
am not sure what we will gain from it (how many user would try it, but not
try nightlies, for example).


Have we produced nightlies before? Doesn't that require an automatic
build system for Mac and Windows?

I hope others join this conversation. To alpha or not to alpha?

Scott



For what it's worth, both alpha1 and alpha2 of the LyX 2.2 release had 
significant bugs on windows 
(http://marc.info/?l=lyx-users=144833725611421=2 and 
http://marc.info/?l=lyx-devel=144878562018319=2).


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Tentative schedule for 2.3.0 release

[Scott Kostyshak]

On Mon, Apr 10, 2017 at 09:46:45AM +0200, Jean-Marc Lasgouttes wrote:

> It was proably discussed last time, but I do not remember: what is the
> rationale for having an alpha before feature freeze? Shouldn't it be
> the opposite?

The requirements and expectations of an alpha are low. I think it is
understood that there should not be any big features right before the
feature freeze. But doing it this way allows us to get an alpha out
quickly and get testing on 99% of the features that will go into the
final release.


On Mon, Apr 10, 2017 at 11:23:16AM +0100, José Abílio Matos wrote:

> OTHO I remember that as the release manager of one of the previous releases 
> the alpha release was the first moment to the test and lubricate the release 
> procedure. To guarantee that tools like "make distcheck" work as intended. By 
> decoupling this from the beta stage where we should by then be in feature 
> freeze the testing was easier.
> Note that this is my personal recollection, I can be wrong. :-)

Indeed, this is nice. I think it was more important last time when it
was the first time I was release manager. It was good for me to practice
the fun process of signing the files, make sure upload to FTP works,
etc.

> With that said we have improved the test and maintenance of the release tools 
> and since the last version was released less than one year ago and Scott is 
> the release manager I agree that we can skip this version. But clearly this 
> is 
> Scott's call.

I am inclined to keep the alpha but am open to more discussion.

One reason for keeping the alpha is that we do not have strong
requirements to get it out. It is a way to start the ball rolling.
Requirements to release a beta are more strict, and it is nice to break
up a big task into smaller more achievable tasks.

A second reason to keep the alpha is that very few Windows and Mac users
can compile a development version. An alpha is nice in situations where
we cannot reproduce a bug. We can ask users if they can still reproduce
e.g. a serious crash that they reported. This can let us know if that
issue is something we need to focus on fixing before a beta.


On Mon, Apr 10, 2017 at 11:58:51AM +0200, Jean-Marc Lasgouttes wrote:

> Seriously, I am not sure about the alpha release. It is serious work, and I
> am not sure what we will gain from it (how many user would try it, but not
> try nightlies, for example).

Have we produced nightlies before? Doesn't that require an automatic
build system for Mac and Windows?

I hope others join this conversation. To alpha or not to alpha?

Scott


signature.asc
Description: PGP signature

Re: Tentative schedule for 2.3.0 release

[Stephan Witt]

Am 10.04.2017 um 05:40 schrieb Scott Kostyshak :
> 
> Dear all,
> 
> I think there is agreement that master is pretty stable. Besides just a
> feeling, I think that this can be confirmed by looking at the trac
> tickets with "2.3.0" milestone and tickets with the "regression"
> keyword.
> 
> I propose the following schedule for the 2.3.0 release process:
> 
>alpha:   22 April
>feature freeze:  19 May
>beta:09 June
>RC:  12 July
>final:   01 August
> 
> Uwe and Stephan, do you know if you will be available around these dates
> to produce binaries?

Yes. These dates are no problem for me. I’m in France when final is planned.
But I cannot think of a hotel without network access in Europe. 

Stephan

> 
> As usual, this schedule is tentative and likely to change (dates could
> be earlier or later).
> 
> Please feel free to propose changes to this schedule, or to ask for me
> to explain why I chose a certain date (or rather a certain duration
> between stages).
> 
> Scott
> 

Re: Tentative schedule for 2.3.0 release

[José Abílio Matos]

On Monday, 10 April 2017 10.58.51 WEST Jean-Marc Lasgouttes wrote:
> No, because doing everything by opposition to others is like doing doing
> it like them: it is following their whim 

:-)
 
> Seriously, I am not sure about the alpha release. It is serious work,
> and I am not sure what we will gain from it (how many user would try it,
> but not try nightlies, for example).
> 
> JMarc

That is a reasonable objection. In essence that was the reason to have it 
dropped from Fedora.

OTHO I remember that as the release manager of one of the previous releases 
the alpha release was the first moment to the test and lubricate the release 
procedure. To guarantee that tools like "make distcheck" work as intended. By 
decoupling this from the beta stage where we should by then be in feature 
freeze the testing was easier.
Note that this is my personal recollection, I can be wrong. :-)

With that said we have improved the test and maintenance of the release tools 
and since the last version was released less than one year ago and Scott is 
the release manager I agree that we can skip this version. But clearly this is 
Scott's call.

-- 
José Abílio

Re: Tentative schedule for 2.3.0 release

[Jean-Marc Lasgouttes]

Le 10/04/2017 à 11:27, José Abílio Matos a écrit :

Again following your reasoning since everyone is abandoning the alpha release
we should keep it. ;-)


No, because doing everything by opposition to others is like doing doing 
it like them: it is following their whim :)


Seriously, I am not sure about the alpha release. It is serious work, 
and I am not sure what we will gain from it (how many user would try it, 
but not try nightlies, for example).


JMarc

Re: Tentative schedule for 2.3.0 release

[José Abílio Matos]

On Monday, 10 April 2017 08.46.45 WEST Jean-Marc Lasgouttes wrote:
> It was proably discussed last time, but I do not remember: what is the
> rationale for having an alpha before feature freeze? Shouldn't it be the
> opposite?

I think that this is the usual procedure. Take Fedora as an example, the alpha 
release is done before the feature freeze.

The rationale, as far as I can remember, is to invite the users to test and 
get an idea where the project is coming and how do the new features integrate 
in the project. So it could be possible that some feature is deemed unready 
and dropped before feature freeze.

On the other hand there is a proposal to drop the alpha release starting from 
Fedora 27 (to be released in October/November). So that means that Fedora 26 
alpha, that was released last Tuesday, is the last alpha release for Fedora.

Again following your reasoning since everyone is abandoning the alpha release 
we should keep it. ;-)
-- 
José Abílio

Re: Tentative schedule for 2.3.0 release

[Jean-Marc Lasgouttes]

Le 10/04/2017 à 05:40, Scott Kostyshak a écrit :

I think there is agreement that master is pretty stable. Besides just a
feeling, I think that this can be confirmed by looking at the trac
tickets with "2.3.0" milestone and tickets with the "regression"
keyword.


Yes, I think it is time to think seriously about it.


I propose the following schedule for the 2.3.0 release process:

alpha:   22 April
feature freeze:  19 May


It was proably discussed last time, but I do not remember: what is the 
rationale for having an alpha before feature freeze? Shouldn't it be the 
opposite?



beta:09 June
RC:  12 July
final:   01 August


1st of august will probably be a slow period. But there may not be a 
better solution.


JMarc