Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Anthonys Lists]

On 11/03/2016 01:45, toki wrote:

On 10/03/2016 01:27, Wols Lists wrote:


On top of that, an integrity layer that enforces datatypes. This isn't part of 
standard multi-value,

What?  Back when I played with Pick, one of the selling points was that
one couldn't put the wrong type of data into a record field. Was that
feature simply a vendor provided customization?


OMG... Yes it must have been.

ED FILE RECORD
scribble scribble scribble
FI

Bingo, one record with all sorts of data all over the place with no 
validity checking whatsoever. Bear in mind that in relational, the 
schema is PREscriptive, defining what data goes where. In Pick, the 
DICTionary is DEscriptive, telling you what's supposed to go where - 
indeed it is so non-prescriptive that it's optional!


If you used one of the generators, such as  or System Builder, they 
probably did use the dictionary as a schema, and would have enforced 
integrity. I want to put a layer at the WRITE level that, if enabled, 
enforces the DICTionary as a schema - it shouldn't be that hard.



I'll then need a Basic compiler.

Does it have to be BASIC?
Can't R or Python be used instead of BASIC?

###

I realize that using R means either including another scripting
language, or upgrading the existing R Language extension so that it
installs a version of R that plays nicely within LibreOffice.


One of the problems with "play nicely with Pick" is that Pick is p-code 
based, and that p-code gets embedded in the data files ... so I need 
something where I can embed the object code, as data, in the DICTionary. 
(For the relational guys, these are "calculated fields", Pick "stores a 
mini program in the column definition of the schema" which then 
calculates the value of that column.)


But that's one of the reasons for wanting to play nice with / integrate 
with StarBasic - it makes it easy to spit out a .odf from the database. 
That's one up on Crystal Reports :-)

I know Pick isn't the easiest of topics to Google for, but some links for 
reading ...

Talking about which, Given how poor the documentation for BASE is, do
you know anybody who would be willing and able to write documentation on
using PICK within LibreOffice. (FWIW, Even a developers outline on what
it should do, would be a good starting point for users.)
That's actually one of my strong points - not necessarily knowing what's 
required but I'm very good at explaining to users AT THEIR LEVEL what 
they need to know. If I can see where they're struggling, I can explain 
it to them in terms they can understand.


For example, the way I can best describe Pick (to someone who has some 
degree of database knowledge) is to say that just as the row is the 
basic unit in relational, so the RECORD is the basic unit in Pick. The 
RECORD maps to a real world object and, in relational terms, should be a 
3nf view of that object. Because that 3nf view includes foreign keys, I 
can then access other objects/RECORDs via a "directed graph" type 
mechanism, rather than a relational join. This may have pros and cons, 
but a massive pro is speed. And because you're thinking at the object 
level, it doesn't really make sense to have a relational style "record 
set". Instead, think of stepping through your 3nf objects using a cursor 
size of one.


Hopefully that'll showcase my explanational skills, and give you an idea 
as to how Pick functions, though if you've played with it I guess you've 
already got some idea :-)


Unfortunately, I don't know of any truly Free Software implementation I 
could recommend to go with LO. The only plausible candidate is OpenQM / 
ScarletDME, which is *allegedly* GPL'd. Note the stress on "allegedly" 
:-( MaVerick, which has been mentioned elsewhere, I think just ran out 
of steam (and it's Java-based - a victim of "let's rewrite everything in 
Java" imho).



And can I write a version of Pick that comes over as a bright shiny new 
bauble? I don't know, but I can damn well give it the good old college try!



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


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

Re: Firebird doesn't support MSVC 2015

[Miklos Vajna]

Hi David,

On Wed, Mar 02, 2016 at 07:37:40PM +0100, David Ostrovsky  
wrote:
> > The wiki states that 32-bit >build is broken, that sounds like a
> >blocker as well. (Or is it just >that the wiki is outdated?
> >configure.ac:5277 suggests it's up to date.)
> 
> Yes, wiki was outdated, should be fixed now. Thanks for noticing.

Hmm, I've set up a 32bit VM with VS2015 only (no VS2013). Currently
configure fails at find_dotnetsdk46(), which isn't too surprising, since
even you added a TODO, saying the current code only works on 64bit. :-)

It would be really nice if this would be addressed before VS2013 support
is dropped. I'm mentioning this here, as my concern is that you only
test 64bit and CI only tests VS2013+VS2015, not VS2015 only.

Thanks,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[toki]

On 10/03/2016 11:37, Wols Lists wrote:

> And it would be nice to include an "easy to use" database with LO.

a) Doesn't LibO still include the db3 compatible database engine?  If
so, that can be used;

b) I understand the dislike of SQLite, but for non-database programmers,
for most purposes, it is fine.

> Why do most people use Excel instead of Access? Because Access is too hard!

They use Excel, either because nobody showed them how to use Access, or,
more commonly, because Access was not part of their office suite.

> And this design is tried and tested and 40 years old

But can you write it so that it looks like a bright shiny new bauble?

jonathon

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

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[toki]

On 10/03/2016 01:27, Wols Lists wrote:

> On top of that, an integrity layer that enforces datatypes. This isn't part 
> of standard multi-value,

What?  Back when I played with Pick, one of the selling points was that
one couldn't put the wrong type of data into a record field. Was that
feature simply a vendor provided customization?

> I'll then need a Basic compiler. 

Does it have to be BASIC?
Can't R or Python be used instead of BASIC?

###

I realize that using R means either including another scripting
language, or upgrading the existing R Language extension so that it
installs a version of R that plays nicely within LibreOffice.

> I know Pick isn't the easiest of topics to Google for, but some links for 
> reading ...

Talking about which, Given how poor the documentation for BASE is, do
you know anybody who would be willing and able to write documentation on
using PICK within LibreOffice. (FWIW, Even a developers outline on what
it should do, would be a good starting point for users.)



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

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Chris Sherlock]

> On 10 Mar 2016, at 10:37 PM, Wols Lists  wrote:
> 
> Well, all modern Picks implement SQL access.
> 
> And as far as I'm aware, all modern RDBMS implement some form of stored
> procedure, ie have some form of internal programming language. I suspect
> end users will find the Pick way of dealing with it is a lot easier than
> the relational way, but hey, give them the choice!
> 
> And it would be nice to include an "easy to use" database with LO. imho
> that means "something that is NOT relational"! Why do most people use
> Excel instead of Access? Because Access is too hard!

The issue isn’t whether we support Pick, the issue is about how do we get out 
unit tests working for Base. 

Firebird was chosen some time ago because it supports SQL. Pick sounds great, 
don’t get me wrong, but I don’t think it’s a candidate for our automated tests, 
at least at this point. 

Chris

P.S. as an aside, when I was in high school, some wit printed a sign and stuck 
it to the high school computing teacher’s office door - it had a clipart 
picture of a PC and under it the sign read:

“What is G.I.R.L.S, and is it IBM compatible?”

Imagine my surprise to read the following on that Wikipedia article about Pick:

"Pick was originally implemented as the Generalized Information Retrieval 
Language System (GIRLS) on an IBM System/360”. I guess the answer was “yes”.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Wols Lists]

