from:"Alexander"

Thanks Michael, much appreciated !

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

Re: LO Community ex Vanilla and user expectations, impact and other points.



Further to this discussion a concrete example of where this confusion is
likely to lead :

I've just reported bug 141830.

Bug not reproducible in :

Version: 7.1.2.2 / LibreOffice Community
Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded


Bug present in :

Version: 7.1.2.3 / LibreOffice Community
Build ID: a393d9064b7eb849da7f488ab43f56a404be32ae
CPU threads: 8; OS: Mac OS X 11.2.3; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded
This is the currently released version of LO Vanilla (installed this
morning via AppStore).


How is a QAer (other than myself as the original reporter) attempting to
triage going to be able to tell which version of LO we are talking about
here ? Both products have "Community" in the infobox.

How will a user know what the difference is when asked ?


Alex


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

Re: LO Community ex Vanilla and user expectations, impact and other points.

Le 22/04/2021 à 11:25, Michael Meeks a écrit :

Hi Michael,


> 
>   This is a fairly fundamental limitation of the app-store I'm afraid;
> and it is regrettable indeed.
>> However, this version now points directly to the LibreOffice website,
>> and I feel that user expectations are being somewhat misled, due to the
>> missing functionality.


Yes, I understand that, although it was also my understanding that it
is/was still possible to provide a complete JDK into the app that could
then be accepted into the AppStore. I also understand that that might
require significant effort from Collabora to do so, and that perhaps
from a business point of view, it is not a route that it wishes to go down.

Additionally, from a wider project view, it might also set a precedent
with regard to other OSes for which LO doesn't bundle the JDK (for a
number of equally valid reasons).

> 
>   Is there somewhere better we can point ? for example, if you could
> control that landing page (which is easy) where would you have it land?
> Can we make a better page that doesn't confuse people and explains how
> they can download the TDF version and an OpenJDK to get better 'Base'
> support?
> 

My suggestion would be to have it point to a Collabora page, after all
it is a Collabora product, which page would direct the user to the
LibreOffice project as the source for any questions, documentation, etc,
and additionally, should the user feel so inclined in order to obtain
the missing functionality, to the download site of the TDF release.

Personally, I would find it helpful if the pros/cons of each were
identified on such a page. That way, the user makes their choice in full
knowledge.

For example, the AppStore blurb text doesn't mention that LO Vanilla
includes multiple language support - this is a huge positive for many
people compared to the TDF downloads which require separate langpack
installations and their associated issues.

On the negative side, of course, the absence of any Java functionality,
but also what that entails in terms of functional limitation. The
current note in brackets at the end of the AppStore text is somewhat
light on the implications of the lack of Java, stating that it only
affects usage of the HSQLDB embedded engine, when in reality the extent
is far greater.

The landing page pointed to by the banner could explain those
differences in more detail, e.g. :

- no Java-based database connectivity whatsoever, so no JDBC connections
to any DB engine reliant on JDBC drivers - considering the broad range
of JDBC drivers available, this is by far one of the most common ways of
connecting to a backend database engine ;

- no database reporting engine (jfreereport) ;

- no beanshell or Javascript support

- no Java extension support (e.g. LanguageTool)


Are these suggestions of any use ?

Alex










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

LO Community ex Vanilla and user expectations, impact and other points.

Hi all,

Apologies if this has already been debated somewhere and I've missed it
(probably), but I have just received an update for LO Vanilla through
the Apple AppStore, and I noticed that the StartCenter now carries a
banner/sticker inscribed "LibreOffice Community" in the bottom lefthand
corner, which is an active link pointing to

https://www.libreoffice.org/)

As a QA triager, I am somewhat confused as to the message being sent out
here.

As we know, the "community" version provided by Collabora doesn't have
the same functionality as the TDF download (e.g. no Java support,
therefore no hsqldb support, no reportbuilder, etc).

However, this version now points directly to the LibreOffice website,
and I feel that user expectations are being somewhat misled, due to the
missing functionality.

Users who click on the link will land on the LibreOffice landing page
and look for help (e.g. Ask, or the documentation section) where they
will see that Java functionality is supposed to be supported, and my
concern is that once a user realizes that a deliberate confusion has
been entertained, it will probably be too late.

The user in question will by now almost certainly have dismissed LO as
not up to scratch, and will probably fail to understand why they should
now go and install a different app with a confusingly similar name, and
unauthenticated to boot, outside of the AppStore.

My takeaway from this confusion is unfortunately all rather negative,
and ultimately my concern is that the confusion will lead to the "by
default" replacement of desktop LO on the Mac by "LO Vanilla/Community"
with ensuing loss of functionality, driven by one actor of the LO
community in its broadest sense, and which the LO project will have at
worst underwritten, at best implictly condoned.

I also feel somewhat uncomfortable with providing help for a product
that maintains this duplicity.

Unfortunately, I don't really have any better suggestions on how to
manage this, but for me, willingly confusing users is not the way forward.

I am as yet undecided on whether I would wish to maintain my
contribution to the project in the current environment. Clearly, I have
some thinking still to do in that regard.


Alex



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

Re: About tdf#138715 and future of Thunderbird address book support

2021-04-21 Thread Alexander Thurgood

Le 10/12/2020 à 10:38, Tor Lillqvist a écrit :
> My recommendation would be to just drop the Thunderbird address book
> driver without any replacement.
> 


I would be interested to know what replacement would be suggested instead ?


Currently, if I take macOS as my example, LO enters a crash/recovery
loop anytime any function execution in a macab connected ODB is
attempted (bug 126961).

ODBC connections are also broken (bug 138990).

Sure, macOS has built-in OS-provided sqlite3, but currently no way to
use it from within LO.

Currently, there is no way to create any sort of ODB file connecting to
one of the main addressbook formats (either native OS, or multi-OS) for
the macOS system.


Just my ha'penneth.

Alex


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

Re: About building on Apple Silicon M1

2021-04-21 Thread Alexander Thurgood



Le 16/04/2021 à 08:42, Stephan Bergmann a écrit :

> Apart from that, things just work (thanks to Tor, mostly).
> 

How about Firebird support ? Does that build / is it functional yet ?


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

Re: About MacOs future with ARM

2020-06-24 Thread Alexander Thurgood

Le 24/06/2020 à 12:15, julien2412 a écrit :


Hi Julien,

Good questions IMHO.

From what I read yesterday, Apple would propose a "Rosetta 2" on-the-fly
byte-code conversion environment to allow programs compiled for x86
hardware to continue running for a while at least to ease the transition.

For those of us having been (un)fortunate or old enough to have lived
through the first iteration of Rosetta, when Apple transitioned from PPC
to x86 they will know that performance will take a significant hit,
memory consumption will likely go through the roof, and that some stuff
just won't work...depending on how well Apple implements Rosetta 2.

Then comes the question of whether, indeed, the project has the
resources to provide 2 ongoing versions of LO for macOS for 2 different
chip architectures...

Will be interesting to see how this evolves.

Alex


