Re: minutes of ESC call ...

[Kaganski Mike]

On 11/2/2017 8:10 PM, Michael Meeks wrote:
> * Completed Action Items:
>  + ship the horror win / VC runtime DLLs with the installer (Cloph)
>  [ patch appears to work, but we already have them in the installer
>if you do an admin-install they are already installed.
>we ship them twice – once as LibreOffice, but once as a run-time 
> module
>not entirely elegant.
>for 5.4 – merge it as-is, for 6.0 do something clever.
> http://dev-builds.libreoffice.org/daily/libreoffice-5-4/Win-x86@62-TDF/tdf_108580/
>  ]

1. For 6.0, we would not need to ship the merge module - because that 
module is only working for WinXP. So that leaves us with just one copy.

2. Still, having app-local DLLs is worse than system-updateable (at 
least security-wise: if we bundle app-local DLLs, then we would have to 
put their advisories to our site? so that users using not-up-to-date LO 
versions could know that they might be vulnerable, despite having 
updated their systems). So, we could try to include MSUs from KB2999226 
[1]. There are 3 different packages for each bitness that cover all 
supported platforms requiring the update (Win7, Win8, Win8.1):
- for x86:
   Windows6.1-KB2999226-x86.msu
   Windows8-RT-KB2999226-x86.msu
   Windows8.1-KB2999226-x86.msu
- for x64:
   Windows6.1-KB2999226-x64.msu
   Windows8-RT-KB2999226-x86.msu
   Windows8.1-KB2999226-x64.msu

The size of all three x86 packages is 1.77 MB total; three x64 packages 
are 3.24 MB total.

The MSUs are installable using Windows Update Standalone Installer [2] 
(system component in all those Windows versions). Custom actions would 
need to be created, with relevant conditions (VersionNT; [3]).

The drawbacks (besides extra size):
1. We need to also check for pre-conditions: if the KB2999226 is already 
installed; if required pre-requisite KBs are present (see [1]; 
prerequisites exist for Win7 and Win8.1 - curiously no preconditions for 
Win8). For Win7, the prerequisite is SP1, so may just state this version 
as system requirement? For Win8.1, the prerequisite is [4], which is 
several hundred MB...
2. We somehow need to get the packages to dev environment when building 
the installer - should we put the blobs to our server to fetch as 
external package on build? (I don't know if there's a static URL for 
those files on MS site.)

[1] https://support.microsoft.com/en-us/help/2999226
[2] https://support.microsoft.com/en-us/help/934307
[3] https://msdn.microsoft.com/en-us/library/aa370556
[4] https://support.microsoft.com/en-us/help/2919355

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

32bitjavacrash workaround?

[Kaganski Mike]

Hi,

As the java's stack management still is the problem for LibreOffice on 
Linux [1], I had an idea (disclaimer: I use Windows for development, and 
I have no Java experience, so I don't volunteer for the hardest part):

Currently we have a test for working OpenCL implementation, that 
launches on certain conditions to disable its use if test is failed.

Cannot we do the same for Java? E.g., spawn a separate process, that 
would do something simple with Java, which is known to segfault on the 
problem, and on failure, disable using the selected JVM (and show a 
warning)? And launch the test at first run (on user's profile creation); 
on JVM selection in advanced options; after a crash (in recovery).

Does that make sense? I suppose it could avoid having blacklists of 
Java+kernel combinations etc, and be good for end users that suffer from 
the crashes: they would both not avoid crashes, and be informed.

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=108619

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Localization issues related to telling users to update after submitting a crash report

[Kaganski Mike]

On 4/17/2017 1:47 AM, Markus Mohrhard wrote:
> we need a way to
> notify users that reports for these versions are ignored and that they
> should use a newer version.
> ...
> My problem is now whether we
> need to provide a localized version of this string. The string would
> come from the server which currently has no translation support. In
> theory we know the localization of the soffice instance that has
> submitted the crash report but I'd like avoid adding many localized
> strings to the crash reporter.
>
> Are there any objections against showing the generic update request
> instead of a localized one when someone uses an old version? If there
> are no objections I would implement this and try to get the necessary
> changes in 5.4 and 5.3.3.

Can we have a localizable generic message with placeholders for version 
numbers taken from server response?


-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOffice Error during make command

[Kaganski Mike]

On 7/31/2017 11:08 AM, Miklos Vajna wrote:
> Hi,
> 
> On Fri, Jul 21, 2017 at 09:24:04PM -0700, sherlock  
> wrote:
>> As It mentioned in the tutorial(
>> https://wiki.documentfoundation.org/Development/BuildingForAndroid ), I
>> downloaded latest version via this command( git clone
>> git://anongit.freedesktop.org/libreoffice/core libreoffice ). If I should
>> use special commit how can I download it?
> 
> No, latest master is supposed to build.

I suppose that OP wanted to know how to switch to a specific commit of 
his liking, rather than if he needs some specific commit to build.

If my understanding is right, then you should use usual git clone (as 
you mentioned), and then use git checkout  to switch to a 
specific commit (if you have some good reason to use headless state).


-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LO 80731 - Incorrect syntax does compile, MID without end bracket

[Kaganski Mike]

Hi Pierre,

On 8/4/2017 4:26 AM, Pierre Lepage wrote:
> I have implemented a new warning option on compilation. I did not go too 
> far.

Great!

> A simple checkbox "Warning On" and an "else" in the faulty 
> structure causing the problem of the closing parenthesis does the trick. 
> I have included a screen copy of the dialog with the "Warning On" option.
> 
> The behavior of StarBasic with the "Warning On" option would be as follows.
> 
> A) Warning On and active IDE window: Warning displayed on line where 
> normally there would be an error.
> 
> B) Warning On and IDE window inactive: Warning at the beginning of the 
> macro execution in the application window.
> 
> C) Warning Off: No tolerated error and no warning stop.
> 
> For the case of the closing parenthesis, the warning message could be 
> the following: A closing parenthesis is missing in one or more 
> expressions with the Mid function.

Could you post your change to gerrit please? It's better to discuss code 
there.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

C[++]: Normalizing include syntax ("" vs <>)

[Kaganski Mike]

Hi!

Lately, I've pushed some commits ([1], [2], [3]) that change syntax used 
for some includes. I wanted to share my rationale behind that, along 
with some notes about past discussion on this topic.

The topic is using one of two syntaxes described for #include directive 
in standard (section [cpp.include]): in angular brackets <> vs in quotes 
"". The standard reads:

 > 2 A preprocessing directive of the form
 > # include < h-char-sequence > new-line
 > searches a sequence of implementation-defined places for a header 
identified uniquely by the specified sequence
 > between the < and > delimiters, and causes the replacement of that 
directive by the entire contents of the
 > header. How the places are specified or the header identified is 
implementation-defined.
 > 3 A preprocessing directive of the form
 > # include " q-char-sequence " new-line
 > causes the replacement of that directive by the entire contents of 
the source file identified by the specified
 > sequence between the " delimiters. The named source file is searched 
for in an implementation-defined
 > manner. If this search is not supported, or if the search fails, the 
directive is reprocessed as if it read
 > # include < h-char-sequence > new-line
 > with the identical contained sequence (including > characters, if 
any) from the original directive.
 > ...
 > [ Note: Although an implementation may provide a mechanism for making 
arbitrary source files available to
 > the < > search, in general programmers should use the < > form for 
headers provided with the implementation,
 > and the " " form for sources outside the control of the implementation.

The discussion that took place at [4] raised some concerns on possible 
problems due to inconsistent treatment of the quoted syntax in MS 
compiler vs gcc. Namely, [5] states, that
 > The preprocessor searches for include files in this order:
 > 1) In the same directory as the file that contains the #include 
statement.
 > 2) In the directories of the currently opened include files, in the 
reverse order in which they were opened. The search begins in the 
directory of the parent include file and continues upward through the 
directories of any grandparent include files.
 > 3) Along the path that's specified by each /I compiler option.
 > 4) Along the paths that are specified by the INCLUDE environment 
variable.

while [6] reads about quoted syntax:
 > This variant is used for header files of your own program. It 
searches for a file named file first in the directory containing the 
current file, then in the quote directories and then the same 
directories used for . You can prepend directories to the list of 
quote directories with the -iquote option.

So, it is speculated that these differences might result in very hard to 
trace bugs. Thus, it was suggested to use <> syntax uniformly, to avoid 
that possibility.

However, doing so creates some problems, at least with IDE integration 
with VisualStudio. The generated project, naturally, doesn't add 
file-specific include paths to each file, to include the files' 
directories. This makes the includes of headers sitting in the same 
directory as the source file, referenced using <> syntax, to fail in the 
editor's parser, and errors (failed includes + unknown identifiers) 
being highlighted (underlined with red) in editor window. This impairs 
the ease of use of the IDE aids (e.g., Intellisense, and error 
highlighting that gets masked by false errors throughout the code).

Here I propose an updated rule to follow in the use of includes in the 
project's code:

1. Use *only* <> syntax for any include that resides in include paths 
explicitly defined in the module's mk file (gb_Library_set_include), 
global includes ($INCLUDE), e.g., /include, and system headers ( 
or ) - these are interface headers.
As all implementations agree to use both implementation include places 
and -I-defined places as search paths for <> syntax, this will likely 
not allow inconsistency problems (and is actually what is used now in 
most of the code).

2. Use *only* <> syntax for includes inside headers that reside in such 
places (e.g., no header in /include should include other headers using 
"" itself). This is aimed to prevent cases where some header placed in 
the current source's directory would conflict with an include referred 
from a global interface header.

3. *Always* use "" syntax *only* for includes that refer to headers 
placed next to the current source in the same directory (or 
subdirectories), i.e. that would be found using the "." entry of -I 
switch. These are implementation headers. This applies to both includes 
in c[xx] files as well as in h[xx] residing in directories like 
/sw/source/core/access (as opposed to those in /sw/inc).

As all implementations search current source's directory first for 
includes referred using "" syntax, as a side effect, these rules will 
(1) speed up searching for same-directory implementation headers (whic

Re: C[++]: Normalizing include syntax ("" vs <>)

[Kaganski Mike]

Hi,

09.10.2017 12:23, Stephan Bergmann пишет:
> On 10/09/2017 10:29 AM, Stephan Bergmann wrote:
>> On 10/06/2017 11:26 AM, Kaganski Mike wrote:
>>> 3. *Always* use "" syntax *only* for includes that refer to headers
>>> placed next to the current source in the same directory (or
>>> subdirectories), i.e. that would be found using the "." entry of -I
>>> switch. These are implementation headers. This applies to both includes
>>> in c[xx] files as well as in h[xx] residing in directories like
>>> /sw/source/core/access (as opposed to those in /sw/inc).
>>
>> Does that mean that once you're done we can stop adding -I. to 
>> SOLARINC in configure.ac?  (Also, it's unclear to me what
>>
>>-I$(dir $(3))
>>
>> in gb_CObject__command_pattern in 
>> solenv/gbuild/platform/com_{GCC,MSC}_class.mk is good for, and 
>> whether it could then be dropped, too.)

Yes, that was my plan, but ...

>
> Seeing that both solenv/gbuild/platform/com_{GCC_defs,MSC_class}.mk 
> already drop SOLARINC's -I. from gb_LinkTarget_INCLUDE, it is probably 
> rather the latter -I$(dir $(3)) that can be dropped from 
> gb_CObject__command_pattern in 
> solenv/gbuild/platform/com_{GCC,MSC}_class.mk once you're done.


You are quite right, this is what should be ultimately removed. Thank you!

>
> (And -I. dropped from SOLARINC in configure.ac as an orthogonal clean 
> up?  Would need auditing what other places using SOLARINC (besides 
> those gb_LinkTarget_INCLUDE that drop it anyway) might need it for.)
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

-- 
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

A proposal for separate English localization

[Kaganski Mike]

Hello!

Recently I was approached by members of our local community who manage 
the translation of LibreOffice UI to Russian. I was told that they have 
a regularly recurring problem, that each time a developer changes an 
English string in LibreOffice UI, they have that string untranslated in 
pootle, and need to repeat same actions again to re-translate it. What's 
worse, the translation that pootle suggest in that case is oftentimes wrong.

This is *not* related to changes that were recently made by Caolan to 
the localization machinery; rather, it's more like commit 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=029f2fdc where 
hundreds of strings were slightly changed for consistency in UI. That's 
of course necessary to do, but the specifics of our translation makes 
the English (built in) translation the source for all others, and every 
change in it (even irrelevant for a other translation that, say, has the 
strings capitalized consistently) forces *all translation teams* to do 
the extra work.

I received a proposal that looks like that: make an English translation 
yet another ordinary translation, and make strings in code immutable. 
When a developer decides to change English strings, those changes would 
go to the translation, not to the source. This way, the new strings 
would, as before, add work to translation teams, but changes to English 
translation that are irrelevant to other translations will be local.

I had a discussion on the topic with erAck, and he raised several 
concerns. First, the English translation is the fallback in case there's 
no localized translated string. Second: developers would not work with 
pootle, and that would raise need for English localization team. Third, 
that developers don't know if thier change to English UI is or is not 
relevant to other translation; English being the source for others, the 
change might need to be reflected in the other translations, so each 
change should be reviewed by localizers anyway.

When I discussed the topic with Olivier, he also told me that the 
workflow is very uncomfortable for translation teams, and stressed that 
the tooling gives wrong proposals for changed translations, thus not 
helping in the process.

I wanted to ask all interested parties to discuss the topic, and share 
your opinions. From my side, I suppose that the concerns raisedby Eike 
could be sloved like this:

1. The English translation becomes the fallback. In case that there's no 
English string for an element, that should be blocked on compilation 
stage, or alternatively the immutable code string would become the fallback.

2. The English translation should be created in a different way (in a 
dedicated source file?) to be easy for developers to change.

3. Any change in English translation (not in immutable source strings!) 
would trigger all other translations of this string to become fuzzy 
(thus not loosing previous translation, but just signaling the 
requirement to review).

Hope this makes sense. I must admit that I myself don't have a deep 
knowledge in our localization machinery, so if this isn't reasonable, 
please ignore my proposals.

-- 
Best regards,
Mike Kaganski

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: odt's to image-embedded html's

[Kaganski Mike]

Hi Nazarii,

17 Июн 2018 г. 17:11 пользователь Nazarii  написал:

Hello everybody,

Sorry for disturbing you but I'm in need of some help (was trying to Google but 
without much success).

Given:

  *   Lubuntu 18.04
  *   LO 6.0

I have a bunch of odt files (in one folder). I need to convert all of them to 
html files with embedded images. I was trying to use a code like the following:

for f in *.odt; do echo "Processing $f"; libreoffice6.0 --writer "$f"; soffice 
--convert-to html:HTML:EmbedImages "$f"; done

What the libreoffice6.0 --writer "$f" is about? Doesn't it work without it?

but without success. Maybe somebody of you can help me to figure out how to 
write an appropriate code?

Thank you in advance!


--
Best regards, Mike Kaganski.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Cppcheck: Reduction of False Positives with a MSVC Project File

[Kaganski Mike]

Hi!

https://gerrit.libreoffice.org/60119
https://gerrit.libreoffice.org/60122
https://gerrit.libreoffice.org/60120
https://gerrit.libreoffice.org/60121
https://gerrit.libreoffice.org/60123

are meant to take care of those that aren't false positives...

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

precompiled_basctl is always rebuilt on Windows, even when no edits were made

[Kaganski Mike]

Hi!

Since last few weeks, I see that precompiled_basctl started to get 
rebuilt every time I do an incremental build on my Win10+VS2015+cygwin64 
development box (and, naturally, the dependent module as well). This 
happens whenever I do make build-nocheck, even when there were no edits 
to anything in the tree. The net result is slower builds.

The problem persists after make clean; make.

Debugging with make --debug=b shows this:

[...skip...]
File 'baside.sdi' does not exist.
   Must remake target 'baside.sdi'.
   Successfully remade target file 'baside.sdi'.
File 'basslots.hrc' does not exist.
   Must remake target 'basslots.hrc'.
   Successfully remade target file 'basslots.hrc'.
  Prerequisite 'baside.sdi' of target 
'D:/sources/lo-core1/workdir/SdiTarget/basctl/sdi/basslots' does not exist.
  Prerequisite 'basslots.hrc' of target 
'D:/sources/lo-core1/workdir/SdiTarget/basctl/sdi/basslots' does not exist.
 Must remake target 
'D:/sources/lo-core1/workdir/SdiTarget/basctl/sdi/basslots'.
[...skip...]
  Prerequisite 
'D:/sources/lo-core1/workdir/SdiTarget/basctl/sdi/basslots' is newer 
than target 'D:/sources/lo-core1/workdir/SdiTarget/basctl/sdi/basslots.hxx'.
 Must remake target 
'D:/sources/lo-core1/workdir/SdiTarget/basctl/sdi/basslots.hxx'.
[...skip...]
Prerequisite 
'D:/sources/lo-core1/workdir/SdiTarget/basctl/sdi/basslots' is newer 
than target 'D:/sources/lo-core1/workdir/Headers/Library/basctllo.dll'.
   Must remake target 
'D:/sources/lo-core1/workdir/Headers/Library/basctllo.dll'.
[...skip...]
Prerequisite 
'D:/sources/lo-core1/workdir/Headers/Library/basctllo.dll' is newer than 
target 
'D:/sources/lo-core1/workdir/PrecompiledHeader/debug/precompiled_basctl.hxx.gch'.
   Must remake target 
'D:/sources/lo-core1/workdir/PrecompiledHeader/debug/precompiled_basctl.hxx.gch'.
[...skip to EOF]

The two files (baside.sdi and basslots.hrc) naturally exist in basctl/sdi.

Looking at workdir/Dep/SdiTarget/basctl/sdi/basslots.d, there are the 
two files that are listed without paths, unlike the rest:

D:/sources/lo-core1/workdir/SdiTarget/basctl/sdi/basslots : \
  D:/sources/lo-core1/basctl/sdi/basslots.sdi \
  D:\sources\lo-core1\include\editeng\editids.hrc \
  D:\sources\lo-core1\include\editeng\memberids.h \
  D:\sources\lo-core1\include\sfx2\sfxsids.hrc \
  D:\sources\lo-core1\include\svl\memberid.h \
  D:\sources\lo-core1\include\svl\solar.hrc \
  D:\sources\lo-core1\include\svx\svxids.hrc \
  D:\sources\lo-core1\include\svx\unomid.hxx \
  D:\sources\lo-core1\sfx2\sdi\sfx.sdi \
  D:\sources\lo-core1\sfx2\sdi\sfxitems.sdi \
  D:\sources\lo-core1\svx\sdi\svx.sdi \
  D:\sources\lo-core1\svx\sdi\svxitems.sdi \
  D:\sources\lo-core1\svx\sdi\xoitems.sdi \
  baside.sdi \
  basslots.hrc

D:/sources/lo-core1/basctl/sdi/basslots.sdi :

D:\sources\lo-core1\include\editeng\editids.hrc :

D:\sources\lo-core1\include\editeng\memberids.h :

D:\sources\lo-core1\include\sfx2\sfxsids.hrc :

D:\sources\lo-core1\include\svl\memberid.h :

D:\sources\lo-core1\include\svl\solar.hrc :

D:\sources\lo-core1\include\svx\svxids.hrc :

D:\sources\lo-core1\include\svx\unomid.hxx :

D:\sources\lo-core1\sfx2\sdi\sfx.sdi :

D:\sources\lo-core1\sfx2\sdi\sfxitems.sdi :

D:\sources\lo-core1\svx\sdi\svx.sdi :

D:\sources\lo-core1\svx\sdi\svxitems.sdi :

D:\sources\lo-core1\svx\sdi\xoitems.sdi :

baside.sdi :

basslots.hrc :

[EOF]

I couldn't find the reason for this file being generated like that. The 
workaround that works for me now is to edit the 
workdir/Dep/SdiTarget/basctl/sdi/basslots.d to include the paths for the 
files.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: libreoffice 6.1.0.0.beta1 failing hsqldb test

[Kaganski Mike]

On 5/31/2018 10:47 AM, Miklos Vajna wrote:
> IIRC Rene had SAL_USE_VCLPLUGIN=svp set globally. master had
> fixes to tolerate that but not sure if that was cherry-picked to
> libreoffice-6-1.

The https://gerrit.libreoffice.org/54068 was reverted in 
https://gerrit.libreoffice.org/54123 after mst fixed it properly.


-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: about basic header files

[Kaganski Mike]

Hi Rahul Gurung!

On 8/8/2018 9:37 AM, Rahul Gurung wrote:
> In colleges, we are taught to use header files like iostream.h in cpp to 
> use various functions, but while diving in LO code (specifically java  
> and cpp tests)  i found that we don't mention those header files, why so?

Please be more specific: like which .cpp file uses what, and which 
header you expect but don't find. Most probably you simply don't see 
that the expected header is mentioned in a wrapper header already included.


-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Windows Debug builds failure: 'DbgGUIInitSolarMutexCheck': identifier not found

[Kaganski Mike]

Hi!

