Recent

Recent Posts

Pages: [1] 2 3 ... 10
1
General / Re: How to: create DLL file for Windows 10 64-Bit Pro
« Last post by paule32 on Today at 06:03:15 pm »
a index, to the VMT table of QString ?
how about this table ?
is it (the strcture) documented ?

I mean, I see the TVmt record, where the first Index point to: vinstanceSize: LongDWORD
2
Debugger / Re: FpDebug breakpoint on "begin"
« Last post by Martin_fr on Today at 06:01:03 pm »
I compared the location of the blue dots in Delphi and Lazarus. In Delphi, dots are placed near the left edge of the gutter. When debugging, they usually do not conflict with other icons. The dots in Lazarus are placed at the right edge of the gutter. As a result, they are often covered by other icons. Maybe it would be possible to separate vertical areas (stripes) in the gutter in which different types of icons would be displayed, so that they would not overlap? Additionally, divided into editor modes: editing and debugging. In each of these modes, the editor could display different icons in separate areas of the gutter.

Left vs right isn't the issue, or is it. Just were each type of icon goes compared to others.

Bookmarks go into the 1st (leftmost) column.
All the rest goes into the 2nd column => well, that changed: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40914

Even in Delphi, afaik breakpoints themself cover the blue dot.

So, this is only about error/warning/note icons?
They could be moved to the bookmark column (unless a bookmark is also set on that line).



I don't know if they would benefit much from having a dedicated 3rd column.

Btw, you can set the gutter to provide 3 columns (editor options > display / 3.99). But that wont dedicate any of the columns to anything.
3
Debugger / Re: FpDebug breakpoint on "begin"
« Last post by Martin_fr on Today at 05:55:08 pm »
One thing I wonder: in Lazarus, blue dots appear in the editor gutter when debugging is started. They disappear when debugging is finished. In Delphi, blue dots appear after compilation/build is completed and remain after debugging is completed. What is the reason for this difference in the behavior of both IDEs?
I don't know how Delphi implements them.
If they are loaded from debug info, or if the Delphi compiler creates dedicated info for the IDE.  (Like fpc could (for other purposes) with "-b" generate info for an IDE)).


In Lazarus, they come from the debug info. Without this, this, the IDE can not find out which source lines did generate machine code. (also that means, strictly speaking where fpc associates it, as sometimes fpc moves this when optimizing...).
So historically, Lazarus got them using GDB, and that only happened when the debugger started.
FpDebug too, only loads them when it starts debugging.

Though having a build in reader, the IDE could read that info at an earlier point. That raises the same question as keeping them after debugging does => what for?

As soon as you edit, there is a chance that they become inaccurate. That is true even during debugging, but usually with more extensive editing being done while the debugger does not run, the issue gets more noticeable.
If you break a line into 2, and then join each part with other lines (that may or may not have been added after the last compilation) then the blue dots aren't very accurate any more.

Also as for seeing if IFDEFed code is active, the Lazarus IDE highlights that without the need of compiling. The only part it wont show you is dead code elimination.  "if false then".


The only case were loading them after compile would be needed is, if you set your project to "not compile automatically". So you can
- compile
- edit
- run/debug without compiling the recent edits

Then of course you want the blue dots after compile, because they secretly contain the mapping of any changed line numbers due to edit after the compile (which helps setting breakpoints).
(Afaik delphi does not map line numbers for edited code ?)

Anyway, I also think of the blue dots as a nice indicator that the debugger is running. So thats a point for the current behaviour.
4
Thanks for looking - it must just be a problem with the Interbase connection. At least we can always use an old version of Lazarus/fpc if we really have to. We could change the database but there are a lot of stored procedures (which tend to use different syntax between databases, so that might also cause trouble). I don't want to start debugging Lazarus (and the problem is probably at the fpc level anyway). So my options seem to be:
1) Go back to an old Lazarus version, probably 1.4.2 (ugh!).
2) Change database & probably have to re-write stored procedures - and other programs that extract data from the database (ugh!).
3) Add a fix-up bodge after every query close (if I copy out the SQL, clear the SQL, re-write it, and re-do the prepare, it fixes the bug) - this will slow everything down, but may be our best option.
4) Add this problem to the bug tracker & wait until someone fixes it (could take forever).
Any other ideas?
5
Interesting,
6
General / Re: How to: create DLL file for Windows 10 64-Bit Pro
« Last post by Thaddy on Today at 05:39:16 pm »
You should not mess with the create. So, no. 1 is an index....
What do you want to achieve?
The lea would probably crash big time.
7
General / Re: Generics - correct syntax
« Last post by Blaazen on Today at 05:07:02 pm »
Changing field to protected or public does not work. I tried both 3.2.2 and the newest 3.3.1.

I wanted to test Vulkan (something simple) but none of the listed repos works: https://wiki.freepascal.org/Vulkan

