Forum > General
Exploring FPC/Lazarus units and packages
Curt Carpenter:
--- Quote from: MarkMLl on July 13, 2024, 10:11:25 pm ---OK, here's where I'm at.
Before anything else, I don't want anybody to think that I'm attempting to disparage MvC's excellent work with the reference manuals. I've done a fair amount of technical writing, and know how difficult it can be.
However from the POV of somebody who's done a fair amount of technical writing, and also from having gone through (some of) the Python material thoroughly, I think we can highlight two things as major problems:
a) "How do I..."
10233 in /fpcsrc/packages
b) "What changed, and when..."
--- End quote ---
Oh absolutely yes. Some of the most painful times of my career were attempts at technical writing. It's an exceptional and rare talent. And one of the wonders of Turbo Pascal and Delphi in the early days was that they clearly had some great tech writers working on them.
One thing I think would be helpful would be a way to just create a specialized list of the available files applicable to a given operating system. There are 2008 items in my /fpcsrc/rtl folder and 10233 in /fpcsrc/packages. Most of them are of no help to someone that is trying to learn fpc/lazarus just for a particular OS. If there was a way to say "list all of the files and folders in fpcsrc that are applicable to WidnowsCE" for example, it would at least narrow the path up the learning curve. But to do that, someone would have to go through all those items I think -- real work.
TRon:
Just some random remarks.
Most if not all of the choices for placing certain type declarations in a particular unit is hinted by Delphi. As the recent practical example the declaration of tbytedynarray (Delphi's system.types)
As already mentioned by MarkMLI the existing documentation is mostly written to be reference material even though some documentation comes with examples to try make things more clear. imho Borland did a much better job when they published their compiler and IDE as their documentation was exhaustive and explained about every (new) feature into details and with accompanied practical examples and explanations to show the ropes.
You can definitely see the difference between a commercial entity and an open source project (which as Mark already stipulated is in no way meant as a comment to MvC and/or other contributors).
Reference documentation simply isn't and never will be exhaustive, full of examples and/or try guide new users to get themselves acquainted. imho its goal is to inform the user about the workings/constructs and that's more or less it. If you want more in depth material you can either opt for 3th party documentation (books comes to mind) or get yourself familiar with the existing examples and the wiki. Having a search on the forums is also not a bad idea in case you get stuck.
That is all far from optimal but do-able.
If you ask what are the main units you would have to get yourself acquainted with then I would answer that with that it depends on your goal(s). For generic use and newcomers: system, sysutils and in the past also unit dos and graphics.
MarkMLI also mentioned the *nix related units and that is of course applicable in case that is your target. That list could be completely different when writing code for another target. And from there on it pretty much depends on the specific topic.
Because also then the real questions begin to pop-up. Do you want to use OOP ? Generics ? Operators ? Helpers ? Do you stick to the default shipped units or prefer 3th party units. Do you want to write GUI applications ?
Till this day (and for over 2 decades) I still haven't read all available reference material shipped with FPC/Laz. When there is need to use a certain class or component that I am unfamiliar with then I start reading, try out examples examine the wiki, forum and try to obtain all relevant information. Sometimes I can get away with just looking at an example other times I am stunned at the complexity and usage of some implementations such as f.e. charts and spreadsheets simply because they offer so many functionality that I barely scratch the surface when in using them.
I agree that things could be much better and afaik the wiki was meant to supplement the reference documentation but quite frankly (and despite some serious efforts) to me it all looks like an enourmous pile of snippets linked together (and yes there are definitely some very good and well written wiki pages but they do not represent the majority).
I believe the discussion has been brought up multiple times in the past that there seem to be something missing between reference documentation and wiki articles and quite frankly I do not seem capable to put my finger on what exactly the missing part is or could be (trees, forest and clueless).
edit:
My take on using AI to let yourself guide.
Short answer: please don't.
Long answer: AI is
- full of presenting buggy code and explanations (it basically lies straight to your face and when confronting the lie then lies about lying as well).
- based on generic consensus e.g. what the majority deems fit (which you might think is a good idea but is actually bad)
- If you do not already know what you are doing (e.g. ask the exact correct question and basically know the correct answer) you can be deceived.
- AI will eventually lead to (even more) enshittification.
- for any other topic in your life f.e. buy a car or sell your house would you accept a roll of the dice ? (because in basics that is exactly what AI does).
And probably tons of other reasons that do not directly pop into mind.
MarkMLl:
--- Quote from: Curt Carpenter on July 14, 2024, 01:19:01 am ---Oh absolutely yes. Some of the most painful times of my career were attempts at technical writing. It's an exceptional and rare talent. And one of the wonders of Turbo Pascal and Delphi in the early days was that they clearly had some great tech writers working on them.
--- End quote ---
It's difficult enough when one is working with developers who have to- as a matter of company policy- help. Once subcontractors and loosely-affiliated associates are involved it's virtually impossible to have anything coherent, since each is likely to have coding and markup policies incompatible with anybody else.
The early Borland manuals were gems, as were the JPI/Topspeed manuals... I don't know whether they inherited the writers when the companies split. However I remember something about Borland loosing a large amount of documentation on the Delphi-2 era, which is why later versions were more and more skimpy.
--- Quote ---One thing I think would be helpful would be a way to just create a specialized list of the available files applicable to a given operating system. There are 2008 items in my /fpcsrc/rtl folder and 10233 in /fpcsrc/packages. Most of them are of no help to someone that is trying to learn fpc/lazarus just for a particular OS. If there was a way to say "list all of the files and folders in fpcsrc that are applicable to WidnowsCE" for example, it would at least narrow the path up the learning curve. But to do that, someone would have to go through all those items I think -- real work.
--- End quote ---
If you build your own compiler you might find https://github.com/MarkMLl/fpclaz_build_scripts useful. It uses the compiler's -vt flag hence
--- Code: ---= /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/system.pp
+ /lib64/ld-linux-x86-64.so.2
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/osdefs.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/sysosh.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/pmutext.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/rtldefs.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/sysos.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/errno.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/ostypes.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/ptypes.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/pmutext.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/./x86_64/stat.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/signal.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/./x86_64/sighndh.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/./x86_64/syscallh.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/./x86_64/syscall.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/./x86_64/sysnr.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/ossysc.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/osmacro.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/system.pp
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/./x86_64/sighnd.inc
+ /usr/local/src.fpc/fpcbuild-3.2.2/fpcsrc/system.pp
--- End code ---
and so on. Should be OK on Linux or SunOS/Solaris, untested on Mac, would need to be completely redone on Windows.
MarkMLl
MarkMLl:
--- Quote from: TRon on July 14, 2024, 06:59:27 am ---My take on using AI to let yourself guide.
Short answer: please don't.
--- End quote ---
It has its place as a way to manage information based on the "flavour" of the material it's processing.
There might possibly be enough in the language/user/programmer reference manuals (which I think we all agree are pretty good) and wiki to train it, after which- once it's decided how to group and categorise concepts- it might possibly be usable as an index generator for the RTL/FCL (which is where the problems are, IMO). But I don't know how that would be tackled in practice, or what resources it would take.
Can anybody comment: if all versions of the relevant manuals were available online, could the relevant LLM training be distributed over the user community?
MarkMLl
TRon:
--- Quote from: MarkMLl on July 14, 2024, 11:22:17 am ---It has its place as a way to manage information based on the "flavour" of the material it's processing.
--- End quote ---
I have no idea if a LLM trained specifically for one programming language/purpose would perform better (you might be inclined to think so).
--- Quote ---Can anybody comment: if all versions of the relevant manuals were available online, could the relevant LLM training be distributed over the user community?
--- End quote ---
You could even do that off-line on a local running LLM. There are engines available that let you do that (I posted something about using whisper on someones question but the same concept also works for other models). The generated data can be distributed as a normal file, f.e. see huggingface.
It takes a lot of horsepower and time though. I do not know if there already exist a distributed way of training a model.
Navigation
[0] Message Index
[#] Next page
[*] Previous page