Re: [fpc-pascal] Delphi for Linux is out
First off, I’m sorry for implying that the current units are insufficient. I just looked through our code and we’re using far fewer “external ‘c’” definitions than I thought we were. The documentation generally looks good too, so I assume most of trouble was from not being as familiar with Free Pascal’s RTL layout and using search techniques that worked better for Delphi/Kylix than for it. We had to maintain both FPC and Kylix code in parallel for several years too, and that undoubtedly made things more complicated than they would have been otherwise. I’ll keep that bias in mind in the future. On 3/23/2017 2:40 PM, Michael Van Canneyt wrote: > No-one has ever offered to maintain a Libc import unit. It was provided > only as a courtesy to Kylix devs. That's probably because the Wiki says: "The libc unit is deprecated, and frozen in time for Kylix compatibility, and won't be ported to other architectures or operating systems." It also has a long list of other reasons why the entire idea is flawed. We had a rough port to both Linux64 and Darwin32 but never tried to submit those changes back for that very reason. > That said, if someone steps up and offers to update Libc for all > supported architectures, she/he is welcome. This is another instance where you’re (possibly unconsciously) discouraging people from submitting patches. By saying “update ... for all supported architectures”, you’re implying that adding Linux64 or Darwin isn’t worth it unless they also spend time on ARM, Haiku, and uclibc. I certainly understand that from a idealogical point of view, but if someone doesn’t have the time or knowledge to cover everything, it does make it seem like a partial patch wouldn’t be welcome. OTOH, maybe that is intentional, and I can’t say it’s wrong, since it does provide a high barrier to expanding the scope of that unit. In any case, it’s not relevant for us now. As I said, we recently removed all of our Libc.pas usage. On 3/23/2017 4:29 PM, Marco van de Voort wrote: > Could you name the mantis items with improvements/problems ? No, though I’ll try to submit some for the cases where there could be improvement. The only thing I can think of that would have been retroactively useful is if Libc.pas had included deprecated declarations with messages saying where the replacement units/methods are. — Zoë Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi for Linux is out
On 3/23/2017 12:31 PM, Marco van de Voort wrote: It didn't help that some component maintainers like Synapse stuck to the libc format way too long. Only in 2007-2009 when FPC on OS X got important that changed, I still use Indy(10) that switched much earlier to this day. Having just removed the last vestiges of Libc.pas usage from our own project, this is entirely on the heads of the FPC maintainers. Whatever the concerns regarding Libc.pas, it's usage was simple: Add "Libc" to your uses clause, look up (extensive) function documentation and sample code in the standard Posix man pages and StackOverflow. The recommended FPC approach, on the other hand, is a combination of "Use functions from the RTL, BaseUnix, or other random packages" and "Import the relevant functions yourself", and the documentation is "Hope some exists or that adding an fp prefix works". Add to that, sometimes the RTL does have the imports/record translations you need, but doesn't bother to expose them publicly. Free Pascal has done great things, and I absolutely appreciate all of it, but not having a good alternative to Libc.pas or Delphi's new Posix.*.pas APIs has definitely been an annoying pain point. -- Zoë Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Getting strange FTP error using Indy 10 idFTP
On 11/22/2017 1:50 PM, Bo Berglund wrote: 20:14:01.018 EXCEPTION: Invalid PORT Command. Set FTP.Passive := True. PORT is used for active connections, where the server opens a connection to the client computer for the data stream. PASV is used for passive connections, where the client opens a second connection to the server. https://stackoverflow.com/questions/1699145/what-is-the-difference-between-active-and-passive-ftp#1699163 -- Zoë Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Anyone know where Blaise Thorne is?
Has anyone had any contact with Blaise Thorne in the past couple of months? In mid-March he told me he would have an updated version of the closure branch ready in a couple of days and then went silent. I only have his email address and haven't been able to get a response. Thanks, Zoë Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] _Release call location for unused function results
In the code below Bar creates a reference counted object and returns an
interface to it. Foo calls Bar but doesn't assign the result anywhere.
In Delphi, this produces the result:
Foo >
TAutoRelease.Create
Foo <
TAutoRelease.Destroy
But in Free Pascal it produces this:
Foo >
TAutoRelease.Create
TAutoRelease.Destroy
Foo <
If I change Foo to assign the interface to a local variable but don't do
anything with that variable, Free Pascal produces the same results as
Delphi.
Delphi's behavior is what I expected, and allows tricks with triggering
behavior when leaving the current scope. Barry Kelly has one example on
his blog where he talks about implementing C++'s RAII using it:
http://blog.barrkel.com/2010/01/one-liner-raii-in-delphi.html
Is Free Pascal's behavior intentional? Can it be changed to match Delphi?
Thanks,
Zoë Peterson
Scooter Software
program AutoRelease;
{$IFDEF FPC}{$MODE DELPHI}{$ENDIF}
{$APPTYPE CONSOLE}
uses
Classes,
SysUtils;
type
TAutoRelease = class(TInterfacedObject)
constructor Create;
destructor Destroy; override;
end;
constructor TAutoRelease.Create;
begin
WriteLn('TAutoRelease.Create');
end;
destructor TAutoRelease.Destroy;
begin
WriteLn('TAutoRelease.Destroy');
inherited;
end;
function Bar: IInterface;
begin
Result := TAutoRelease.Create;
end;
procedure Foo;
begin
WriteLn('Foo >');
Bar;
WriteLn('Foo <');
end;
begin
Foo;
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
On 4/14/2019 10:41 AM, Jonas Maebe wrote: That was because Apple did the same with the Objective-C language: https://en.wikipedia.org/wiki/Objective-C#Objective-C_2.0 :) How does $modeswitch objectivec1 differ from objectivec2? That article mentions that Objective-C 2.0 added 64-bit support, but we've only had objectivec1 enabled and our 64-bit builds appear to be working without issue? -- Zoë Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String conversions
On 6/28/2019 3:07 PM, Ryan Joseph wrote: On Jun 28, 2019, at 3:40 PM, Martok wrote: So, I would expect (and FastMM has codepaths for that), that repeated reallocations cause some form of "over-allocating" growth and most of the individual "+1" reallocs will be essentially no-ops. Interesting. How could we test this to see if it’s true? From FastMM4's readme: https://github.com/pleriche/FastMM4/blob/master/README.md "Intelligent reallocations. Avoids slow memory move operations through not performing unneccesary downsizes and by having a minimum percentage block size growth factor when an in-place block upsize is not possible." Allocations within certain ranges are all lumped together based on fixed block sizes (e.g., 15-24 bytes allocations are all rounded up to 24 bytes). It both reduces fragmentation and helps with resize performance (there is other resize-specific logic as well). String allocations and performance factored heavily into the benchmarking for the FastCode competition that lead to FastMM4. You should do your own benchmarking vs the system allocator though, to see if it provides an improvement, especially if you're doing extensive multithreading. We've been using FastMM with FPC on macOS and Linux for about 4 years now and are very happy with it. -- Zoë Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] New Cocoa headers
I just updated to the newer Cocoa headers (Thanks Jonas!) and I've run
into a problem with Lazarus.
NSExtensionContext.inc includes this line:
{$if
defined(__OBJC2__)defined(interface)defined(NSExtensionContext)defined(NSObject)}
It compiles ok for some reason, but screws up Code Tools so things like
jump to inherited don't work on subclasses of AppKit defined Objective-C
classes.
Is that line correct? Do it (and other places that have the same
construct) need to be fixed or does Code Tools need to be updated to
understand it?
It exists in the GitHub version of the headers too.
Thanks!
--
Zoë Peterson
Scooter Software
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very vague gettickcount64 description?
On 9/8/2019 2:09 AM, Michael Van Canneyt wrote: For relative measurements, units are not needed. A ratio has no units, the only thing that is required is that the units for both measurements are the same (which should be the case on a single platform). That's fair. GetTickCount is also the best thing for quickly checking timeouts and the like though. I can certainly agree that FPC would benefit from a function that can return platform-specific timing data as quickly as possible, but that should just be called something else. But I have re-checked the Microsoft documentation, the implementation, and have added millisecond units to documentation of gettickcount(64). Thank you :) Note that the FPC implementation gives an increasing time, not the number of milliseconds elapsed since system boot. Which is what, strictly speaking, it should return to comply to the Microsoft implementation. That seems like a reasonable restriction to me. Needing the actual system uptime is going to be a much rarer than profiling or checking elapsed times, and supporting that aspect would be in conflict with making the function low overhead. -- Zoë Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Language Server
Ryan, Do you have a link to the LSP discord channel? I tried following the one you posted Friday, but I got an error that I either didn't have access to any text channels or there weren't any on the server. Thanks! On 4/27/2020 10:12 AM, Ryan Joseph via fpc-pascal wrote: On Apr 26, 2020, at 4:46 PM, Ryan Joseph wrote: The other thing I'm stuck on with code tools. In TCodeManagerTool: function FindReferences(IdentifierCode: TCodeBuffer; X, Y: integer; SearchInCode: TCodeBuffer; SkipComments: boolean; var ListOfPCodeXYPosition: TFPList; var Cache: TFindIdentifierReferenceCache // you must free Cache ): boolean; Any word on this? Is it even possible to find all references in a project or do we need to extend code tools for this to work? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics in Objective Pascal?
On 11/2/20 1:01 PM, Ryan Joseph via fpc-pascal wrote: What are you trying to do exactly? There are categories in ObjC but those don't allow fields (they're like helpers in Object Pascal). If you need to share data between a bunch of different NSView subclasses then all you can do is make a common subclass or make the shared data a class of its own and pass that into all your subclasses. Nothing ObjC related about that however but I'm not sure what you're trying to do. I have an NSView subclass with a bunch of fields and methods, and I wanted to be able to optionally swap that out with a parallel version derived from NSVisualEffectView without duplicating all of the code. I was hoping that adding generics to objcclass would be relatively trivial and just hadn't been asked for, but I know how assuming that usually goes. More specifically, under LCL/Cocoa, TCustomControl's Handle uses a TCocoaManualScrollView(NSView) (in lcl/interfaces/cocoa/cocoascrollers.pas) that has a bunch of code to interact with the LCL objects. When running recent versions of macOS in dark mode, custom controls like TTreeView actually use a behind-the-window blur rather than a plain clWindow FillRect. Since a lot of the TCocoaManualScrollView interaction is just general NSView messages or LCL protocol/category extensions, I figured I could keep the changes fairly small if I was able to just swap in a TCocoaManualScrollView, which would avoid introducing another view in the hierarchy, keep the code cleaner, and be easier to disable if MACOS_MINIMUM_DEPLOYMENT_TARGET < 10.10. I should be able to make it work with composition and re-parenting things when necessary, but there will be a lot more management code, so I thought I'd ask. -- Zoë Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature Announcement: Function References and Anonymous Functions
Sven, I'm absolutely thrilled to see this finally merged. I sincerely appreciate all of the work that you and Blaise put into it over such a long time. I can't wait to see what the community is able to do with it. Thank you, and thank you to the entire Free Pascal team for everything you've all built. -- Zoë Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