> Hello,
> 
> I noticed that Apple will sell machines with homemade ARM processors in a
> quite near future see
> https://www.news1.news/en/2020/06/mac-with-apple-silicon-processors-the-complete-guide.html
> 
> I thought it could be interesting to add this subject in ESC, so these
> points may be discussed for example:
> - do we want to keep on proposing Mac version ?
> If no, quite simple, we can purge some code in LO basecode.
> If yes:
> - are we prepared for this transition? (perhaps it'll need full Cocoa
> framework use, I haven't read the impacts yet)
> - have we got enough devs for this?
> - budget to buy future Mac with ARM ?
> - propose during some time (perhaps 3-4 years) 2 LO releases for Mac : Intel
> and ARM
> - TB and Jenkins machine with Mac ARMs?
> - impact on all external libs, old ones like HSQLDB may bring some problems
> (since we're stuck with version 1.8)
> 
> It seems Cupertino guys will help some projects like SKIA, see:
> https://www.macg.co/macos/2020/06/arm-apple-facilite-la-transition-de-plusieurs-projets-open-source-114881
> (sorry French source, didn't find English source)
> 
> Perhaps it's too early to talk about it, perhaps there's no big deal, ...
> I got no expertise here and no opinion here, just wanted to spotlight this
> subject.
> 
> Any thoughts here?
> 
> Julien
> 
> 
> 
> --
> Sent from: 
> http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
> 

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

Re: Compiling LO on macOS using lode - yasm and nasm not found

2020-05-13 Thread Alexander Thurgood

Le 13/05/2020 à 22:55, Eivind Samseth a écrit :

Hi Eivind,

> The BuildingOnMac page doesn’t reference yasm or nasm at all, not sure if it 
> rather should be included in the packages the lode environment sets up?
> 

It doesn't matter, the build should complete anyway without them. It
does on my macMini, and I get those warnings too.


Alex

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

Re: About LO and ODBC

2020-04-28 Thread Alexander Thurgood

Le 28/04/2020 à 15:02, Julien Nabet a écrit :

Hi Julien,


> Would you be ok to remove and replace deprecated functions from ODBC <
> 3.0 or do you think about some cons?
> 

I would have thought / hoped that by now, no one working with LO over
ODBC is using any ODBC driver stuff that calls purely into the ODBC2 API
(or are they) ?

I would also hope that we do not rely on, rather than optionally
fallback support, ODBC2 or older implementations in any way within our
own code (having said that, some of the Base code goes back more than 20
years, so possible) ?


Otherwise, if it is killing useless deadweight cruft, put it up there on
the wishlist of things to do away with ;-)


Alex

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

[Libreoffice-commits] core.git: Branch 'libreoffice-6-4' - vcl/qt5

2020-04-19 Thread Alexander Volkov (via logerrit)

 vcl/qt5/Qt5FilePicker.cxx |5 +
 1 file changed, 5 insertions(+)

New commits:
commit 0f025b702a1964c429ab670c9b8aee8636d209b2
Author: Alexander Volkov 
AuthorDate: Thu Apr 9 17:08:03 2020 +0300
Commit: Michael Weghorn 
CommitDate: Mon Apr 20 08:03:31 2020 +0200

Qt5 implement DELETE_ITEMS action in file picker

It is used to clear "Version" listbox before adding new items.

Change-Id: I4cb9557c8f56d80c1dfac68dc2b5b45b5c69c2f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91982
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski 
(cherry picked from commit 3a22be0178b950ab3d21eadab2bc34e7ea93eec8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92174
Reviewed-by: Michael Weghorn 

diff --git a/vcl/qt5/Qt5FilePicker.cxx b/vcl/qt5/Qt5FilePicker.cxx
index d37c28b33c11..d648a5d94b75 100644
--- a/vcl/qt5/Qt5FilePicker.cxx
+++ b/vcl/qt5/Qt5FilePicker.cxx
@@ -431,6 +431,11 @@ void Qt5FilePicker::handleSetListValue(QComboBox* pWidget, 
sal_Int16 nControlAct
 pWidget->removeItem(nPos);
 break;
 }
+case ControlActions::DELETE_ITEMS:
+{
+pWidget->clear();
+break;
+}
 case ControlActions::SET_SELECT_ITEM:
 {
 sal_Int32 nPos = 0;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] core.git: vcl/qt5

2020-04-14 Thread Alexander Volkov (via logerrit)

 vcl/qt5/Qt5FilePicker.cxx |5 +
 1 file changed, 5 insertions(+)

New commits:
commit 3a22be0178b950ab3d21eadab2bc34e7ea93eec8
Author: Alexander Volkov 
AuthorDate: Thu Apr 9 17:08:03 2020 +0300
Commit: Jan-Marek Glogowski 
CommitDate: Tue Apr 14 19:35:51 2020 +0200

Qt5 implement DELETE_ITEMS action in file picker

It is used to clear "Version" listbox before adding new items.

Change-Id: I4cb9557c8f56d80c1dfac68dc2b5b45b5c69c2f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91982
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski 

diff --git a/vcl/qt5/Qt5FilePicker.cxx b/vcl/qt5/Qt5FilePicker.cxx
index d37c28b33c11..d648a5d94b75 100644
--- a/vcl/qt5/Qt5FilePicker.cxx
+++ b/vcl/qt5/Qt5FilePicker.cxx
@@ -431,6 +431,11 @@ void Qt5FilePicker::handleSetListValue(QComboBox* pWidget, 
sal_Int16 nControlAct
 pWidget->removeItem(nPos);
 break;
 }
+case ControlActions::DELETE_ITEMS:
+{
+pWidget->clear();
+break;
+}
 case ControlActions::SET_SELECT_ITEM:
 {
 sal_Int32 nPos = 0;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: remove attribute table:cell-range-address at element in ODF 1.4

2020-04-01 Thread Alexander Thurgood

Le 31/03/2020 à 16:56, Regina Henschel a écrit :

Hi Regina,


> Does anyone know, whether there exists a scenario (besides sx* import
> filter) where it makes a difference for LibreOffice, whether the
> attribute exists or not?
> 


I don't know whether this is the case, but would Charts in Base Reports
be concerned ?


Alex

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

[LOK] Rendering spreadsheets, threaded rendering

2020-03-06 Thread Alexander Komakhin

Hi,

I'm developing document viewer for corporate mobile OS Aurora. It's
Linux based(kernel 3.10.49), gcc is 4.9.4, LO 6.1.6.3

Using paintPartTile to render separate lists of XLS document draws an
area of empty cells near the content itself, can I somehow tell LO to
"ensure only data visible"? Also, rendering such big area takes a lot
of time (using mobile device).

Btw, are functions paint*Tile reentrant? Can I call them from separate
threads?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Randomnes in LibreOffice Encryption

2019-12-10 Thread Alexander Thurgood

Le 10/12/2019 à 14:57, Steve Martin a écrit :

Steve,

If you haven't already read this, it might be helpful :

http://ringlord.com/dl/Decrypting%20ODF%20Files.odt


Alex

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

Re: ESC meeting minutes: 2019-11-07 - macOS 10.15 notarization

2019-12-02 Thread Alexander Thurgood

Le 02/12/2019 à 17:20, William Gathoye (LibreOffice) a écrit :

Hi William,


> I'm jumping on this "notarization" problem. Do we have any news to share
> about this topic?

There is a potential workaround which requires the adminstrator (in most
cases, this is the main user of the Mac anyway), to specifically grant
full disk access to the LibreOffice app bundle, via :

System Preferences > Security and Confidentiality > Allow Full Disk
Access > then add the LibreOffice app to the list.

Obviously, most users will be loathe to actually do this as it
specifically removes the protections around the jailed/containered
"secure" application environment that Apple expects users (and
application providers) to abide by.

As to whether something is being considered from a coding point of view
to resolve the problem, I have no idea.


Alex

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

Re: MacOS build issue

2019-11-14 Thread Alexander Thurgood

Le 14/11/2019 à 17:54, Michael Stahl a écrit :

I don't see any of these errors (which isn't of much help, admittedly)
when building on Catalina from a zsh shell, but then I'm not using LODE.

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

Re: About putting back Firebird experimental

2019-09-04 Thread Alexander Thurgood

Le 22/08/2019 à 12:12, Jean-Pierre Ledure a écrit :

Hi all,

> (3) the limits are different: e.g. VARCHAR max. length is < 2Gb in
> Hsqldb and  < 32K in Firebird, the max. length of a table row is < 2Gb
> in Firebird and <64K in Firebird, the max. length of a column name is
> 128B in Hsqldb and 31B in Firebird.
> 

And therein lies the problem, we have substituted the default db engine
for one that is less, or depending on how you look at it, otherwise
capable, in many respects...without providing the means for users of the
existing one to have their data survive the transition, or rather, we
let them believe that it will survive, and then fail at the task.

I feel we would do well to remember that this is people's live and
valuable data we are potentially messing with here, and not all of these
users are DBAs, in fact rather the contrary. It matters not a jot that
db engine XYZ can outperform db engine ABC under circumstance PQR if the
data that the user originally had gets screwed up, or if the yearbook,
contacts with photos, or multilingual accounts DB they were running no
longer functions correctly, or at all, they won't forgive us for it.

And yes, I appreciate that at some stage, a decision on whether we have
reached a sufficiently advanced stage of conversion therapy will need to
be taken and acted upon. The question then is what level of
success/failure is deemed acceptable ?


Alex

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

Re: About putting back Firebird experimental

2019-08-20 Thread Alexander Thurgood

Le 20/08/2019 à 10:28, Julien a écrit :

Hi Julien,

+1 from me.

As a QA triager, I can but agree with Julien given the current stage of
development. The migration code still fails to handle multiple, basic
elements of embedded hsqldb ODB files found in actual use. If it can't
even do the basics of migration properly, what hope do we have of
convincing users to switch ?

Forcing users to be the unwitting testers (as is currently perceived to
be the case - indeed, I saw such a recrimination in a migration bug
report I dealt with today) of such a system is bound to provoke at best
apathy or resignation, at worst anger, frustration and searching for
another tool that won't trash your data.


Clearly, the work required for the tender by TDF was underestimated. I
see this currently as a kind of unwanted offspring, neither here, nor
there, and certainly not fit for purpose, despite all of the very good
work put in.

Anyway, my 2c as usual.

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

Re: vcl_pdfexport test failing on master with MacOS

2019-07-26 Thread Alexander Thurgood

Le 22/07/2019 à 17:58, Alexander Thurgood a écrit :


FWIW, I opened a bug report about this in bug 126559.

Alex




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

Re: vcl_pdfexport test failing on master with MacOS

2019-07-22 Thread Alexander Thurgood

Le 22/07/2019 à 17:18, Jan-Marek Glogowski a écrit :

Thanks for your input, I'll just have to try and disable them.

FWIW, there have been no daily master builds available from the daily
builds repo for MacOS at least since May 23rd, 2019, and it seems that
the other dailies (6.2/6.3) are also unavailable from around the same date.

The last master dailies successfully released for Linux date back to
11/07/2019, so something isn't working quite right in the LO
infrastructure somewhere


Alex




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

vcl_pdfexport test failing on master with MacOS

2019-07-22 Thread Alexander Thurgood

Hi all,

Anyone else experiencing the same problem ?

As from today, or at earliest from Thurs or Fri last week, I keep
getting a build failure (debug enabled build) on master on MacOS with
the vcl_pdfexport.text:

pdfexport.cxx:415 : Assertion
Test name : (anonymous namespace)::PdfExportTest::testTdf107868
equality assertion failed
Expected : 0
Actual : 4



pdfexport.cxx:668 (anonymous namespace)::PdfExportTest:testSoftHyphenPos
double equality assertion failed
Expected : 11.05
Actual : 1
Delta: 1e-06

This is currently preventing the build from progressing as it keeps
cropping up repeatedly.


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

Re: Base without HSQL support?

2019-06-06 Thread Alexander Thurgood

Le 06/06/2019 à 00:00, Drew Jensen a écrit :

For my 2c :

> Right now if the ODB file with HSQL does not have any of the following
> data types, decimal, numeric, Image(Blob), Date, Time or TIMESTAMP, the
> data transfer will succeed. How many odb files would have one or more of
> those IDK but guessing it would be a fair percentage. 
> 

In other words, and this may seem harsh, the migration assistant is
pretty much useless for the majority of embedded hsqldb ODBs out there
in real-world actual daily use.

I would also add that every single table bar three (Customers,
Suppliers, Categories) we currently propose through the table creation
wizard in the Business category, has at least one of those fields, which
means that if people have used them in the past to create embedded
hsqldb files, they are all pretty much likely to fail on migration in
one way or another. I haven't checked the Personal category list of
tables, but I imagine it is a similar story.

> Here is the real problem though, imo, right now with 6.3 if you try to
> import any external source into decimal and numeric fields with Firebird
> there is an issue. If you drag drop a table from any Base file type or
> from Calc or import a text file as CSV. The Date, time, TIMESTAMP and
> Boolean fields in Firebird also have some issues with the those Import
> Wizard functions, but less extreme in that the import function is more
> restrictive on what is recognized as valid input compared to the Import
> Wizard when using the HSQL sdbc. 

In addition to what Drew outlines above, correct UTF and collation
support need to be guaranteed for all those who don't use ASCII English
in their DBs. We too often have a habit of forgetting that there are DB
users outside of the anglophone sphere, and their migration concerns are
just as valid.


Alex

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

[Libreoffice-commits] core.git: vcl/source

2019-04-09 Thread Alexander Farrow (via logerrit)

 vcl/source/gdi/CommonSalLayout.cxx |2 +-
 vcl/source/gdi/sallayout.cxx   |   10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

New commits:
commit a39f2e1943c7092dd32bd1f4e480ee6da54a80e4
Author: Alexander Farrow 
AuthorDate: Mon Apr 8 18:54:20 2019 +0100
Commit: Noel Grandin 
CommitDate: Tue Apr 9 09:10:22 2019 +0200

tdf#103322 GlyphItem::m_aLinearPos use getX() instead of X()

GlyphItem::m_aLinearPos is a tools::Point variable.
Eventually it will be changed to a basegfx::B2DPoint variable - to add 
support
for sub pixel glyph positioning.

basegfx::B2DPoint has the getX() method to retrieve a point's X coordinate.

tools::Point has two methods to retrieve a point's X coordinate:
1. X()
2. getX()
Both of these methods return the same value because getX() just calls X().
So any call to X() can replaced by getX() and vice versa.

By replacing calls to X() with getX() now we won't have to make these 
changes
later when we swap from tools::Point to basegfx::B2DPoint.

Change-Id: Idfa0584cb3a7ce246b5499814b7e29f86167d8b8
Reviewed-on: https://gerrit.libreoffice.org/70436
Tested-by: Jenkins
Reviewed-by: Noel Grandin 

diff --git a/vcl/source/gdi/CommonSalLayout.cxx 
b/vcl/source/gdi/CommonSalLayout.cxx
index 6187ec6fed5c..872603228508 100644
--- a/vcl/source/gdi/CommonSalLayout.cxx
+++ b/vcl/source/gdi/CommonSalLayout.cxx
@@ -767,7 +767,7 @@ void GenericSalLayout::ApplyDXArray(const ImplLayoutArgs& 
rArgs)
 nOverlap = nExcess / (nCopies - 1);
 }
 
-Point aPos(pGlyphIter->m_aLinearPos.X() - nTotalWidth, 0);
+Point aPos(pGlyphIter->m_aLinearPos.getX() - nTotalWidth, 0);
 int nCharPos = pGlyphIter->m_nCharPos;
 int const nFlags = GlyphItem::IS_IN_CLUSTER | 
GlyphItem::IS_RTL_GLYPH;
 while (nCopies--)
diff --git a/vcl/source/gdi/sallayout.cxx b/vcl/source/gdi/sallayout.cxx
index 9b665674d999..fc0a765e2af7 100644
--- a/vcl/source/gdi/sallayout.cxx
+++ b/vcl/source/gdi/sallayout.cxx
@@ -712,7 +712,7 @@ DeviceCoordinate GenericSalLayout::GetTextWidth() const
 for (auto const& aGlyphItem : *m_GlyphItems.Impl())
 {
 // update the text extent with the glyph extent
-DeviceCoordinate nXPos = aGlyphItem.m_aLinearPos.X();
+DeviceCoordinate nXPos = aGlyphItem.m_aLinearPos.getX();
 if( nMinPos > nXPos )
 nMinPos = nXPos;
 nXPos += aGlyphItem.m_nNewWidth - aGlyphItem.m_nXOffset;
@@ -789,14 +789,14 @@ void GenericSalLayout::Justify( DeviceCoordinate 
nNewWidth )
 {
 for( pGlyphIter = m_GlyphItems.Impl()->begin(); ++pGlyphIter != 
pGlyphIterRight;)
 {
-int nX = pGlyphIter->m_aLinearPos.X();
+int nX = pGlyphIter->m_aLinearPos.getX();
 nX = static_cast(nX * fSqueeze);
 pGlyphIter->m_aLinearPos.setX( nX );
 }
 }
 // adjust glyph widths to new positions
 for( pGlyphIter = m_GlyphItems.Impl()->begin(); pGlyphIter != 
pGlyphIterRight; ++pGlyphIter )
-pGlyphIter->m_nNewWidth = pGlyphIter[1].m_aLinearPos.X() - 
pGlyphIter[0].m_aLinearPos.X();
+pGlyphIter->m_nNewWidth = pGlyphIter[1].m_aLinearPos.getX() - 
pGlyphIter[0].m_aLinearPos.getX();
 }
 }
 
@@ -850,7 +850,7 @@ void GenericSalLayout::GetCaretPositions( int nMaxIndex, 
long* pCaretXArray ) co
 // calculate caret positions using glyph array
 for (auto const& aGlyphItem : *m_GlyphItems.Impl())
 {
-long nXPos = aGlyphItem.m_aLinearPos.X();
+long nXPos = aGlyphItem.m_aLinearPos.getX();
 long nXRight = nXPos + aGlyphItem.m_nOrigWidth;
 int n = aGlyphItem.m_nCharPos;
 int nCurrIdx = 2 * (n - mnMinCharPos);
@@ -943,7 +943,7 @@ void GenericSalLayout::MoveGlyph( int nStart, long nNewXPos 
)
 if( pGlyphIter->IsRTLGlyph() )
 nNewXPos += pGlyphIter->m_nNewWidth - pGlyphIter->m_nOrigWidth;
 // calculate the x-offset to the old position
-long nXDelta = nNewXPos - pGlyphIter->m_aLinearPos.X();
+long nXDelta = nNewXPos - pGlyphIter->m_aLinearPos.getX();
 // adjust all following glyph positions if needed
 if( nXDelta != 0 )
 {
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: Add AdjustX method to basegfx::B2DPoint

2019-04-08 Thread Alexander Farrow

Hi Noel,

Noel Grandin wrote:
>Are we going to be doing this behind the
>   VCL_FLOAT_DEVICE_PIXEL
>define and using the DeviceCoordinate typedef ?

I'm assuming your referring to my recent patch:
https://gerrit.libreoffice.org/#/c/70329/ 

That's a good point, do you mean doing something like:
#if VCL_FLOAT_DEVICE_PIXEL
    B2DPoint aCurrPos(0.0, 0.0);
#else
    B2IPoint aCurrPos(0, 0);
#endif

>(as a side note I had no idea we had this enabled on mac and ios already)

That's interesting, I didn't know that. I've OpenGrok searched the code for
where we are doing this but I couldn't find it. I found line 10247 in
configure.ac, which looks related:
https://opengrok.libreoffice.org/xref/core/configure.ac?r=c51b68dd#10247 

But it's commented out (line starts with dnl).

With many thanks,
Alex
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

2019-04-08 Thread Alexander Farrow

Hi Mike,

Kaganski Mike wrote:
>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.

Not a problem, apologies for the confusion.


>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.

Awesome, thanks in advance for your help.

- Alex

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

Re: Add AdjustX method to basegfx::B2DPoint

2019-04-08 Thread Alexander Farrow

Hi Thorsten,

Thanks for your reply.

Thorsten Behrens wrote:
>tools::Point is not exactly a role model for a nicely designed class,
>so I'd hesitate to take any literal bits out of that. ;)

Good to know, I'm new to the codebase so I'll keep that in mind.

>Many places using AdjustX() also call AdjustY() just the next line, so
>for that you could use basegfx::B2DPoint::operator+=(const B2DTuple&)

Sure but there are occasions in the code where we are just modifying
a single coordinate. My recent patch is an example:
https://gerrit.libreoffice.org/#/c/70329/ 

>If you believe you *must* use a single-component modifier

A single-component modifier isn't a must but it might be nice for
when we are only changing one coordinate.

> please come up with something that blends well with the b2dtuple/point
>concept. Also ideally, you will maintain some amount of internal
>consistency (e.g. compare how operator*, *= etc. all got added in
>farious flavours, such that math with b2dtuples works like the
>'canonical' way when done with skalars or various forms of vectors).

If we do decide to go ahead with this I'll be sure to follow your
implementation requirements.

With many thanks,
Alex
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Add AdjustX method to basegfx::B2DPoint

2019-04-05 Thread Alexander Farrow

Hi everybody,

Recently for GSoC I have been looking into resolving
"Use floating point for glyph positioning in VCL" 
<https://bugs.documentfoundation.org/show_bug.cgi?id=103322>

This involves changing the types of variables from tools::Point to 
basegfx::B2DPoint.
tools::Point <https://docs.libreoffice.org/tools/html/classPoint.html> has a 
method called AdjustX(long nHorzMove), which adds nHorzMove to X:

basegfx::B2DPoint 
<https://docs.libreoffice.org/basegfx/html/classbasegfx_1_1B2DPoint.html> does 
not have such a method. So calls to AdjustX(nHorzMove) are
being replaced by something like setX(getX() + nHorzMove).

It works fine of course but I think AdjustX looks cleaner and it feels like a 
step
backwards when moving from tools::Point to basegfx::B2DPoint.

An OpenGrok search 
<https://opengrok.libreoffice.org/search?project=core&refs=AdjustX> for AdjustX 
reveals it is used frequently in the code-base,
which suggests it is a method which developers have found useful in the past.

If it is agreed that we should add such a method I would be happy to implement 
it.
Also for consistency we might want to add a similar method to other classes in
basegfx such as B2IPoint.

With many thanks,
Alexander Farrow (IRC: Alexander Farrow)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: doxygen: Illegal command n as part of a title section

2019-04-05 Thread Alexander Thurgood

Le 05/04/2019 à 11:50, himajin10 a écrit :

Hi,

> Hello, himajin10 here!
> 
> When I build LibreOffice locally, I often get just a bit upset because
> of the following warnings. Less warning will give me less stress :-)
> 

FWIW, I also see these when building on macOS, but have never gotten
around to checking whether it causes an issue in the API documentation.

Alex


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

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

2019-04-04 Thread Alexander Farrow

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.

    There is also https://gerrit.libreoffice.org/#/c/62219 


    Interesting post for a different problem with the same solution: 
Getting real
    linearly-scalable text
    (https://lists.cairographics.org/archives/cairo/2008-May/014149.html 
)
    But it's also 10 years old...

    The image link still works and show the (potentially long fixed?) 
problem
    https://www.flickr.com/photos/behdad/2493693932/sizes/o 


    Then there is
    
https://www.unicodeconference.org/presentations/S5T2-Röttsches-Esfahbod.pdf 

    - that's from 2016.
    It's not about positioning, but a nice overview of Chromes text 
rendering
    evolution, as Behdad Esfahbod is working for Google for quite some time.

Thanks for the links, I'll give them a read through. Any resources regarding 
text
rendering are greatly appreciated.

I've continued familiarising myself with the text layout code and I've got a 
couple
of simple patches to submit for review. I've finished looking into how to change
GlyphItem to use floating point values for glyph positioning and I'm now looking
into how to change DeviceCoordinate from a long to a double.

I think to move forward with the project the next step is to get the proposal 
finished
and submitted. I've got the first draft ready and although it is a WIP I was 
wondering
if I could send it to you for some feedback?

I look forward to working with you on this project.

Thanks,
Alex (IRC: AlexanderFarrow)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Subpixel glyph positioning - Looking for a mentor

2019-03-29 Thread Alexander Farrow

For GSoC 2019 I would love to work on the "Sub-pixel and stable glyph 
positioning" project from the
list of ideas without a mentor:
https://bugs.documentfoundation.org/show_bug.cgi?id=103322 
<https://bugs.documentfoundation.org/show_bug.cgi?id=103322>

I'm particularly interested in this project as I experience poor glyph 
positioning quite often as a
LibreOffice user.

To achieve the required skills for this project I read the "State of text 
rendering" paper  by Behdad
Esfahbod to further my understanding of text rendering. I've also followed the 
HarfBuzz tutorial to
develop a primitive text rendering program.

I've been familiarising myself with the LibreOffice text rendering code 
particularly CommonSalLayout.
I've written a very small patch for this file, changing a variable from 
tools::Point to basegfx::B2DPoint
to add support for floating point values.

I've followed the Bugzilla comments and I'm now looking into what changes will 
need to be made
throughout the code-base to store the glyph positions in a floating point 
variable. Specifically, I'm
currently looking into how to make the following code changes:

1. DeviceCoordinate -  Change from a long to a double.
2. GlyphItem - Change m_aLinearPos from tools::Point to basegfx::B2DPoint. 
Change m_nOrigWidth
from an int to a double. Change m_nXOffset from an int to a double.

I am hoping that somebody would like to be my mentor for this project.

With many thanks,
Alexander Farrow (IRC: AlexanderFarrow)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

cppunittest crashes building dbaccess_hsqldb

2019-03-28 Thread Alexander Thurgood

Hi all,

I am getting repeat crashes in cppunittest when attempting to build
dbaccess_hsqldb from master on macOS.

I opened a bug report and enclosed a trace :

https://bugs.documentfoundation.org/show_bug.cgi?id=124374

but Xisco suggested I raise it here instead.

Unfortunately, this stops the LO build from completing at the moment.



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

[Libreoffice-commits] core.git: filter/uiconfig

2019-03-22 Thread Alexander Farrow (via logerrit)

 filter/uiconfig/ui/xmlfiltersettings.ui |  220 +---
 1 file changed, 120 insertions(+), 100 deletions(-)

New commits:
commit f8251c40b4c512b6ea54ea2207a3816d8b925711
Author: Alexander Farrow 
AuthorDate: Tue Mar 19 18:44:23 2019 +
Commit: Adolfo Jayme Barrientos 
CommitDate: Sat Mar 23 07:18:50 2019 +0100

tdf#123937 XML Filter Settings Dialog: Move "help" and "close" buttons

Move the "help" and "close" buttons to the bottom of the dialog.
The "help" button will be at the bottom left.
The "close" button will be at the bottom right.

Change-Id: I496a3c95dd4761d8a360ad85fc5af03d0c53f131
Reviewed-on: https://gerrit.libreoffice.org/69468
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos 

diff --git a/filter/uiconfig/ui/xmlfiltersettings.ui 
b/filter/uiconfig/ui/xmlfiltersettings.ui
index 9425b2187a70..2161e87a12e7 100644
--- a/filter/uiconfig/ui/xmlfiltersettings.ui
+++ b/filter/uiconfig/ui/xmlfiltersettings.ui
@@ -12,97 +12,12 @@
 
   
 False
+vertical
 12
 
   
 False
-vertical
-True
-start
-
-  
-_New...
-True
-True
-True
-True
-  
-  
-False
-True
-0
-  
-
-
-  
-_Edit...
-True
-True
-True
-True
-  
-  
-False
-True
-1
-  
-
-
-  
-_Test XSLTs...
-True
-True
-True
-True
-  
-  
-False
-True
-2
-  
-
-
-  
-_Delete...
-True
-True
-True
-True
-  
-  
-False
-True
-3
-  
-
-
-  
-_Save as Package...
-True
-True
-True
-True
-  
-  
-False
-True
-4
-  
-
-
-  
-_Open Package...
-True
-True
-True
-True
-  
-  
-False
-True
-5
-  
-
+end
 
   
 gtk-help
@@ -114,7 +29,8 @@
   
 False
 True
-6
+0
+True
   
 
 
@@ -130,7 +46,7 @@
   
 False
 True
-8
+1
   
 
   
@@ -142,14 +58,124 @@
   
 
 
-  
-100
+  
 True
 False
-
-  
-XML Filter List
+12
+
+  
+100
+True
+False
+
+  
+XML Filter 
List
+  
+
   
+  
+True
+True
+0
+  
+
+
+  
+True
+False
+vertical
+True
+start
+
+  
+_New...
+True
+True
+True
+True
+  
+  
+False
+True
+0
+  
+
+
+  
+_Edit...
+True
+True
+True
+True
+  
+  
+False
+True
+1
+  
+
+
+  
+_Test XSLTs...
+True
+True
+True
+True
+  
+  
+False
+True
+2
+  
+
+

GSoC 2019 Applicant Introduction

2019-03-22 Thread Alexander Farrow

Hi everybody,

I'm Alexander Farrow and I'm very keen to to work with LibreOffice for GSoC 
2019, having been a LibreOffice user since its initial release.

I study Computer Science and Mathematics at Queen Mary, University of London. 
I've submitted my first EasyHack patch ( 
https://gerrit.libreoffice.org/#/c/69468/ 
<https://gerrit.libreoffice.org/#/c/69468/> )  and I will start working on 
another one soon. 

- Alexander Farrow (IRC Nick: AlexanderFarrow)


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

Alexander Farrow license statement

2019-03-22 Thread Alexander Farrow

All of my past & future contributions to LibreOffice may be licensed under the 
MPLv2/LGPLv3+ dual license.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: MacOS Python: how to install additional packages

2018-12-07 Thread Alexander Thurgood

Le 06/12/2018 à 07:35, Jens Tröger a écrit :

This is issue has come up before, if not here, then at least probably on
the user mailing list. I too am interested in a solution, but currently
don't have one (having tried like you to import modules in the past,
failed, and rapidly given up).

My understanding was that this is an as yet unresolved problem in which
nobody has a particular interest, time or energy to look at. I would
hope to be proved wrong :-)