On 10/03/16 08:51, Lionel Elie Mamane wrote:
>> > Pick, now generically known as MultiValue, is an n-dimensional
>> > database, and can be shown to be a proper superset of relational.
> Sorry to be blunt, but as long as it can be used as relational through
> SQL in a way that is close to the consensus of "the usual suspects" of
> relational SQL databases, it is acceptable. If it is better, but
> different, I don't think it is a good match for Base, an application
> and framework built around SQL.
> 
> If it can do more, but we can use the "relational SQL subset"
> reliably, then fine. But we *do* *need* to address it through SQL, not
> some other API/language that is more general.

Well, all modern Picks implement SQL access.

And as far as I'm aware, all modern RDBMS implement some form of stored
procedure, ie have some form of internal programming language. I suspect
end users will find the Pick way of dealing with it is a lot easier than
the relational way, but hey, give them the choice!

And it would be nice to include an "easy to use" database with LO. imho
that means "something that is NOT relational"! Why do most people use
Excel instead of Access? Because Access is too hard!
> 
>> > So. My plans. Implement a string class (...). Implement the data
>> > store (...)
>> > On top of that, an integrity layer that enforces datatypes. (...)
>> > On top of that we'll need a Pick shell, and a SQL shell.

> You mean none of these is done yet? That looks like something for a
> somewhat distant future (on the scale of LibreOffice releases), then.

Well, if you think back, I've been a bit diffident about coming forward
in the past, for precisely this reason. On the other hand, if I can get
the bit between my teeth, re-implementing an existing design is usually
pretty easy. And this design is tried and tested and 40 years old ... :-)

I'm hoping this will be the "kick up the backside" that really gets me
going.
> 
> So on the LibreOffice side, we should probably use something else in
> the short term. When your thing is ready, we can integrate it.
> 
> As I wrote previously, we can offer the choice between several
> embedded formats.
> 
>> > I'll then need a Basic compiler. (...)
>> > The wikipedia page (what else :-)
>> > https://en.wikipedia.org/wiki/Pick_operating_system
> I didn't go see a page about an "operating system" when looking for a
> DBMS...

"The database is the computer"? Pick is a database from the ground up,
but it was originally designed to run on bare metal so it had to
implement some operating system functionality. That was offloaded to an
off-the-shelf operating system as soon as it moved to general-purpose
hardware. Oddly enough, that off-the-shelf OS was Red Hat Linux :-) As a
commercial database available on Linux, Pick predates Oracle by about a
year :-)

I gather (I've never used it) the IBM AS/400 is the same sort of "the
database is the computer" mentality.

Now to go and do some work on the system ... :-)

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

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Lionel Elie Mamane]

On Thu, Mar 10, 2016 at 01:27:46AM +, Wols Lists wrote:
> On 09/03/16 18:06, Lionel Elie Mamane wrote:
>> On Wed, Mar 09, 2016 at 06:59:08PM +0100, Lionel Elie Mamane wrote:
>>> On Tue, Mar 08, 2016 at 08:44:03PM +, Wols Lists wrote:
 On 08/03/16 13:32, Lionel Elie Mamane wrote:

> At this point, I'd say, even more strongly than usual: the one
> that will do it will decide. Upgrading to a modern Java-based
> database would maybe not be that bad after all...

 Sounds like I'd better get my finger out then!

 IF I can get the basics in place (and to be honest it is a big
 if), are other people prepared to muck in and help with the bits
 I can't do?

>>> Now, specifically, duckduckgo-ing for "Pick" does not bring the
>>> expected results, so if you could give me some links to see what
>>> you are talking about? Thanks.

>> Found
>> http://www.computerworld.com/article/2579803/business-intelligence/open-source-pick-like-database-being-developed.html
>> which sent me to "MaVerick" which led me to
>> http://www.maverick-dbms.org/doc/index.html

>> I see that it can act as datastore for MySQL and PostgresSQL; this
>> gives the impression that it is a datastore, but there is no SQL
>> layer. What do you intend to use as SQL layer? Develop one?

> Pick, now generically known as MultiValue, is an n-dimensional
> database, and can be shown to be a proper superset of relational.

Sorry to be blunt, but as long as it can be used as relational through
SQL in a way that is close to the consensus of "the usual suspects" of
relational SQL databases, it is acceptable. If it is better, but
different, I don't think it is a good match for Base, an application
and framework built around SQL.

If it can do more, but we can use the "relational SQL subset"
reliably, then fine. But we *do* *need* to address it through SQL, not
some other API/language that is more general.

> So. My plans. Implement a string class (...). Implement the data
> store (...)

> On top of that, an integrity layer that enforces datatypes. (...)

> On top of that we'll need a Pick shell, and a SQL shell.

You mean none of these is done yet? That looks like something for a
somewhat distant future (on the scale of LibreOffice releases), then.

So on the LibreOffice side, we should probably use something else in
the short term. When your thing is ready, we can integrate it.

As I wrote previously, we can offer the choice between several
embedded formats.

> I'll then need a Basic compiler. (...)

> The wikipedia page (what else :-)
> https://en.wikipedia.org/wiki/Pick_operating_system

I didn't go see a page about an "operating system" when looking for a
DBMS...

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

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Wols Lists]

On 09/03/16 18:06, Lionel Elie Mamane wrote:
> On Wed, Mar 09, 2016 at 06:59:08PM +0100, Lionel Elie Mamane wrote:
>> On Tue, Mar 08, 2016 at 08:44:03PM +, Wols Lists wrote:
>>> On 08/03/16 13:32, Lionel Elie Mamane wrote:
> 
 At this point, I'd say, even more strongly than usual: the one that
 will do it will decide. Upgrading to a modern Java-based database
 would maybe not be that bad after all...
> 
>>> Sounds like I'd better get my finger out then!
> 
>>> IF I can get the basics in place (and to be honest it is a big if),
>>> are other people prepared to muck in and help with the bits I can't
>>> do?
> 
>> Now, specifically, duckduckgo-ing for "Pick" does not bring the
>> expected results, so if you could give me some links to see what you
>> are talking about? Thanks.
> 
> Found
> http://www.computerworld.com/article/2579803/business-intelligence/open-source-pick-like-database-being-developed.html
> which sent me to "MaVerick" which led me to
> http://www.maverick-dbms.org/doc/index.html
> 
> I see that it can act as datastore for MySQL and PostgresSQL; this
> gives the impression that it is a datastore, but there is no SQL
> layer. What do you intend to use as SQL layer? Develop one?
> 
Actually, Pick is a full-blown environment - "the database is the
computer". So it's a hell of a lot more than just a datastore. And be
careful, you might get me on to a full-blown advocacy rant ... :-) I'll
try and keep it short, but Relational Technology (ie a First Normal Form
database) is pretty much a con trick. It's a two-dimensional *MODEL*
store, not a *DATA* base. imnsho, a First Normal Form database is in
*serious* breach of Einstein's dictum "Make things as simple as
possible, BUT NO SIMPLER".

Pick, now generically known as MultiValue, is an n-dimensional database,
and can be shown to be a proper superset of relational. As a result it
is smaller, faster, and can do anything relational can do. It's quite
similar to (but a very different heritage from) Cache. And I know
bashing Oracle is a sport, but my favourite Pick war story is a port
from Pick (a variant known as UniVerse) to Oracle. After 6 months hard
work, the Oracle consultants proudly told management that a complicated
query was 10% faster on the Oracle system, than the old UniVerse system.
That is, they were proud until the UniVerse sysadmin said "you mean your
twin Xeon 800 machine is only 10% faster than my Pentium 90?".

