Re: [fpc-pascal] Abstract classes ignored
> On Apr 17, 2021, at 3:09 PM, Sven Barth wrote: > > The compiler will generate a warning in case you instantiate a class that is > abstract or has abstract methods. You can escalate these warnings to errors > if you need: It's probably not practical to put that warning into all potential files but a warning is still probably good enough as a reminder. It's curious though why it's not an error by default, because if the class is abstract and you instantiate it and try to use it things are going to fail anyways so why does the compiler allow it in the first place? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Directory Tree
In Unicode/UTF8 "char" can be represented by several bytes so my code won't work. It seems you use page code 850 (here in France we are in 1252 which doesn't have the box chars). In unit uFileVirtualTree line 469, I have added type String850= type String(850); declared the local variable s of String850 on line 488, and changed on line 533 the default encoding of the Stringlist to 850 by sl.DefaultEncoding:= TEncoding.GetEncoding(850); It seems to be sufficient to get the box characters. I didn't dig further but it seems to work either on Windows and Linux and in text file generated. In the ODT file I used a numbered list but I think it will be difficult to get something closer to a tree. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Background info on Generics in FPC
Am 17.04.2021 um 21:07 schrieb Graeme Geldenhuys via fpc-pascal: I'm looking at the wiki and official FPC language documentation. What was the reason for the decision to make the FPC syntax so verbose regarding Generics? I don't know what the original reason was, but nowadays it's main advantage is that it avoids ambiguity. Take the following code: === code begin === someint := SomeGeneric + 42; === code end === The problem is that Delphi allows overloading of generic types with non-generic types, variables, constants and routines, thus up until the SomeType the code could in fact be the following as well: === code begin === var SomeType, SomeGeneric: LongInt; someint: Boolean; begin someint := SomeGenericThe compiler's parser has a very limited look ahead and thus especially with more complex specializations (especially nested ones) and type overloads in scope the compiler might not come to the right decision (e.g. it decided to parse it as a specialization, but it should have been a non-generic expression instead) and then it would need to do back tracking. Delphi's parser handles such cases correctly, but FPC's parser is currently simply not capable of that. Thus the "specialize" keyword definitely helps to differentiate between a non-generic expression and a specialization. This also means that the non-Delphi modes currently can handle more complex expressions involving generics than mode Delphi can. And for the "generic" keyword one could say that this way it is clear that one can't use the type as is and instead one must specialize them (also remember that originaly FPC did not support inline specializations; instead you had to do a type declaration for each specialization you wanted). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Abstract classes ignored
Am 17.04.2021 um 20:30 schrieb Ryan Joseph via fpc-pascal:
From the documentation: "An abstract class is a class that cannot be instantiated
directly. Instead, a descendent class must always be instantiated. However, for Delphi
compatibility, the compiler ignores this directive."
Why does this get ignored and what does this have to do with Delphi? I
personally would like for this to actually work and give a compiler error if
you instantiate the abstract class.
The compiler will generate a warning in case you instantiate a class
that is abstract or has abstract methods. You can escalate these
warnings to errors if you need:
=== code begin ===
program tabstract;
{$MODE OBJFPC}
{$WARN CONSTRUCTING_ABSTRACT ERROR}
type
TAbstract1 = class abstract
end;
TAbstract2 = class
procedure Test; virtual; abstract;
end;
var
a1: TAbstract1;
a2: TAbstract2;
begin
a1 := TAbstract1.Create;
a2 := TAbstract2.Create;
end.
=== code end ===
This will generate two (different) errors.
With this we're allowing more than Delphi does (which warns in the
second case, but the warning can not be escalated to error and does not
warn for the first case at all), but Delphi compatbility is more
important here, thus the default is a warning and not an error. This
will not be changed.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Directory Tree
I tried
vertical_line_char=#179;
horizontal_line_char=#196;
angle_char=#192;
crossing_char=#195;
which are the appropriate ASCII box characters...
but it produces:
M: = 32:34
Project1 = 18:30
? File1 = 8:32
? File2 = 7:43
? File3 = 2:15
Project2 = 14:04
Component1 = 14:04
Part1 = 5:32
Part2 = 8:32
I also tried
vertical_line_char=chr(179);
horizontal_line_char=chr(196);
angle_char=chr(192);
crossing_char=chr(195);
then I thought they must be Unicode.. so I tried the Unicode box characters:
vertical_line_char=$2502;
horizontal_line_char=$2500;
angle_char=$2514;
crossing_char=$251C;
but that gave me errors saying my constants were out of range and must be
between 0 and 255... so if they have to be between 0 and 255, then they should
be ACSII characters.. .so my original characters should have worked... so maybe
it's just my text editor that's the problem...
is there a way we can maybe make it rich text format so the font can be
specified? Then I could specify Consolas which is a fixed width font and get
the box characters from that... or maybe there is a way to do this with the ODT
file.
The ODT file opens in MS Word, but it doesn't draw the tree, it has text Like:
1
1.1 M: 32:34
1.1.1 Project1 18:30
1.1.1.1 File1 8:32
1.1.1.2 File2 7:43
Any ideas how to get box characters to work?
James
-Original Message-
From: fpc-pascal On Behalf Of Jean
SUZINEAU via fpc-pascal
Sent: Friday, April 16, 2021 6:23 PM
To: fpc-pascal@lists.freepascal.org
Cc: Jean SUZINEAU
Subject: Re: [fpc-pascal] Directory Tree
Le 15/04/2021 à 20:16, James Richters via fpc-pascal a écrit :
> It doesn't have to be a PDF, it could be an image file, or even a text
> file...maybe I can just make a text file of the output and use box
> characters to draw the tree. It seems like I should be able to get the
> branches of the treedata somehow and just do a writeln to a file with
> the right formatting.
I have added a text rendering of the tree, it's saved in a text file Result.txt.
The rendering code is in unit uFileVirtualTree, function
ThVirtualStringTree.render_as_text. It's called in ufFileVirtualTree in
procedure TfFileVirtualTree.bGetCheckedClick:
m.Lines .Text:= slResult.Text+#13#10+hvstResult.render_as_text;
m.Lines .SaveToFile('Result.txt');
In function ThVirtualStringTree.render_as_text I used 3 constants for the chars
used for drawing the tree outline:
vertical_line_char='|';
horizontal_line_char='-';
angle_char='*';
crossing_char='L';
You can tune this to your needs.
I have added to a rendering as numbered list in an odt file, the text file
format for Libre Office and Open Office. The "template"
FileTree.odt is duplicated with a temp name in the user temp directory, and
opened in the software register in windows for opening odt files by the
function OpenDocument() of Lazarus. Depending on your installation it can be
open in Libre Office/OpenOffice or in MS Word (sometimes the rendering is not
perfect in Word).
Before recompiling the project, you will need to open first in Lazarus the
package pascal_o_r_mapping\02_Units\OD_DelphiReportEngine_Units.lpk
in order to make Lazarus know where it is.
If for some reason you can't load this package, you can remove it from the
dependency panel of the project inspector, and in unit ufFileVirtualTree,
comment out in the use clause the unit uFileVirtualTree_odt, and comment out in
procedure TfFileVirtualTree.bGetCheckedClick the line:
OpenDocument( FileVirtualTree_odt( 'FileTree.odt', hvstResult));
I've considered making a screenshot of virtual tree component but if the whole
opened tree doesn't fit in the screen it will not work.
___
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] Background info on Generics in FPC
> On Apr 17, 2021, at 1:07 PM, Graeme Geldenhuys via fpc-pascal > wrote: > > Hi > > I'm looking at the wiki and official FPC language documentation. What was > the reason for the decision to make the FPC syntax so verbose regarding > Generics? There is a plan to make these optional via a mode switch but it hasn't happened yet. Personally I like the "generic" keyword but the specialize keyword is annoying if you don't make a type alias (and for function calls of course). Implicit function specialization is already ready so at least we won't need to use <> at all for function calls. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Background info on Generics in FPC
> Am 17.04.2021 um 21:07 schrieb Graeme Geldenhuys via fpc-pascal > : > > Hi > > I'm looking at the wiki and official FPC language documentation. What was > the reason for the decision to make the FPC syntax so verbose regarding > Generics? Same reason why we have a : array[0..10] of integer; instead of a : integer[0..10]; After all, using the keywords generic and specialize felt more pascalish to us. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Background info on Generics in FPC
Hi I'm looking at the wiki and official FPC language documentation. What was the reason for the decision to make the FPC syntax so verbose regarding Generics? eg: What we have now type generic TArray = array of t; TMyIntegerArray = specialize TArray; generic IList<_T> = Interface Function GetItem(AIndex : Integer) : _T; Procedure SetItem(AIndex : Integer; AValue : _T); Function GetCount : Integer; Property Items [AIndex : Integer] : _T Read GetItem Write SetItem; Property Count : Integer Read GetCount; end; generic TList<_T>=class(TObject, specialize IList<_T>) public type TCompareFunc = function(const Item1, Item2: _T): Integer; Function GetItem(AIndex : Integer) : _T; Procedure SetItem(AIndex : Integer; AValue : _T); Function GetCount : Integer; Public data : _T; procedure Add(item: _T); procedure Sort(compare: TCompareFunc); end; Why couldn't it have been made less verbose like this: type TArray = array of t; TMyIntegerArray = TArray; IList<_T> = Interface Function GetItem(AIndex : Integer) : _T; Procedure SetItem(AIndex : Integer; AValue : _T); Function GetCount : Integer; Property Items [AIndex : Integer] : _T Read GetItem Write SetItem; Property Count : Integer Read GetCount; end; TList<_T>=class(TObject, IList<_T>) public type TCompareFunc = function(const Item1, Item2: _T): Integer; Function GetItem(AIndex : Integer) : _T; Procedure SetItem(AIndex : Integer; AValue : _T); Function GetCount : Integer; Public data : _T; procedure Add(item: _T); procedure Sort(compare: TCompareFunc); end; Out of curiosity I would like to understand the reasoning behind the verbose usage of the keywords `generic` and `specialize`. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Abstract classes ignored
From the documentation: "An abstract class is a class that cannot be instantiated directly. Instead, a descendent class must always be instantiated. However, for Delphi compatibility, the compiler ignores this directive." Why does this get ignored and what does this have to do with Delphi? I personally would like for this to actually work and give a compiler error if you instantiate the abstract class. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation patch for fcl/netdb
Thank you. I will check it out ASAP. Before publishing, I will need to document all identifiers in the unit. Michael. On Sat, 17 Apr 2021, Noel Duffy via fpc-pascal wrote: I've added a documentation patch to bug 0037906 in the bug tracker. This covers the new code that I added to fcl/netdb for DNS resolution as well most of the other functions and procedures in the unit. The patch also adds examples that showcase the new functions. I've tested these on Fedora 32 only. https://bugs.freepascal.org/view.php?id=37906#c130418 ___ 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
[fpc-pascal] Documentation patch for fcl/netdb
I've added a documentation patch to bug 0037906 in the bug tracker. This covers the new code that I added to fcl/netdb for DNS resolution as well most of the other functions and procedures in the unit. The patch also adds examples that showcase the new functions. I've tested these on Fedora 32 only. https://bugs.freepascal.org/view.php?id=37906#c130418 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