I suspect that there aren't a whole lot of python dev specialists out
there working on LO, and even fewer with an interest or acces to a Mac.


Alex


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

Re: Calc research & funcalc ...

2018-09-24 Thread Alexander Bock

Hi Michael,

Just a little note of warning. The forum you're posting to is one of
developers who typically intersperse their replies into edited-down
E-mail contexts. They also read through the whole E-mail to ensure they
got it all.

Thanks for the warning. So you saying we should not include the previous part 
of the conversation in our replies?

Sure, we do this each year - always fun; this year in Albania -
starting early next week: do join us. Next year's location to be
announced but will happen.

Unfortunately, I have a big deadline which is due this Friday, so I am not 
going anywhere :( I’d very much like to join next year though!

Correct; so far. Always more to do there. We'd love help as well - if
you have students interested in the more vexed engineering of
re-assembling our aircraft in-flight =) the interesting (and partially
solved) issue of more deeply unwinding the implicit intersections for
more precise dependencies and a decent view of the dependency graph is
something we'd love help with eg.

Haha! Probably not how we should sell it to them though. It is surprisingly 
difficult to “sell” the idea to the students in projects when you
mention the word “spreadsheets”. Most people know what a spreadsheet is but do 
not always understand or appreciate the complex
wiring behind the scenes. Last time, we threw around a bit parallelism and 
compiler stuff in the hopes that it would attract some students.