So. My plans. Implement a string class that implements the dynamic
arrays that Pick is built on. Implement the data store - a hashed
key-value setup. I didn't realise how widely linear hashing was used
until recently, but it's the technology behind Sleepycat, behind hashed
variables in Perl, and probably a fair few other places as well.

On top of that, an integrity layer that enforces datatypes. This isn't
part of standard multi-value, but imho is a massive omission. It'll be
optional to switch it on, but if enabled it will ensure datatype integrity.

On top of that we'll need a Pick shell, and a SQL shell.

I'll then need a Basic compiler. A lot of stuff gets done in the
database - should be done there - and it's needed for that. That's where
I came a cropper last time I tried. And I got the impression StarBasic
isn't being actively cared for - maybe these two could get together :-)


I know Pick isn't the easiest of topics to google for, but some links
for reading ...

The wikipedia page (what else :-)
https://en.wikipedia.org/wiki/Pick_operating_system

A bit of a critique of Relational vs MultiValue (written by yours truly)
http://grokthelaw.freeforums.net/thread/250/oracle-google

A website about Pick. Note that the second like is again by yours truly...
http://www.pickwiki.com/index.php/Main_Page
http://www.pickwiki.com/index.php/MVDefinition

Rocket Software now owns most of the variants of Pick out there. They
bought U2 off of IBM (which I strongly suspect IBM sold because it was
growing so fast it threatened to swamp their DB2 division - when they
sold it it was 1/3 of the division, and it was reportedly growing at
double figures per annum ...) They then bought out the original Pick
Systems.
http://www.rocketsoftware.com/solutions/dbms-and-application-servers/learn

Then a couple more snippets - I don't know if you've heard of the data
warehouse system called DataStage - owned by IBM. They acquired it when
they bought U2, and they kept it when they sold U2 off. It was based on
UniVerse, a MultiValue system. A large chunk of the banking system
software market is owned by a company called Temenos, and it runs on
jBase, another MultiValue system. If you happen to see a green screen in
a travel agents, this is almost certainly the original Pick - it pretty
much owned that market - and I strongly suspect it's still underneath
modern gui software.

So while you may not see a lot of Pick, there's actually an awful lot
out there. And if you follow my links, you'll see I'm pretty
comtemptuous of relational 

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Wols Lists]

On 09/03/16 17:59, Lionel Elie Mamane wrote:
> On Tue, Mar 08, 2016 at 08:44:03PM +, Wols Lists wrote:
>> On 08/03/16 13:32, Lionel Elie Mamane wrote:
> 
>>> At this point, I'd say, even more strongly than usual: the one that
>>> will do it will decide. Upgrading to a modern Java-based database
>>> would maybe not be that bad after all...
> 
>> Sounds like I'd better get my finger out then!
> 
>> IF I can get the basics in place (and to be honest it is a big if),
>> are other people prepared to muck in and help with the bits I can't
>> do?
> 
> I'll answer a different question: Will Lionel, under his policy of
> "the one that will do it will decide", merge the patch?
> 
> The answer is:
> 
> If it is a well-maintained RDBMS that is reasonably featureful and
> solid, that doesn't bring us in other directions than "the usual
> suspects of the external ones" (MariaDB, PostgreSQL, Microsoft SQL
> Server, H2, HSQLDB2, etc), that it does not introduce undue
> incompatibilities (or difficulties in maintaining compatibility with
> those), that the SQL dialect and behaviour is reasonably close to the
> "common ground" between the "usual suspects", etc. Then yes, I will
> merge the patch.

Well, I did say Pick is a NoSQL database ...

Thing is, does "No" stand for "No" or for "Not Only"?
> 
> If the RDBMS engine is self-implemented, then it has to come with a
> strong commitment to maintaining it, preferably animating a (future)
> development community around it.
> 
That is very much the intent ...
> 
> Also, we are not forced to have only one embedded database format, we
> can have several, so if several people do the work, we can merge the
> several ones.
> 
> 
> Now, specifically, duckduckgo-ing for "Pick" does not bring the
> expected results, so if you could give me some links to see what you
> are talking about? Thanks.
> 
See my response to your next post.

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

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Lionel Elie Mamane]

On Tue, Mar 08, 2016 at 08:44:03PM +, Wols Lists wrote:
> On 08/03/16 13:32, Lionel Elie Mamane wrote:

>> At this point, I'd say, even more strongly than usual: the one that
>> will do it will decide. Upgrading to a modern Java-based database
>> would maybe not be that bad after all...

> Sounds like I'd better get my finger out then!

> IF I can get the basics in place (and to be honest it is a big if),
> are other people prepared to muck in and help with the bits I can't
> do?

I'll answer a different question: Will Lionel, under his policy of
"the one that will do it will decide", merge the patch?

The answer is:

If it is a well-maintained RDBMS that is reasonably featureful and
solid, that doesn't bring us in other directions than "the usual
suspects of the external ones" (MariaDB, PostgreSQL, Microsoft SQL
Server, H2, HSQLDB2, etc), that it does not introduce undue
incompatibilities (or difficulties in maintaining compatibility with
those), that the SQL dialect and behaviour is reasonably close to the
"common ground" between the "usual suspects", etc. Then yes, I will
merge the patch.

If the RDBMS engine is self-implemented, then it has to come with a
strong commitment to maintaining it, preferably animating a (future)
development community around it.


Also, we are not forced to have only one embedded database format, we
can have several, so if several people do the work, we can merge the
several ones.


Now, specifically, duckduckgo-ing for "Pick" does not bring the
expected results, so if you could give me some links to see what you
are talking about? Thanks.

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

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Lionel Elie Mamane]

On Wed, Mar 09, 2016 at 06:59:08PM +0100, Lionel Elie Mamane wrote:
> On Tue, Mar 08, 2016 at 08:44:03PM +, Wols Lists wrote:
>> On 08/03/16 13:32, Lionel Elie Mamane wrote:

>>> At this point, I'd say, even more strongly than usual: the one that
>>> will do it will decide. Upgrading to a modern Java-based database
>>> would maybe not be that bad after all...

>> Sounds like I'd better get my finger out then!

>> IF I can get the basics in place (and to be honest it is a big if),
>> are other people prepared to muck in and help with the bits I can't
>> do?

> Now, specifically, duckduckgo-ing for "Pick" does not bring the
> expected results, so if you could give me some links to see what you
> are talking about? Thanks.

Found
http://www.computerworld.com/article/2579803/business-intelligence/open-source-pick-like-database-being-developed.html
which sent me to "MaVerick" which led me to
http://www.maverick-dbms.org/doc/index.html

I see that it can act as datastore for MySQL and PostgresSQL; this
gives the impression that it is a datastore, but there is no SQL
layer. What do you intend to use as SQL layer? Develop one?

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

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Wols Lists]

On 08/03/16 13:32, Lionel Elie Mamane wrote:
> At this point, I'd say, even more strongly than usual: the one that
> will do it will decide. Upgrading to a modern Java-based database
> would maybe not be that bad after all...

Sounds like I'd better get my finger out then!

IF I can get the basics in place (and to be honest it is a big if), are
other people prepared to muck in and help with the bits I can't do?

