Recent

Recent Posts

Pages: [1] 2 3 ... 10
1
Debugger / Re: Poll: Watches and DisplayFormat => How do you think data should be displayed
« Last post by 440bx on Today at 07:13:51 pm »
I'll keep all that in mind.

I got one thing to finish before I can give this latest version a good workout.

But, I don't need to finish anything to thank you again for all that work.  FpDebug is getting to be a really nice debugger.  In many ways I find it more enjoyable than VS' debugger, that has been my "gold standard" for years and now I find FpDebug more responsive and intuitive.   Good stuff ... and getting better.

2
Debugger / Re: Poll: Watches and DisplayFormat => How do you think data should be displayed
« Last post by Martin_fr on Today at 06:50:51 pm »
Just a note on the "char array to string" => It is limited by the overall length of the array.

The manual cast "^char(@arrardata[1])" => is a different expression sent to the backend, and the backend then figures out what data to sent based on that expression.

The "Value Formatter" does not change the expression. The backend does still evaluate that array, and returns that data. Like a "DisplayFormat" (e.g. hex/dec/bin for numbers) the "Value Formatter" merely changes how this data is displayed (and it omits some data, if it is told to stop at #0).

This also means that there is a difference for sparse arrays. (arrays with memory gaps between their elements). If an array of char for some reason had each element aligned to a 4 byte boundary, then there would be 3 empty bytes between the element. (Afaik no way to make that happen with fpc, but...). The array would show "'a','b','c'", the display-formatter "'abc'", but the "pchar" trick would show "'a'#1#2#3'b'#4#5#6'c'" (depending on what trash would be present in the gaps, or if it was #0 it would cut off).

However, the Value formatter does assemble the pascal "char" as code-units into an utf8 string. (Of course, setting a codepage could be added).

Internally that is owed to the strict differentiation between a frond and back end.

It is possible that (at extra cost), Value formatters off the future could evaluate extra data.
There also is a "backend converter" which can handle this in the backend.

A further difference between work done in the front or back end is, that data stored in debug history can not be updated by the backend (as the debug process is no longer in the state that it was). But front end formatting can still be done. (even if currently access to that is not yet implemented)
3
Windows / Re: Lazarus for Windows on aarch64 (ARM64) - Native Compiler
« Last post by msintle on Today at 06:42:18 pm »
Quote from: Wallaby on April 17, 2024, 10:25:46 pm
Quote from: msintle on April 17, 2024, 04:12:52 pm
Nice to see everyone has plenty of love for their favorite operating systems ;)
Can we get back on track - what needs to be done to fix FPC so larger apps like Lazarus can be compiled successfully for aarch64 on Windows?

Indeed  :D From my experience with the trunk compiler, it works in principle for simple programs, but there are two showstopper bugs I have reported:

Win64 AArch64 optimizer bug and Win64 AArch64 exception handling

I already offered to pay anyone in the FPC team who is able to fix those issues (aka offer a bounty), but so far looks like no one is interested.

Was there a pre-set dollar value attached to those bounties?

If there's a value where this would make sense and justify the - I'm sure excruciatingly painful - work involved, I could take it up with my employer, too.
4
Windows / Re: Lazarus for Windows on aarch64 (ARM64) - Native Compiler
« Last post by msintle on Today at 06:28:18 pm »
Quote from: dbannon on Today at 07:02:55 am
Quote from: VisualLab on April 16, 2024, 09:41:40 pm
So, I think the OP's original question is valid. We support an Alpha chip running Tru64 but not the hardware/software combo anyone can buy in their local (computer) shops today ?

Thank you for the support and putting it in better terms than I ever could.
5
Third party / Re: InstallAware Using Lazarus IDE
« Last post by marcov on Today at 04:46:46 pm »
Quote
Right now it's plain impossible to install official Lazarus releases on most Linux environments, unless you're using FPCUPDLX. Again, it is exactly the same for Apple Silicon native macOS installations - for which there's no PKG installer available, period. FPCUPDLX is a heroic effort, but has a track record of backing itself into corners it cannot get itself out of (I've been seeing error 512 and/or outright hangs of the compilation process on virtually every Linux system I've tried it on, when using FPC 3.3.1 and Trunk/Stable Lazarus).

I replied about changing the working windows to something else. I don't see the point of that, since the shared aspect will be low as I said as every OS has its own files and directories.

But be my guest, start building and iterating installers, and we'll see how it goes.

Quote
Am I the only one in thinking this investment would pay off dividends over time? Instead of maintaining multiple - and disparate - PKG, DEB, RPM installation scripts

Since the distributions only integrate those(deb,pkg), and most users install via their distro tools this is a strange statement. I don't know much about OSX practicalities.

And I think the different iterations of the installer scripts for various OSes and distros should not be underestimated either.

Anyway, the only thing is just go out and try if you feel strong about it.
6
Networking and Web Programming / Re: Who is Indy mattias?
« Last post by paweld on Today at 04:17:53 pm »
Quote from: jollytall
/lib/x86_64-linux-gnu/libc.so.6: version GLIB_2.34 not found.
you may find a solution here: https://forum.lazarus.freepascal.org/index.php/topic,58888.0.html
7
Third party / Re: InstallAware Using Lazarus IDE
« Last post by msintle on Today at 04:15:29 pm »
Quote from: marcov on April 18, 2024, 10:05:26 am
Quote from: msintle on April 16, 2024, 06:53:01 pm
Would anybody like to look into making Lazarus's cross-platform native code setups using InstallAware?

A single project would compile into Windows, Linux (aarch64 and AMD64), and macOS (Intel and Apple Silicon) targets.

Most installer work is OS specific, and, in the case of FPC/lazarus even the file lists to install are, since there are *nix and windows specific packages, and similarly due to Lazarus' widgetsets.

You can try, but I don't really expect that much from it, nor that it will match the current inno setups.

It's about measuring up.

A good user of InstallAware would use compiler variables to create conditional parts of the installation script that are platform (and even CPU architecture) specific, while retaining an overall consistent look and feel for the entire setup (regardless of platform).

Right now it's plain impossible to install official Lazarus releases on most Linux environments, unless you're using FPCUPDLX. Again, it is exactly the same for Apple Silicon native macOS installations - for which there's no PKG installer available, period. FPCUPDLX is a heroic effort, but has a track record of backing itself into corners it cannot get itself out of (I've been seeing error 512 and/or outright hangs of the compilation process on virtually every Linux system I've tried it on, when using FPC 3.3.1 and Trunk/Stable Lazarus).

I honestly can't see the harm in having a consistent installation process, with official support for AMD64 and aarch64 targets on both Linux and macOS. It'll only serve to make Lazarus more accessible for greater adoption. With Delphi just at #11 on this year's Tiobe index, the timing is really perfect for an upgrade of the installation (and by implication, the user experience).

Am I the only one in thinking this investment would pay off dividends over time? Instead of maintaining multiple - and disparate - PKG, DEB, RPM installation scripts, there'd be just one setup project and one conditionally compiled setup script. That sounds like three times the less work to me. Help me understand how this is a bad thing?
8
Beginners / Re: how to get class and method name from inside the method
« Last post by Joanna on Today at 03:53:05 pm »
Thanks cdbc. It seems like autocomplete doesn’t work well inside a twincontrol helper  but it compiles ok.
9
Networking and Web Programming / Re: Who is Indy mattias?
« Last post by jollytall on Today at 03:34:56 pm »
Thanks, that is clear.
But I have another problem. I compiled and got the large executable I mentioned above, but now it does not run on the server where I want to run it, because a file /lib/x86_64-linux-gnu/libc.so.6: version GLIB_2.34 not found.
Again, this program did compile and run before. I changed one cosmetic line, and now without uses Interfaces it does not compile and with it, it is huge and does not run.
What can be wrong?
10
Other / Re: I just released a commercial game written in freepascal and lazarus
« Last post by BrassGear on Today at 03:17:28 pm »
Thank you, Seenkao.

It seems the general consensus so far that the presentation of the landing page is a major problem.

This is valuable feedback. It identified a blind spot I was not aware of.
Pages: [1] 2 3 ... 10

TinyPortal © 2005-2018