I believe some students would be interested in helping out, especially on a 
real-world application. I’ll pass it on to my supervisor and
see if he has been approached by any students. As previously mentioned, my own 
time is unfortunately exceedingly scarce.

While Calc seems daunting, it's really only ~400k lines of code and
attacking a reasonably well understood problem (vs. say writer layout =).

That should be fine :) Especially if a student hones in on a specific feature 
and with the major refactoring that Calc has undergone.

Are the benchmarks from the OpenCL kernel code publicly available? We would 
love to have some idea of the performance boosts
on all the six spreadsheets.

Mvh/Best regards,

Alexander Asp Bock, PhD student
Computer Science Department<https://computerscience.wikit.itu.dk/>
IT University of Copenhagen<http://en.itu.dk/>

On 22 Sep 2018, at 19.19, Michael Meeks 
mailto:michael.me...@collabora.com>> wrote:

Hi Alexander,

On 21/09/18 12:57, Alexander Bock wrote:
Yes, that’s very close :) Thanks! I can see there is also a tentative
LibreOffice Conference

Sure, we do this each year - always fun; this year in Albania -
starting early next week: do join us. Next year's location to be
announced but will happen.

The threaded variant you refer to is the one from the slides right? As I
understand, the interpreter is not fully parallel but runs cell
arrays/formula groups in parallel.