Bear in mind I'm quite happy with a relational layer and SQL as an
add-on, but a lot of the "con" points with SQLite, you might feel the
same about Pick. I'm not sure I agree with you there ...

I'm looking at it initially as being a bit like MS Access, the initial
implementation might be single user, but everything is already planned
out in my head. The file format will very rapidly get frozen, so you
won't have all these upgrade headaches ...

At the end of the day, I *WANT* to do this, but I have to be honest and
say my skill-set currently falls a bit short, and I have family issues
that may well get in the way. But I'm going to have a crack at it, if
anyone would care to help? And I'll try and get some help from the Pick
side of the fence, but I'm aware of several attempts at an Open Source
Pick that have never really got off the ground - probably due to lack of
exposure.

And if it gets the exposure, I expect users will start saying "oh, this
is an easy database to use". One of the reasons Pick has a crap
reputation among computer scientists is too many applications were
written by users - like accountants, travel agents, etc etc.

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

Re: Firebird doesn't support MSVC 2015

[Lionel Elie Mamane]

On Sun, Mar 06, 2016 at 06:39:14PM +0100, David Ostrovsky wrote:
> On Fri, 2016-03-04 at 19:59 +0100, Lionel Elie Mamane wrote:
> > On Wed, Mar 02, 2016 at 08:02:39AM +0100, David Ostrovsky wrote:

>>> "I tried to compile fb with MSVC2015.  After fixing macro issues,
>>> you'll see more errors and more serious.  The list of errors is
>>> almost endless. (Of course no, but it's huge.)  There will be
>>> errors that can change the runtime behaviour. So, it's better to
>>> coordinate your efforts with FB devs and not do all yourself."


>> Would a "headlong rush" makes things better? That is, Firebird 3.0
>> has its Release Candidate 2 out now. So we could start using it,
>> and make it non-experimental only with their 3.0 final or something
>> like that?  If it support MSVC2015, maybe even has a fixed build
>> system, then "things get better".

> AFAICT upcoming Firebird 3.0 doesn't support MSVC 2015. Moreover,
> following the discussion on FB developer mailing list, in this thread:
> [1], it turns out, that MSVC 2013 was selected to be used for the next
> FB 4 release, (...)

That discussion is a bit confused between:

1) What will be used to compile the binaries on http://www.firebirdsql.org/

2) What compiler or compiler*s* is/are supported and tested.

If 1) is MSVC2013 but 2) includes MSVC2015 (with developers regularly
using MSVC2015) then I wouldn't be that worried. Although some people
in that thread make that same point, I don't know of they are [core]
developers or outsiders, which would make a difference in the
impression it makes of the recognition by "the project" of these
issues.

IMHO 1) can even be switched between 4.0.5 and 4.0.6 or something like
that :) When Windows XP is "truly dead", even in the corners of
Northern Eurasia :)

Worrying indeed.

> (...) it could be problematic to not being able to upgrade the tool
> chain on Windows for the next 10 years.

We could switch to not linking Firebird "in-house" but "just" bundling
it? The same way our predecessor project used to bundle Java (and
maybe other things)?

Would that seem workable to you guys? Assuming Firebird survives the
fact that Windows 18 will needs binaries compiled with MSVC 2030 or
something like that ;)

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

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Lionel Elie Mamane]

On Mon, Mar 07, 2016 at 02:32:05PM +0200, Noel Grandin wrote:
> On 2016/03/07 2:11 PM, Lionel Elie Mamane wrote:

>> A few examples of how SQLite differs from the SQL standard (be it de facto
>> or de jure standard) in quite deep, fundamental ways:

>>  * lack of other datatypes than "integer", "real" (float), "string of 
>> characaters"
>>and "string of bytes": the basic ones are dates, times, timestamps.

>>  * lack of datatype checking; one can insert "noel" in a column of
>>type "integer"

>>  * type attached to value, not to column

> That is true, but we could implement basic checking of our own on
> top of that,

Maybe we could even convince SQLite to do the checking by
systematically inserting "CHECK" constraints on the columns.

Again, all these "yes, we can do this ourselves" brings me back to my
impression of "we can build a DBMS like we need on top of SQLite, but
SQLite is not it". If someone wants to build their own "DBMS like we
need" on top of SQLite, and MAINTAIN IT, then sure, we can use that in
LibreOffice. It can even be called "the SQLibreOfficeIte, or SQLOite
or some combination of LibreOffice and SQLite.

> or just ignore it, and rely on the user getting it right most of the
> time (which they normally do). And when they don't, it is a rather
> soft failure mode in SQLite.

No, I don't think so, because lack of data canonicalisation leads to
*wrong* *results* in queries.

See e.g. https://bugs.documentfoundation.org/show_bug.cgi?id=38811#c21
for examples around dates, times and timestamps.

> I suppose we can just keep limping along with our current state of
> affairs, (...) But it would be nice to upgrade to something a
> little more modern, and Firebird is not really working out for us,
> and what other options do we really have?

Well... In some way, for a whole class of users, it does not matter
much since they use external databases anyway. We could even axe the
embedded database. In another way, the concept of an external database
flies over the head of many users, so we lose a whole class of
users. Plus there are good uses for the "just copy this one file and
you get everything" of an embedded database. In that "other way",
"limping along" is a slow, agonising death. *Anything* that works and
is maintained is better than the current situation: HSQLDB2, H2, a
Firebird that compiles with recent compilers (and will continue to),
...

At this point, I'd say, even more strongly than usual: the one that
will do it will decide. Upgrading to a modern Java-based database
would maybe not be that bad after all...

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

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Caolán McNamara]

On Mon, 2016-03-07 at 16:11 +0100, Lionel Elie Mamane wrote:
> On Tue, Mar 08, 2016 at 02:06:07AM +1100, Chris Sherlock wrote:
> > Is HSQLDB out of the question?
> 
> HSQLDB2 and H2 are good choices if we decide to stay with a Java-
> based
> one (which brings performance problems because of the slowness of
> crossing the C++-to-Java barrier).

IIRC we don't bundle a java runtime into our windows builds which is
another nuisance wrt java components. We rely on there being one
already installed which isn't guaranteed to be the case.

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

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Chris Sherlock]

I understand, but the situation with Firebird seems less than ideal, at least 
in terms of Windows builds at any rate. 

Are the tests really that much slower? Obviously we are relying on having a 
Java installation to test out Base. 

Can we isolate those things that we can test on sqlite to sqlite, and any other 
things to HSQLDB2 or H2? If/when sqlite or some other more appropriate embedded 
database comes along, then we can consider switching. 

Oh, and I’m not sure if this brings much to the table, but I wonder if we can 
simulate joins. After all, to get a right join you just swap tables, and you 
can actually simulate a full outer join with just a combination of other joins. 

Chris

> On 8 Mar 2016, at 2:11 AM, Lionel Elie Mamane  wrote:
> 
> On Tue, Mar 08, 2016 at 02:06:07AM +1100, Chris Sherlock wrote:
>> Is HSQLDB out of the question?
> 
> HSQLDB2 and H2 are good choices if we decide to stay with a Java-based
> one (which brings performance problems because of the slowness of
> crossing the C++-to-Java barrier).
> 
>>> On 7 Mar 2016, at 11:32 PM, Noel Grandin  wrote:
>>> 
>>> 
>>> 
 On 2016/03/07 2:11 PM, Lionel Elie Mamane wrote:
 On Mon, Mar 07, 2016 at 08:23:53AM +0200, Noel Grandin wrote:
 A few examples of how SQLite differs from the SQL standard (be it de facto
 or de jure standard) in quite deep, fundamental ways:
 
 * lack of other datatypes than "integer", "real" (float), "string of 
 characaters"
   and "string of bytes": the basic ones are dates, times, timestamps.
 
 * lack of datatype checking; one can insert "noel" in a column of
   type "integer"
 
 * type attached to value, not to column
