Recent

Author Topic: Installing sqlite3laz 0.4, IDE rebuilds and links ok but won't restart  (Read 601 times)

PaulANormanNZ

  • Jr. Member
  • **
  • Posts: 93
Hi,

I've had a read around other Forum postings, but haven't quite found this situation yet.

Quite simply using Package/Install Uninstal Packages to attempt and install sqlite3laz 0.4

Everything goes fine no error messages, then after the IDE has linked and made its .exe it goes to restart.

Then a dialog box comes up saying that it can not.

Quote
"The application was unable to start correctly (0x000007b). Click ok to close the application."

I can delete the .exe and restore "lazarus.old.exe", but can not understand why the IDE rebuilds, links ok but won't execute sucessfully.

Any help please?
Paul

Lazarus 1.8.4 r57972 FPC 3.0.4 x86_64-win64-win32/win64


GetMem

  • Hero Member
  • *****
  • Posts: 3495
Hi Paul,

Just download SQLite3.dll and copy to Lazarus folder. Make sure the bitness are the same.

PaulANormanNZ

  • Jr. Member
  • **
  • Posts: 93
Thanks very much for that,

I got the needed dll from https://sqlite.org/index.html

When I read https://wiki.lazarus.freepascal.org/SQLite
I knew that I would need a DLL for distributed projects,
but neither there,

Quote
SQLite is an embedded (non-server) single-user database that can be used in FPC and Lazarus applications. Various drivers can be used to access SQLite from FPC/Lazarus programs. All drivers do need the SQLite library/dll in the executable directory (which can be your project directory or e.g. (projectdir)/lib/architecture/ depending on your Lazarus project settings) (and distributed with your executable) in order to work ...

nor in the component "Package Info" is anything said about a DLL being needed for the Lazarus IDE.

From the Install/Uninstall Packahes Dialogue:

Quote
Author: Luiz Américo Pereira Câmara
Description / Abstract: TSqlite3Dataset class package

License: Modified LGPL

Filename:  E:\lazarus\components\sqlite\sqlite3laz.lpk
Current state: not installed, RunAndDesignTime

I even looked in \lazarus\components\sqlite there is only a README.txt file in a subdirectory... lib/README.txt  which says...

Quote
Output directory of package SQLiteLaz

Would it seem useful, especially at the install phase- that the "Package info" would include mention of any dependancies and where to get them from?

Thanks again,
Paul
« Last Edit: July 20, 2019, 06:31:38 am by PaulANormanNZ »

GetMem

  • Hero Member
  • *****
  • Posts: 3495
Quote
Would it seem useful, especially at the install phase- that the "Package info" would include mention of any dependancies and where to get them from?
It would be useful in my opinion. What message do you have in mind?
« Last Edit: July 17, 2019, 10:28:24 am by GetMem »

PaulANormanNZ

  • Jr. Member
  • **
  • Posts: 93
Thanks for that,

Just my personal oppinion, these components that are part of the official releases could have a thing required where by there must be a wiki entry like the https://wiki.lazarus.freepascal.org/SQLite and text in the package (especially that which appears in component intall window) showing the address of the wiki entry even just for copy and pasting in a browser.

Blender.org is an Open Source project that has led the way in this - in that they require proper documentation before anythhing can be officially released. And it really works there. (And that is a truly mammoth project!)

One advantage of such an approach, is that a wiki can be updated, as I would suggest may be helpful in this specific SQLite3 case, so that even after release - a component set's information can be revised where needed - whereas information contained within an official install component is, well, quite static until the next update is done by the individual  developer user of component(s).

Perhaps here with SQLite3 - the installation information could include a simple statement,

Quote
"There are required binary file dependancies for IDE installation and project distribution, please see:
https://wiki.lazarus.freepascal.org/SQLite for information and instructions."

The Lazarus "Online Package Manager" sometimes provides live links to the developers' websites. Which is a great help too.
But as that is fickle, I wonder there too, if a https://wiki.lazarus.freepascal.org/ entry (even just pointing to the componet developer's current web site if one is maintained) would still be a great help in all events?

Certainly something like this, could cut down on otherwise unnecessary Forum traffic here :-)

 
« Last Edit: July 17, 2019, 01:05:09 pm by PaulANormanNZ »

GetMem

  • Hero Member
  • *****
  • Posts: 3495