Correct; so far. Always more to do there. We'd love help as well - if
you have students interested in the more vexed engineering of
re-assembling our aircraft in-flight =) the interesting (and partially
solved) issue of more deeply unwinding the implicit intersections for
more precise dependencies and a decent view of the dependency graph is
something we'd love help with eg.

While Calc seems daunting, it's really only ~400k lines of code and
attacking a reasonably well understood problem (vs. say writer layout =).

ATB,

Michael.

--
michael.me...@collabora.com<mailto:michael.me...@collabora.com> <><, GM 
Collabora Productivity
Hangout: mejme...@gmail.com<mailto:mejme...@gmail.com>, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe

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

Re: Calc research & funcalc ...

2018-09-21 Thread Alexander Bock

Hi Trent,

About a year ago, I thought up an idea on my own very like Funcalc, that I 
called Scriptsheets.  At the time, I did not know Funcalc and its predecessors, 
going back about 20 years, existed.  I briefly though I had had a Very Original 
Idea.  Alas, it was not so.  See: 
https://haskell.markmail.org/search/?q=scriptsheets .

Cool! Funcalc doesn’t go 20 years back. The original inspiration came from a 
2003 paper by Simon Peyton-Jones et al. called: “A User-Centred Approach to 
Functions in Excel” which suggested the idea but did not implement AFAIK. There 
are a few papers on the subject on my supervisor’s site as well as other 
resources which I linked earlier.

There have been some attempts at scripting spreadsheets (even with Haskell) but 
I do not recall the titles. Also, there was a document that described a 
spreadsheet implemented in the functional language Clean (I/O) which had some 
interesting features. For example, I believe lazy evaluation was used to only 
update cells that were needed to show the current visible section of the 
spreadsheet.

Given that I am one person, and woefully under-prepared in computer science to 
accomplish my goals, the odds are I won't get very far on my roadmap before 
getting distracted.

My own background is biotechnology, so do not let your background discourage 
you.

Even if I do embark on step 5, the odds are it will wind up as Java-based 
abandonware like Frege or Jython.

At this stage in your journey, doing is learning which in my opinion is more 
important than worrying if your software will be abandoned at some point in the 
future.

But that is not why I am writing.  Can I prevail on the good graces of either 
of you to look through my first draft prospectus for Scriptsheets to see if, 
against all odds, there is anything of interest in it?  I would REALLY 
appreciate feedback from someone involved with spreadsheet professional 
programming or research.  The text runs 31 dry, boring pages.  I finished it 
2017-11-02.

I am in the final stages of my PhD and barely have time for anything else at 
the moment, so I will unfortunately have to respectfully decline :/ hopefully 
someone on the mailing list with more time can help.

Mvh/Best regards,

Alexander Asp Bock, PhD student
Computer Science Department<https://computerscience.wikit.itu.dk/>
IT University of Copenhagen<http://en.itu.dk/>

On 19 Sep 2018, at 09.04, trent shipley 
mailto:trent.ship...@gmail.com>> wrote:

About a year ago, I thought up an idea on my own very like Funcalc, that I 
called Scriptsheets.  At the time, I did not know Funcalc and its predecessors, 
going back about 20 years, existed.  I briefly though I had had a Very Original 
Idea.  Alas, it was not so.  See: 
https://haskell.markmail.org/search/?q=scriptsheets .

I have only a degree in mathematics (at which was was not very good) and a 
community college certificate in computer programming from the CIS department 
(at which I did quite well).

At present, my plan is to:

  1.  Finish the Haskell book I'm working on (Hutton 2016) to get some exposure 
to functional programming.
  2.  Work my way through a book on writing compilers in Java. (Ronald Mak 
2009, or maybe I'll get something newer by then.)
  3.  Work through the Calc/Funcalc book.
  4.  Translate the Calc/Funcalc programs from C# into Java.
  5.  Start the Scriptsheets project.

Given that I am one person, and woefully under-prepared in computer science to 
accomplish my goals, the odds are I won't get very far on my roadmap before 
getting distracted.  Even if I do embark on step 5, the odds are it will wind 
up as Java-based abandonware like Frege or Jython.

But that is not why I am writing.  Can I prevail on the good graces of either 
of you to look through my first draft prospectus for Scriptsheets to see if, 
against all odds, there is anything of interest in it?  I would REALLY 
appreciate feedback from someone involved with spreadsheet professional 
programming or research.  The text runs 31 dry, boring pages.  I finished it 
2017-11-02.

Regards,

Trent.

On Tue, Sep 18, 2018 at 2:56 AM Michael Meeks 
mailto:michael.me...@collabora.com>> wrote:
Hi Alexander,

On 18/09/18 10:26, Alexander Bock wrote:
> I would be delighted to join one of the hackfests if time allows. Is
> there a schedule available somewhere?

We typically have one in Hamburg at some stage in the year - which
would be near you; the ESC minutes have details on all of those as they
come up (posted to this list weekly). We also have a larger hackfest in
Brussels before or after FOSDEM - which is an excellent conference to
attend anyway =)

> I know of EUSPRIG as well and their horror stories
> <http://eusprig.org/horror-stories.htm>

Some good stories there =) Thanks for the list of conferences.

> Do you run any of the generated OpenCL kernels in parallel or do you run
> a normal sequential recalc

Re: Calc research & funcalc ...

2018-09-21 Thread Alexander Bock

Hi Michael,

We typically have one in Hamburg at some stage in the year - which
would be near you; the ESC minutes have details on all of those as they
come up (posted to this list weekly). We also have a larger hackfest in
Brussels before or after FOSDEM - which is an excellent conference to
attend anyway =)

Yes, that’s very close :) Thanks! I can see there is also a tentative 
LibreOffice Conference
announced in the wiki<https://wiki.documentfoundation.org/Events/2019>. Thanks 
for the FOSDEM recommendation!

Only in very recent times (the last generation) has typical GPU
hardware become capable of running multiple kernels simultaneously
and/or pre-empting running kernels. This leads to amusing situations -
whereby moving the mouse while a long running sheet calculates would
simply not be able to render - until a Windows / TDR was triggered. We
had to come up with heuristics to break down the CL workload into
bite-sized chunks to avoid this. More modern hardware doesn't have this
issue though.

Interesting stuff :)

And yes, we use CL when we think it makes sense - based on weights and
complexity of the relevant formulae. Otherwise we use the old
interpreter (or now its threaded variant - again depending on complexity).

I like the practical approach using weights and formula complexity. We 
currently use a full
big-step cost semantics for the formula language to estimate cost in the static 
partitioning
algorithm. Unfortunately, assigning costs also results in quite a slowdown in 
the partitioning algorithm.
As one of my colleagues said though, you can think of the process as compiling 
the spread-
sheet into a partition that can scheduled to run on a set of multicore 
processors.

The threaded variant you refer to is the one from the slides right? As I 
understand, the interpreter
is not fully parallel but runs cell arrays/formula groups in parallel.

Mvh/Best regards,

Alexander Asp Bock, PhD student
Computer Science Department<https://computerscience.wikit.itu.dk/>
IT University of Copenhagen<http://en.itu.dk/>

On 18 Sep 2018, at 11.55, Michael Meeks 
mailto:michael.me...@collabora.com>> wrote:

Hi Alexander,

On 18/09/18 10:26, Alexander Bock wrote:
I would be delighted to join one of the hackfests if time allows. Is
there a schedule available somewhere?

We typically have one in Hamburg at some stage in the year - which
would be near you; the ESC minutes have details on all of those as they
come up (posted to this list weekly). We also have a larger hackfest in
Brussels before or after FOSDEM - which is an excellent conference to
attend anyway =)

I know of EUSPRIG as well and their horror stories
<http://eusprig.org/horror-stories.htm>

Some good stories there =) Thanks for the list of conferences.

Do you run any of the generated OpenCL kernels in parallel or do you run
a normal sequential recalculation and call the kernel code as necessary?
I would suspect the latter given the information you have provided so far :)

Only in very recent times (the last generation) has typical GPU
hardware become capable of running multiple kernels simultaneously
and/or pre-empting running kernels. This leads to amusing situations -
whereby moving the mouse while a long running sheet calculates would
simply not be able to render - until a Windows / TDR was triggered. We
had to come up with heuristics to break down the CL workload into
bite-sized chunks to avoid this. More modern hardware doesn't have this
issue though.

And yes, we use CL when we think it makes sense - based on weights and
complexity of the relevant formulae. Otherwise we use the old
interpreter (or now its threaded variant - again depending on complexity).

HTH,

Michael.

--
michael.me...@collabora.com<mailto:michael.me...@collabora.com> <><, GM 
Collabora Productivity
Hangout: mejme...@gmail.com<mailto:mejme...@gmail.com>, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe

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