>>> 
>>> 
>>> That is true, but we could implement basic checking of our own on top of 
>>> that, or just ignore it, and rely on the user getting it right most of the 
>>> time (which they normally do). And when they don't, it is a rather soft 
>>> failure mode in SQLite.
>>> 
>>> 
 
 Also annoying, but can be worked around:
>>> 
>>> Yeah, that's what I mean - there are other issues, but they can be worked 
>>> around.
>>> 
>>> I suppose we can just keep limping along with our current state of affairs, 
>>> it's not like Base is that widely used, or particularly vital to our future.
>>> 
>>> But it would be nice to upgrade to something a little more modern, and 
>>> Firebird is not really working out for us, and what other options do we 
>>> really have?
>>> 
>>> At least SQLite is widely used and moving forward at a reasonable rate.
>>> 
>>> Regards, Noel.
>>> 
>>> ___
>>> LibreOffice mailing list
>>> LibreOffice@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>> 

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

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Lionel Elie Mamane]

On Tue, Mar 08, 2016 at 02:06:07AM +1100, Chris Sherlock wrote:
> Is HSQLDB out of the question?

HSQLDB2 and H2 are good choices if we decide to stay with a Java-based
one (which brings performance problems because of the slowness of
crossing the C++-to-Java barrier).

> > On 7 Mar 2016, at 11:32 PM, Noel Grandin  wrote:
> > 
> > 
> > 
> >> On 2016/03/07 2:11 PM, Lionel Elie Mamane wrote:
> >> On Mon, Mar 07, 2016 at 08:23:53AM +0200, Noel Grandin wrote:
> >> A few examples of how SQLite differs from the SQL standard (be it de facto
> >> or de jure standard) in quite deep, fundamental ways:
> >> 
> >>  * lack of other datatypes than "integer", "real" (float), "string of 
> >> characaters"
> >>and "string of bytes": the basic ones are dates, times, timestamps.
> >> 
> >>  * lack of datatype checking; one can insert "noel" in a column of
> >>type "integer"
> >> 
> >>  * type attached to value, not to column
> > 
> > 
> > That is true, but we could implement basic checking of our own on top of 
> > that, or just ignore it, and rely on the user getting it right most of the 
> > time (which they normally do). And when they don't, it is a rather soft 
> > failure mode in SQLite.
> > 
> > 
> >> 
> >> Also annoying, but can be worked around:
> > 
> > Yeah, that's what I mean - there are other issues, but they can be worked 
> > around.
> > 
> > I suppose we can just keep limping along with our current state of affairs, 
> > it's not like Base is that widely used, or particularly vital to our future.
> > 
> > But it would be nice to upgrade to something a little more modern, and 
> > Firebird is not really working out for us, and what other options do we 
> > really have?
> > 
> > At least SQLite is widely used and moving forward at a reasonable rate.
> > 
> > Regards, Noel.
> > 
> > ___
> > LibreOffice mailing list
> > LibreOffice@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/libreoffice
> 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Chris Sherlock]

Is HSQLDB out of the question?

Chris

Sent from my iPhone

> On 7 Mar 2016, at 11:32 PM, Noel Grandin  wrote:
> 
> 
> 
>> On 2016/03/07 2:11 PM, Lionel Elie Mamane wrote:
>> On Mon, Mar 07, 2016 at 08:23:53AM +0200, Noel Grandin wrote:
>> A few examples of how SQLite differs from the SQL standard (be it de facto
>> or de jure standard) in quite deep, fundamental ways:
>> 
>>  * lack of other datatypes than "integer", "real" (float), "string of 
>> characaters"
>>and "string of bytes": the basic ones are dates, times, timestamps.
>> 
>>  * lack of datatype checking; one can insert "noel" in a column of
>>type "integer"
>> 
>>  * type attached to value, not to column
> 
> 
> That is true, but we could implement basic checking of our own on top of 
> that, or just ignore it, and rely on the user getting it right most of the 
> time (which they normally do). And when they don't, it is a rather soft 
> failure mode in SQLite.
> 
> 
>> 
>> Also annoying, but can be worked around:
> 
> Yeah, that's what I mean - there are other issues, but they can be worked 
> around.
> 
> I suppose we can just keep limping along with our current state of affairs, 
> it's not like Base is that widely used, or particularly vital to our future.
> 
> But it would be nice to upgrade to something a little more modern, and 
> Firebird is not really working out for us, and what other options do we 
> really have?
> 
> At least SQLite is widely used and moving forward at a reasonable rate.
> 
> Regards, Noel.
> 
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Noel Grandin]

On 2016/03/07 2:11 PM, Lionel Elie Mamane wrote:

On Mon, Mar 07, 2016 at 08:23:53AM +0200, Noel Grandin wrote:
A few examples of how SQLite differs from the SQL standard (be it de facto
or de jure standard) in quite deep, fundamental ways:

  * lack of other datatypes than "integer", "real" (float), "string of 
characaters"
and "string of bytes": the basic ones are dates, times, timestamps.

  * lack of datatype checking; one can insert "noel" in a column of
type "integer"

  * type attached to value, not to column




That is true, but we could implement basic checking of our own on top of that, or just ignore it, and rely on the user 
getting it right most of the time (which they normally do). And when they don't, it is a rather soft failure mode in SQLite.





Also annoying, but can be worked around:



Yeah, that's what I mean - there are other issues, but they can be worked 
around.

I suppose we can just keep limping along with our current state of affairs, it's not like Base is that widely used, or 
particularly vital to our future.


But it would be nice to upgrade to something a little more modern, and Firebird is not really working out for us, and 
what other options do we really have?


At least SQLite is widely used and moving forward at a reasonable rate.

Regards, Noel.

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

alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

[Lionel Elie Mamane]

On Mon, Mar 07, 2016 at 08:23:53AM +0200, Noel Grandin wrote:

> In the space of open-source SQL database engines, SQLite is far and
> away the most widely used and supported option.

> Maybe we should try using that instead?

A few examples of how SQLite differs from the SQL standard (be it de facto
or de jure standard) in quite deep, fundamental ways:

 * lack of other datatypes than "integer", "real" (float), "string of 
characaters"
   and "string of bytes": the basic ones are dates, times, timestamps.

 * lack of datatype checking; one can insert "noel" in a column of
   type "integer"

 * type attached to value, not to column

These can be worked around in an application that is written
specifically for SQLite, but are thorns in the case of an application
(like LibreOffice) that targets the "general SQL standard / de facto
agreement", and *wants* rely on the DBMS for error-checking.

Also annoying, but can be worked around:

 * lack of "RIGHT JOIN"

It might not be obvious why lack of "RIGHT JOIN" is
annoying, since:

 1) one can switch the order of tables, and right to left

 2) the above switch can be done, since SQLite supports parenthesised
joins [which is not guaranteed by the basic SQL standard]