Quote
Perhaps here with SQLite3 - the installation information could include a simple statement:
"There are required binary file dependancies for IDE installation and project distribution, please see:
https://wiki.lazarus.freepascal.org/SQLite for information and instructions."
I updated the "package info", it will be available in the next major release or you can test it with Lazarus Trunk(see attached image). Thanks for the suggestion.

Quote
Just my personal opinion, these components that are part of the official releases could have a thing required where by there must be a wiki entry like the https://wiki.lazarus.freepascal.org/SQLite and text in the package (especially that which appears in component intall window) showing the address of the wiki entry even just for copy and pasting in a browser.
It's a good idea, but creating a wiki page for each package requires a lot of work.

Quote
The Lazarus "Online Package Manager" sometimes provides live links to the developers' websites. Which is a great help too.
Unfortunately at least 40% of the packages are no longer maintained.


PaulANormanNZ

  • Jr. Member
  • **
  • Posts: 93
Thank you very much for your help in this,

It is truly one of the top things that will give Open Source even a chance of great success.

Information Intergration and Documentation is all too often Open Source's Achilles heel otherwise.

We can have the best packages, components and units in the world, but if they are not well documented, code is not commented, or obvious in its flow, we're up the creek.

Take for example the truly wonderful TBGRAbitmap and family.
Normally if you ask somewhere for guidance on what to do (there are some quite inflected approaches - say for example - applying filters) you are simply told to look at the excellant LazPaint app source code -  I sometimes wonder if some who say that, have ever tried to do that :-)

Now that is a truly advanced piece of coding - but have you ever tried to follow it through in Lazarus IDE? The forms are, for the average Lazarus developer, laid out in a most advanced almost obstrificated fashion - though as I say quite advanced, and you might not even be able to identify and  follow things like a simple click procedure through :-) !

So, often for installation, inititalisation, finilisation, and even what might be expected to be straight forward things, you really do need some documentation pointers.

Can't work wothout them.

May be a funding drive for documentation is needed?

Quote
It's a good idea, but creating a wiki page for each package requires a lot of work.

Ok then, obviously then these issues end up on the Forum here, or at Stack Exchange etc...

"requires a lot of work" Is there a way then that it can be made more straight forward for the good answers that come forward over time here and elsewhere, to end up as part of such Lazarus Wiki entries?

 - Perhaps having mechanisms/reminders built in for making even a basic a Wiki entry pointing back to their Forum Thread, would beceome the next step, for a person once they have the answer(s) they are looking for?

If you Post - take Ownership of the Issue for the Common Good.

(No more of threads simply ending with empty statemetns like:- "its ok now I workled it all out" !!!)

It seems that every component that is a part of an official release, and anything else major that comes along, should have an initial Lazarus wiki entry established, and referenced to as a matter of form, even if that entry is initially quite sparse, or only mirrors/copies content (to make sure its always available) - and points to the last known maintainer's information or elsewhere.
Then if a new maintainer comes along, the central wiki entry can be updated, but Lazarus Users know where to start looking at first after the CHM - the  Lazarus IDE wiki :-)

Then such wiki entries can be augmented as time goes by, as people leaarn / find out things.

Some of that material and content might make it back into the built in CHM help?
And maybe the CHM could point to the live Wiki entries?

Better to start off meagre and poor in content, and grow it, than have nothing and no where  central identified at all -  for valuable contributions eventually to go?

We already have a wealth of valuable information here, but it is spread out and often not found by simple search terms - thats where the Wiki was envisaged to help?

Thanks again,
Paul

lucamar

  • Hero Member
  • *****
  • Posts: 1991
It's a good idea, but creating a wiki page for each package requires a lot of work.

IMHO, it's a lot of work ... now that there are so many undocumented (and almost abandoned) packages. But writing a minimum page stating some basic info---like what the package is, its intended use, requirements, where the docs are (if any), etc.---is a question of 10 minutes max. maybe 20 for a more complete one; if each developer took the trouble to do it---even just adding a README to the package---there would be less problems like the OP had.

As it is, it looks as if developers were so ashamed of their packages that they release them as if they were throwing them to the wind and letting them land wherever and however they may.

Good engineering practice dictates that each time you add a publicly visible function/method/proc/property/whatever, you write somewhere the minimal documentation for it. This then forms the basic of the formal docs.

And it is not so difficult to do with todays' editors and IDEs: just a question of keeping open a "myunit.txt" along with the "myunit.pas" and adding the (pre-)doc comments there. Which incidentally serves also as a kind of "canary-test": if you can't write a single-paragraph description of some function then something is wrong with that function and refactoring time is (should be) coming.

But yeah, I know: "if wishes were cents..."

Sorry for the rant--this is a pet peeve of mine.
« Last Edit: July 20, 2019, 07:29:51 am by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.2/2.0.4  - FPC 3.0.4 on:
(K|L)Ubuntu 12..16, Windows XP SP3, various DOSes.

PaulANormanNZ

  • Jr. Member
  • **
  • Posts: 93
Its right what you are saying.

Actually I have found through direct communication when I used Delphi more once, and since being on Lazarus now for years, some developers who as you put it, abandon their projects to the wind, often more originally wrote them for themselves   -- you don't really need docs then do you? :-)

... And actually don't realise how good or almost sometimes even essential what they have done is.
 And probably because they are more humble than you might expect, are genuinely surprised when someone really really takes it all seriously.

Trouble is often their life circumstances have significantly changed by the time you can even find them again.

Quote
May be a funding drive for documentation is needed?

What if financial incentives were offered for important catch-ups?

First: Really need good corporate sponsors like Blender.org has.

Another really worthwhile step would be to get an amenable tertiary institution to offer course credit for students to work on it all as markable projects.

Paul
« Last Edit: July 20, 2019, 08:26:32 am by PaulANormanNZ »

trev

  • Full Member
  • ***
  • Posts: 185
developers who as you put it, abandon their projects to the wind, often more originally wrote them for themselves

All my projects were originally written by me to scratch my itch, then shared. It is more common than many realise.

On the other hand, I do provide relatively detailed help files having been both a content author and programmer for a commercial legal publishing company and later a legal publishing charity.

Quote
What if financial incentives were offered for important catch-ups?

Then you'd need a third party to check that documentation where it's only be done to claim the compensation :)

The better idea is to encourage people to update/add to the wiki which is what I've been doing for the less travelled macOS and FreeBSD pages since I returned to Lazarus/FPC after many years and abandoned the latest incarnation of Delphi 10 (having been a Delphi user from v1 through 7, and Kylix v1 through 3).
o Lazarus v2.1.0 r61775, FPC v3.3.1 r42640, macOS 10.14.6 (with sup update), Xcode 10.3
o Lazarus v2.1.0 r61574, FPC v3.3.1 r42318, FreeBSD 12.0 (Parallels VM)
o Lazarus v2.1.0 r61574, FPC v3.0.4, Ubuntu 18.04 (Parallels VM)

lucamar

  • Hero Member
  • *****
  • Posts: 1991
First: Really need good corporate sponsors like Blender.org has.

Blender is a bad example because it's quite a special case. It produces--for those "sponsors"--gobs of mpney so they are really interested in having it in tight working order and as well documented as possible (to avoid having to spend too much when training new flunkies ;))

Free Pascal, Lazarus, etc. are in quite another category--they produce much less money for their users and the virtual cake is more ... distributed? bewteen core  and external projects.



All my projects were originally written by me to scratch my itch, then shared. It is more common than many realise.

That's true but when one is so "proud" of the result so as to want to share it, one should also be proud enough to want to present it at its best, which means with carefully explained examples and documentation. Even if just to brag: "It's so simple all you have to do is ..." or "It's so complete that you can use all this funcitons ...." But (most?) people don't do it: they just stick some source in a VCS and seem to say almost despectively: "There you have it, don't bother me anymore"

Not talking specifically about you, of course, just in general.

Quote
The better idea is to encourage people to update/add to the wiki

For external pacages, yes, the wiki is appropiate. For core packages and units, though, it would be better to update/add to the base documentation.

I've been quite a lot of times sorely tempted to try to form some kind of "Documentation Team" to slowly (but surely) document all the undocumented (or poorly documented) parts of the FCL and other FPC packages, the LCL, etc. I seriously think that a well coordinated team of 5..10 commited persons would dispach most of it in about a year.

Unfortunately I lack time to commit myself, which I guess happens to most of us, so I end up forgetting about it ... until the next time I have to look for help on something and find only (if at all) a skeleton help-page with just the function declaration.

What realy irks me is that I'm sure most of us do something similar to what I do: write some test, take some notes, add comments to our code like: "This needs be so because...", etc. And all that wealth of information is locked out of public view in our hard-disks, pen-drives, CDs, etc.

If only days had a few hours more!
« Last Edit: July 20, 2019, 10:57:36 am by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.2/2.0.4  - FPC 3.0.4 on:
(K|L)Ubuntu 12..16, Windows XP SP3, various DOSes.