Re: Calc research & funcalc ...

2018-09-18 Thread Alexander Bock

Hi,

Sounds like an interesting book =) It's a shame we had a
LibreOffice conference in Denmark a couple of years back and would have
been interesting to meet up and compare spreadsheet design notes. Perhaps
you could join one of our Hamburg hackfests at some stage.

It’s a good read with lots of different design considerations. There’s also a
bunch of bachelor<https://www.itu.dk/people/sestoft/itu/bachelorprojekter.html>
and master<https://www.itu.dk/people/sestoft/itu/specialer.html> thesis
projects that investigate some of the suggestions from the book.

I would be delighted to join one of the hackfests if time allows. Is there a
schedule available somewhere?

Easy - just reply to the mail - and be aware it's permanently public.

I see. Easy indeed.

You might think so - but I couldn't possibly comment =) It would
be interesting too do some measurements and benchmarking here I think - we
have our own numbers, but some 3rd party looking at this might find some
good things.

It is definitely worth a try at some point :)

Ultimately I'd be really interested in how your compiled & jitted
C# stuff works too, you can emit IL rather than C-strings (as we do for CL)
so perhaps it is also rather fast.

The book provides all the details but there are a few
papers<https://www.itu.dk/people/sestoft/publications.html> on it as well
(search for sheet-defined function).

In essence, a dependency graph is constructed from the single output cell of
the SDF and analysed. There are code generators available for each kind of
expression in the language which are called as needed to generate the code as
specified by the cells in the dependency graph. Extra optimisations are used to
decrease packing/unpacking of internal structures and to generate local
variables for things that are used more than once. The code is emitted via the
ILGenerator<https://docs.microsoft.com/en-us/dotnet/api/system.reflection.emit.ilgenerator?redirectedfrom=MSDN&view=netframework-4.7.2>
class.

SDF compilation performance has not been an issue for me thus far.

Interesting. Anyhow I'd suggest that LibreOffice is a great code-base
to read through to update Peter's book - we're wrestling mightily with the
data structures to make it cleaner, faster and more sensible while staying
fully compatible with Excel.

I will relay that to my supervisor :) I did skim through your dependency graph
code at some point.

I'm also curious if there are good spreadsheet conferences out there,
I attended EUSPRIG in the past which was interesting - any recommendations ?

I know of EUSPRIG as well and their horror
stories<http://eusprig.org/horror-stories.htm> although I have not attended.
Personally, I have mainly attended conferences on parallelism and concurrency
as well as (declarative) programming language implementation, which are the two
main parts of my PhD.

Actually, I did go through a list of about 100 references in a survey paper I
wrote on spreadsheet technology, picking out the venues for papers on the
subject. They should be good venues for literature searches on spreadsheets or
for publication.

* International Conference on Software Engineering (ICSE) - lots of
spreadsheet papers published here.
* Principles and Practice of Declarative Programming (PPDP)
* International Conference on Functional Programming (ICFP) - mainly due to
the functional nature of spreadsheets and SDFs.
* Journal of Functional Programming (JFP) - ditto.
* Commercial Users of Functional Programming (CUFP) - ditto.
* European Symposium on Programming (ESOP)
* Automated Software Engineering (ASE)
* Journal on Systems and Software
* Human Centric Computing Languages and Environments
* Journal of Visual Languages and Computing
* Foundations on Software Engineering (FSE)
* Visual Languages and Human-Centric Computing (VL/HCC) - lots of
spreadsheet papers published here as well.
* Transactions on Software Engineering (TSE)
* ACM Transactions on Software Engineering Methodology
* International Symposium on End-User Development (IS-EUD)

Note that some of these journals/conferences may not be active anymore.

Do you run any of the generated OpenCL kernels in parallel or do you run a
normal sequential recalculation and call the kernel code as necessary? I would
suspect the latter given the information you have provided so far :)

Mvh/Best regards,

Alexander Asp Bock, PhD student
Computer Science Department<https://computerscience.wikit.itu.dk/>
IT University of Copenhagen<http://en.itu.dk/>

On 7 Sep 2018, at 11.33, Michael Meeks
mailto:michael.me...@collabora.com>> wrote:

Hi there,

So - opening this to a wider audience with minor edits - and
more comments in-line:

On 03/09/18 16:21, Alexander Bock wrote:
Sorry for the delay in getting back to you.

Michael wrote:
First - great to meet you; and good to

Re: Mysql/Mariadb connector extension flag not recognized on MacoS when building LibreOffice

2018-08-28 Thread Alexander Thurgood

Le 28/08/2018 à 16:29, Andras Timar a écrit :

Hi Andras,

Thanks for the info.

> MySQL connector is built-in code now, not an extension.

Does that mean that the flag --enable-bundle-mariadb is also no longer
necessary ?


Alex


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

Mysql/Mariadb connector extension flag not recognized on MacoS when building LibreOffice

2018-08-28 Thread Alexander Thurgood

Hi all,

Has someone removed the configure flag --enable-ext-mariadb-connector flag ?

If so, what is the flag that should be used now if one wants to build
the mysql/mariadb connector extension ?

TIA,

Alex

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

Re: Undefined symbols for architecture x86_64 in libmariadb-connector-c - build failure on master, with macOS

2018-08-21 Thread Alexander Thurgood

Le 21/08/2018 à 09:24, Stephan Bergmann a écrit :

Well my build completed successfully this morning, so I'm guessing your
fix did it, thanks !

Alex

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

Re: Undefined symbols for architecture x86_64 in libmariadb-connector-c - build failure on master, with macOS

2018-08-20 Thread Alexander Thurgood

Le 20/08/2018 à 18:24, Drew Jensen a écrit :


Yep, that's almost certainly the culprit, as it appears to have been
committed just after I started my last successful build.




> Noticed over on the QA IRC channel some talk about Mac and a recent
> change to the MySQL sdbc code:
> "Switch from mysql to MariaDB C API" :
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=3478d7453a3d65b3d8d164e8f898a0b79f005c58
> for the change record.
> 



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

Re: Undefined symbols for architecture x86_64 in libmariadb-connector-c - build failure on master, with macOS

2018-08-20 Thread Alexander Thurgood

Le 20/08/2018 à 17:24, Alexander Thurgood a écrit :

The last change I see when git grepping mariadb is a commit from Miklos
relating to fixing the Windows build...but this was back in May, and I
have been successfully building from master on MacOS, including after
make clean, git pull and make using an export in my environment to the
mysql-connector-c source since well before May 30th, 2018...





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

Undefined symbols for architecture x86_64 in libmariadb-connector-c - build failure on master, with macOS

2018-08-20 Thread Alexander Thurgood

HI all,

In my usually uneventful master builds, last built on August 13th, I am
now seeing the following build failure in mysqlc.uno.dylib :

Undefined symbols for architecture x86-64:
"_iconv", referenced from _mariadb_convert_string in
libmariadb-connector-c.a
"_iconv_close", referenced from _mariadb_convert_string in
libmariadb-connector-c.a
"_iconv_open", referenced from _mariadb_convert_string in
libmariadb-connector-c.a

clang: error: linker command failed with exit code 1


What gives ?

Alex

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

Re: Firebird build from master fails on macOS

2018-06-28 Thread Alexander Thurgood

Le 27/06/2018 à 17:34, Alexander Thurgood a écrit :


Well, the build seems to be working fine again now, so whatever...


> Hey all,
> 
> Heads up to the curator of the built-in Firebird package. The build from
> master is failing for me currently on macOS 10.13.5 with the following
> error message :
> 
> can't format message 17:3 -- message file
> /Users/Shared/LO/core/workdir/UnpackedTarball/firebird/gen/Release/firebird/firebird.msg
> not found
> 


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

Firebird build from master fails on macOS

2018-06-27 Thread Alexander Thurgood

Hey all,

Heads up to the curator of the built-in Firebird package. The build from
master is failing for me currently on macOS 10.13.5 with the following
error message :

can't format message 17:3 -- message file
/Users/Shared/LO/core/workdir/UnpackedTarball/firebird/gen/Release/firebird/firebird.msg
not found



Alex

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

Re: Database migration in Base

2018-04-10 Thread Alexander Thurgood

Le 10/04/2018 à 12:30, Tamas Bunth a écrit :


Hi Tamas,

Read through your blog posts, sounds really promising, and I am
interested in testing with various hsqldb ODB files that I have accrued
over time through QAtriaging of Base problems.

Is there any particular setup required to test, other than building from
master ?

Are any startup parameters required ?

Note that I would be testing on macOS.


Alex


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

Re: Image cropping depends on screen resolution

2018-02-26 Thread Alexander Thurgood

Le 26/02/2018 à 22:48, Thorsten Behrens a écrit :

> Sounds like a bug to me, please file (with sample document) at
> bugs.documentfoundation.org
> 

Sounds like :

https://bugs.documentfoundation.org/show_bug.cgi?id=112538


Alex


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

Draw and Impress fail to launch in master build and 6.0b1

2017-11-28 Thread Alexander Thurgood

Hi all,

In reference to tdf#114086, neither Draw nor Impress will launch in the
current 6.0 beta, nor from my master build of today.

Failure to load the component libsdlo.dylib is indicated as the cause.
Build linking issue or packaging problem ?


Alex

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

Re: Linker warning about shared_ptr on Mac, when compiling for iOS.

2017-10-19 Thread Alexander Thurgood

Le 18/10/2017 à 19:11, Jan Iversen a écrit :

Hi Jan,

FWIW, I have seen this too in the standard OSX LO build, but have so far
ignored it, as it doesn't seem to affect the build outcome or LO's
behaviour (at least not in any way that I have encountered).


Alex

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

Re: iOS, status update

2017-10-04 Thread Alexander Thurgood