The answer lies in compatibility with other databases, that support
LEFT and RIGHT, but not parenthesised joins. We could have a
compatibility flag that says "do things the first way vs do them the
second way". We already have some flags like that :)

I haven't even started talking about missing features, like e.g. FULL
OUTER JOIN.

Or bite the GPL bullet and embed MariaDB.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Firebird doesn't support MSVC 2015

[Noel Grandin]

In the space of open-source SQL database engines, SQLite is far and away the 
most widely used and supported option.

Maybe we should try using that instead?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Firebird doesn't support MSVC 2015

[David Ostrovsky]

Hi Lionel, 

On Fri, 2016-03-04 at 19:59 +0100, Lionel Elie Mamane wrote:
> On Wed, Mar 02, 2016 at 08:02:39AM +0100, David Ostrovsky wrote:
> 
> > So, after fixing number of MSVC 14.0 related bugs in FB
> > module: [1], I filed this bug upstream: [2] and got there
> > this comment from Egor Pugin:
> 
> > "I tried to compile fb with MSVC2015. 
> > After fixing macro issues, you'll see more errors and more serious.
> > The
> > list of errors is almost endless. (Of course no, but it's huge.) 
> > There will be errors that can change the runtime behaviour. So,
> > it's
> > better to coordinate your efforts with FB devs and not do all
> > yourself." 
> 

[...]

> Would a "headlong rush" makes things better? That is, Firebird 3.0
> has
> its Release Candidate 2 out now. So we could start using it, and make
> it non-experimental only with their 3.0 final or something like that?
> If it support MSVC2015, maybe even has a fixed build system, then
> "things get better".

AFAICT upcoming Firebird 3.0 doesn't support MSVC 2015. Moreover,
following the discussion on FB developer mailing list, in this thread:
[1], it turns out, that MSVC 2013 was selected to be used for the next
FB 4 release, that tentatively expected to land in 2020 (info from the
mentioned thread). IOW, we can hope that FB > 4 will eventually support
MSVC 2015, something around 2025. Given that Python 3.5, that this
project currently depends on, dropped support for MSVC 2013, it could
be problematic to not being able to upgrade the tool chain on Windows
for the next 10 years.

* [1] [Firebird-devel] Compiler for official Firebird 4 release on
Windows
http://www.mail-archive.com/firebird-devel@lists.sourceforge.net/msg112
99.html

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

Re: Firebird doesn't support MSVC 2015

[Lionel Elie Mamane]

On Wed, Mar 02, 2016 at 08:02:39AM +0100, David Ostrovsky wrote:

> So, after fixing number of MSVC 14.0 related bugs in FB
> module: [1], I filed this bug upstream: [2] and got there
> this comment from Egor Pugin:

> "I tried to compile fb with MSVC2015. 
> After fixing macro issues, you'll see more errors and more serious. The
> list of errors is almost endless. (Of course no, but it's huge.) 
> There will be errors that can change the runtime behaviour. So, it's
> better to coordinate your efforts with FB devs and not do all
> yourself." 

> I see two options:

> * Declare FB only supported on platforms, where it can be built with
> current compiler toolchain that is used and decided by this project. 
> * Cancel MSVC 14.0 upgrade for now and wait until it's supported by FB
> project

Would a "headlong rush" makes things better? That is, Firebird 3.0 has
its Release Candidate 2 out now. So we could start using it, and make
it non-experimental only with their 3.0 final or something like that?
If it support MSVC2015, maybe even has a fixed build system, then
"things get better".

Popa Marius Adrian once made some steps in that direction:
https://gist.github.com/mariuz/bcde7f783b657b2465e5

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

Re: Firebird doesn't support MSVC 2015

[Andrzej Hunt]

Having spent some more time using SQLite recent I don't think it would be a bad 
choice for the default embedded DB. Yes it lacks type checking, but it's well 
tested, seems to be easier to build, and is much more widely used.

The reason we wanted a new DB was to allow using Base without the Java 
dependency, i.e. to allow more people to try Base easily. The reason we went 
for firebird instead of SQLite was the lack of type checking/dynamic type 
system that SQLite has. In hindsight I feel like this isn't actually a huge 
issue for the average user who probably just wants to build something simple in 
Base. (A bunch of well known of real life applications rely on SQLite without 
issues.)

Note: if someone is truly concerned about the underlying database I suspect 
they should be running their own external DB, which lets them choose from a 
large number of DBs (I'm not a base expert though, don't quote me on this...). 
All we're doing here is setting the default DB when you create a .odb work an 
embedded DB.

One issue that would need investigating is forwards compatibility - which I 
discovered potentially doesn't exist between eg SQLite 3.8 and 3.6. So maybe 
this isn't actually a good solution either, unless we'd stick to one version of 
SQLite across LO versions.

- Andrzej

On 3 March 2016 09:53:40 GMT-08:00, Jonathan Aquilina  
wrote:
>Instead of reinventing the wheel why not look at SQLite or there is a
>nosql
>db couchdb as well but not sure how easy that would be to integrate
>with LO
>
>This email has been sent from a virus-free computer protected by Avast.
>www.avast.com
>
><#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>Jonathan Aquilina
>
>On Thu, Mar 3, 2016 at 6:50 PM, Wols Lists 
>wrote:
>
>> On 02/03/16 12:12, Noel Grandin wrote:
>> >
>> >
>> > On 2016/03/02 2:11 PM, Michael Stahl wrote:
>> >>
>> >> personally i'd be inclined towards alternatives that are less
>likely to
>> >> trigger toolchain problems - maybe there's a SQL database
>implemented
>> >> in, say, Java somewhere...
>> >>
>> >
>> > Maybe even one that shares a committer with LO ?
>> >
>> :-)
>>
>> Sounds like I ought to get my finger out :-)
>>
>> I want to write a NoSQL database (a Pick derivative) and the plan is
>to
>> do it and make it part of LibreOffice. Problem is, as a carer, I find
>it
>> very hard to get the time available to concentrate, and I also don't
>> have all the skills I need.
>>
>> Anyways, I will try and have a crack at it - life seems to be getting
>a
>> bit easier at the moment - and see where it takes us.
>>
>> For those who know me, I am very much anti relational practice - imho
>> it's impossible to write an efficient truly relational database - the
>> theory has technical flaws that seriously impact any FNF engine.
>> Basically, that (in contravention of Einstein's dictum) the engine is
>> *too* *simple*, which means that any applications *must* be *overly*
>> *complex*. I'll wax lyrical if you like but you'd be wise not to get
>me
>> started :-)
>>
>> My main problem is that a Pick database is actually a complete
>operating
>> environment. Fundamental to its operation is its language, called
>> DATABASIC, and while I could probably write the database engine
>without
>> too much difficulty, writing the language compiler is a step too far
>at
>> the moment.
>>
>> Anyways, here's to having a go - if anyone's mad enough to join me,
>great!
>>
>> Cheers,
>> Wol
>> ___
>> LibreOffice mailing list
>> LibreOffice@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>>
>
>
>
>
>___
>LibreOffice mailing list
>LibreOffice@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Firebird doesn't support MSVC 2015

[Wols Lists]

On 04/03/16 16:09, Andrzej Hunt wrote:
> One issue that would need investigating is forwards compatibility -
> which I discovered potentially doesn't exist between eg SQLite 3.8 and
> 3.6. So maybe this isn't actually a good solution either, unless we'd
> stick to one version of SQLite across LO versions.