On 8/8/2018 3:56 PM, Stephan Bergmann wrote:
> On 07/08/18 18:14, Stephan Bergmann wrote:
>> As we speak, I happen to run into your CppunitTest_cppuhelper_qa_misc 
>> failure with my MSVC build (with latest Visual Studio 2017, see above) 
>> too, will investigate.  (The test currently only runs (late) during 
>> `make check`, see  "No need 
>> for CppunitTest_cppuhelper_qa_misc to be a subsequentcheck".)
> 
> Mike is working on a fix at  
> "Don't break __CxxDetectRethrow contract"

I seem to be unable to come with a solution, so I decided to summarize 
my findings here.

So, with commit 6ddecf61ecada646fbd6f8809270d47289727e8a, Caolán has 
uncovered a hidden bug that must have been there for some time. Function 
cpp_call() in bridges/source/cpp_uno/msvc_win32_*/uno2cpp.cxx uses SEH 
(__try-__except statement) to guard the called method; 
CPPU_CURRENT_NAMESPACE::mscx_filterCppException() is used there as the 
__except expression; and the latter uses CRT's *internal* 
__CxxDetectRethrow() function to check if the handled C++ exception is 
being re-thrown. __CxxDetectRethrow() checks the opaque exception 
descriptor passed by pointer (which has internal EHExceptionRecord* 
type), and basically detects if two conditions are true: the exception 
is C++ exception (using PER_IS_MSVC_EH macro), and that it has no 
exception information (using PER_PTHROW macro); see comment in 
ExFilterRethrow in MSVCRT's crt/src/vcruntime/frame.cpp for the same check.

Unfortunately, the function __CxxDetectRethrow() modifies global state: 
it increments an internal variable (__ProcessingThrow++), which is used 
throughout CRT's exception handling code to detect that unwinding is in 
progress when its value is non-zero (one comment says "we are 
unwinding... possibly called from a dtor()"). In that case, e.g., 
std::current_exception() returns empty exception_ptr (related code is in 
CRT's __ExceptionPtr::_CurrentException() method). As documented in the 
beginning of the crt/src/vcruntime/mgdframe.cpp, where 
__CxxDetectRethrow() is defined, the function is used internally when 
C++ exceptions are handled in COM+. It is designed to be used in 
specific conditions, and after some other companion functions have been 
called (specifically, __CxxExceptionFilter and 
__CxxRegisterExceptionObject); finally, __CxxUnregisterExceptionObject 
must be called. All the mentioned functions also modify 
__ProcessingThrow; they also modify other internal variables (global 
state), allocate and release memory; and __CxxUnregisterExceptionObject 
also destructs the exception object.

All of the described complexity made me unable to come with a proper way 
to call those functions: they expect some state of SEH; they modify the 
state; not calling __CxxExceptionFilter leads to still unpaired 
decrements of __ProcessingThrow; trying to finally call 
__CxxUnregisterExceptionObject destroys the object that we tested in our 
mscx_filterCppException, which leads to use-after-delete. So the problem 
now remains: it's not enough to just revert the Caolán's commit 
mentioned above, since we obviously break CRT state now and then, and 
the revert would just hide this, not solve.

The related code (using __CxxDetectRethrow to check for the exception 
being rethrown) was introduced with commit 
37d3cdd8d280f509ffa37e47c4706213f4dcda7c from 2003; but I don't know if 
the function already had current behaviour back then.

Just for reference, I paste here the reference code given in 
crt/src/vcruntime/mgdframe.cpp as the example of how the functions work 
together:


// Model of C++ eh in COM+
//
// void func()
// {
// try {
// TryBody();
// } catch (cpp_object o)
// {
// CatchOBody();
// } catch (...)
// {
// CatchAllBody();
// }
// }
//
// Turns into this:
//
//
// void func()
// {
// int rethrow;
// // One per try block
// int isCxxException;
// // One per catch(...)
// __try {
// TryBody();
// }
// __except(__CxxExceptionFilter(exception,
//   typeinfo(cpp_object),
//   flags,
//   &o))
// // This is how it's done already
// {
// // Begin catch(object) prefix
// char *storage = _alloca(__CxxQueryExceptionSize());
// rethrow = false;
// __CxxRegisterExceptionObject(exception,
//  storage);
// __try {
// __try {
// // End catch(object) prefix
// CatchOBody();
// // Begin catch(object) suffix
// } __except(rethrow = __CxxDetectRethrow(exception),
//EXCEPTION_CONTINUE_SEARCH)
// {}
// }
// __finally
// {
// __CxxUnregisterExceptionObject(storage,
//   

Re: Windows Debug builds failure: 'DbgGUIInitSolarMutexCheck': identifier not found

[Kaganski Mike]

I forgot to mention that the problem with CppunitTest_cppuhelper_qa_misc 
manifests itself because it happens to have two tests: testCatchThrow 
first, which triggers the described behaviour and modifies global state, 
and testgetCaughtException second, that tries to test exception handling 
and fails because it's already broken at this stage. Trying to run only 
the latter (using CPPUNIT_TEST_NAME) will succeed.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

PythonTest_sw_python failure

[Kaganski Mike]

Since commit 4a290888580474f9542f185091bb2a6fcf4e9a53, 
PythonTest_sw_python fails on Windows (with VS 15.8.6) in 
SvtBroadcaster::~SvtBroadcaster() on line 102

  while (dest != maDestructedListeners.end() && (*dest < *it))

on second iteration when maListeners contains more than 1 item. The 
assertion "vector iterators incompatible" is failed in this case. 
Ignoring the assertion still fails the unit test.

Reverting 4a290888580474f9542f185091bb2a6fcf4e9a53 (and subsequent 
48bf5a74186140760a734091a85e85d198e6fdfa) allows to pass the test.

My autogen.input:

--with-external-tar=c:/lo/src/lo-externalsrc
--with-junit=c:/lo/src/junit-4.10.jar
--with-ant-home=c:/lo/src/apache-ant-1.9.5
--with-galleries=no
--enable-pch
--enable-dbgutil
--enable-symbols
--without-help
--without-package-format
--disable-64-bit
--with-gdrive-client-id=XXX
--with-gdrive-client-secret=XXX
--enable-breakpad
--disable-windows-build-signing

===

$ /opt/lo/bin/make PythonTest_sw_python
C:/cygwin64/opt/lo/bin/make -j 12 -rs -f C:/lo/src/core/Makefile.gbuild 
PythonTest_sw_python
[PRL] CustomTarget/postprocess/images/sorted.lst
[PRL] CustomTarget/postprocess/images/commandimagelist.ilst
make[1]: Circular 
C:/lo/src/core/workdir/ExternalProject/twain_dsm.prepare <- 
C:/lo/src/core/workdir/UnpackedTarball/twain_dsm.done dependency dropped.
[ECH] CustomTarget/instsetoo_native/setup/version.ini
[PRL] CustomTarget/postprocess/images/images_breeze.zip
[PRL] CustomTarget/postprocess/images/images_breeze_dark.zip
[PRL] CustomTarget/postprocess/images/images_colibre.zip
[PRL] CustomTarget/postprocess/images/images_elementary.zip
[PRL] CustomTarget/postprocess/images/images_karasa_jaga.zip
[PRL] CustomTarget/postprocess/images/images_sifr.zip
[PRL] CustomTarget/postprocess/images/images_sifr_dark.zip
[PRL] CustomTarget/postprocess/images/images_tango.zip
[PKG] instsetoo_native_setup
[CUS] postprocess/images
[PKG] postprocess_images
[BIN] postprocess
[MOD] postprocess
[ALL] All modules but instset: UnoControls accessibility animations 
apple_remote avmedia basctl basegfx basic bean binaryurp bridges canvas 
chart2 cli_ure codemaker comphelper configmgr connectivity cppcanvas 
cppu cppuhelper cpputools cui dbaccess desktop dictionaries drawinglayer 
dtrans editeng embeddedobj embedserv emfio eventattacher extensions 
external msc-externals apache-commons beanshell boost breakpad clew 
clucene coinmp cppunit curl epoxy expat firebird glm gpgmepp graphite 
harfbuzz hsqldb hunspell hyphen icu jfreereport lcms2 libabw libassuan 
libcdr libcmis libebook libepubgen libetonyek libexttextcat libfreehand 
libgpg-error libjpeg-turbo liblangtag libmspub libmwaw libnumbertext 
libodfgen liborcus libpagemaker libpng libqxp librevenge libstaroffice 
libtommath libvisio libwpd libwpg libwps libxml2 libxslt libzmf lpsolve 
mariadb-connector-c mdds mdnsresponder misc_extensions more_fonts mythes 
neon nss openssl pdfium poppler postgresql python3 redland rhino 
twain_dsm ucpp xmlsec xsltml zlib extras filter forms formula fpicker 
framework helpcompiler hwpfilter i18nlangtag i18npool i18nutil idl idlc 
io javaunohelper jurt jvmaccess jvmfwk l10ntools librelogo 
libreofficekit lingucomponent linguistic lotuswordpro nlpsolver o3tl odk 
offapi officecfg onlineupdate oovbaapi oox opencl package postprocess 
pyuno qadevOOo readlicense_oo registry remotebridges reportbuilder 
reportdesign ridljar sal salhelper sax sc scaddins sccomp scp2 scripting 
sd sdext setup_native sfx2 shell slideshow smoketest solenv soltools sot 
starmath stoc store svgio svl svtools svx sw swext sysui test testtools 
toolkit tools ucb ucbhelper udkapi uitest unodevtools unoidl unoil 
unotest unotools unoxml ure uui vbahelper vcl winaccessibility wizards 
writerfilter writerperfect xmerge xmlhelp xmloff xmlreader xmlscript 
xmlsecurity
[PYT] sw_python
warn:sfx.appl:14300:15220:sfx2/source/appl/app.cxx:191: No DDE-Service 
possible. Error: 16399
warn:vcl:14300:15220:vcl/win/window/salframe.cxx:1084: 
WinSalFrame::SetIcon(): Could not load large icon !
warn:vcl:14300:15220:vcl/win/window/salframe.cxx:1085: 
WinSalFrame::SetIcon(): Could not load small icon !
warn:basic:14300:15220:basic/source/uno/namecont.cxx:973: Cannot access 
extensions!
warn:basic:14300:15220:basic/source/uno/namecont.cxx:973: Cannot access 
extensions!
warn:vcl:14300:15220:vcl/win/window/salframe.cxx:1084: 
WinSalFrame::SetIcon(): Could not load large icon !
warn:vcl:14300:15220:vcl/win/window/salframe.cxx:1085: 
WinSalFrame::SetIcon(): Could not load small icon !
.warn:vcl:14300:15220:vcl/win/window/salframe.cxx:1084: 
WinSalFrame::SetIcon(): Could not load large icon !
warn:vcl:14300:15220:vcl/win/window/salframe.cxx:1085: 
WinSalFrame::SetIcon(): Could not load small icon !
.warn:vcl:14300:15220:vcl/win/window/salframe.cxx:1084: 
WinSalFrame::SetIcon(): Could not load large icon !
warn:vcl:14300:15220:vcl/win/window/salframe.cxx:1085: 
WinSalFrame::SetIcon(): Could not load small icon !
.warn:vcl:14300:15220:vcl/

Re: plural forms translation, ngettext

[Kaganski Mike]

On 10/5/2018 6:09 PM, Caolán McNamara wrote:
> To current NC_(context, string) we add NNC_(context, singular, plural)
> when declaring the strings for translation

How does it play with other languages, where we might have more complex 
rules? E.g., in Russian, a "singular" form might be used for any decimal 
integer ending with 1 except 11 (e.g., 21, 31, 101...); also endings for 
numbers with 2, 3, 4 differ from 5 and greater (22 from 25 likewise)...

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build error on Windows

[Kaganski Mike]

Hi Gabor,

On 10/10/2018 10:58 AM, Gabor Kelemen wrote:
> We are experiencing a misterious build error with current master branch 
> on Windows without any code changes.
> make distclean does not help. Any idea what could be done here?
> 
> [build DEP] LNK:Library/dbmmlo.dll
>     Creating library 
> D:/LibreOffice/core/workdir/LinkTarget/Library/isubsequenttest.lib and 
> object D:/LibreOffice/core/workdir/LinkTarget/Library/isubsequenttest.exp
> [build LNK] Library/dbmmlo.dll
> [build DEP] LNK:Library/sdbtlo.dll
> [build LNK] Library/sdbtlo.dll
> [build MOD] desktop
>     Creating library 
> D:/LibreOffice/core/workdir/LinkTarget/Library/ivclplug_win.lib and 
> object D:/LibreOffice/core/workdir/LinkTarget/Library/ivclplug_win.exp
> [build MOD] dtrans
>     Creating library 
> D:/LibreOffice/core/workdir/LinkTarget/Library/idbaxml.lib and object 
> D:/LibreOffice/core/workdir/LinkTarget/Library/idbaxml.exp
> [build CMP] embeddedobj/source/msole/emboleobj.windows
> salframe.o : error LNK2019: unresolved external symbol 
> __imp__SHStrDupW@8 referenced in function "long __cdecl 
> InitPropVariantFromString(wchar_t const *,struct tagPROPVARIANT *)" 
> (?InitPropVariantFromString@@YAJPB_WPAUtagPROPVARIANT@@@Z)
> D:/LibreOffice/core/instdir/program/vclplug_winlo.dll : fatal error 
> LNK1120: 1 unresolved externals
>     Creating library 
> D:/LibreOffice/core/workdir/LinkTarget/Library/idbmm.lib and object 
> D:/LibreOffice/core/workdir/LinkTarget/Library/idbmm.exp
> [build MOD] extensions
> [build CMP] xmlsecurity/util/xmlsecurity
>     Creating library 
> D:/LibreOffice/core/workdir/LinkTarget/Library/isdbt.lib and object 
> D:/LibreOffice/core/workdir/LinkTarget/Library/isdbt.exp
> 
> mt.exe : general error c101008d: Failed to write the updated manifest to 
> the resource of file 
> "D:/LibreOffice/core/instdir/program/vclplug_winlo.dll". A rendszer nem 
> tal?lja a megadott f?jlt. [System cannot find the given file]
> make[1]: *** [D:/LibreOffice/core/vcl/Library_vclplug_win.mk:20: 
> D:/LibreOffice/core/instdir/program/vclplug_winlo.dll] Error 96
> make[1]: *** Waiting for unfinished jobs
> make: *** [Makefile:286: build] Error 2

What version of Windows SDK do you use? Please look in config_host.mk 
for WINDOWS_SDK_*

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build error on Windows

[Kaganski Mike]

On 10/10/2018 12:02 PM, Stephan Bergmann wrote:
> Looks like a bug in 
> 
>  
> "Implement Windows VCL backend as plugin", which removed the shlwapi 
> dependency from vcl/Library_vcl.mk but didn't add it to 
> vcl/Library_vclplug_win.mk.

At least SDK 10.0.16299.0 doesn't seem to require it...

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build error on Windows

[Kaganski Mike]

On 10/10/2018 8:57 PM, Jan-Marek Glogowski wrote:
> I did my build without specifying an SDK, so this uses the newest one on the 
> system (from VS 2017).
> I simply removed all dependencies and added libraries, until linking didn't 
> fail anymore.
> Mike added shlwapi in commit 095caf5c7501 ("Restore using shlwapi by VCL code 
> on Windows"). Thanks
> for that.
> 
> So I looked for information and found:
> 
> https://docs.microsoft.com/de-de/windows/desktop/WinProg/using-the-windows-headers
> 
> git grep _WIN32_WINNT finds a lot of different versions in our code, but most 
> are just in StdAfx*.h
> boilerplate after a #ifndef. We can probably also drop all the WINVER ones.
> 
> Which probably only leaves the version specified in com_MSC_defs.mk for 
> Windows XP from commit
> f01580ce9c5f ("Windows: Require at least Windows XP SP2") - was just an 
> oversight?
> 
> I pushed an untested patch to Gerrit to get rid of all #ifndef => #define 
>  and the
> duplication in com_MSC_defs.mk: https://gerrit.libreoffice.org/#/c/61631
> 
>  From configure.ac (will always use the newest one):
> WINDOWS_SDK_ACCEPTABLE_VERSIONS="10.0 8.1A 8.1 8.0 7.1A"
> 
> Should we actually default to the oldest one for our build, or at least use 
> that version for Jenkins?

When preparing for the conference, I created a build environment from 
scratch, and followed our Wiki [1] to the letter (to test it). Then I 
learned that, despite the guidelines told about the requirement to 
install SDK 8.1 only, build process still required SDK 10 (I didn't 
install SDK 10 initially, and only tested without specifying any 
--with-windows-sdk ; in that case, the build failed until I have 
installed SDK 10). So actually I don't see a reason to default to that 
older version (mentioning about which I have removed from the wiki 
page). Possibly we even can't build without SDK 10 present at all? then 
I'd remove support for any older completely.

[1] https://wiki.documentfoundation.org/Development/BuildingOnWindows

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Upstream clang compiler plugins, licensing

[Kaganski Mike]

On 10/10/2018 10:53 PM, Tamás Zolnai wrote:
> With this new information I agree that it would be the best to clear the 
> licensing and use LLVM in every source file under compilerplugins 
> folder. So the question is what is the best way to do that. What is the 
> best way to ask every authors for a permission to relicense the code? Do 
> we need some kind of short license statement from the authors, similar 
> the general LO license statement?

I am not sure that having a subdirectory under core which is licensed 
differently from the rest of the code is good. I imagine a situation 
when one would need a license statement like

   "All of my past & future contributions to LibreOffice may be
licensed under the MPLv2/LGPLv3+ dual license.

All my contributions to directory foo may be licensed under the bar
license.

All my contributions to directory bar may be licensed ..."

which would become a nightmare. I suppose that if a separate-licensed 
thing is required, then just create a dedicated project, which would be 
external dependency for LibreOffice. Of course, you'd need to get the 
license statements for the existing code (as you discussed).

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

RE: Future of Java

[Kaganski Mike]

Hi,

IMO, there's nothing requiring "handling". Oracle declared that it will not 
continue providing patches for *an aging version* (namely, SE 8) of software, 
unless those who really need that old version are going to pay for the work of 
supporting that dinosaur. (And if some business needs that version that badly, 
paying for that is normal.)

At the same time, they provide newer versions of the software that doesn't have 
these requirements, which means that if Oracle doesn't have contracts for v8, 
they may just drop it, and if they have, the contracts would fund the work.

And all that only concerns corporate users.

What is there to handle here at TDF level? the ongoing work to get rid of Java 
dependency is orthogonal to this.


От: LibreOffice  от имени Mark 

Отправлено: 4 июля 2018 г. 22:55
Кому: libreoffice@lists.freedesktop.org
Тема: Future of Java


When updating my Java installation I was pointed to this notice:



https://java.com/en/download/release_notice.js



which announces Oracle's intention to require licensing for commercial use as 
early as next year, and probably for all use after 2020:



Public updates for Oracle Java SE 8 released after January 2019 will not be 
available for business, commercial or production use without a commercial 
license.

If you are a CONSUMER using Java for individual, personal use, you will 
continue to have the same access to Oracle Java SE 8 updates as you do today 
through at least the end of 2020. In most instances, the Java-based 
applications you run are licensed separately by a company other than Oracle 
(for example, games you play on your PC are likely developed by a gaming 
company). These applications may run on the Java platform and be dependent on 
Oracle Java SE 8 updates beyond 2020. Accordingly, Oracle recommends you 
contact your application provider for details on how they plan to continue to 
provide application support to you.

If you are a DEVELOPER, Oracle recommends you review the roadmap information 
for Java SE 8 and beyond and take appropriate action depending on the type of 
application you develop and your distribution model.

Are there plans in place to handle Oracle's move?  I think they should be 
publicised prominently.  If there are not, it seems a plan is required urgently.







 --

Best regards,

Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

RE: Make clean fails for unpackedTarballs in subpath firebird

[Kaganski Mike]

Hi Regina;

This is the problem with cygwin 2.10, which I had to describe in our wiki: 
https://wiki.documentfoundation.org/Development/BuildingOnWindows#Install_Cygwin_Requirements:

"Cygwin 2.10.0-1 have introduced a breaking 
change
 related to treatment of files with 
FILE_ATTRIBUTE_TEMPORARY 
attribute set. This interferes with Firebird creating such files in 
workdir/UnpackedTarball/firebird/gen/Debug/firebird (with names like 
fb_trace_09y6aq), which results in failing build due to failure to remove a 
non-empty directory. The problem is reported to be fixed in Cygwin snapshot 
2018-03-09. The error message is like

 rm: cannot remove 
'D:/sources/lo-core1/workdir/UnpackedTarball/firebird/gen/Debug/firebird': 
Directory not empty


A workaround is to open the directory using a file manager (like Windows File 
Explorer) and remove the file(s) left there manually."

(Sorry for possible bad markup in my mail; I only have access to web UI of my 
mail ATM.)
Building LibreOffice on Windows with Cygwin and MSVC: Tips 
...
Build dependencies. Before you can start hacking LibreOffice on Windows, you 
need to follow these instructions to set up a build environment. Install Visual 
Studio
wiki.documentfoundation.org


Building LibreOffice on Windows with Cygwin and MSVC: Tips 
...
Build dependencies. Before you can start hacking LibreOffice on Windows, you 
need to follow these instructions to set up a build environment. Install Visual 
Studio
wiki.documentfoundation.org




От: LibreOffice  от имени Regina 
Henschel 
Отправлено: 5 июля 2018 г. 4:46
Кому: LO dev fdo
Тема: Make clean fails for unpackedTarballs in subpath firebird

Hi all,

if I use /opt/lo/bin/make clean it stops with the error message
"rm: das Entfernen von
'D:/Build_ODF_layers/core/workdir/UnpackedTarball/firebird/gen/Debug/firebird'
ist nicht möglich: Directory not empty"
And indeed it has a 0Byte file fb_trace_wj10i8 in
unpackedTarball/firebird/gen/Debug/firebird.

I can delete the file manually in Windows explorer. But I think it is an
error. I write here, because I don't find a suitable category in Bugzilla.

Kind regards
Regina
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

--
Best regards,
Mike Kaganski.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Assertion Failed!: MSVCP140D.dll , Expression: ploc->_Mbcurmax == 1 || ploc->_Mbcurmax == 2

[Kaganski Mike]

On 5/6/2018 9:49 PM, himajin10 wrote:
> I've updated my Visual Studio 2017 Preview to 15.7.0 Preview 6.0 and 
> then started to fail to make my own  LibreOffice build with the 
> following error.
> ...

I see quite a few changes in the 15.7.0 changelog [1] that might affect 
us; so - did you make clean to begin with?

[1] 
https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Subsequent Test PythonTest_dbaccess_python stuck in Infinite Loop

[Kaganski Mike]

On 5/10/2018 4:33 PM, Luke Benes wrote:
> 
> When you do a 'make check' under Windows, recent builds never finish. I have 
> narrowed this regression to

commit c0965754df3309c39d316b76b2205af559bd28e3 tries to address that.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Windows build failure - C2131: expression did not evaluate to a constant

[Kaganski Mike]

On 04.12.2018 9:30, Noel Grandin wrote:
> 
> 
>> I'm seeing the following build failure on Windows 32-bit release build:
>> D:/core/vcl/source/bitmap/BitmapTools.cxx(1078): error C2131: 
>> expression did not evaluate to a constant
>> D:/core/vcl/source/bitmap/BitmapTools.cxx(1097): error C2131: 
>> expression did not evaluate to a constant
>> make[1]: *** [D:/core/solenv/gbuild/LinkTarget.mk:293: 
>> D:/core/workdir/CxxObject/vcl/source/bitmap/BitmapTools.o] Error 2
> 
> You need the latest Visual Studio 2017 release.

So, it seems that commit establishes another VS baseline?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Windows build failure - C2131: expression did not evaluate to a constant

[Kaganski Mike]

On 04.12.2018 10:37, Stephan Bergmann wrote:
> 
> Our recently-bumped MSVC baseline is Visual Studio 2017 version 15.7 
> (the "version 15.7" suffix is important, there are many different 
> releases of Visual Studio 2017, with ever-increasing C++ standard 
> compliance).  That should be enforced by configure since 
> 
>  
> "On Windows, check for at least Visual Studio 2017 version 15.7".
> 
>  "Compute 
> (un-)premultiply_table at compile time" was checked by Jenkins' tb78 at 
> , and the mention 
> of "14.14" in e.g. "export 
> COMPATH=C:/PROGRA~2/MIB055~1/2017/COMMUN~1/VC/Tools/MSVC/14.14.26428" 
> () 
> makes it look like that configuration indeed uses Visual Studio 2017 
> version 15.7 per the mapping from "MSVC++ 14.14" to "_MSC_VER == 1914 
> (Visual Studio 2017 version 15.7)" documented at 
> .
>  
> 
> 
> Not sure what goes wrong for you.  What version of VS are you using?

I have just pulled, and I confirm this with 64-bit build, with VS 
version 15.9.3.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Windows build failure - C2131: expression did not evaluate to a constant

[Kaganski Mike]

On 04.12.2018 14:17, Kaganski Mike wrote:
> 
> I have just pulled, and I confirm this with 64-bit build, with VS
> version 15.9.3.
> 

I mean, I confirm that with my version of compiler, the problem is 
reproducible.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Trying to create editor using LibreOffice

[Kaganski Mike]

Hi,

On 04.12.2018 13:33, Rohit Garg Satpal Garg wrote:
> Hi Team,
> 
> I am trying to create editing application for my one of the research 
> projects but I am stuck on implementation of  getLinreOfficeKitHandler() 
> which is missing from the source files.

It is not missing. See implementation in 
Java_org_libreoffice_kit_LibreOfficeKit_getLibreOfficeKitHandle() at 
sal/android/libreofficekit-jni.c:152.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Windows build failure - C2131: expression did not evaluate to a constant

[Kaganski Mike]

On 04.12.2018 14:18, Kaganski Mike wrote:
> On 04.12.2018 14:17, Kaganski Mike wrote:
>>
>> I have just pulled, and I confirm this with 64-bit build, with VS
>> version 15.9.3.
>>
> 
> I mean, I confirm that with my version of compiler, the problem is
> reproducible.
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
> 

Reported that to 
https://developercommunity.visualstudio.com/content/problem/398218/c2131-error-with-stdarray-and-stdmake-integer-sequ.html.

As noted there, I have discovered the code to succeed if I replace 256 
to any number up to 234.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Subsequent Unit Test CppunitTest_sc_ddelinkobj Failing Under Windows

[Kaganski Mike]

On 12/13/2018 3:05 AM, Jens Carl wrote:
> Hello Luke,
> 
> On 12/8/18 7:09 AM, Luke Benes wrote:
> 
>> Would you like any additional debugging info?
> 
> I personally don't have access to any Windows machines and my knowledge 
> about Windows Devolvement (Virtual Studio) is very limited. So I 
> unfortunately can't provide you with any instructions how to debug it.
> 
> I'll ask on the IRC if it's possible for me to get some kind of access 
> to a Windows machine. If it's possible I will start to debug the code.

https://gerrit.libreoffice.org/65079 handles this. Please ask about 
Windows access though, because it's mandatory to test on Windows.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppunitTest_chart2_xshape Failure with Display Scaling on Windows

[Kaganski Mike]

Hi Luke!

On 12/16/2018 10:57 PM, Luke Benes wrote:
> The fix for *Bug 121685* 
> , 
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=7263d223ddf4
> ​
> Is causing the core Unit Test CppunitTest_chart2_xshape to fail when you 
> set,  Settings->Display->Scale=125%​

Unfortunately cannot repro locally. Possibly it's worth trying to only 
add manifest to soffice.bin, not to all console applications. Will try 
that tomorrow.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Changing soffice.bin to be console application on Windows

[Kaganski Mike]

Hi!

Currently soffice.bin on Windows is built with subsystem set to GUI. 
This creates a number of problems, including impossibility to output 
--version/--help into a text using command like

soffice --help > somefile

(or do similar things piping the output to other commands in batch 
files); absence of debug output in the console (if not launching from 
cygwin).

I have prepared a patch making soffice.bin a proper console Windows 
application: https://gerrit.libreoffice.org/63572. The patch also 
introduces a new launcher soffice.com (in addition to existing 
soffice.exe). That is to make possible to call soffice from command 
line, and have proper console launcher for that call.

I now ask for opinions from those who might know (or suspect) why that 
is a wrong move. Thank you for reviews/opinions!

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Changing soffice.bin to be console application on Windows

[Kaganski Mike]

On 19.11.2018 18:48, Stephan Bergmann wrote:
> On 19/11/2018 16:38, Kaganski Mike wrote:
>> I have prepared a patch making soffice.bin a proper console Windows
>> application: https://gerrit.libreoffice.org/63572. The patch also
>> introduces a new launcher soffice.com (in addition to existing
>> soffice.exe). That is to make possible to call soffice from command
>> line, and have proper console launcher for that call.
> 
> If there's both soffice.exe and soffice.com in the same directory 
> (assuming the "new launcher osffice.com" also goes into program\), what 
> will happen if some client starts just soffice w/o extension (either 
> from a shell, or from Windows' equivalent of exec, if it's possible to 
> call that w/o an extension)?  (program\soffice.exe is part of the stable 
> 3rd-party interface on Windows, but I'm not sure whether we officially 
> announce it as "program\soffice.exe is part of the stable interface" (so 
> client code could be considered broken if it calls that w/o extension) 
> or as "program\soffice is part of the stable interface".)

Yes, the soffice.com goes to the same program\ along with soffice.exe. 
And that's for the very purpose of the described scenario: when user 
calls soffice without an extension, .com is (usually) the preferred 
extension (subject to PATHEXT override), as described in [1]. Note that 
calling soffice without an extension is usually (always?) the case for 
console-like operation; while shell integration (including desktop 
shortcuts and registry) is done using explicit .exe. Also note that 
CreateProcess WinAPI only substitutes .exe in case the extension is 
omitted [2], so this scenario (calling soffice from a custom application 
without explicitly specifying .exe) should be unaffected.

The soffice.com is made to do exactly the same as soffice.exe (modulo 
being console application, and thus behave properly in different console 
and batch scenarios). In fact, the two are made as WinMain()|main() 
calling the real impl function which does everything that previously was 
in soffice.exe's WinMain.

Currently our help (and multiple resources everywhere) often (not sure 
if exclusively) mention commands like "soffice --switches". And both 
this and calling soffice.exe explicitly is currently inconsistent across 
platforms, because on other platforms, the call works as proper console 
call. So I see this as (hopefully) making the API consistent with what 
we announce.

[1] https://en.wikipedia.org/wiki/COM_file#Execution_preference
[2] 
https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessw
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Unable to build with poppler 0.71.0

[Kaganski Mike]

On 19.11.2018 16:07, Andrey Cherepanov wrote:
> If build with poppler 0.71.0 I get errors for missing type GBool:
> 
> In file included from
> /usr/src/RPM/BUILD/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/wrapper_gpl.cxx:20:0:
> /usr/src/RPM/BUILD/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx:153:17:
> error: 'GBool' does not name a type; did you mean 'bool'
>   virtual GBool upsideDown() override { return gTrue; }
>   ^
>   bool
> /usr/src/RPM/BUILD/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx:156:17:
> error: 'GBool' does not name a type; did you mean 'bool'
>   virtual GBool useDrawChar() override { return gTrue; }
>   ^
>   bool
> ...
> 
> There is commit
> https://gitlab.freedesktop.org/poppler/poppler/commit/163420b48bdddf9084208b3cadf04dafad52d40a
> 
> Replace GBool, gTrue, and gFalse by bool, true, false, resp.
> 
> So type GBool (and so on) is no longer exist and it should be replaced
> by bool in sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx
> 

Should be fixed in commit 5e8bdd9203dd642111c62a6668ee665a20d4ba19 < 
https://git.libreoffice.org/core/+/5e8bdd9203dd642111c62a6668ee665a20d4ba19%5E%21/
 
 >.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Failing

[Kaganski Mike]

After last pull, JunitTest_chart2_unoapi reliably fails for me on master 
on Win10 with this call stack:

ucrtbased.dll!issue_debug_notification(const wchar_t * const message) 
Line 28
at minkernel\crts\ucrt\src\appcrt\internal\report_runtime_error.cpp(28)
ucrtbased.dll!__acrt_report_runtime_error(const wchar_t * message) Line 154
at minkernel\crts\ucrt\src\appcrt\internal\report_runtime_error.cpp(154)
ucrtbased.dll!abort() Line 61
at minkernel\crts\ucrt\src\appcrt\startup\abort.cpp(61)
ucrtbased.dll!common_assert_to_stderr(const wchar_t * const 
expression, const wchar_t * const file_name, const unsigned int 
line_number) Line 187
at minkernel\crts\ucrt\src\appcrt\startup\assert.cpp(187)
ucrtbased.dll!common_assert(const wchar_t * const expression, 
const wchar_t * const file_name, const unsigned int line_number, void * 
const return_address) Line 420
at minkernel\crts\ucrt\src\appcrt\startup\assert.cpp(420)
ucrtbased.dll!_wassert(const wchar_t * expression, const wchar_t * 
file_name, unsigned int line_number) Line 444
at minkernel\crts\ucrt\src\appcrt\startup\assert.cpp(444)
vcllo.dll!ImplDbgTestSolarMutex() Line 46
at c:\lo\src\core\vcl\source\app\dbggui.cxx(46)
tllo.dll!DbgTestSolarMutex() Line 78
at c:\lo\src\core\tools\source\debug\debug.cxx(78)
vcllo.dll!OpenGLSalBitmap::Create(const Size & rSize, unsigned short 
nBits, const BitmapPalette & rBitmapPalette) Line 164
at c:\lo\src\core\vcl\opengl\salbmp.cxx(164)
vcllo.dll!Bitmap::Bitmap(const Size & rSizePixel, unsigned short 
nBitCount, const BitmapPalette * pPal) Line 108
at c:\lo\src\core\vcl\source\bitmap\bitmap.cxx(108)
vcllo.dll!o3tl::make_unique(Size & 
, unsigned short & ) Line 29
at c:\lo\src\core\include\o3tl\make_unique.hxx(29)
vcllo.dll!vcl::PNGReaderImpl::ImplReadHeader(const Size & 
rPreviewSizeHint) Line 665
at c:\lo\src\core\vcl\source\gdi\pngread.cxx(665)
vcllo.dll!vcl::PNGReaderImpl::GetBitmapEx(const Size & rPreviewSizeHint) 
Line 342
at c:\lo\src\core\vcl\source\gdi\pngread.cxx(342)
vcllo.dll!vcl::PNGReader::Read(const Size & i_rPreviewSizeHint) Line 1732
at c:\lo\src\core\vcl\source\gdi\pngread.cxx(1732)
vcllo.dll!GraphicFilter::ImportGraphic(Graphic & rGraphic, const 
rtl::OUString & rPath, SvStream & rIStream, unsigned short nFormat, 
unsigned short * pDeterminedFormat, GraphicFilterImportFlags 
nImportFlags, 
com::sun::star::uno::Sequence * 
pFilterData, const WmfExternal * pExtHeader) Line 1813
at c:\lo\src\core\vcl\source\filter\graphicfilter.cxx(1813)
vcllo.dll!GraphicFilter::ImportGraphic(Graphic & rGraphic, const 
rtl::OUString & rPath, SvStream & rIStream, unsigned short nFormat, 
unsigned short * pDeterminedFormat, GraphicFilterImportFlags 
nImportFlags, const WmfExternal * pExtHeader) Line 1281
at c:\lo\src\core\vcl\source\filter\graphicfilter.cxx(1281)
vcllo.dll!GraphicFilter::FilterCallback(ConvertData & rData) Line 2509
at c:\lo\src\core\vcl\source\filter\graphicfilter.cxx(2509)
vcllo.dll!GraphicFilter::LinkStubFilterCallback(void * instance, 
ConvertData & data) Line 2481
at c:\lo\src\core\vcl\source\filter\graphicfilter.cxx(2481)
sofficeapp.dll!Link::Call(ConvertData & data) Line 84
at c:\lo\src\core\include\tools\link.hxx(84)
sofficeapp.dll!desktop::Desktop::ImplInitFilterHdl(desktop::Desktop * 
__formal, ConvertData & rData) Line 1752
at c:\lo\src\core\desktop\source\app\app.cxx(1752)
sofficeapp.dll!desktop::Desktop::LinkStubImplInitFilterHdl(void * 
instance, ConvertData & data) Line 1749
at c:\lo\src\core\desktop\source\app\app.cxx(1749)
vcllo.dll!Link::Call(ConvertData & data) Line 84
at c:\lo\src\core\include\tools\link.hxx(84)
vcllo.dll!GraphicConverter::Import(SvStream & rIStm, Graphic & rGraphic, 
ConvertDataFormat nFormat) Line 44
at c:\lo\src\core\vcl\source\gdi\cvtgrf.cxx(44)
chartcorelo.dll!chart::ChartModel::impl_loadGraphics(const 
com::sun::star::uno::Reference & 
xStorage) Line 621
at 
c:\lo\src\core\chart2\source\model\main\chartmodel_persistence.cxx(621)
chartcorelo.dll!chart::ChartModel::impl_load(const 
com::sun::star::uno::Sequence & 
rMediaDescriptor, const 
com::sun::star::uno::Reference & 
xStorage) Line 576
at 
c:\lo\src\core\chart2\source\model\main\chartmodel_persistence.cxx(576)
chartcorelo.dll!chart::ChartModel::load(const 
com::sun::star::uno::Sequence & 
rMediaDescriptor) Line 543
at 
c:\lo\src\core\chart2\source\model\main\chartmodel_persistence.cxx(543)
chartcontrollerlo.dll!chart::ChartFrameLoader::load(const 
com::sun::star::uno::Sequence & 
rMediaDescriptor, const 
com::sun::star::uno::Reference & xFrame) 
Line 170
at 
c:\lo\src\core\chart2\source\controller\main\chartframeloader.cxx(170)
fwklo.dll!framework::LoadEnv::impl_loadContent() Line 1149
at c:\lo\src\core\framework\source\loadenv\loadenv.cxx(1149)
fwklo.dll!framework::LoadEnv::startLoading() Line 38

Failing JunitTest_framework_complex

[Kaganski Mike]

JunitTest_framework_complex fails reliably for me on current master with 
assertion

  assert( mpWindowContext.is() );

failing at OpenGLSalGraphicsImpl::doFlush().

I could debug it to WinOpenGLContext::ImplInit() having m_aGLWin.hDC == 
nullptr, thus ChoosePixelFormat fails. The call stack for this point is


vclplug_winlo.dll!WinOpenGLSalGraphicsImpl::CreateWinContext
vcllo.dll!OpenGLSalGraphicsImpl::doFlush
vcllo.dll!OpenGLFlushIdle::Invoke
vcllo.dll!Scheduler::ProcessTaskScheduling
vcllo.dll!Scheduler::CallbackTaskScheduling
vcllo.dll!SalTimer::CallCallback
vclplug_winlo.dll!WinSalTimer::ImplHandleElapsedTimer
vclplug_winlo.dll!ImplSalYield
vclplug_winlo.dll!WinSalInstance::DoYield
vcllo.dll!ImplYield
vcllo.dll!Application::Yield
vcllo.dll!Application::Execute
sofficeapp.dll!desktop::Desktop::Main
vcllo.dll!ImplSVMain
vcllo.dll!SVMain
sofficeapp.dll!soffice_main
soffice.bin!sal_main
soffice.bin!main
soffice.bin!invoke_main
soffice.bin!__scrt_common_main_seh
soffice.bin!__scrt_common_main
soffice.bin!mainCRTStartup
kernel32.dll!BaseThreadInitThunk
ntdll.dll!RtlUserThreadStart


The mrWinParent.mhLocalDC is nullptr here; the nullprt value has been 
set when it was released *before that event* in 
WinSalFrame::ReleaseFrameGraphicsDC with this call stack:


vclplug_winlo.dll!WinSalGraphics::setHDC
vclplug_winlo.dll!WinSalFrame::ReleaseFrameGraphicsDC
vclplug_winlo.dll!WinSalFrame::ReleaseGraphics
vcllo.dll!vcl::Window::ReleaseGraphics
vcllo.dll!vcl::Window::dispose
vcllo.dll!ImplBorderWindow::dispose
vcllo.dll!VclReferenceBase::disposeOnce
vcllo.dll!VclPtr::disposeAndClear
vcllo.dll!vcl::Window::dispose
vcllo.dll!Control::dispose
vcllo.dll!Edit::dispose
vcllo.dll!SpinField::dispose
vcllo.dll!MetricField::dispose
vcllo.dll!VclReferenceBase::disposeOnce
vcllo.dll!VclPtr::disposeAndClear
vcllo.dll!VclBuilder::disposeBuilder
vcllo.dll!VclBuilderContainer::disposeBuilder
svxlo.dll!PanelLayout::dispose
svxlo.dll!svx::sidebar::ParaPropertyPanel::dispose
vcllo.dll!VclReferenceBase::disposeOnce
sfxlo.dll!VclPtr::disposeAndClear
sfxlo.dll!sfx2::sidebar::SidebarPanelBase::disposing
cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::dispose

sfxlo.dll!cppu::PartialWeakComponentImplHelper::dispose
sfxlo.dll!sfx2::sidebar::Panel::dispose
vcllo.dll!VclReferenceBase::disposeOnce
sfxlo.dll!VclPtr::disposeAndClear
sfxlo.dll!sfx2::sidebar::Deck::ResetPanels
sfxlo.dll!sfx2::sidebar::SidebarController::CreatePanels
sfxlo.dll!sfx2::sidebar::SidebarController::CreateDeck
sfxlo.dll!sfx2::sidebar::SidebarController::SwitchToDeck
sfxlo.dll!sfx2::sidebar::SidebarController::SwitchToDeck
sfxlo.dll!sfx2::sidebar::SidebarController::UpdateConfigurations
sfxlo.dll!sfx2::sidebar::SidebarController::notifyContextChangeEvent
fwklo.dll!`anonymous 
namespace'::ContextChangeEventMultiplexer::BroadcastEventToSingleContainer
fwklo.dll!`anonymous 
namespace'::ContextChangeEventMultiplexer::broadcastContextChangeEvent

sfxlo.dll!sfx2::sidebar::ContextChangeBroadcaster::BroadcastContextChange
sfxlo.dll!sfx2::sidebar::ContextChangeBroadcaster::Activate
sfxlo.dll!SfxShell::BroadcastContextForActivation
swlo.dll!SwPagePreview::SwPagePreview
swlo.dll!SwPagePreview::CreateInstance
sfxlo.dll!SfxViewFactory::CreateInstance
sfxlo.dll!SfxBaseModel::createViewController
sfxlo.dll!`anonymous 
namespace'::SfxFrameLoader_Impl::impl_createDocumentView
sfxlo.dll!`anonymous namespace'::SfxFrameLoader_Impl::load
fwklo.dll!framework::LoadEnv::impl_loadContent
fwklo.dll!framework::LoadEnv::startLoading
fwklo.dll!framework::LoadEnv::loadComponentFromURL
fwklo.dll!`anonymous namespace'::Frame::loadComponentFromURL
sfxlo.dll!SfxViewFrame::LoadViewIntoFrame_Impl
sfxlo.dll!SfxViewFrame::SwitchToViewShell_Impl
sfxlo.dll!SfxViewFrame::ExecView_Impl
sfxlo.dll!SfxStubSfxViewFrameExecView_Impl
sfxlo.dll!SfxShell::CallExec
sfxlo.dll!SfxDispatcher::Call_Impl
sfxlo.dll!SfxDispatcher::PostMsgHandler
sfxlo.dll!std::_Invoker_pmf_pointer::_Call 
 >),SfxDispatcher * 
&,std::unique_ptr > >
sfxlo.dll!std::invoke 
 >),SfxDispatcher * 
&,std::unique_ptr > >
sfxlo.dll!std::_Invoker_ret::_Call 
 >),SfxDispatcher * 
&,std::unique_ptr > >
sfxlo.dll!std::_Call_binder 
 >),std::tuple 
 >,std::tuple 
 > &&> >
sfxlo.dll!std::_Binder 
 >),SfxDispatcher *,std::_Ph<1> const 
&>::operator() 
 > >
sfxlo.dll!st

Re: Failing JunitTest_framework_complex

[Kaganski Mike]

On 21.11.2018 16:37, Jan-Marek Glogowski wrote:
> Hi Mike
> 
> Am 21.11.18 um 14:01 schrieb Kaganski Mike:
>> JunitTest_framework_complex fails reliably for me on current master with
>> assertion
>>
>>assert( mpWindowContext.is() );
> 
> Can you check if reverting
> 
> commit 6cdfe5ebb4f6c06bfa8b0e67e778dd68131c14e3
> Author: Jan-Marek Glogowski 
> Date:   Tue Oct 9 19:29:54 2018 +0200
> 
>  Drop some headless mode variants
> 
> helps?

Thank you!
It definitely helps. Just tested several times (it was failing reliably 
before the revert). Something more is needed for unit tests and OpenGL case.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: remove followed by a push_back of same var (SwSpellDialogChildWindow)

[Kaganski Mike]

On 24.11.2018 10:23, julien2412 wrote:
> I noticed these lines:
>  737 if(pCurrentTextObj)
>  738 {
>  739 m_pSpellState->m_aTextObjects.remove(pCurrentTextObj);
>  740
> m_pSpellState->m_aTextObjects.push_back(pCurrentTextObj);
>  741 }
> See
> https://opengrok.libreoffice.org/xref/core/sw/source/uibase/dialog/SwSpellDialogChildWindow.cxx#737
> 
> Is it a special trick so some other vars are notified or just a plain error?

Something to guarantee that there is only a single instance of it, and 
it's the top element?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Help regarding Transliteration in LO writer

[Kaganski Mike]

Hi!

On 26.11.2018 13:39, Harshad Gorde wrote:
> Hello everyone,
> 
> I am interested in introducing transliteration facility (English to 
> Devnagari) to LibreOffice writer. But, after downloading the huge source 
> code I am unable to decide where to start.
> 
> Kindly suggest me some initial steps to be followed.

Personally I would suggest you to start by writing a (StarBasic) macro 
[1] for that. Not because I suppose it shouldn't be built in (I don't 
suppose that), but because for such a high-level task, a Basic macro 
could be very good initial approximation/plot for a future C++-based 
function, but allows you to avoid additional complexity at the first 
steps. IMO.

[1] http://www.pitonyak.org/oo.php

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Crash test update, now with backtraces

[Kaganski Mike]

On 26.05.2019 17:14, Caolán McNamara wrote:
> On Fri, 2019-05-24 at 10:31 +0200, Luboš Luňák wrote:
>>   Could you please name those .backtrace.txt? I can't view those files
>> online, because they get treated as binary files and so Firefox only
>> offers to download them.
> 
> Yeah, I changed that in the script after the first run, it'll be .txt
> in future ones.

I suppose it should be more about proper content type as reported by 
server, than about name.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Using Amazon Corretto as Oracle JDK replacement for building LibreOffice on Windows

[Kaganski Mike]

Hi,

Since Oracle JDK versions prior to 12 are now unavailable from the 
official site [1] for unregistered users (and version 12 is said to 
still have problems/needs workarounds [2]), I decided to give Amazon 
Corretto [3] a try. I downloaded and installed the two MSIs listed on 
that page (amazon-corretto-8.212.04.2-1-windows-x64.msi and 
amazon-corretto-8.212.04.2-1-windows-x86.msi) - I chose to setup full 
just in case, and I need the two packages to be able to build both 
32-bit and 64-bit LibreOffice, - and then setup and run lode. With that, 
LibreOffice x64 master build succeeded normally. So this is just to let 
you know in case you need an alternative JRE.

[1] http://www.oracle.com/technetwork/java/javase/downloads/index.html
[2] 
https://wiki.documentfoundation.org/Development/BuildingOnWindows#Install_Java
[3] 
https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/downloads-list.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppunitTest_sc_macros_test hanging indefinitely with font scaling on Windows

[Kaganski Mike]

Hi!

On Windows 10 x64 (1903 build 18362.116), having "all items scaling" set 
to 150%, with current master (now at 
b170256fb6ebaf774b02b89835b19d9f3a1afb89) built for x64 in dbgutil 
config, running

 > make CppunitTest_sc_macros_test

reliably hangs indefinitely. It never returns from 
Scheduler::ProcessEventsToIdle (specifically, never leaves the while( 
Application::Reschedule( true ) ) loop); the call stack is

> vcllo.dll!Scheduler::ProcessEventsToIdle() Line 480
>   at C:\cygwin\home\user\lode\dev\core\vcl\source\app\svapp.cxx(480)
> test.dll!test::BootstrapFixture::setUp() Line 119
>   at 
> C:\cygwin\home\user\lode\dev\core\test\source\bootstrapfixture.cxx(119)
> subsequenttest.dll!UnoApiTest::setUp() Line 28
>   at C:\cygwin\home\user\lode\dev\core\test\source\unoapi_test.cxx(28)
> test_sc_macros_test.dll!CppUnit::TestCaller::setUp() Line 181
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\include\cppunit\TestCaller.h(181)
> cppunitd_dll.dll!CppUnit::TestCaseMethodFunctor::operator()() Line 33
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestCase.cpp(33)
> vclbootstrapprotector.dll!`anonymous namespace'::Protector::protect(const 
> CppUnit::Functor & functor, const CppUnit::ProtectorContext & __formal) Line 
> 49
>   at 
> C:\cygwin\home\user\lode\dev\core\test\source\vclbootstrapprotector.cxx(49)
> cppunitd_dll.dll!CppUnit::ProtectorChain::ProtectFunctor::operator()() Line 21
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\ProtectorChain.cpp(21)
> unobootstrapprotector.dll!`anonymous namespace'::Prot::protect(const 
> CppUnit::Functor & functor, const CppUnit::ProtectorContext & __formal) Line 
> 90
>   at 
> C:\cygwin\home\user\lode\dev\core\unotest\source\cpp\unobootstrapprotector\unobootstrapprotector.cxx(90)
> cppunitd_dll.dll!CppUnit::ProtectorChain::ProtectFunctor::operator()() Line 21
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\ProtectorChain.cpp(21)
> unoexceptionprotector.dll!`anonymous namespace'::Prot::protect(const 
> CppUnit::Functor & functor, const CppUnit::ProtectorContext & context) Line 63
>   at 
> C:\cygwin\home\user\lode\dev\core\unotest\source\cpp\unoexceptionprotector\unoexceptionprotector.cxx(63)
> cppunitd_dll.dll!CppUnit::ProtectorChain::ProtectFunctor::operator()() Line 21
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\ProtectorChain.cpp(21)
> cppunitd_dll.dll!CppUnit::DefaultProtector::protect(const CppUnit::Functor & 
> functor, const CppUnit::ProtectorContext & context) Line 15
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\DefaultProtector.cpp(15)
> cppunitd_dll.dll!CppUnit::ProtectorChain::ProtectFunctor::operator()() Line 21
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\ProtectorChain.cpp(21)
> cppunitd_dll.dll!CppUnit::ProtectorChain::protect(const CppUnit::Functor & 
> functor, const CppUnit::ProtectorContext & context) Line 86
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\ProtectorChain.cpp(86)
> cppunitd_dll.dll!CppUnit::TestResult::protect(const CppUnit::Functor & 
> functor, CppUnit::Test * test, const 
> std::basic_string,std::allocator > & 
> shortDescription) Line 182
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestResult.cpp(182)
> cppunitd_dll.dll!CppUnit::TestCase::run(CppUnit::TestResult * result) Line 87
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestCase.cpp(87)
> cppunitd_dll.dll!CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult 
> * controller) Line 65
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestComposite.cpp(65)
> cppunitd_dll.dll!CppUnit::TestComposite::run(CppUnit::TestResult * result) 
> Line 24
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestComposite.cpp(24)
> cppunitd_dll.dll!CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult 
> * controller) Line 65
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestComposite.cpp(65)
> cppunitd_dll.dll!CppUnit::TestComposite::run(CppUnit::TestResult * result) 
> Line 24
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestComposite.cpp(24)
> cppunitd_dll.dll!CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult 
> * result) Line 48
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestRunner.cpp(48)
> cppunitd_dll.dll!CppUnit::TestResult::runTest(CppUnit::Test * test) Line 150
>   at 
> C:\cygwin\home\user\lode\dev\core\workdir\UnpackedTarball\cppunit\src\cppunit\TestResult.cpp(150)
> 