Le 04/10/2017 à 10:33, Tor Lillqvist a écrit :
>> Current 9.0 does not compile the libraries correctly, but it also does not
>> compile the normal LO app for macOSX correctly.
>>
> 

It compiles for me too, and provides a working app bundle, at least in
my symbols enabled build from current master.

XCode9.0, HighSierra OSX10.13


Alex


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

Re: Repeated unit test failures on master MacOS in libtest_sw_uwriter

2017-09-26 Thread Alexander Thurgood

Le 26/09/2017 à 12:25, Alexander Thurgood a écrit :

> 
> Cheers, yes, saw that go in earlier this morning, am just attempting a
> rebuild now.
> 
> 

Build successful, thanks !

Alex

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

Re: Repeated unit test failures on master MacOS in libtest_sw_uwriter

2017-09-26 Thread Alexander Thurgood

Le 26/09/2017 à 11:19, Stephan Bergmann a écrit :

> 
> Hopes are that
> 
> "Blind fix for Xcode 9" will fix this.

Cheers, yes, saw that go in earlier this morning, am just attempting a
rebuild now.


Alex

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

Repeated unit test failures on master MacOS in libtest_sw_uwriter

2017-09-25 Thread Alexander Thurgood

Hi all,

I've been seeing repeated build failures in libtest_sw_uwriter when
trying to build master on MacOS (10.12.6), with the following error :

Undefined symbols for architecture x86_64:
"SfxEnumItem::operator==(SfxPoolItem const&) const"
referenced from:
SwDocTest::testTableAutoFormats() in uwriter.o
ld: symbols not found for architecture x86_64

clang: error: linker command faied with exit code 1


Is this test not designed for this architecture, or am I missing something ?


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

Re: Rebuilding LO freezes on macOS

2017-08-24 Thread Alexander Thurgood

Le 23/08/2017 à 21:28, Thorsten Wagner a écrit :

Hi THorsten,


> (2) During building again build freezes while linking 
> "Library/libscfiltlo.dylib". "make" loops consuming 100% cpu on a single 
> core. Build has to be interrupted by killing "make" processes.
> 

I see this occasionally, or though it tends to be during population of
instdir (so towards the end of the build) and not specifically in
libscfiltLO.dylib. Possibly the parallel build gets into a race
condition somewhere (shrugs) and I have to kill it, clean it and restart.

I remember reading somewhere a long time ago about changing the ulimit
number of openable file descriptors, something like this here:

https://unix.stackexchange.com/questions/108174/how-to-persist-ulimit-settings-in-macos

That might help, but if you need to push past the hard limit set by
Apple as default, then you need to buy AppleServer for OSX from the
AppStore.


Alex

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

Re: Build failure with current master on MacOS

2017-07-25 Thread Alexander Thurgood

Le 25/07/2017 à 13:18, Tor Lillqvist a écrit :


> 
> GNU gettext package is available in Homebrew.
> 
> 
> But we have traditionally strongly advised against polluting one's build
> environment on macOS with Homebrew and similar. Has this changed?
> 

Apparently. Or rather, there appears to be some creep in the general
direction of adding further build dependencies to one's environment.

As I experienced yesterday in a separate incident, seeking to try out
mariadb and a few other gnome/gtk resources, before removing it all
again, installing virtually anything from HomeBrew pollutes your LO-dev
environment with pkgconfig foo which autogen.sh then promptly tells you
to remove or alter your path settings. So, still incompatible with LO's
build environment and I would still recommend against using HomeBrew.


Alex







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

Re: Build failure with current master on MacOS

2017-07-25 Thread Alexander Thurgood

Le 24/07/2017 à 16:29, Caolán McNamara a écrit :

Thanks for the headsup !

Alex

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

Re: Build failure with current master on MacOS

Le 24/07/2017 à 15:16, Michael Stahl a écrit :

> (here "fixed" means you'll get an error message from configure instead
> that tells you to install gettext)
> 

At least the message is explicit enough ;-)

I don't build via LODE, just the standard OSX Terminal.app.

It has worked fine (with the odd exception) for years (since LO began,
in fact).

The day I am forced (as in, because everything forces the user in that
direction) to set up a specific environment to get LO to build on Mac is
the day I stop building LO on Mac. In that case, we become no better
than HomeBrew or ports, or any other similar project. Oh well, such is
progress :-)


Alex


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

Re: Build failure with current master on MacOS

Le 24/07/2017 à 15:16, Michael Stahl a écrit :