Where Pick scores :-)

All the smarts are in the code, the basic data structure has hardly
altered since it was originally written at the end of the 60s. The
problem is that Relational explicitly hides the internal structure, Pick
exposes it as part of the user API.

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

Re: Firebird doesn't support MSVC 2015

[Wols Lists]

On 03/03/16 17:53, Jonathan Aquilina wrote:
> Instead of reinventing the wheel why not look at SQLite or there is a
> nosql db couchdb as well but not sure how easy that would be to
> integrate with LO

Is SQLite a relational db? In which case it's no interest to me ... :-)

As for other nosql dbs, the reason I would go down the Pick route is it
is the database technology I understand. And unfortunately I do not know
of a Pick database under a Free licence :-( which is a good reason for
wanting to write one :-)

If you come across a Pick DB called OpenQM I would advise you not to
touch it with a bargepole unless your sole purpose is playing/personal
use :-( Shame, as it's actually a very nice product.

If anybody else has any ideas, don't wait on me!!!

Cheers,
Wol
> 
> This email has been sent from a virus-free computer protected by Avast.
> www.avast.com
> 
> 
> 
> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> Jonathan Aquilina
> 
> On Thu, Mar 3, 2016 at 6:50 PM, Wols Lists  > wrote:
> 
> On 02/03/16 12:12, Noel Grandin wrote:
> >
> >
> > On 2016/03/02 2:11 PM, Michael Stahl wrote:
> >>
> >> personally i'd be inclined towards alternatives that are less
> likely to
> >> trigger toolchain problems - maybe there's a SQL database implemented
> >> in, say, Java somewhere...
> >>
> >
> > Maybe even one that shares a committer with LO ?
> >
> :-)
> 
> Sounds like I ought to get my finger out :-)
> 
> I want to write a NoSQL database (a Pick derivative) and the plan is to
> do it and make it part of LibreOffice. Problem is, as a carer, I find it
> very hard to get the time available to concentrate, and I also don't
> have all the skills I need.
> 
> Anyways, I will try and have a crack at it - life seems to be getting a
> bit easier at the moment - and see where it takes us.
> 
> For those who know me, I am very much anti relational practice - imho
> it's impossible to write an efficient truly relational database - the
> theory has technical flaws that seriously impact any FNF engine.
> Basically, that (in contravention of Einstein's dictum) the engine is
> *too* *simple*, which means that any applications *must* be *overly*
> *complex*. I'll wax lyrical if you like but you'd be wise not to get me
> started :-)
> 
> My main problem is that a Pick database is actually a complete operating
> environment. Fundamental to its operation is its language, called
> DATABASIC, and while I could probably write the database engine without
> too much difficulty, writing the language compiler is a step too far at
> the moment.
> 
> Anyways, here's to having a go - if anyone's mad enough to join me,
> great!
> 
> Cheers,
> Wol
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> 
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
> 
> 

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

Re: Firebird doesn't support MSVC 2015

[Jonathan Aquilina]

Instead of reinventing the wheel why not look at SQLite or there is a nosql
db couchdb as well but not sure how easy that would be to integrate with LO

This email has been sent from a virus-free computer protected by Avast.
www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Jonathan Aquilina

On Thu, Mar 3, 2016 at 6:50 PM, Wols Lists  wrote:

> On 02/03/16 12:12, Noel Grandin wrote:
> >
> >
> > On 2016/03/02 2:11 PM, Michael Stahl wrote:
> >>
> >> personally i'd be inclined towards alternatives that are less likely to
> >> trigger toolchain problems - maybe there's a SQL database implemented
> >> in, say, Java somewhere...
> >>
> >
> > Maybe even one that shares a committer with LO ?
> >
> :-)
>
> Sounds like I ought to get my finger out :-)
>
> I want to write a NoSQL database (a Pick derivative) and the plan is to
> do it and make it part of LibreOffice. Problem is, as a carer, I find it
> very hard to get the time available to concentrate, and I also don't
> have all the skills I need.
>
> Anyways, I will try and have a crack at it - life seems to be getting a
> bit easier at the moment - and see where it takes us.
>
> For those who know me, I am very much anti relational practice - imho
> it's impossible to write an efficient truly relational database - the
> theory has technical flaws that seriously impact any FNF engine.
> Basically, that (in contravention of Einstein's dictum) the engine is
> *too* *simple*, which means that any applications *must* be *overly*
> *complex*. I'll wax lyrical if you like but you'd be wise not to get me
> started :-)
>
> My main problem is that a Pick database is actually a complete operating
> environment. Fundamental to its operation is its language, called
> DATABASIC, and while I could probably write the database engine without
> too much difficulty, writing the language compiler is a step too far at
> the moment.
>
> Anyways, here's to having a go - if anyone's mad enough to join me, great!
>
> Cheers,
> Wol
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Firebird doesn't support MSVC 2015

[Wols Lists]

On 02/03/16 12:12, Noel Grandin wrote:
> 
> 
> On 2016/03/02 2:11 PM, Michael Stahl wrote:
>>
>> personally i'd be inclined towards alternatives that are less likely to
>> trigger toolchain problems - maybe there's a SQL database implemented
>> in, say, Java somewhere...
>>
> 
> Maybe even one that shares a committer with LO ?
> 
:-)

Sounds like I ought to get my finger out :-)

I want to write a NoSQL database (a Pick derivative) and the plan is to
do it and make it part of LibreOffice. Problem is, as a carer, I find it
very hard to get the time available to concentrate, and I also don't
have all the skills I need.

Anyways, I will try and have a crack at it - life seems to be getting a
bit easier at the moment - and see where it takes us.

For those who know me, I am very much anti relational practice - imho
it's impossible to write an efficient truly relational database - the
theory has technical flaws that seriously impact any FNF engine.
Basically, that (in contravention of Einstein's dictum) the engine is
*too* *simple*, which means that any applications *must* be *overly*
*complex*. I'll wax lyrical if you like but you'd be wise not to get me
started :-)

My main problem is that a Pick database is actually a complete operating
environment. Fundamental to its operation is its language, called
DATABASIC, and while I could probably write the database engine without
too much difficulty, writing the language compiler is a step too far at
the moment.

Anyways, here's to having a go - if anyone's mad enough to join me, great!

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

Re: Firebird doesn't support MSVC 2015

[Stephan Bergmann]

On 03/02/2016 07:25 PM, Alexander Thurgood wrote:

Toolchain problems on OSX with firebird too...currently not building
with firebird enabled in my own master builds, as the build fails each
time when I do.


* "When building LibreOffice on OS X 10.11 you currently need to use at 
least --disable-firebird-sdbc." 
()


* See 
 
"Compilation on OS X 10.11" for why you might need to explicitly 
configure --disable-firebird-sdbc, and why it might be set implicitly 
instead, depending on your master revision.


* See the commit message of 
 
"Allow external/firebird to be built with a custom SHELL under Mac OS X 
10.11" for how to build external/firebird on 10.11 after all ("build 
your own bash and pass it to make with SHELL=...").


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

Re: Firebird doesn't support MSVC 2015

[julien2412]