The PasVulkan from BeRo1985 is active but its a huge 5GB repo and you need to download another 4 repos and still it doesn't compile.
8
Third party / Re: InstallAware Using Lazarus IDE
« Last post by msintle on Today at 05:03:08 pm »
....
Right now it's plain impossible to install official Lazarus releases on most Linux environments, unless you're using FPCUPDLX.
Sorry, thats plain silly.
I run a set of seven virtual and real machines to build and test my app before release. Yesterday, I decided I needed to use Lazarus 3.2 instead of 3.0 so, quick tweak of my bash script, installed Lazarus 3.2 on four quite different Linux systems in about 5 minutes each. They all had FPC323 snapshot and each worked as expected.

(My script grabs a local Lazarus source zip or, if necessary downloads one, puts it in an appropriate place, build lazarus, sets up a config dir, trivial !)

That script sounds like gold. Would you mind sharing it? A starting point for a Lazarus Linux installer could actually be converting that script into an InstallAware setup itself.

I've been unable to install Lazarus via FPCUPDLX (so I have the latest version) on literally any Linux (aarch64 or AMD64) that I tried it on recently. Call me an idiot, but I either keep getting error 512, or the compiler hangs at some or the other part of the local compilation process.

To say nothing of the fact that installing pre-compiled binaries would speed things up for everyone, but then we'd be stuck with official releases again.

Quote
Again, it is exactly the same for Apple Silicon native macOS installations -
I don't have Apple Silicon hardware but have no problem building Lazarus on a intel based Mac and cross compiling.

Quote
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).
...
Help me understand how this is a bad thing?

Even within Linux, different binary install models are more or less compulsory. End users who want a binary install expect the familiar install model for their platform. Deb users want a deb, rpm users want an rpm, packman....

Yes, and that is part of the problem here we'd be addressing.

One single look and feel installer would be unfamiliar to every possible user. Its like saying we can make a car that runs on water, or a boat that runs on land, possible and has been done. But in both cases, they do a terrible job at everything !
...
Davo

InstallAware have already achieved this objective with their own installer for themselves. Including selectable components, web downloads, and even web updates. So clearly it is possible, as I have seen it work consistently and predictably on every platform I've been able to try it on.

Even if it can't boot itself in GUI mode, their installer falls back to console rendering for setup dialogs. Even their web updates work this way (and are launched via Linux "shortcuts" accessed from the Activities menus) and are quite a thing to see, especially in view of the fact that nothing is hard-coded but simply being rendered from fully customizable dialog designs. Imagine having many Lazarus configuration steps moved to the installer, where they belong; instead of a confusing first launch experience, which is how it is today! (debugger, FPC locations, etc.)

It's crazy a product built using Lazarus can do this, while Lazarus itself cannot (granted, the product in question is an installer, so maybe not an entirely fair comparison).
9
Third party / Re: InstallAware Using Lazarus IDE
« Last post by msintle on Today at 04:52:37 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.

I would love to try that, but I'm not sure how to do it properly. Who are some people that might be able to provide guidance?

InstallAware Multi Platform does have its own Setup Capture tool, but I'm wary of using this - as it will just dump a list of files (and folders) and not really contribute anything beyond that.

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.

Why do we have to care about the distribution-specific package formats when InstallAware builds native code, Windows-esque "setup" (without the .exe) binaries that run directly and install regardless of which package formats the distribution has built-in support for?

This is the native code power of Lazarus at work, people!

I would fathom the only matter at hand would be whether Lazarus has particular dependencies for each individual distribution, in which case, it could turn into a spaghetti mess of untangling those dependencies. For example, Qt5 editions of Lazarus on Linux require the installation of a Qt5Pas library - which seems distribution agnostic - and is therefore good news. But what of other potential GTK2/Qt5 libs that might be required on some distributions (and not others)?

I've tested InstallAware itself and seen that if it cannot boot its GUI setup for some reason, it'll still go ahead and display console renderings of whatever (custom) setup dialogs that are a part of your project. So this gives me confidence that the tool at hand, at least, can cope with missing mandatory GUI dependencies, and at least get to the point of installing them (without instantly breaking).

But this won't answer what the specific Linux dependencies are, and what the best practices would be to install them.

For example with the Setup Capture route, you could obtain a full list of binaries required for each particular scenario. But Setup Capture doesn't tell you which of those binaries are encapsulated in which Linux packages on which platforms...and distributing ready-compiled-binaries made for one distribution on other distributions seems like that could be a bit of a brute forcing.

Ideally, we'd only be including Lazarus (and Free Pascal) binaries (and sources) in our distribution...and use the underlying operating system package manager to install missing dependencies "natively", if that makes sense?

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.

I would love to get started, but I can hardly see myself pulling this off alone.

Maybe macOS would be far easier to do, as InstallAware already includes sample projects to install Xcode Command Line Tools - as part of an InstallAware setup - which is the only dependency Lazarus has on macOS.

The irony there being FPCUPDLX already works fine on macOS, and the real problem I'd like to solve here is how to get the job done on Linux.
10
Windows / Re: Lazarus for Windows on aarch64 (ARM64) - Native Compiler
« Last post by msintle on Today at 04:42:43 pm »
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.

I think last time, a year ago, I offered $300 US for each with a possibility of increase if it's difficult and takes a lot of time. Yet, it seems no one is interested.

Where is the place to offer such bounties?

I would like to propose higher amounts and see if anyone bites.
Pages: [1] 2 3 ... 10

TinyPortal © 2005-2018