Re: Reveal code, old macros convert them to LO

[Kaganski Mike]

Hi!

On 04.07.2019 20:08, Uwe Brauer wrote:
> 
> 
>  From time to time the question pops up whether LO could support
> Wordperfects reveal code. Sometimes it is stated that this feature could
> be implemented by a macro/extension.
> 
> Now I remember that long time ago such macros existed and using the
> wayback machine I found them. They were written around 2005 for OO 1.2,
> using the sxw format.

Great that you have interest for bringing the power features to LO.
I'm curious what the "reveal code" feature looks like in WP, and what it 
looked like in OOo with the said macros?

Personally I would love to see a greatly reworked style manager, with 
ability to show the settings applied to any piece of text in layers - 
from most basic (paragraph style, with its inheritance) through possibly 
several character styles, to the top manual formatting, where one could 
easily see the structure - with all intermediate properties - of what we 
see as the result. Possibly something like modern browsers' object 
inspectors. But I'm afraid that there's no "codes" in LO (if I 
understand it right - my understanding is that it shows something like 
"xml tags" or some such) - and if I'm right, then trying to fake the 
actual "property set"-based architecture into "codes" would result in 
much effort with small output.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

sw_uiwriter hangs in testDateFormFieldCurrentDateInvalidation

[Kaganski Mike]