Alex Thurgood wrote
> Le 02/03/2016 13:12, Noel Grandin a écrit :
> 
> 
> Toolchain problems on OSX with firebird too...currently not building
> with firebird enabled in my own master builds, as the build fails each
> time when I do.
> 
> Alternatives to an experimental feature that never got off the ground,
> interesting, but please not another Java db, no matter how good it is
> (and I actually really like h2 fwiw).
> 
> If the inclination is to go back to Java db (so much for getting rid of
> the Java dependencies), why not just upgrade hsqldb to the latest, and
> stuff backwards compatibility ?

Idem for me, impossible to build:
...
make[4]: Entering directory
'/Users/XXX/lo/lode/dev/core/workdir/UnpackedTarball/firebird/gen'
rm -f -f msg.fdb
echo create database \'msg.fdb\'\; | ../gen/firebird/bin/isql_static
dyld: Library not loaded:
@__OOO/libicuuc.dylib.56
  Referenced from:
/Users/XXX/lo/lode/dev/core/workdir/UnpackedTarball/firebird/gen/../gen/firebird/bin/isql_static
  Reason: image not found
/bin/sh: line 1:  2819 Doneecho create database
\'msg.fdb\'\;
  2820 Trace/BPT trap: 5   | ../gen/firebird/bin/isql_static
../gen/Makefile.refDatabases:91: recipe for target 'msg.timestamp' failed
make[4]: *** [msg.timestamp] Error 133
make[4]: Leaving directory
'/Users/XXX/lo/lode/dev/core/workdir/UnpackedTarball/firebird/gen'
Makefile:278: recipe for target 'ref_databases' failed
...
with master sources updated some days ago.

Even it would build, there are still lots of things to deal with it (see
bugreports).

I tried to build with a newer HSQLDB version but was stuck by packaging
stuff (it seems there's a bug workaround with our packaging of current
HSQLDB version, I don't remember the details).

I agree we should get rid of Java part (and so HSQLDB) but meanwhile we're a
bit stuck.

Julien



--
View this message in context: 
http://nabble.documentfoundation.org/Firebird-doesn-t-support-MSVC-2015-tp4177149p4177220.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Firebird doesn't support MSVC 2015

[David Ostrovsky]

Hi Miklos,

On Wed Mar 2 08:56:14 UTC 2016, Miklos Vajna wrote:

>>On Wed, Mar 02, 2016 at 08:02:39AM +0100, David Ostrovsky wrote:
>> I see two options:
>> * Declare FB only supported on platforms, where it can be built with
>> current compiler toolchain that is used and decided by this project.
[...]

>What are the other blockers at the moment?

All problems (except FB) should be sorted out by now.

> The wiki states that 32-bit >build is broken, that sounds like a
>blocker as well. (Or is it just >that the wiki is outdated?
>configure.ac:5277 suggests it's up to date.)

Yes, wiki was outdated, should be fixed now. Thanks for noticing.


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

Re: Firebird doesn't support MSVC 2015

[Alexander Thurgood]

Le 02/03/2016 13:12, Noel Grandin a écrit :


Toolchain problems on OSX with firebird too...currently not building
with firebird enabled in my own master builds, as the build fails each
time when I do.

Alternatives to an experimental feature that never got off the ground,
interesting, but please not another Java db, no matter how good it is
(and I actually really like h2 fwiw).

If the inclination is to go back to Java db (so much for getting rid of
the Java dependencies), why not just upgrade hsqldb to the latest, and
stuff backwards compatibility ?



Alex


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

Re: Firebird doesn't support MSVC 2015

[Noel Grandin]

On 2016/03/02 2:11 PM, Michael Stahl wrote:


personally i'd be inclined towards alternatives that are less likely to
trigger toolchain problems - maybe there's a SQL database implemented
in, say, Java somewhere...



Maybe even one that shares a committer with LO ?

http://h2database.com/html/main.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Firebird doesn't support MSVC 2015

[Michael Stahl]

On 02.03.2016 12:44, Stephan Bergmann wrote:
> On 03/02/2016 12:32 PM, Michael Stahl wrote:
>> i think we can do without firebird for now, it's an experimental feature
>> anyway so it can be fixed at a later time when somebody gets around to it.
> 
> Given how firebird keeps popping up as one of the worst external modules 
> whenever you fiddle with a new toolchain, are we sure it'll ever get out 
> of the experimental feature status?  Or would it be time to search for 
> better alternatives right from the start?

personally i'd be inclined towards alternatives that are less likely to
trigger toolchain problems - maybe there's a SQL database implemented
in, say, Java somewhere...


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

Re: Firebird doesn't support MSVC 2015

[Stephan Bergmann]

On 03/02/2016 12:32 PM, Michael Stahl wrote:

i think we can do without firebird for now, it's an experimental feature
anyway so it can be fixed at a later time when somebody gets around to it.


Given how firebird keeps popping up as one of the worst external modules 
whenever you fiddle with a new toolchain, are we sure it'll ever get out 
of the experimental feature status?  Or would it be time to search for 
better alternatives right from the start?

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

Re: Firebird doesn't support MSVC 2015

[Michael Stahl]

On 02.03.2016 08:02, David Ostrovsky wrote:
> 
> So, after fixing number of MSVC 14.0 related bugs in FB
> module: [1], I filed this bug upstream: [2] and got there
> this comment from Egor Pugin:
> 
> "I tried to compile fb with MSVC2015. 
> After fixing macro issues, you'll see more errors and more serious. The
> list of errors is almost endless. (Of course no, but it's huge.) 
> There will be errors that can change the runtime behaviour. So, it's
> better to coordinate your efforts with FB devs and not do all
> yourself." 

ok, sounds like there is some work to do...

> I see two options:
> 
> * Declare FB only supported on platforms, where it can be built with
> current compiler toolchain that is used and decided by this project. 
> * Cancel MSVC 14.0 upgrade for now and wait until it's supported by FB
> project

i think we can do without firebird for now, it's an experimental feature
anyway so it can be fixed at a later time when somebody gets around to it.


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

Re: Firebird doesn't support MSVC 2015

[Miklos Vajna]

Hi,

On Wed, Mar 02, 2016 at 08:02:39AM +0100, David Ostrovsky  
wrote:
> I see two options:
> 
> * Declare FB only supported on platforms, where it can be built with
> current compiler toolchain that is used and decided by this project. 
> * Cancel MSVC 14.0 upgrade for now and wait until it's supported by FB
> project

What are the other blockers at the moment? The wiki states that 32-bit
build is broken, that sounds like a blocker as well. (Or is it just that
the wiki is outdated? configure.ac:5277 suggests it's up to date.)

Regards,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Firebird doesn't support MSVC 2015

[David Ostrovsky]

So, after fixing number of MSVC 14.0 related bugs in FB
module: [1], I filed this bug upstream: [2] and got there
this comment from Egor Pugin:

"I tried to compile fb with MSVC2015. 
After fixing macro issues, you'll see more errors and more serious. The
list of errors is almost endless. (Of course no, but it's huge.) 
There will be errors that can change the runtime behaviour. So, it's
better to coordinate your efforts with FB devs and not do all
yourself." 

I see two options:

* Declare FB only supported on platforms, where it can be built with
current compiler toolchain that is used and decided by this project. 
* Cancel MSVC 14.0 upgrade for now and wait until it's supported by FB
project

* [1] https://gerrit.libreoffice.org/22757
* [2] http://tracker.firebirdsql.org/browse/CORE-5120
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice