Recent Posts

Pages: [1] 2 3 ... 10
@kkuba: I have checked the example attached to tvplanit (examples\datastore\zeos) and it works without any errors.
Windows 10 x64, PostgreSQL 14.2, Lazarus trunk + FPC 3.2-fixes
Databases / Problems installing the IBX component
« Last post by Ever on Today at 03:32:40 pm »

    I have tried to run the IBX component in versions 2.6, 2.5 and 2.4, they compile without any problems, but when I start the Lazarus IDE it shows me the following error:

     IBX is unable to locate or otherwise load Firebird Library. Object reference is Nil

     When installing version 2.3 of said component I did not experience any problems.

    I am using Lazarus 2.2.6 in a 64-bit version, on Windows 11. I must note that I have two Firberid servers installed on the computer, versions 3 and 4 but 32-bit. In the Windows environment variables I have the paths of both versions of Firebird

    I thank you in advance for the support you can give me.
Packages and Libraries / Re: VisualPlainIT and Postgress old problem returned
« Last post by wp on Today at 03:30:46 pm »
No changes have been made to the zeos-datastore unit since the last update in OPM (v1.8.2). All the other changed made after v1.8.2 release are not related to databases.

Unfortunately my Postgres installation seems to be broken, thus I cannot look at this issue at the moment in more detail.
In Lazarus, I use ZEOS simply the stable version. It works without any problem with Postgres version 14.9. WP fixed this bug already last year, but new code snippets were added. To the eye, these fragments are probably related to this bug. That's why I asked WP, to take a look at the issue. The error came out accidentally, it's not every day that you do create on the base. :)
A rudimentary(basic) plug-in system based on build stages

In Free Pascal, the preprocessor and the tokenizer are pretty much merged and then directly deliver a token stream that is parsed into a tree representation. No other complete-file representation exist in between (not even non-text). So basing a plugin system on text  sounds like you haven't looked at how a/the compiler works.

What you are describing is more something for a source 2 source converter. Most compilers get  rid of textual representation as quickly as possible, simply because it is slowing.

Maybe an overall preprocessor would be theoretically possible. (operating on the whole file before being processed), because that could be inserted before the compiler does anything with the read file. But the rest seems pure fantasy to me.

If this thread is going to divert into a discussion on a plugin system/implementation wouldn't it make more sense to split off this topic ?

2 cents
A rudimentary(basic) plug-in system based on build stages doesn't require high maintenance or complex API because it's simple. For example, the compiler calls a library "processdata(filename{string},stage{enum})" routine for each processed file like:
  • processdata('/development/foo.pas',stage1); At stage 1 the addon routine reads the file and if the file content has syntaxes known that can't be understood by the FPC, those are modified(translated). It's like an external compiler mode directive but it might even translate an entire file from a different than Pascal computer language to Pascal.
  • processdata('/development/foo.pas',stage2); At stage 2 the compiler already checked the syntax of the source files and arranged it according to it's own standardized code format. For example, all lines are trimmed, all those useless empty lines are removed, macros have been applied, all function calls have a single text line with parameters, a single block for each constant, type and variable declarations(for example: "procedure Foo;var x:integer;var y:integer;begin...end;" would remove the duplicate "var" keyword) and so on. Because the content of the file has been cleaned, arranged and verified for valid syntaxes, it would be easy for the plug-in to work with it. A "repeat" line will always be followed by a line that starts with "until " and ends with ";". A "for" loop line will always start with "for ". An assignment line will always contain ":=" in a greater than 1 position and will end with ";". So, it would be easier to process most of the source code.
  • ...
  • processdata('/development/foo.s',stageN); At stage N the compiler built the assembly files, files that have the assembly code arranged the same way as the pascal code was arranged in stage 2. Again, the plug-in will analyse the file and make changes to it. For the code presented in the first post, the compiler generates consecutive and identical "neg*" lines, which means that a plug-in can easily remove some of them, it's not rocket science.
So, the plug-in system doesn't necessary have to be something very complex. In the above example, there is a single addon(plug-in) routine that's called. Obviously, file reads and writes should be avoided, a TargetCPU parameter might be usefull, a compiler optimization level parameter might be usefull, and so on. Plug-in capabilities might be presented at compiler's request, capabilities that should appear when calling the compiler with the "-i" series of parameters, but those are details.

To me it looks like it's not a significant effort to implement such a simple(basic, rudimentary) addon(plug-in) system mostly because it's based on compiler's build stages, not on internal routines(functions and procedures) and structures(like records) that are subject to frequent changes. And because it's based on compiler's build stages, similar results should be achievable by using compiler calling parameters. For example, FPC has the "-s" series of parameters to stop the building process before using an assembler, but doesn't have a parameter to stop the process in an earlier stage, when the code is still in Pascal syntax. In addition, FPC doesn't have a "restartstage" or  a "resumebuild" like parameter, forcing you to use external tools directly. So, once FPC has a parameter to stop it's build process in a stage where the code is still in Pascal language and a parameter to resume it's building process, or restart it at a specified stage, most likely 80% of this rudimentary addon infrastructure is done.
Obviously, FPC's current architecture might be so inappropriate to stopping, restarting a stage and resuming it's own building process, that would make implementing even such a stage-based rudimentary addon system a nightmare.
I guess it is down to personal preferences dbannon. Nothing wrong with using one method/provision over the other (or combine them) ?

I do wonder why you stated that you believe that to be the only way to be able to manage such things though (you could be perfectly right there, it is only that I have a different experience but that might be because I am an oddball  ).

For example, the notarization, seem pretty basic to me for that particular platform so personally I would try and incorporate that into my fpc.cfg so that the only time I need to have a look at it is when the notarization version needs to change (I have honestly no idea so assumed for that to be once in a blue moon ?). If notarization depends on the host/target platform version then automate it based on that).
From 10km in the air everything seems small. Conceptualizing on the back of a beer coaster is not the hurdle. The nitty-gritty of implementing it in an useful way and then maintaining that.
I stand by what I said.  Whether 10km or 1cm in the air, designing a _stable_ API, while it requires thought and care, is not very difficult. The design of APIs (stable and unstable) is not an occult science. 

A stable API is usually the result of some forward thinking (what could they need) combined with feedback found while actually using the API. But usually both require iteration. Even e.g. .NET went through several iterations (1.0, 1.1 and 2.0 were afaik mutually incompatible and only 2.0+ was somewhat stable). And that even with the massive internal use and considerable internal iterations feedback cycles that they had.

That said, I concede and, conceded in the previous post, that the _implementation_ of an API could likely require a prohibitive effort, mostly due to FPC's current architecture.
Pages: [1] 2 3 ... 10

TinyPortal © 2005-2018