> 
> this should be fixed on master with commit
> 68d7faae7d748b6adcf8ba71a5b7ec9d80031c1b
> 
> (here "fixed" means you'll get an error message from configure instead
> that tells you to install gettext)
> 
> (how one would best install gettext on MacOS is another question that i
> don't know the answer to; perhaps via LODE ?)
> 

Ok, thanks, but I guess it still means I can't build with localized
version until that is sorted. Where did this new requirement come from ?


Alex

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

Re: Build failure with current master on MacOS

Le 24/07/2017 à 14:45, Michael Stahl a écrit :

> what does this say:
> 
> grep MSG config_host.mk
> 

Both MSGFMT and MSGUNIQ are undefined.


Alex

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

Re: Build failure with current master on MacOS

Le 24/07/2017 à 13:09, Michael Stahl a écrit :


Hi all,

>> [PKG] python3
>> /Users/XXX/lo/lode/dev/core/solenv/gbuild/Package.mk:81: *** Something
>> depends on package python3 which does not exist..  Stop.
>>
> 
> this should be fixed on master with commit
> 8c9ed261cb9201774943e438cf5394c1dcfa8c49

Yes, saw that too this morning, but that isn't the same problem I'm
experiencing as I pulled again after that and still with a make clean,
make, I'm getting the same failure as I reported in accfr.mo and
avmediafr.mo.


Alex


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

Build failure with current master on MacOS

Hi all,

My master build is currently failing after a make clean and fresh git
pull when building MO first in accfr, and now avmediafr - have there
been some recent changes to gettext pushed to master or some other
element of the FR language support that could have led to these
failures. I see the following message just before the failure :

interim-update-for-gettext : processing
/core/translations/source/fr/accessibility

interim-update-for-gettext : merging
/core/translations/source/fr/accessibility/source/helper.po


and similar messages in avmedia, but also :

sh --force-po command not found





Alex

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

Re: Unit test build failure in sw_htmlimport

2017-06-20 Thread Alexander Thurgood

Hi Vasily,

Thanks for the information. I am enclosing the build output from the
terminal.


Alex

[build CUT] sw_htmlimport
[build CUT] sw_ooxmlexport
warn:sal.bootstrap:33693:1:sal/rtl/bootstrap.cxx:378: couldn't open file: 
file:///Volumes/BUILDHD/Shared/LO/core/workdir/LinkTarget/Executable/cppunittesterrc
File tested,Execution Time (ms)
warn:legacy.osl:33693:1:xmloff/source/transform/OOo2Oasis.cxx:1925: duplicate 
doc handler
warn:legacy.osl:33693:1:xmloff/source/transform/OOo2Oasis.cxx:1925: duplicate 
doc handler
warn:xmloff:33693:1:xmloff/source/core/xmlerror.cxx:169: An error or a warning 
has occurred during XML import/export!
Error-Id: 0x10020002
Flags: 1 WARNING
Class: 2 FORMAT
Number: 2
Parameters:
0: style:font-name-asian
1: HG Mincho Light J
Exception-Message: 

warn:xmloff:33693:1:xmloff/source/core/xmlerror.cxx:169: An error or a warning 
has occurred during XML import/export!
Error-Id: 0x10020002
Flags: 1 WARNING
Class: 2 FORMAT
Number: 2
Parameters:
0: style:font-name-complex
1: Arial Unicode MS
Exception-Message: 

warn:xmloff:33693:1:xmloff/source/core/xmlerror.cxx:169: An error or a warning 
has occurred during XML import/export!
Error-Id: 0x10020002
Flags: 1 WARNING
Class: 2 FORMAT
Number: 2
Parameters:
0: style:font-name-asian
1: HG Mincho Light J
Exception-Message: 

warn:xmloff:33693:1:xmloff/source/core/xmlerror.cxx:169: An error or a warning 
has occurred during XML import/export!
Error-Id: 0x10020002
Flags: 1 WARNING
Class: 2 FORMAT
Number: 2
Parameters:
0: style:font-name-complex
1: Arial Unicode MS
Exception-Message: 

warn:xmloff:33693:1:xmloff/source/core/xmlerror.cxx:169: An error or a warning 
has occurred during XML import/export!
Error-Id: 0x10020002
Flags: 1 WARNING
Class: 2 FORMAT
Number: 2
Parameters:
0: style:font-name-asian
1: HG Mincho Light J
Exception-Message: 

warn:xmloff:33693:1:xmloff/source/core/xmlerror.cxx:169: An error or a warning 
has occurred during XML import/export!
Error-Id: 0x10020002
Flags: 1 WARNING
Class: 2 FORMAT
Number: 2
Parameters:
0: style:font-name-complex
1: Arial Unicode MS
Exception-Message: 

warn:xmloff:33693:1:xmloff/source/core/xmlerror.cxx:169: An error or a warning 
has occurred during XML import/export!
Error-Id: 0x10020002
Flags: 1 WARNING
Class: 2 FORMAT
Number: 2
Parameters:
0: style:font-name-asian
1: HG Mincho Light J
Exception-Message: 

warn:xmloff:33693:1:xmloff/source/core/xmlerror.cxx:169: An error or a warning 
has occurred during XML import/export!
Error-Id: 0x10020002
Flags: 1 WARNING
Class: 2 FORMAT
Number: 2
Parameters:
0: style:font-name-complex
1: Arial Unicode MS
Exception-Message: 

warn:svtools:33693:1:svtools/source/svhtml/parhtml.cxx:1394: GetOption: unknown 
HTML option 'xmlns'
warn:basic:33693:1:basic/source/uno/namecont.cxx:974: Cannot access extensions!
warn:basic:33693:1:basic/source/uno/namecont.cxx:974: Cannot access extensions!
picture.html:
4130
testPictureImport::Import finished in: 4386ms
File tested,Execution Time (ms)
warn:vcl:33693:1:vcl/osx/salmenu.cxx:925: no menu
inlined_image.html:
3026
testInlinedImage::Import finished in: 3084ms
File tested,Execution Time (ms)
PageAndParagraphFilled.html:
426
testInlinedImagesPageAndParagraph::Import finished in: 457ms
File tested,Execution Time (ms)
warn:svtools:33693:1:svtools/source/svhtml/parhtml.cxx:1394: GetOption: unknown 
HTML option 'xmlns'
list-style.html:
style is 1
527
testListStyleType::Import finished in: 558ms
File tested,Execution Time (ms)
meta-ISO8601-dates.html:
397
testMetaIsoDates::Import finished in: 425ms
File tested,Execution Time (ms)
meta-changedby.html:
414
testChangedby::Import finished in: 447ms
File tested,Execution Time (ms)
table_border_1px.html:
/Volumes/BUILDHD/Shared/LO/core/sw/qa/extras/htmlimport/htmlimport.cxx:232:testTableBorder1px::Import
equality assertion failed
- Expected: 9
- Actual  : 12
- different InnerLineWidth

testTableBorder1px::Import finished in: 476ms
/Volumes/BUILDHD/Shared/LO/core/sw/qa/extras/htmlimport/htmlimport.cxx:232: 
Assertion
Test name: testTableBorder1px::Import
equality assertion failed
- Expected: 9
- Actual  : 12
- different InnerLineWidth

Failures !!!
Run: 7   Failure total: 1   Failures: 1   Errors: 0
warn:fwk.desktop:33693:1:framework/source/services/desktop.cxx:1070: Desktop 
disposed before terminating it
warn:legacy.osl:33693:1:sw/source/core/layout/newfrm.cxx:363: Who didn't 
deregister?
warn:legacy.osl:33693:1:sw/source/core/layout/newfrm.cxx:363: Who didn't 
deregister?
warn:legacy.osl:33693:1:sw/source/core/layout/newfrm.cxx:363: Who didn't 
deregister?
warn:legacy.osl:33693:1:sw/source/core/layout/newfrm.cxx:363: Who didn't 
deregister?
warn:legacy.osl:33693:1:sw/source/core/layout/newfrm.cxx:363: Who didn't 
deregister?
warn:legacy.osl:33693:1:sw/source/core/layout/newfrm.cxx:363: Who didn't 
deregister?
warn:legacy.

Unit test build failure in sw_htmlimport

2017-06-20 Thread Alexander Thurgood

Hi all,

On Mac OSX, attempting to build from master (make clean, fresh pull)?
I'm seeing repeat build failures in sw_htmlimport preventing the rest of
the build from completing.

The failure is in an assertion not met in table_border_1px.html
testTableBorder1px::Import
Different inner line width.

Anyone else experiencing the same thing ?

OSX 10.12.4
XCode 8.0



Alex

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

Re: DbGridControl's confusion of BrowseBox's column number vs. column ID

2017-03-10 Thread Alexander Thurgood

Le 10/03/2017 à 16:01, Lionel Elie Mamane a écrit :


Hi all,

> 
> It starts to look like bugs will appear if you:
> 
> 1) Open a document with a form with a table control.
> 
> 2) Move a column (which may be possible only pogrammatically or after
>tdf#54021 is fixed)
> 
> 3) Try to copy the cell text (you'll copy from the wrong column)
> 

Perhaps the mailmerge and DatatoText functionalities might also expose
this "feature" too as they use, if I understand correctly, a DbGridCtrl
to populate data from the data source and then push that elsewhere ?



Alex

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

Re: Build Time Query

2017-02-24 Thread Alexander Thurgood

Le 23/02/2017 à 22:53, Jason Marshall a écrit :

Hi Jason,

> The actual build triggered by running ‘make' initially ran for
> approximately ten hours, but unfortunately the battery failed on my
> computer meaning that the build presumably was interrupted.  Clearly,
> the battery failure issue was unfortunate, but I am unclear as to the
> expected build times on the above specification of platform.  Would
> greater than ten hours be expected, as I am aware that the hardware
> specification above is quite low.  In addition, if the failed build is


With a spec like the one you describe, expect an initial build to take
anywhere between 24 and 48 hours, possibly even longer depending on how
many other bits you have added in terms of build switches (e.g.
languages, extensions, etc).

Even minor changes in git can also provoke 24h+ re-builds with a setup
like that, at least, that was certainly my previous experience with a
similar rig.


Alex


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

Re: News on Xcode IDE, libre office now loads as 1 project, with modules etc.

2017-01-13 Thread Alexander Thurgood

Le 13/01/2017 à 17:07, Jan Iversen a écrit :
> 


> Bjoern is the right person to ask, he declared a number of modules for
> blacklisted. Once reason could be if the module contains Java, another
> can be the makefiles are not using the standard gb_ macros.
> 
> 
> gb_GbuildToJson_BLACKLISTEDMODULES := connectivity compilerplugins
> cli_ure dictionaries bridges helpcompiler helpcontent2 icon-themes jurt
> sal shell cppu cppuhelper cpputools extensions external i18npool
> javaunohelper lingucomponent odk scaddins solenv stoc tools translations
> udkapi unoidl
> 

That is unfortunate as it means that most of the database functionality
is excluded, including the bundled extensions and wizards (abpilot,
bibliography, dbpilots, spotlight/mdimporter), the external stuff :
reportbuilder, firebird, anything that relies on Java.

It is also a bit inconsistent, in that the module "forms" is included,
but without any database connectivity, it is probably not much use. Same
for reportdesign.


I imagine that that represents still quite a bit of work to achieve, so
good luck !


Alex





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

Re: News on Xcode IDE, libre office now loads as 1 project, with modules etc.

2017-01-13 Thread Alexander Thurgood

Le 05/01/2017 à 19:23, jan iversen a écrit :

Hi Jan,


Exploring the included modules in libreoffice.xcodeproj shows that
"connectivity" isn't included - why might this be ?


Alex



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

Re: News on Xcode IDE, libre office now loads as 1 project, with modules etc.

2017-01-11 Thread Alexander Thurgood

Le 06/01/2017 à 11:39, Alexander Thurgood a écrit :

Well, just to report back, it would appear that, after a fresh make
clean pull and rebuild, xcode_ide-integration now has built a
libreoffice.xcodeproj folder.

Thanks for all the work you've put in ! Off to test, now.


Alex


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

Re: News on Xcode IDE, libre office now loads as 1 project, with modules etc.

2017-01-06 Thread Alexander Thurgood

Le 05/01/2017 à 19:23, jan iversen a écrit :

Hi Jan,

Thanks for your input, I'll try the make gbuildtojson again and send you
the zipped output from workdir/gbuildjson as requested.


Alex


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

Re: News on Xcode IDE, libre office now loads as 1 project, with modules etc.

2017-01-05 Thread Alexander Thurgood

Le 04/01/2017 à 18:30, Jan Iversen a écrit :

OK, so I actually looked in the osx directory, and saw an xcodeproj file
(folder).

If I open this up in XCode, I get a few warnings about architecture
overrides and whether I want to have them corrected, but more importantly :

- I only see the following modules listed under soffice : formula, sw,
vcl, java and sc

- an error is thrown in target with the line /opt/lo/bin/make


which obviously doesn't exist (at least not on my system). I'm guessing
that this needs to be corrected to just point to OSX system make.


Alex



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

Re: News on Xcode IDE, libre office now loads as 1 project, with modules etc.

2017-01-05 Thread Alexander Thurgood

Le 04/01/2017 à 18:30, Jan Iversen a écrit :

Hi Jan,

> Some positive news before tomorrows ESC meeting.
> 
> I just pushed commit f5dcce42e3d94ac121b2a511a7feddff272f2e4e.
> 
> That commit updates gbuild-to-ide to generate libreoffice.vcxproj (ONLY
> OSX), that contains (limited by gbuildtojson delivery)
> 
> - All modules
> - All cxx files within the modules
> - All targets within the modules
> 

Nice !

I tried running it on OSX and get the fatal error :

Attribute Error: 'NoneType' object has no attribute group

in the gbuild parser, line 113



Alex



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

Re: make gbuildtojson and make xx-ide-integration problems.

Le 15/12/2016 à 12:11, Alexander Thurgood a écrit :

And surely the whole aim of the foo-ide-integration thing is to allow
the default to be built from within the target IDE and not to require
setting ENVs for frameworks that are not the default ?



Alex

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

Re: make gbuildtojson and make xx-ide-integration problems.

Le 15/12/2016 à 11:50, Jan Iversen a écrit :
> 

> 
> If your make does not fail with a python backtrace, then you have another 
> problem, like missing python3.
> 

Did I misunderstand something, as I don't recall python3 becoming a
requirement for building LO ?
The default python framework on OSX 10.12.1 is python2.7 and this is
what appears in the shell.

The gbuildtojson script looks in workdir/GeneratedPackage directory for
python3 but this isn't built by default in an OSX build because a
top-level make finds python2.7 :

checking for a Python interpreter with version >= 2.6...python
checking for python version...2.7
checking for python platform...Darwin
...
checking which Python to use for Pyuno...
checking for a python interpreter with version >= 3.3...none




Alex



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

Re: make gbuildtojson and make xx-ide-integration problems.

Le 15/12/2016 à 11:50, Jan Iversen a écrit :
> 

The error message is :


env: python3: No such file or directory

Alex

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

Re: make gbuildtojson and make xx-ide-integration problems.