Hi!

I see sw_uiwriter hanging locally in 
testDateFormFieldCurrentDateInvalidation (added in commit 
d0ff1090762ac61ce08f54bc76685232699d98a0), never returning from 
Scheduler::ProcessEventsToIdle. Killing the test after some time 
produces multiple lines in console:

> warn:vcl.schedule:5488:13820:vcl/source/app/svapp.cxx:470: 
> ProcessEventsToIdle: 1000
> warn:vcl.schedule:5488:13820:vcl/source/app/svapp.cxx:470: 
> ProcessEventsToIdle: 2000
> ...
> warn:vcl.schedule:5488:13820:vcl/source/app/svapp.cxx:470: 
> ProcessEventsToIdle: 845000

I believe that's the reason for massive number of aborted Windows 
jenkins builds that lately affect our CI (just the last few are builds 
#34586, #34587, #34588, #34589, #34590, #34591).

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: sw_uiwriter hangs in testDateFormFieldCurrentDateInvalidation

[Kaganski Mike]

On 14.07.2019 22:23, Jan-Marek Glogowski wrote:
> 
> If you want to debug Windows AnyInput handling, feel free
> to contact me on IRC (or even mail), if you have questions.

I have tried putting some tracing breakpoints to 
WinSalInstance::AnyInput, and I can say that at least when the process 
is already hung (emitting all those "ProcessEventsToIdle: 100500" 
warnings), the function isn't called at all.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Request for review: Convert Fontwork to TextWarp on export

[Kaganski Mike]

On 15.06.2019 10:04, Regina Henschel wrote:
> My patch would implement the export from "Fontwork" to "TextWarp" 
> without character fill and outline. My question is, whether you agree, 
> that such step is useful? Even if character fill and outline will not be 
> implemented soon?

I suppose that this is a great improvement. Having this landed, it would 
be easier for others to develop further steps based on this.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Can mimalloc turn out to be useful for LibreOffice?

[Kaganski Mike]

MS has released its mimalloc [1] under BSD license as a drop-in 
replacement for malloc. It is said to have excellent performance. It's 
also cross-platform. Can it be useful for LibreOffice (on supported 
platforms)? What is required to actually make LibreOffice use it, and 
how to test possible performance effect?

[1] https://github.com/microsoft/mimalloc

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC - QR Code] Week Report 5 (June 24 - June 30)

[Kaganski Mike]

Hi!

On 02.07.2019 11:40, shubham goyal wrote:
> Status of project
> - I will be left with calling QR Code feature in Word/impress/ and other 
> applications if requires.


Not sure that making the feature for Word is within the scope of the 
project ;-)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Review for "improve import/export of line styles"

[Kaganski Mike]

On 02.09.2019 9:20, Németh László wrote:
>> And technical question: What do I need to do locally in Git, so
>> that the
>> information, that the no longer needed file
>> "lo_preset_dashes.odt" has
>> to be deleted, is included in my commit?
> 
> 
> If you deleted the file accidentally,
> 
> git checkout sw/qa/extras/ooxmlexport/data/lo_preset_dashes.odt
> 
> and
> 
> git rm sw/qa/extras/ooxmlexport/data/lo_preset_dashes.odt
> 
> and add deletion to the actual commit:
> 
> git commit --amend

If you have already deleted the file, there's no need to restore it then 
git rm. Just add its current (deleted) state to the index using

   git add path/to/removed/file

and proceed as usual (actually, using git commit -a --amend (when 
appropriate) also picks the removal correctly).

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Crash test update

[Kaganski Mike]

On 27.04.2019 18:33, Caolán McNamara wrote:
> On Sat, 2019-04-27 at 00:33 +, Crashtest VM wrote:
>> New crashtest update available at
>> http://dev-builds.libreoffice.org/crashtest/0b56eb2c10ab4ca027f1a37e04519366b3cd7433/
> 
> 
> soffice.bin --headless --convert-to xlsx ooo83250-1.ods
> semi-reliably assert with null pDim at xepivotxml.cxx:504
> I presume this started with b082998401e37e6c7534906601bc481423a6ded0
> tdf#113908: Implement exporting pivot tables' groups fields to XSLX

I'm sorry it took too long; https://gerrit.libreoffice.org/77110 
addresses this.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: libreoffice converstion of egistrymodifications.xcu user items to systemwide xml registry share

[Kaganski Mike]

See also:

https://wiki.documentfoundation.org/Deployment_and_Migration#Post_deployment_configuration
https://ask.libreoffice.org/en/question/185522/how-do-i-turn-off-opengl-while-deploying-libreoffice/
https://ask.libreoffice.org/en/question/167622/how-to-disable-java-in-configuration-files/
https://ask.libreoffice.org/en/question/186732/how-to-change-default-ui-language-for-all-users-in-command-prompt-in-ubuntu-1804/

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

CppunitTest_sc_macros_test fails after commit 7282014e362a1529a36c88eb308df8ed359c2cfa

[Kaganski Mike]

Hi!

After commit 7282014e362a1529a36c88eb308df8ed359c2cfa, now 
CppunitTest_sc_macros_test fails when testing 
sc/qa/extras/testdocuments/Window.xls:

> C:/lo/src/core/sc/qa/extras/macros-test.cxx(338) : error : Assertion
> Test name: ScMacrosTest::testVba
> equality assertion failed
> - Expected: OK
> - Actual  : Test Results
> 
> 
>  Failed:  : Window.LargeScroll(ToLeft): ScrollColumn is: 10
>  Failed:  : Window.SmallScroll(ToLeft): ScrollColumn is: 10
>  Failed:  : Pane.LargeScroll(ToLeft): ScrollColumn is: 10
>  Failed:  : Pane.SmallScroll(ToLeft): ScrollColumn is: 10
> Tests passed: 26
> Tests failed: 4
> 
> - script reported failure in file Window.xls
> 
> Failures !!!
> Run: 5   Failure total: 1   Failures: 1   Errors: 0

Opening the said spreadsheet in master and performing the test also 
gives that error *if* Calc window is wide enough to show more than 16 
full columns. The problem is that after the first 64 columns, the width 
of them unexpectedly changes; so page-scrolling 3 pages right starts to 
show less then 16 full columns, which changes result of page-scrolling 3 
pages left.

I.e., with 17 full columns visible initially (last full column Q), 
calling LargeScroll to scroll 3 pages right makes first visible column 
AZ, and last visible full column is 52 (BO; 17*3+1) => 16 visible 
columns. Now calling LargeScroll to scroll 3 pages left moves to 16*3=48 
columns left => first visible would become D (while A expected).

Also the columns BM and later don't show normal grid.

Noel, does this ring a bell? How to make all unallocated columns to have 
standard width and grid?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bug 74702 - Issue with bool OutputDevice::IsNativeControlSupported(ControlType, ControlPart)

[Kaganski Mike]

On 15.04.2019 10:33, Adrien Ollier wrote:
> Hello everybody,
> 
> working on bug #74702 
>  led me to 
> read file core/vcl/source/outdev/nativecontrols.cxx.
> 
> I think there is an issue here:
> 
> 
> 
> If mpGraphics == nullptr and AcquireGraphics() == false, then the second 
> if does not return false and we execute the instruction of the return 
> statement but this will lead to a crash (because mpGraphics is false in 
> this scenario).

No, please check what AcquireGraphics() does. Namely, it is used here to 
acquire mpGraphics when it's not yet available. In fact, lines 166-167 
are equivalent to this: "if (!mpGraphics) AcquireGraphics(); if 
(!mpGraphics) return false;"

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bug 74702 - Issue with bool OutputDevice::IsNativeControlSupported(ControlType, ControlPart)

[Kaganski Mike]

On 15.04.2019 10:44, Adrien Ollier wrote:
> OutputDevice::AcquireGraphics() is a pure virtual function, so we cannot 
> know in the general case what it does.
> And what is written is not really equivalent to what you wrote because 
> if AcquireGraphics() is false, there is not a second check for 
> mpGraphics. That's why it is an issue.

AcquireGraphics() is not just "any function". Despite someone could of 
course implement it to play poker, its purpose is to acquire mpGraphics 
and return if it succeeded. Failing that is programmer's error breaking 
contract. There's no use to introduce that kind of checks here. Please 
see existing implementations, like VirtualDevice::AcquireGraphics() in 
vcl/source/gdi/virdev.cxx.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bug 74702 - Issue with bool OutputDevice::IsNativeControlSupported(ControlType, ControlPart)

[Kaganski Mike]

On 15.04.2019 10:44, Adrien Ollier wrote:
> And what is written is not really equivalent to what you wrote because 
> if AcquireGraphics() is false, there is not a second check for mpGraphics

Also note that when AcquireGraphics() is false (telling it could not 
acquire mpGraphics successfully), we return false. It returning true 
means that now mpGraphics is non-nullptr, and then we proceed.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

FastSerializerHelper::singleElement/startElement internal API changed

[Kaganski Mike]

Hi!

This is just to notify those who might currently use 
FastSerializerHelper in patches being prepared.

Commit 1fe24bb1e2fbe44a4bf2c03297e259b3a18b1235 has modified the 
singleElement/startElement[NS] APIs by removing FSEND (which was a 
remnant of old C-style varargs implementation). So if you use these APIs 
in your ongoing work, please rebase.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Properly notify gpgme about spawn executable location on Windows

[Kaganski Mike]

Hi Thorsten, *,

When working on a 6-0-based branch on Windows, in make check, two python 
tests emit modal error dialogs about missing gpgme-w32spawn.exe:

> ---
> GpgME not installed correctly
> ---
> gpgme-w32spawn.exe was not found in the detected installation directory 
> of GpgME
>   "C:\lo\src\core\instdir\program\python-core-3.5.5\bin"
> 
> Crypto operations will not work.
> 
> If you see this it indicates a problem with your installation.
> Please report the problem to your distributor of GpgME.
> 
> Developer's Note: The install dir can be manually set with: 
> gpgme_set_global_flag
> ---
> ОК
> ---

For completeness, the tests are sw_python and 
pyuno_pytests_insertremovecells, but this is not really important; 
obviously, the tests themselves don't need the initialization of 
security context, and the unneeded initialization was fixed somewhere 
down the road, and later versions don't block on the tests.

However, I suppose that it's possible in theory that some user python 
script could ultimately need initializing gpgme. In that case, the 
problem would hit the user. Having a modal dialog waiting on a possibly 
headless server is not a correct behavior :-)

The cause here is that by default, gpgme only expects to find the spawn 
process in the same location as the current executable (see 
_gpgme_get_w32spawn_path and _gpgme_get_inst_dir in 
gpgmepp/src/w32-util.c). It works when the executable is soffice.bin; 
but for python, which is located in a subdirectory of instdir/program, 
this is not true (see error message above). It needs to be told 
explicitly where to look for the executable; and it's only possible 
using gpgme_set_global_flag call.

So I went ahead and prepared a patch for this: 
https://gerrit.libreoffice.org/71014, which adds a check if the spawn 
executable is in the same directory as current process executable, and 
if not, queries UNO_PATH environment variable to check if it contains 
the executable, to notify gpgme about the path.

My questions are:

1. First of all - do I understand it correctly that the problem is real 
- so there are possible scenarios involving e.g. python (or another 
process which executable is not in LO's instdir/program), that might 
need gpgme? I'm not familiar with our scripting framework, so I might 
actually invent a non-existing problem after all. I see that problem 
happening only with those tests, and I don't know if the later fix has 
completely ruled away the possibility to run that code from python, or 
just made that called only when really needed (which implies that it 
will happen eventually).

2. To find the executable, I use UNO_PATH envvar. As far as I can tell, 
even directly running soffice.bin without having UNO_PATH set in 
environment, sets the variable correctly, so this works as expected. But 
is there a better way?

3. The patch needs to add a gpgmepp wrapper for gpgme_set_global_flag 
function, because the function itself is not accessible from the place: 
if I simply used it, linking it fails:

> [LNK] Library/xsec_xmlsec.dll
>Creating library 
> C:/lo/src/core/workdir/LinkTarget/Library/ixsec_xmlsec.lib and object 
> C:/lo/src/core/workdir/LinkTarget/Library/ixsec_xmlsec.exp
> SecurityEnvironment.o : error LNK2019: unresolved external symbol 
> gpgme_set_global_flag referenced in function "public: __cdecl 
> SecurityEnvironmentGpg::SecurityEnvironmentGpg(void)" 
> (??0SecurityEnvironmentGpg@@QEAA@XZ)
> C:/lo/src/core/instdir/program/xsec_xmlsec.dll : fatal error LNK1120: 1 
> unresolved externals

I could overlook how to use the function without the need of the wrapper 
- if so, please give me a hint how to do that properly. If there's no 
way to do that, then I'll create a pr to https://github.com/KDE/gpgmepp.

Thanks.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Properly notify gpgme about spawn executable location on Windows

[Kaganski Mike]

Hi Thorsten,

Thanks for your analysis!

On 21.04.2019 0:22, Thorsten Behrens wrote:
> Kaganski Mike wrote:
>> However, I suppose that it's possible in theory that some user python
>> script could ultimately need initializing gpgme. In that case, the
>> problem would hit the user. Having a modal dialog waiting on a possibly
>> headless server is not a correct behavior :-)
>>
> Hmm - so the uitests are rigging the office in a very specific way,
> using subprocess.Popen to spawn a child soffice process from python
> (which calls CreateProcess on Windows). Code for that is in
> uitest/libreoffice/connection.py, Python3 help blurb is
> 
>   https://docs.python.org/3/library/subprocess.html#subprocess.Popen
> 
> It is a tad surprising that this would somehow 'think' it is still the
> main python executable on Windows, perhaps there's a way to
> parameterize the Popen call differently to rectify that?

I am quite sure that's python.exe process that I debug in VS here (path: 
C:\lo\src\core\instdir\program\python-core-3.5.5\bin\python.exe, 
launched by python.exe in C:\lo\src\core\instdir\program); with a 
command line like this:

> "C:\lo\src\core\instdir\program\\python-core-3.5.5" "-m" "unittest" 
> "insertremovecells"

... and a call stack like this:

> xsec_xmlsec.dll!SecurityEnvironmentGpg::{ctor}::__l2::() Line 49
>   at c:\lo\src\core\xmlsecurity\source\gpg\securityenvironment.cxx(49)
> xsec_xmlsec.dll!SecurityEnvironmentGpg::SecurityEnvironmentGpg() Line 66
>   at c:\lo\src\core\xmlsecurity\source\gpg\securityenvironment.cxx(66)
> xsec_xmlsec.dll!SEInitializerGpg::createSecurityContext(const rtl::OUString & 
> __formal) Line 45
>   at c:\lo\src\core\xmlsecurity\source\gpg\seinitializer.cxx(45)
> xmlsecurity.dll!DocumentSignatureManager::init() Line 80
>   at 
> c:\lo\src\core\xmlsecurity\source\helper\documentsignaturemanager.cxx(80)
> xmlsecurity.dll!DocumentDigitalSignatures::ImplVerifySignatures(const 
> com::sun::star::uno::Reference & rxStorage, 
> const com::sun::star::uno::Reference & 
> xSignStream, DocumentSignatureMode eMode) Line 313
>   at 
> c:\lo\src\core\xmlsecurity\source\component\documentdigitalsignatures.cxx(313)
> xmlsecurity.dll!DocumentDigitalSignatures::verifyDocumentContentSignatures(const
>  com::sun::star::uno::Reference & rxStorage, 
> const com::sun::star::uno::Reference & 
> xSignInStream) Line 176
>   at 
> c:\lo\src\core\xmlsecurity\source\component\documentdigitalsignatures.cxx(176)
> sfxlo.dll!SfxObjectShell::ImplAnalyzeSignature(bool bScriptingContent, const 
> com::sun::star::uno::Reference
>  & xSigner) Line 1538
>   at c:\lo\src\core\sfx2\source\doc\objserv.cxx(1538)
> sfxlo.dll!SfxObjectShell::ImplGetSignatureState(bool bScriptingContent) Line 
> 1567
>   at c:\lo\src\core\sfx2\source\doc\objserv.cxx(1567)
> sfxlo.dll!SfxObjectShell::GetDocumentSignatureState() Line 1718
>   at c:\lo\src\core\sfx2\source\doc\objserv.cxx(1718)
> sfxlo.dll!SfxObjectShell::CheckForBrokenDocSignatures_Impl() Line 981
>   at c:\lo\src\core\sfx2\source\doc\objmisc.cxx(981)
> sfxlo.dll!SfxObjectShell::CheckSecurityOnLoading_Impl() Line 933
>   at c:\lo\src\core\sfx2\source\doc\objmisc.cxx(933)
> sfxlo.dll!SfxObjectShell::FinishedLoading(SfxLoadedFlags nFlags) Line 1081
>   at c:\lo\src\core\sfx2\source\doc\objmisc.cxx(1081)
> sclo.dll!ScDocShell::Load(SfxMedium & rMedium) Line 658
>   at c:\lo\src\core\sc\source\ui\docshell\docsh.cxx(658)
> sfxlo.dll!SfxObjectShell::LoadOwnFormat(SfxMedium & rMedium) Line 3041
>   at c:\lo\src\core\sfx2\source\doc\objstor.cxx(3041)
> sfxlo.dll!SfxObjectShell::DoLoad(SfxMedium * pMed) Line 723
>   at c:\lo\src\core\sfx2\source\doc\objstor.cxx(723)
> sfxlo.dll!SfxBaseModel::load(const 
> com::sun::star::uno::Sequence & 
> seqArguments) Line 1795
>   at c:\lo\src\core\sfx2\source\doc\sfxbasemodel.cxx(1795)
> sfxlo.dll!`anonymous namespace'::SfxFrameLoader_Impl::load(const 
> com::sun::star::uno::Sequence & rArgs, 
> const com::sun::star::uno::Reference & 
> _rTargetFrame) Line 693
>   at c:\lo\src\core\sfx2\source\view\frmload.cxx(693)
> fwklo.dll!framework::LoadEnv::impl_loadContent() Line 1141
>   at c:\lo\src\core\framework\source\loadenv\loadenv.cxx(1141)
> fwklo.dll!framework::LoadEnv::startLoading() Line 375
>   at c:\lo\src\core\framework\source\loadenv\loadenv.cxx(375)
> fwklo.dll!framework::LoadEnv::loadComponentFromURL(const 
> com::sun::star::uno::Reference & 
> xLoader, const 
> com::sun::star::uno::Reference & 
> xContext, const rtl::OUString & sURL, const rtl::OUString & sTarget, long 
> n

Re: Properly notify gpgme about spawn executable location on Windows

[Kaganski Mike]

On 21.04.2019 0:22, Thorsten Behrens wrote:
>> 1. First of all - do I understand it correctly that the problem is real
>> - so there are possible scenarios involving e.g. python (or another
>> process which executable is not in LO's instdir/program), that might
>> need gpgme?
>>
> See above - but even for uitests, the issue might become relevant, so
> I see at least no harm in keeping that fix (unless Popen can be fixed
> to not have Windows inherit too much parent process attributes).
> 

Just checked with master, that the call to gpgme is avoided now due to 
commit 7ac4e48687d7679927f5659e941024445946ffa7 "tdf#118593 sfx2: no 
need to call into xmlsecurity without signature streams", which added a 
check to SfxObjectShell::GetDocumentSignatureInformation. And thus - I 
believe that the patch is indeed useful for the cases where the 
signature streams would be present.

It's a pity that buildbots don't run those tests on Windows hosts. And I 
suppose that we should introduce such a python test with a document with 
signature stream, to properly test this on platforms with substantially 
different implementations. (Not volunteering to the task, though, 
because of lack of required skills.)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bug 74702

[Kaganski Mike]

Hi Adrien,

First of all, it's best to have a tentative change in gerrit, with your 
proposed changes, to have better overview. Please create if you haven't 
yet, and post the link here. Thanks!

On 22.04.2019 11:58, Adrien Ollier wrote:
>  2. In editeng/source/editeng/impedit2.cxx it is required to cast an
> OutputDevice* to a vcl::PDFWriterImpl* to know the real type of pOut
> (and test if the resulting pointer is nullptr or not). This requires
> to include vcl/source/gdi/pdfwriter_impl.hxx but this file is not in
> the common directory for inclusion. How can I include
> vcl/source/gdi/pdfwriter_impl.hxx?

I couldn't find something like "pOut" in 
editeng/source/editeng/impedit2.cxx - so which of the 4300 lines of the 
file you mean? ;-)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: bug 74702

[Kaganski Mike]

Hi Adrien,

On 22.04.2019 12:43, Adrien Ollier wrote:
> sorry I meant impedit3.cxx, lines 2805 and 2806.
> 
> Ok I'll try to make some changes in gerrit.

Nice, looking forward to see it mentioned here in the thread.

Please note that answering someone's answer directly, without CCing the 
mailing list, excludes the message from common discussion. E.g, consider 
how this your reply didn't allow others to also know that you actually 
meant impedit3, and that made others (see Jan-Marek's reply) to waste 
time again. Please always reply to list, or to all, instead of private 
replies.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Fwd: Tinderbox failure, Android-ARM@24-Bytemark-Hosting, MASTER, last success: 2019-04-26 20:22:54

[Kaganski Mike]

Hi!

After my commit ac419786b324 "Don't use std::function in scope guard for 
performance reasons", errors are generated by Android-ARM, as in the 
forwarded message below.

According to 
https://stackoverflow.com/questions/43514188/lambda-passed-to-template-not-defined,
 
it's https://bugs.llvm.org//show_bug.cgi?id=20296 . But why doesn't it 
show up on our jenkins builds; and what should I preferably do: just 
revert the commit, or silence the warning locally somehow (e.g., 
conditionally for Android only)?

--
Best regards,
Mike Kaganski

 Forwarded Message 
Subject:Tinderbox failure, Android-ARM@24-Bytemark-Hosting, MASTER, 
last success: 2019-04-26 20:22:54
Date:   Sat, 27 Apr 2019 00:31:19 +
From:   lohmaier+libreoff...@googlemail.com 

To: caol...@redhat.com , 
mike.kagan...@collabora.com , 
serval2...@yahoo.fr , thorsten.behr...@cib.de 
, tietze.he...@gmail.com 



Hi folks,

One of you broke the build of LibreOffice with your commit :-(
Please commit and push a fix ASAP!

Full log available at http://tinderbox.libreoffice.org/MASTER/status.html

Tinderbox info:

Box name: Android-ARM@24-Bytemark-Hosting
Branch: MASTER
"starttime": 1556323629
Machine: Linux libreoffice2.dh.bytemark.co.uk 4.19.0-4-amd64 #1 SMP 
Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux
Configured with: --build=x86_64-unknown-linux-gnu
--enable-werror
--with-android-sdk=/home/android/android-sdk-linux
--with-android-ndk=/home/android/android-sdk-linux/ndk-bundle
--with-distro=LibreOfficeAndroid
--without-export-validation
--enable-android-editing

Commits since the last success:

 core 
b01a4437c42b docx export: implement text-input field export
cddcab00b81a tdf#124658 - Improve text for the tip-of-the-day
1369a16651ab Fix typos
9b077c26a7a5 Fix typo
95e9b7b2d1a5 tdf#120797: Apply transformation also to the extents of damage
ac419786b324 Don't use std::function in scope guard for performance reasons
8a53befea7cf Removed executions flags on source files

The error is:

build failed - error is::

==
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_nds_DE.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_nl_BE.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_nl_NL.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_nn_NO.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_no_NO.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_oc_FR.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_pl_PL.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_pt_BR.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_pt_PT.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ro_RO.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_rue_SK.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ru_RU.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sc_IT.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sk_SK.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sl_SI.cxx
[build CXX] 
workdir/CustomTarget/i18npool/localedata/localedata_sr_Latn_ME.cxx
[build CXX] 
workdir/CustomTarget/i18npool/localedata/localedata_sr_Latn_RS.cxx
[build CXX] 
workdir/CustomTarget/i18npool/localedata/localedata_sr_Latn_CS.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sr_ME.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sr_RS.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sr_CS.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sv_FI.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_sv_SE.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_tr_TR.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_tt_RU.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_uk_UA.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_vec_IT.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_wa_BE.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_af_NA.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_af_ZA.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ak_GH.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_am_ET.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_AE.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_BH.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_DZ.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_EG.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_IQ.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_JO.cxx
[build CXX] workdir/CustomTarget/i18npool/localedata/localedata_ar_KW.cxx
[build CXX] workdir/CustomTarget/i18n

Re: is gerrit #26348 still somewhere?

[Kaganski Mike]

Hi,

On 29.04.2019 15:04, Eike Rathke wrote:
> Maybe changes marked as abandoned get purged after a while? I don't know.

... but definitely, if a user deletes a draft patch, without publishing 
it, it is deleted irreversibly (or at least irreversibly for the user).

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

C++ initialization talk wideo

[Kaganski Mike]

Hi All, Stephan, Noel,

possibly https://youtu.be/2jJumNzcp6Y would have something interesting 
for you regarding different initialization syntaxes in C++.
Personally for me it was really unexpected that using "=default" in 
method definition is different for inline (inside class definition) and 
outside of the class... well - that is to be expected, right? That's C++ 
after all.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Merging feature/commonsallayout branch

[Kaganski Mike]

Hi Luke,

11/2/2016 3:54 AM, Luke Benes пишет:

Us, as in the LibreOffice, the software many of us volunteer to make as good as 
possible for everyone to enjoy.

Should the Chinese IT manager be embarrassed? Maybe, but coming from a First 
World nation, it’s hard for me to imaging supporting my family on $800/month, 
but at least I try to understand. Should my grandfather at almost 80 now be 
embarrassed? I don’t think so. Maybe I should have tried harder. I know he 
doesn’t use his Chromebook and never boots to Lubuntu.

The point is there are a lot of people out there for whatever reason still us 
XP. Despite what you keep suggesting, dropping XP won’t do anything to change 
them.



From: tlillqv...@gmail.com 
 on behalf of Tor Lillqvist 

Sent: Tuesday, November 1, 2016 2:13 PM
To: slacka
Cc: libreoffice-dev
Subject: Re: Merging feature/commonsallayout branch



 Had we already dropped support for XP, it would have been an embarrassing
demonstration and reflected badly on us.

The only ones that should be embarrassed are those still running XP. Also, who 
are these "us" you are speaking for? --tml

While I agree that no one is to judge if those who are still running XP should 
be embarrassed or not, this specific consideration doesn't matter here.

Those who chose to stay with XP chose the software branch that isn't updated 
anymore. They made their choice between fixed set of functionality that is put 
into XP and evolving set of functionality that is being expanded in later 
versions. OS being platform, this choice inherently included also choosing to 
stay with software that supports that OS. And by making that decision, you 
imply that they suddenly put extra burden on "us" those who volunteer to put 
their effort into writing LO? Just by deciding to stay with aging OS, without 
any donation to this community or someone in person, someone magically creates 
an obligation on "us" and makes it twice as difficult for someone other to 
support and develop their software?

Instead, I see it another way: they had already made a choice to stay with one 
stalled branch (XP); they also chose to stay with another (their version of 
MSO); it's just natural that they can make the same decision about yet another 
software: say v.5.2 of LO. It does support XP, and is open and free as always; 
no one ever takes the right to use that from them.

--
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About replacing some "C-Array" into std::array

[Kaganski Mike]

On 22.11.2019 18:31, julien2412 wrote:
> Taking a look at cppcheck report, I noticed this kind of reports:
> vcl/source/treelist/transfer.cxx
> 132   useStlAlgorithm 398 style   Consider using std::fill algorithm 
> instead of
> a raw loop
> 
> To use std::fill, we'd need to convert the C array into std::array.

I don't see why is the conversion required specifically for using STL. A 
pointer inside the array is a perfect iterator, that STL can use. (No 
objections against conversion where it has benefits :-))

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Accessing code for Calc functions

[Kaganski Mike]

Hi Steve,

On 26.11.2019 17:15, Steve Fanning wrote:
> I am currently working as a member of the Documentation Team, updating 
> Chapter 18 of the Calc Guide (Description of Functions). From time to 
> time during this task, I would benefit from viewing the code that 
> implements individual functions but have not been able to find that 
> code. Could somebody give me some hints please?

E.g., given the function CHITEST [1]:

1. I git grep for the function's name:
 https://opengrok.libreoffice.org/search?project=core&full=CHITEST
2. I see opcode, like "{ "CHITEST" , SC_OPCODE_CHI_TEST },", and grep 
for the opcode:
 
https://opengrok.libreoffice.org/search?project=core&full=SC_OPCODE_CHI_TEST
3. I see "ocChiTest = SC_OPCODE_CHI_TEST," in opcode.hxx, and grep gain 
for it:
 https://opengrok.libreoffice.org/search?project=core&full=ocChiTest
4. In an interprN.cxx, I see "case ocChiTest :", and go there to see the 
name of function called when that opcode arrives:
 
https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/interpr4.cxx?r=0ef5c475#4392
5. So I see the function name is ScChiTest:
 
https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/interpr3.cxx?r=f853ec31#2797

This is possibly too long, but that's from the PoV of not knowing where 
to look initially. Of course, you could also try shortcut searching for 
ScFoo when looking for FOO function... (not always helpful). Anyway, 
this shows the relevant pieces.

> It would also help if I could view the code for the Function Wizard.

For any dialog, you look into its English UI, and grep for the strings 
in it (choose specific enough):
 
https://opengrok.libreoffice.org/search?project=core&full=%22Function+result%22

Find the .ui file, and then grep for its name in .cxx files - you will 
find the constructor creating the dialog or one of its tabs:
 
https://opengrok.libreoffice.org/search?project=core&full=%22formuladialog.ui%22

So likely you need to look in formula/source/ui/dlg/formula.cxx

That's how I do that. HTH.

[1] 
https://help.libreoffice.org/latest/en-US/text/scalc/01/04060181.html?DbPAR=CALC#bm_id3154260

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Fwd: [comment] uitest for bug tdf#126685

[Kaganski Mike]

On 20.11.2019 21:58, Crhonek Zdenek wrote:
> Probably I found the reason - document is opened with macro warning and 
> test stuck here. I don't know why it worked on my computer and on gerrit 
> bots, but now I can reproduce it.  Unfortunately I cannot reproduce the 
> bug after copy of sheets to the new file and deleting of macros didn't 
> help (LO still raise warning).

You could try setting MacroSecurityLevel to 0 in a specifically crafted 
registrymodifications.xcu to use in the test (like the one used for 
setting locale to en-US; see qadevOOo/qa/registrymodifications.xcu, 
which is used in smoketest/CppunitTest_smoketest.mk, 
solenv/gbuild/JunitTest.mk, and - solenv/gbuild/UITest.mk). I don't know 
is making the modification right in that file is OK, or if a dedicated 
one needed.

(I couldn't find macros in the file actually.)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: chart2.check fails in testAxisTitlePositionDOCX

[Kaganski Mike]

On 11.12.2019 1:32, Luke Benes wrote:
> I bisected this regression to
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=d10db7846602c16701dde019f12f61fd536e9ae4
> 
>  tdf#128133 WIN don't exit after link-output filter

I would assume this not to be a regression from that commit, but rather 
a regression from DPI-dependent unit tests added in the time span 
between an unintended disabled inclusion of the DPI-aware manifest in 
commit 7f791f431c79c6d0a156c4a2726a0dfc5ff40cc1, and this one fixing that.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [libreoffice-design] Minutes from the UX/design meeting 2019-DEC-12

[Kaganski Mike]

Dear Paul,

12 дек. 2019 г. 17:30 пользователь paul hofseth  написал:

Sirs,

please do not waste scarce coding resources on thoroughly trivial
matters like colours and signage, but rather on making the programs more
practical to use -  such as for instance having the choice of typeface
as a sdeparate item, not hidden inside the multiple format choices.
Risking ostracism fro monotounous suggestions, I repeat my wish for
sequential views of single pages with as little jumbling as possible of
text and illsustrations when proofreading long documents

Please do not waste scarce coding resources on thoroughly trivial
matters like telling others what to do, but rather on making the programs more
practical to use!

Why do I write this rather harsh statement? Not in the hope that you would 
start doing what I wrote, but to show you one important aspect that you seem to 
overlook. What would you do if you actually be denied of a way to contribute by 
expressing your opinions and wishes, and demanded to do something entirely 
different for the project? For most, such requirement would not mean they 
started contributing differently; that would mean they stopped contributing at 
all. Most people here contribute for one of two reasons: either being paid for 
the work by their employers/customers, or doing things they *can* for own 
enjoyment. Not everyone here likes or is able to do what you'd want them to do 
to fix your pet bug; and your expectation that if you deny someone of doing 
what *you* consider "trivial" would free the resources for a different task, 
are just plain wrong: instead of improving the areas you are interested in, we 
would simply loose those who love and able to contribute in areas *others* are 
interested in, nothing else.

By the way, I actually deem the importance of *your* contriburion (expressing 
your opinion about LibreOffice and its future, feeling for it, and proposing 
something) wery high. So please don't take the initial statement seriously, but 
just as a way to illustrate my point.

Best regards,

Mike Kaganski

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Avoid "JRE required" msg upon extension installation

[Kaganski Mike]

Hi Alexis,

On 2019-12-25 3:23, Alexis de Lattre wrote:
> I developed a LibreOffice Extension that contains a Python macro (and 
> the required Python libs):
> 
> https://github.com/akretion/factur-x-libreoffice-extension  file 
> "factur-x_macro.oxt" (source code in "extension/" subdir)
> 
> But, when I add this extension to LibreOffice on a PC without Java 
> installed, I get this error message:
> 
> << LibreOffice requires a Java runtime environment (JRE) to perform this 
> task. However, use of a JRE has been disabled. Do you want to enable the 
> use of a JRE now?  >>
> 
> If I answer "No", the extension will still work fine (because the 
> extension doesn't need Java at all, it only contains a Python macro). So 
> this message is wrong.
> 
> Could I change something in my macro to avoid this message ? My 
> extension targets users without IT background and they could be scared 
> by that wrong message.
> 
> Thanks in advance for your help,
> 

You can't change anything in the extension to avoid this. This is 
tdf#120363 [1], and is fixed in LibreOffice 6.2.

There are other cases when similar warnings appear; see e.g. [2] which 
is about warning in script organizer dialog, fixed in 6.3.1. If you come 
across such problems in current releases, please file a bug and CC me. 
Thanks.

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=120363
[2] https://bugs.documentfoundation.org/show_bug.cgi?id=126643

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Failing UI tests on Winx64 build

[Kaganski Mike]

Hi,

On 2019-12-26 22:59, Stepas Toliautas wrote:
> I happened to launch some "live" UI tests on my Windows 10 x64 machine 
> and noticed that some of them keep failing -- all with the same exit 
> status 3221225477 (0xC005, access violation) and, supposedly, right 
> at the end of testing, because I don't see any assert or warning 
> messages in output logs (or don't know where to look).

Hopefully these should be fixed with

https://git.libreoffice.org/core/+/3ebf6a090b227c0097ff8668fe023e7bdbdadc5d

and

https://git.libreoffice.org/core/+/8cce131dcc1803ac95f3079098be767662fcca09

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Benchmark results on mdds::multi_type_vector

[Kaganski Mike]

Hi Kohei,

On 2019-12-14 1:38, Kohei Yoshida wrote:
> Alright, since now one person is raising objection on hastily 
> integrating this piece, I should hold on to integrating this piece for 
> now, and let the discussion continue.

If I understand correctly, there was no objections on integrating this 
work into LibreOffice; it sounded more like stating the obvious that the 
we can speculate as long as we want, but only actual usage will show the 
real picture - and that implies that the integration is really needed.

Personally I would love seeing it integrated; and I have high hopes on 
the improvements this offers. My understanding of the typical usage 
patterns of Calc makes me feel that the benefits will vastly outweigh 
possible corner-case slow-down.

Given that there was no further discussion on this topic (AFAICT), do 
you have plans to go on and integrate in in the near future please?

Thank you for your great work!

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Failing UI tests on Winx64 build

[Kaganski Mike]

Hi Stepas Toliautas,

On 2019-12-30 0:32, Stepas Toliautas wrote:
> 
> However, we're not out of the woods yet, since a single new error of
> presumably the same type (access violation at shutdown) cropped up
> in impress_demo uitest suite -- at /backgrounds.ImpressBackgrounds/,
> in /test_background_dialog/ . Test log is at
> http://paste.debian.net/1123087/ . It might well have been there
> before, just the tests didn't get that far before now.
> 
> 
> A few more from another test run are shown below. Note that these (and 
> the last one) come and go, and are NOT reproduced by directly running 
> separate test files. Could it be that concurrent testing (-j 8) of 
> different modules is somehow at fault here?

I hope you had built LO (`make`) after pulling before running `make 
uitest.uicheck`?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Print dialog window too big with 6.4.0~rc1

[Kaganski Mike]

On 2019-12-31 16:32, Paul Menzel wrote:
> LibreOffice 6.4.0.1 40(Build:1) seems to have redesigned the print 
> dialog. The window is too big now, causing the buttons in the bottom not 
> to be seen on a laptop with 1366x768 resolution and GNOME Shell, which 
> does not allow you to move the window outside the screen. If the window 
> is supposed to stay that big, a scrollbar needs to be added so all parts 
> of the dialog can be seen.

Please see tdf#127782. In general, any bug reporting should be done 
there in the bug tracker. Thanks!

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=127782

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Duplicate .uno commands

[Kaganski Mike]

Hi!

In tdf#129549 [1], two .uno commands were identified as duplicating: 
.uno:BulletsAndNumberingDialog and .uno:OutlineBullet. First of them is 
Writer-specific [2]; second is not [3].

In Writer, both of them are routed to SwTextShell::ExecEnterNum, and 
handled identically (in the same switch case), opening the bullets and 
numbering dialog.

They have identical UI names ("Bullets and Numbering"); similar (but not 
identical) icons (see [4] for screenshot of them side by side using 
Colibre icon set); and they both are used in Writer's UI: 
.uno:BulletsAndNumberingDialog in main menu [5], .uno:OutlineBullet in 
context menu [6].

The problem with this, besides duplication itself (including e.g. 
drawing icons), is that both of them appear in customization dialog, and 
that's confusing. Having two elements in customization dialog with same 
name, but different operation, as often happening, is already bad enough 
(user has to experiment to find the one that is needed; that was handled 
partially in tdf#108458); but having two totally identical elements is 
too much IMO. Users would struggle to find the difference; and anyway 
assume they just didn't find the scenario where they act differently.

The question is: how to handle this? I suppose that one of them 
(.uno:BulletsAndNumberingDialog) should be deprecated and hidden from 
the customization UI, and its uses replaced with the other. I suppose we 
can't drop it completely for compatibility reasons (might it be used in 
user code?).

So is there something I miss about these two commands behaving 
identically? Might there be a reason to keep it as is? and is there an 
existing mechanism to hide some .uno commands from the customization UI?

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=129549
[2] 
https://opengrok.libreoffice.org/xref/core/sw/sdi/swriter.sdi?r=7efae60f#452
[3] 
https://opengrok.libreoffice.org/xref/core/svx/sdi/svx.sdi?r=ef6e2b50#5897
[4] https://i.imgur.com/tTAMjDb.png
[5] 
https://opengrok.libreoffice.org/search?project=core&full=%22uno%3ABulletsAndNumberingDialog%22
[6] 
https://opengrok.libreoffice.org/search?project=core&full=%22uno%3AOutlineBullet%22
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Duplicate .uno commands

[Kaganski Mike]

Hi Miklos,

Thanks for your comments!

On 2020-01-03 11:28, Miklos Vajna wrote:
>> The problem with this, besides duplication itself (including e.g.
>> drawing icons), is that both of them appear in customization dialog, and
>> that's confusing.
> 
> You can avoid duplicated icons via icon-themes/.../links.txt.

My point about duplication and icons was duplicated effort for creating 
them - which has already happened, as seen in this case; not how 
technically to make two commands to point to the same icon (which is 
easy - once you *know* that they are duplicates).

> 
>> Having two elements in customization dialog with same
>> name, but different operation, as often happening, is already bad enough
>> (user has to experiment to find the one that is needed; that was handled
>> partially in tdf#108458); but having two totally identical elements is
>> too much IMO. Users would struggle to find the difference; and anyway
>> assume they just didn't find the scenario where they act differently.
> 
> Can't we label the deprecated one as "... (deprecated)"?

Do you mean changing label of one? I'd say it's not ideal: the idea 
behind deprecation will not be obvious; in the presence of many 
non-duplicating commands with identical names, these two would still 
raise questions like "is this one deprecated because it's a duplicate of 
*that other one*, or *of another unknown*, or because of other reason?", 
which would still not address the problem. I hoped there's an existing 
way to mark a command as "hidden from Customization dialog" :-)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Duplicate .uno commands

[Kaganski Mike]

Hi Maxim,

On 2020-01-05 2:38, Maxim Monastirsky wrote:
> The separate .uno:BulletsAndNumberingDialog command predates the
> handling of .uno:OutlineBullet in Writer. The latter was introduced
> only in 2013 as part of the sidebar feature work (commit
> d02f75a8c36705924ddd6a5921fe3012fafce812, "Resolves: #i121420# merge
> sidebar feature"). I believe the intent there was to have a single
> command to dispatch from the sidebar's bullets/numbering popups, across
> different modules, not to introduce any new behavior beyond
> .uno:BulletsAndNumberingDialog.

Thank you; so I assume that hiding .uno:BulletsAndNumberingDialog and 
replacing its uses with .uno:OutlineBullet is OK.

>> and is there an
>> existing mechanism to hide some .uno commands from the customization
>> UI?
> 
> Yes. Each sdi slot has 3 attributes which should be set to FALSE :
> AccelConfig, MenuConfig, ToolBoxConfig. As a result, the given command
> won't be reported to the customization dialog via the
> XDispatchInformationProvider interface. See the actual implementation
> in SfxBaseController::getConfigurableDispatchInformation and
> SfxAppDispatchProvider::getConfigurableDispatchInformation.

Thank you very much - now I see why I rejected my initial assumption of 
this: as you may see in the links to the SDIs in the starting message 
(duplicated below), the .uno:OutlineBullet slot does have the 
AccelConfig and MenuConfig both set to FALSE; yet the slot is visible on 
both menu and keyboard customization tabs. Looking at the places that 
use the constants, I see that they all harvest whatever has at least one 
of the flags set. So obviously a bug here :-)

https://opengrok.libreoffice.org/xref/core/sw/sdi/swriter.sdi?r=7efae60f#452
https://opengrok.libreoffice.org/xref/core/svx/sdi/svx.sdi?r=ef6e2b50#5897

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Duplicate .uno commands

[Kaganski Mike]

On 2020-01-05 17:22, Kaganski Mike wrote:
> On 2020-01-05 2:38, Maxim Monastirsky wrote:
>> The separate .uno:BulletsAndNumberingDialog command predates the
>> handling of .uno:OutlineBullet in Writer. The latter was introduced
>> only in 2013 as part of the sidebar feature work (commit
>> d02f75a8c36705924ddd6a5921fe3012fafce812, "Resolves: #i121420# merge
>> sidebar feature"). I believe the intent there was to have a single
>> command to dispatch from the sidebar's bullets/numbering popups, across
>> different modules, not to introduce any new behavior beyond
>> .uno:BulletsAndNumberingDialog.
> 
> Thank you; so I assume that hiding .uno:BulletsAndNumberingDialog and
> replacing its uses with .uno:OutlineBullet is OK.

For the record: done with 
https://git.libreoffice.org/core/+/d1133d71a6109d1999121fd6a91573d12dc4852b.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Permission not granted to push my patch

[Kaganski Mike]

Hi,

On 04.05.2019 12:45, Cyrille wrote:
> I tried:
> git push ssh://lafric...@gerrit.libreoffice.org:29418/dictionaries 
> HEAD:refs/for/master
> 
> I got now this error:
> remote: Resolving deltas: 100% (1/1)
> remote: Processing changes: refs: 1, done
> remote: ERROR: [b5f81e8] missing Change-Id in commit message footer
> remote:
> remote: Hint: To automatically insert Change-Id, install the hook:
> remote:   gitdir=$(git rev-parse --git-dir); scp -p -P 29418 
> lafric...@gerrit.libreoffice.org:hooks/commit-msg ${gitdir}/hooks/
> remote: And then amend the commit:
> remote:   git commit --amend
> remote:
> To ssh://gerrit.libreoffice.org:29418/dictionaries
>   ! [remote rejected] HEAD -> refs/for/master ([b5f81e8] missing 
> Change-Id in commit message footer)

The cited hint seems pretty obvious? ;-)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Gsoc 2020

[Kaganski Mike]

Hi!

On 2020-01-26 20:18, Ilmari Lauhakangas wrote:
> You could try
> --with-jdk-home=/cygdrive/c/Program Files/Java/jdk-13.0.1

In cygwin, I usually use forward-slash paths, which are perfectly-valid 
cygwin paths, like

--with-jdk-home=C:/Program Files/Java/jdk-13.0.1

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: o3tl::make_unsigned

[Kaganski Mike]

On 2020-01-30 15:30, Stephan Bergmann wrote:
> On 30/01/2020 12:56, Luboš Luňák wrote:
>> On Thursday 30 of January 2020, Stephan Bergmann wrote:
>>> On 29/01/2020 17:14, Luboš Luňák wrote:
    Exactly my point. It's just that you seem to find it guaranteed that
 people won't mess up range checks and only likely there won't be
 titanically huge files/allocations/containers, and I see it the 
 other way
 around. So far I've definitely seen more often somebody get >=0 wrong
 than I've seen 8 exabytes of anything.
>>>
>>> My point is that, for e1 of signed type S1 (where U1 is the unsigned
>>> counterpart) and e2 of unsigned type U2 (where S2 is the signed
>>> counterpart),
>>>
>>>     e1 < 0 || U1(e1) < e2  // (*)
>>>
>>> is guaranteed to work for all types S1 and U2 and all values of e1 and
>>> e2, while
>>>
>>>     e1 < S2(e2)
>>>
>>> is not.  My point has nothing to do with people writing broken code, or
>>> how to prevent them from doing so.
>>>
>>> It is just that for the task "compare a signed e1 against an unsigned
>>> e2", (*) is the tool I at least reach for (naturally; without much of a
>>> second thought, actually).  And it has in fact been used all over the LO
>>> code base,
>>
>>   This contradicts your original mail, where you stated that what is used
>> is "if (sal_uInt32(e1) < e2) ...    // (B)" (i.e. without the <0 
>> check). And
> 
> Maybe it is unclear, but my original mail was talking about a "correct" 
> comparison
> 
>    e1 < e2
> 
> (i.e., where it is known that e1 >= 0, but where compilers might 
> nevertheless emit a signed-vs.-unsigned warning).

Can the hypothetical make_signed function return a signed integer when 
there's a bigger integer type exist, and a struct with overloaded 
operator<=> when there's not, and that overloaded operator<=> would 
check if contained unsigned value is greater than max value of its 
signed argument, and return "contained unsigned is greater than passed 
signed" in that case, otherwise fallback to "convert unsigned to signed 
and compare normally" strategy? This would comply with the scope of the 
function (which, as I understand it, to only be used in preparation to 
comparison), always return mathematically correct result of comparison, 
and allow all smaller types comparison to still be without overhead? 
(But for 64-bit unsigned types, of course, it will introduce the 
overhead. Will it be significant, though?)

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: o3tl::make_unsigned

[Kaganski Mike]

On 2020-01-30 17:25, Luboš Luňák wrote:
> On Thursday 30 of January 2020, Kaganski Mike wrote:
>> Can the hypothetical make_signed function return a signed integer when
>> there's a bigger integer type exist,
> 
>   Yes.
> 
>> and a struct with overloaded
>> operator<=> when there's not, and that overloaded operator<=> would
>> check if contained unsigned value is greater than max value of its
>> signed argument, and return "contained unsigned is greater than passed
>> signed" in that case, otherwise fallback to "convert unsigned to signed
>> and compare normally" strategy? This would comply with the scope of the
>> function (which, as I understand it, to only be used in preparation to
>> comparison), always return mathematically correct result of comparison,
>> and allow all smaller types comparison to still be without overhead?
>> (But for 64-bit unsigned types, of course, it will introduce the
>> overhead. Will it be significant, though?)
> 
>   Not worth it. That'd be like doing error checking for every memory
> allocation - we also bother only with those few cases where it realistically
> can go wrong.
> 

I disagree with this approach. Not checking memory allocation result is 
a strategy with specific and easily controlled results of failed 
expectation. I am sure that it will segfault, not proceeding with wrong 
operation - and that's enough for me. Not checking in the discussed case 
is just a sure way to difficult-to-find bugs - and yes, I see the "this 
will not happen in my time" argument.

I share the "unsigned types are harmful" idea, but I see the logic in 
Stephan's solution which may have correct scope of application without 
any overhead; and there is no strictly correct scope of application for 
"make_signed" on 64-bit integers without additional checking. The 
"number is non-negative" has a natural application; "number no greater 
than std::numeric_limits::max()" is absolutely artificial.

IMO the "let's change make_unsigned with make_signed" only makes sense 
if it is *correct* solution, even if it implies overhead.

My take on this is https://gerrit.libreoffice.org/c/core/+/87762. I can 
see why it might be considered wrong and rejected (e.g., because 
overhead it brings is unacceptable; or because asserting on valid range 
is considered correct...) - but at least this would not (unless I made a 
programming error) give wrong results, not "I believe I will never meet 
values outside of this range".

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: build error : 'f__faststorefence': is not a member of 'GrGLInterface::Functions'

[Kaganski Mike]

On 2020-02-01 8:58, himajin10 wrote:
> I'm getting the following error. how should I fix this error?(and why 
> doesn't Jenkis fail?)
> 
> C:/build/workdir/UnpackedTarball/skia/src/gpu/gl/GrGLGpu.cpp(3771): 
> error C2039: 'f__faststorefence': is not a member of 
> 'GrGLInterface::Functions'
> C:\build\workdir\UnpackedTarball\skia\include/gp/gl/GrGLInterface.h(74): 
> note: see declaration of 'GrGLInterface::Functions'

https://gerrit.libreoffice.org/c/core/+/87780

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

RE: Debugging on Visual Studio (Windows)

[Kaganski Mike]

On 19.07.2024 11:14, Miklos Vajna wrote:
> On Thu, Jul 18, 2024 at 07:30:53PM -0700, Kira Tubo  
> wrote:
>> 2. In Cygwin: make vs-ide-integration
>> 3. In Visual Studio, open LibreOffice.sln
>> 4. Add breakpoints to a .cxx file
>
> To be clear, this is for the IDE integration, debugging doesn't need
> that, it would be for tab completion while editing code, etc.
>
> If you just want to debug, you can simply open the file in question and
> put breakpoints there, no need for any kind of projects.

Just to clarify: while VS IDE integration is not required, it doesn't hurt, and 
can't be a reason of any failure like discussed here.

>> 5. In Cygwin: instdir/program/soffice.exe
>> 6. In Visual Studio, Debug > Attach to Process > soffice.bin (at this
>> point, it asked me to run VS with admin privileges)
>
> I don't recall I had to have admin privileges to debug a normal
> soffice.bin process, but otherwise yes, that's how you do it, yes.

The admin privileges request is most suspicious. I would blame it for 
everything, e.g. I could suspect that there is a problem that admin process 
working with other environment variables could simply be unable to find the 
symbols.

There must not be an admin request. It needs clarification, if you use 
different users to run VS, and run LO.

>> 7. F5 to start debugging
>
> Not sure you need this step, possibly once you attach the debugger to
> the process, it'll wait for your breakpoint to be hit, so you don't have
> to start anything.

Of course, attaching to a running process doesn't need F5 until a breakpoint 
hit, or otherwise paused; when in pause, F5 would resume (and F10 would step 
over).


--
Best regards,
Mike Kaganski

От: LibreOffice  от имени Miklos 
Vajna 
Отправлено: 19 июля 2024 г. 9:14
Кому: Kira Tubo 
Копия: libreoffice@lists.freedesktop.org 
Тема: Re: Debugging on Visual Studio (Windows)

Hi Kira,

On Thu, Jul 18, 2024 at 07:30:53PM -0700, Kira Tubo  wrote:
> I'm having difficulty debugging using Visual Studio on Windows. Not sure if
> I am doing something wrong or I'm missing some things that need to be
> installed.
>
>1. I have --enable-dbgutil set up in my autogen.input file

Good, at this point you should have debug symbols.

>2. In Cygwin: make vs-ide-integration
>3. In Visual Studio, open LibreOffice.sln
>4. Add breakpoints to a .cxx file

To be clear, this is for the IDE integration, debugging doesn't need
that, it would be for tab completion while editing code, etc.

If you just want to debug, you can simply open the file in question and
put breakpoints there, no need for any kind of projects.

>5. In Cygwin: instdir/program/soffice.exe
>6. In Visual Studio, Debug > Attach to Process > soffice.bin (at this
>point, it asked me to run VS with admin privileges)

I don't recall I had to have admin privileges to debug a normal
soffice.bin process, but otherwise yes, that's how you do it, yes.

>7. F5 to start debugging

Not sure you need this step, possibly once you attach the debugger to
the process, it'll wait for your breakpoint to be hit, so you don't have
to start anything.

Regards,

Miklos

Difference in a test behavior on Windows and Linux

[Kaganski Mike]

In commit b37b299d5228beeecb913980780f463756c5a878 [1] I have tested a 
hung sc_stylefamilyobj problem on Windows, that was caused by a bug in 
IndexedStyleSheets::FindPositionsByNameAndPredicate fixed later in 
commit 362082b57b2d6e9119acb3fb033aefcbce8cf8bb [2]. It was introduced 
in 2014 [3], and apparently is not platform-specific.

Since gerrit_linux_clang_dbgutil builds the subsequentcheck tests, the 
problem should have been caught there, when 
https://gerrit.libreoffice.org/69029 was tested, and later, after its 
merge. However, it was passing fine, which shows some serious difference 
in obviously *platform-independent* behavior on Linux and Windows. 
Identically initialized document with identical stylesheet list, iiuc, 
should fail identically when executing the same faulty code, shouldn't 
it? What am I missing?

[1] 
https://git.libreoffice.org/core/+/b37b299d5228beeecb913980780f463756c5a878
[2] 
https://git.libreoffice.org/core/+/362082b57b2d6e9119acb3fb033aefcbce8cf8bb
[3] 
https://git.libreoffice.org/core/+/0c17ccc493d0c7a80f37600dae76a09a119bef78
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC] Subpixel glyph positioning - Looking for a mentor

[Kaganski Mike]

On 04.04.2019 19:56, Alexander Farrow wrote:
> Hi Jan-Marek,
> 
> Thank you for your reply.
> 
>      I have added some potential mentors, which are normally also 
> interested in font
>      rendering. As much as I could potentially do some mentoring, as I 
> know a share
>      of SalLayout and VCL, I have just minimal idea about text rendering, 
> mainly from
>      the time writing the Qt5 VCL backend. I'm willing to do some larger 
> share of it.
>      Someone of you want to share?
> 
> I'm extremely glad to hear that you are happy to be a mentor for this 
> project, as
> I am very keen to continue working on this for GSoC. Thank you for CC'ing 
> Mike and
> Khaled, hopefully we can find another mentor to join us on this project.

Oh! I didn't realize that I was in the explicit CC list; since I never 
worked with font rendering stuff closely, I even didn't consider myself 
as a potential mentor. Sorry, but I don't have required skills. But of 
course, I'm ready to answer any questions in the course of the project 
(be it GSoC or otherwise) as much as I have knowledge. I consider this 
task an important thins, so it's in my scope of interest.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Gitiles VCS browser

[Kaganski Mike]

On 05.04.2019 19:55, Guilhem Moulin wrote:
> Hi Miklos,
> 
> On Fri, 05 Apr 2019 at 09:17:01 +0200, Miklos Vajna wrote:
>> One more aspect: perhaps I'm just unlucky, but on average, I found
>> cgit to load much faster than these git.libreoffice.org links.
> 
> Hmm that's interesting.  That's not something I'm able to reproduce by
> taking 100 random commits from the last 1 non-merge commits in
> master:

 From my observations, the older the commit, the longer it takes. It 
might even timeout for some commits from early 2000s.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Gitiles VCS browser

[Kaganski Mike]

Hi,

On 06.04.2019 1:46, Luke Benes wrote:
> No one in QA and no developers have voiced a preference for gitiles. 
> Because it's slower, it's UI and UX is harder to read, it lacks useful 
> tools like search,  and the URLs are a pain to work with. It's inferior 
> in every way.

Personally I like URLs like
https://git.libreoffice.org/core/+/6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a
being (a) shorter than all alternatives; (b) being libreoffice-related. 
I'd like them to stay; I have no problems with expanded form of those, 
too. After my concerns about dates were addressed, I only would like if 
redirection to the actual (gitiles) address would be something internal, 
not resulting in browser URL change.

Of course, the performance issue is something to solve, too, but that is 
a technical task, which is not a blocker for me.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Gitiles VCS browser

[Kaganski Mike]

On 06.04.2019 17:18, Luke Benes wrote:
> Mike,
> That is not an apples to apples comparison. In your browser open and compare 
> side-by-side:
> 
> https://git.libreoffice.org/core/+/6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a
> and
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a
> 
> Do you really like all of the extraneous information?

Do you mean the tree below? Well - it doesn't hurt me. But if it went 
away (with a link to easily reach the tree from that page), I'd not protest.

> Do you like the missing search bar?

It doesn't matter *for me*, because I don't use it anyway. But I can see 
how people might miss it.

> Do you like having to scroll down several pages to see the relevant 
> information?

I don't quite get that. Which information on that page requires to 
scroll down several pages in gitiles, which does not on cgit?

> Do you like the lack of a search bar?

This is not the fourth argument, but rather the second ;-)

> Besides the fact, these are not what the commits look like on our bug 
> trackers. From
> 
> https://git.libreoffice.org/core/+/bf2f0c913774c90e4c9a65119d0219187bb4498c%5E%21
> while the old cgit would be
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=bf2f0c913774c90e4c9a65119d0219187bb4498c
> 
> Now try to copy the commit ID from the gitiles and do the same for the cgit 
> URL. Do you really prefer the random symbols appended to the end? I can tell 
> you git does not and will puke if you accidentally include any of them.

For me, double-clicking commit number in the address bar in Chrome on 
Windows (e.g., between b and f in the URL above), selects the commit ID 
without the trailing part. Well - of course, if the commit diff were 
right on that initial page without ^! (after the changed files list), 
I'd also not protest.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: When file truncation happens by Basic's Open statement

[Kaganski Mike]

Hi!

On 21.12.2018 20:37, Takeshi Abe wrote:
> In order to tell whether the behavior reported in tdf#119102 [1] is a bug
> or not, I would like to understand the specification of LibO Basic's Open
> statement [2].
> 
> The following table summarizes what current (master) LibO does, which I read
> from SbiStream::Open() in basic/source/runtime/iosys.cxx.
> 
>ACCESS\FOR  | APPEND | BINARY | INPUT | OUTPUT | RANDOM |
> --+++---+++
> default|   -|   -|   -   |   X|   -|
>   READ  ("read only")  |   -|   -|   -   |   -|   -|
>   WRITE ("write only") |   -|  -(*)  |   X   |   X|  -(**) |
>   READ WRITE ("both")  |   -|  -(*)  |   X   |   X|  -(**) |
> 
> "X": the runtime deletes the file of given path first if already exists;
> "-": it does not.
> (*)  requested in i#18638 ;
>   see commit 23b49669ab70cac72d5f6d955e7d2af617e6934e.
> (**) requested in i#61277 ;
>   see commit 42a63dd0e81f13a84a5f551e03ede685e2bf34c7.
> 
> So here is a couple of questions popping up on a confused soul:
> 
> (1) What does the default ACCESS mode mean?
> Is it just the same as READ, WRITE, or READ WRITE?
> Or does it depends on given FOR mode?
> 
> (2) Does 'FOR INPUT + ACCESS WRITE' or 'FOR OUTPUT + ACCESS READ' make
> any sense?

Cannot answer the questions; just for completeness, something you could 
already know:

the current handling of BINARY opened for write was defined in commit 
23b49669ab70cac72d5f6d955e7d2af617e6934e [1] for #i18638 [2].

[1] 
https://git.libreoffice.org/core/+/23b49669ab70cac72d5f6d955e7d2af617e6934e%5E%21/
[2] https://bz.apache.org/ooo/show_bug.cgi?id=18638

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Libre Office Local Installation

[Kaganski Mike]

Hi Komal! Welcome!

On 23.12.2018 10:43, Komal Bharadiya wrote:
> Moreover, I have directly downloaded the libre office
> repository from github. Then followed the steps given on official site
> of libre office.

Although possibly unrelated to the problem, this is clearly wrong. Where 
have you read the directions to download from github read-only secondary 
repository? As far as I know, the official instructions [1] [2] mention 
cloning https://gerrit.libreoffice.org/core (preferrable IMO), or 
anongit, or downloading special tarballs.

Before proceeding, please start with correct repo.

[1] https://wiki.documentfoundation.org/Development
[2] https://www.libreoffice.org/about-us/source-code/

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppunitTest_chart2_xshape Failure with Display Scaling on Windows

[Kaganski Mike]

Hi,

On 16.12.2018 22:57, Luke Benes wrote:
> Mike,
> The fix for *Bug 121685* 
> , 
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=7263d223ddf4
> ​
> Is causing the core Unit Test CppunitTest_chart2_xshape to fail when you 
> set,  Settings->Display->Scale=125%​
> ​
> Setting Scale=100% allows the build to pass with no errors. ​
> ​
> Build log:​
> https://pastebin.com/SpSiCm6u

This is addressed in https://gerrit.libreoffice.org/65595. Note that the 
change does not implement the approach suggested by jmux in [1] (because 
I don't have enough knowledge), and only properly fixes one test to 
consider system DPI. The other affected tests are disabled for now in 
cases of non-default DPI values, which of course would need to be 
reverted once a proper fix is implemented.

[1] 
https://lists.freedesktop.org/archives/libreoffice/2018-December/081591.html

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: OpenGrok for core

[Kaganski Mike]

On 26.12.2018 16:38, Justin Luth wrote:
>  kompi: upgraded on xmas night (as announced to status.tdf) but 
> the index & history namespace changed so I had to trigger a full reindex 
> (which is still ongoing for core)
> 11:28  Possibly core has not indexed yet (as the one 
> largest opengrok project), since guilhem mentioned yesterday that 
> reindexing takes place
> 11:29  oh
> 11:29  shouldn't have taken that long but I didn't foresee the 
> namespace change and didn't notice until it was already too late
> 11:29  :-)
> 11:29  (the previous indexes are nuked)
> 
> 11:33  threw more power at the vm but full indexing takes ages 
> anyway, at the current pace it's unlikely to be done before the week-end 
> :-(

13:46  people wondering about opengrok are invited to check 
https://status.documentfoundation.org/incident/84 for updates

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Fwd: About Build dependencies Environment setup

[Kaganski Mike]

Hi!

On 06.01.2019 21:13, Mohit Kumar wrote:
> Hi,
> I am trying to build dependencies in linux by following the coomand : 
> sudo apt-get build-dep libreoffice but it showing some error.I am 
> attaching the screenshot, Please Help

First of all, please always mention your OS information.
Next, the suggestion that Thorsten mentioned when tried to answer you on 
IRC (you seem to have *really* poor connection) was to try manually 
installing the dependencies, excluding the libpng12-devel; I'd also 
suggest to try installing a newer LibreOffice from PPA [1] which could 
have an updated list of dependencies, which could not have the outdated 
(for your version of OS) dependencies - but that's only my speculation, 
not something known to work.

[1] https://launchpad.net/~libreoffice/+archive/ubuntu/ppa

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: libreoffice pdfimport w/ poppler-0.72.0: build failure

[Kaganski Mike]

Hi Andreas!

On 08.01.2019 3:12, Andreas Sturmlechner wrote:
> In git master, libreoffice fails to build with:
> 
> sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.cxx:558:70: error: ‘const
> class GooString’ has no member named ‘getCString’
> 
> The relevant change in poppler 0.72 release notes:
> * Rename GooString::getCString to GooString::c_str
> 
> The attached patch made it build successfully for me.

Could you please post the patch to gerrit [1] [2], and also post your 
license statement [3]?

[1] https://gerrit.libreoffice.org
[2] https://wiki.documentfoundation.org/Development
[3] 
https://wiki.documentfoundation.org/Development/Developers#License_Statements

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Problem in running make file on Ubuntu 16.04

[Kaganski Mike]

On 08.01.2019 10:44, Komal Bharadiya wrote:
> I have been trying to setup libreoffice dev-environment lately. After 
> executing ./autogen.sh file, I hit make command. The execution takes 
> ample amount of time. It hangs my laptop, and I end up switching it off. 
> I have tried multiple no. of times. But couldn't run it successfully, 
> what can I do? Please help!
> I have Dell Vostro 3568 model.
> Thanking you in anticipation!

https://wiki.documentfoundation.org/Development/BuildingOnLinux#Performance


> Building LibreOffice takes time, a lot of time. Exactly how much depends on 
> how powerful your machine is

Several lines below, there's "Approximate times" section, telling 
someone's experience with some unspecified repo revision, which took 1.5 
hrs. I can tell you that I used to have ~8 hrs build time on Kaveri 7700 
box with spinning HDD.

You should expect long build times on your laptop. But if you also are 
going to do other tasks on it during the build (to increase build times 
even more), then you may adjust it using --with-parallelism (discussed 
there), which defaults to use all your cores, but which you could want 
to set to a lower value to free some resources; or you may run make 
using nice (`nice make`) to decrease its priority and make system 
responsive to interaction without sacrificing cores.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: xpdfwrapper/pdfioutdev_gpl.hxx:227:22: error: ‘virtual void pdfi::PDFOutDev::drawString(GfxState*, const GooString*)’ marked ‘override’, but does not override

[Kaganski Mike]

On 14.01.2019 11:46, Stephan Bergmann wrote:
> On 13/01/2019 23:57, Дилян Палаузов wrote:
>> LO 6.0.7.3 fails compiling with gcc 8.2.1 20190101 I emitting:
>>
>> [build SPP] scp2/source/ooo/ure
>> [build SCP] scp2/source/writer/file_writer
>> [build SPP] scp2/source/xsltfilter/file_xsltfilter
>> [build SPP] scp2/source/xsltfilter/module_xsltfilter
>> [build SPP] scp2/source/gnome/file_gnome
>> [build SPP] scp2/source/gnome/module_gnome
>> [build SPP] scp2/source/sdkoo/sdkoo
>> [build SCP] scp2/source/writer/module_writer
>> [build CXX] sdext/source/pdfimport/xpdfwrapper/pnghelper.cxx
>> In file included from 
>> /src/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/pnghelper.hxx:24,
>>  
>>
>>   from 
>> /src/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/pnghelper.cxx:20:
>>  
>>
>> /src/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx:227:22:
>>  
>> error: ‘virtual void
>> pdfi::PDFOutDev::drawString(GfxState*, const GooString*)’ marked 
>> ‘override’, but does not override
>>   virtual void drawString(GfxState *state, const GooString *s) 
>> override;
>>    ^~
>> /src/libreoffice-6.0.7.3/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx:227:22:
>>  
>> warning:   by ‘virtual void
>> pdfi::PDFOutDev::drawString(GfxState*, const GooString*)’ 
>> [-Woverloaded-virtual]
>> make[1]: *** 
>> [/src/libreoffice-6.0.7.3/solenv/gbuild/LinkTarget.mk:293: 
>> /src/libreoffice-
> 
> You likely need a backport of 
> 
>  
> "fix build with poppler 0.64" (and maybe also backports of further 
> poppler-adaption fixes in that area), or configure 
> --without-system-poppler.
> 
> There is obviously always a chance that building old versions of LO 
> against current system components does not work.  Often enough, you will 
> find fixes for those issues in later versions of LO, and which are often 
> even easy to backport to the version where you need them.

I'm afraid that the message implies that the fix from spring 2018 is 
already there - the constness of the GooString parameter is there in the 
message. So possibly there's some problem detecting the poppler library 
version?

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: xpdfwrapper/pdfioutdev_gpl.hxx:227:22: error: ‘virtual void pdfi::PDFOutDev::drawString(GfxState*, const GooString*)’ marked ‘override’, but does not override

[Kaganski Mike]

Hi!

On 15.01.2019 1:40, Дилян Палаузов wrote:
> Hello,
> 
> the LO source code requires const GooString*, but the 
> /usr/local/include/poppler/OutputDev.h file had no const in the
> declaration of drawString.  The installed poppler was newer than 0.64.0.
> 
> The hack is, that in the past I installed poppler and it installed 
> OutputDev.h .  When I later compiled newer version of
> poppler I have not passed ENABLE_XPDF_HEADERS / 
> ENABLE_UNSTABLE_API_ABI_HEADERS to cmake and in turn “make install” has
> not overwritten /usr/local/include/poppler/OutputDev.h.  This led to a 
> situation with new libpoppler and old OutputDev.h
> without const.  Indeed override triggered correctly.
> 
> --without-system-poppler mitigates.

All current LibreOffice branches, including 6-0-7, have the patch 
mentioned by Stephan previously. You may see the source here:

https://cgit.freedesktop.org/libreoffice/core/tree/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx?h=libreoffice-6-0-7

and the commit to 6-1 here:

https://cgit.freedesktop.org/libreoffice/core/commit?id=106b2c96e9807af14d6eb6e8f83dcf25095a093e

The commit conditionally makes the parameter const when reported poppler 
is 0.64 or newer, following the poppler change "Add const to several 
classes and members" (see 
https://poppler.freedesktop.org/releases.html). Poppler 0.64 and newer 
does have the const in the declaration of drawString - you may check its 
source code at 
https://cgit.freedesktop.org/poppler/poppler/tree/poppler/OutputDev.h?h=poppler-0.64.0,
 
and the commit is 
https://cgit.freedesktop.org/poppler/poppler/commit/poppler/OutputDev.h?h=poppler-0.64.0&id=c4af5981ab2a5f42a9a1194bb5929c2151fc2674.

So the problem in your situation is most likely that you have messed up 
with the mix of new and old headers and library.

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice