Re: [fpc-pascal] Constants in generics
Am Sa., 5. Jan. 2019, 22:57 hat Ryan Joseph geschrieben: > Here’s the new syntax requirements for const params which require types > and consts be separated by semicolons. > > Does TStuff2 need a ; between the two const params? Sven said consts must > follow ; or < but they’re both consts so I thought I’d ask to make sure. > > type > generic TStuff0 = record end; > generic TStuff1 = record end; > generic TStuff2 = record end; > generic TStuff3 = record end; > Just think about it logically: B and C can't be anything else than const, so why would we need to repeat it? Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get "disk" ID
Il 05/01/2019 17:03, Bart ha scritto: I need some function to get a unique ID for a disk. I need this to identify if my program has accessed this disk previously. For that purpose on Linux, out of laziness, I usually just parse the output of command-line utilities, such as blkid or lsblk. blkid /devs/sd/xy/ provides an output such as: blkid /dev/sda1 /dev/sda1: LABEL="SYSTEM" UUID="980C041F0C03F6D2" TYPE="ntfs" or blkid /dev/sda3 /dev/sda3: UUID="ce9d5b2f-232f-4a87-a75e-70e1386dd134" TYPE="ext4" while lsblk can provide either a single partition UUID (/dev/sd/xy/) or the UUIDS for all the disk partitions (/dev/sd/x/): sudo lsblk -f /dev/sda3 NAME FSTYPE LABEL UUID MOUNTPOINT sda3 ext4 ce9d5b2f-232f-4a87-a75e-70e1386dd134 /boot or sudo lsblk -f /dev/sda NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 ntfs SYSTEM 980C041F0C03F6D2 ├─sda2 ntfs Windows 5E1043661043446D /media/Windows ├─sda3 ext4 ce9d5b2f-232f-4a87-a75e-70e1386dd134 /boot ├─sda4 ├─sda5 ntfs HP_RECOVERY 2CF47035F470037E ├─sda6 vfat HP_TOOLS 7E18-51AB ├─sda7 swap 68647ac3-2d0b-4f71-92dd-65220092bab6 [SWAP] └─sda8 ext4 4ccb4264-9920-4d2b-a568-bfc5024eafcd / Those utilities are based on the libblkid library, which does the real job. If you prefer an approach which doesn't require launching an executable and parsing its output, you may give a look to the C code of the sources, find the appropriate API's, and then bind what required to your Pascal program. On Mac OSX you should be able to get the UUID by using diskutil, but I never tested. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Interface bug or some new feature
Hi all
I've been using 3.1.1 compiler for a long time and now I am trying to upgrade
to 3.3.1 from trunk.
However, I am stuck with some new behavior when using classes + interfaces.
I've managed to reproduce it in a small example which follows.
Specifically 3.1.1 compiler compiles it and correctly prints "Double".
3.3.1 compiler refuses to compile it at all.
Please comment if it's a bug or a new breaking feature.
//==
program project1;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes
{ you can add units after this };
type
IIntf1 = interface
procedure P(i:Integer);
end;
TClass1 = class(TInterfacedObject, IIntf1)
procedure P(i:Integer);
end;
IIntf2 = interface(IIntf1)
procedure P(f:Double);
end;
TClass2 = class(TClass1, IIntf2) // Error: No matching implementation for
interface method "P(LongInt);" found
procedure P(f:Double);
end;
procedure TClass1.P(i:Integer);
begin
WriteLn('Integer');
end;
procedure TClass2.P(f:Double);
begin
WriteLn('Double');
end;
var v2:TClass2;
begin
v2:=TClass2.Create;
v2.P(0.0);
v2.Free;
end.
//===
--
Regards,
Denis Golovan
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get "disk" ID
Am Sa., 5. Jan. 2019, 17:05 hat Bart geschrieben: > Hi, > > I need some function to get a unique ID for a disk. > I need this to identify if my program has accessed this disk previously. > > On Windows I can retreive the VolumeSerialNr, but how do I do > something like that in Linux? > Mind you: the "ID" retrieved does NOT have to be the same for each > platform. > (I'ld prefer if the "ID" was some kind of integer.) > > So if a disk on Windows returns 1234, it is not a problem if on Linux > the same disk will return 4567. > The "ID" retrieved however must remeain the same if the disk is > removed and inserted at a later point in time (regardless of a reboot > of the system in the mean time). > If the disk was formatted before inserting a next time, it will not > matter if the "ID" changes. > > Preferrably the code for linux would also work on MacOSX. > Best of course would be to query the serial of the disk itself, we do that in our software at work, but I don't know right now how exactly that needs to be done (I think on Linux we go through SysFS). Alternatively you can use the Disk ID that is located inside the MBR of both MBR and GPT formatted disks at address 0x1B8 with a size of 4 Byte. Please note that you need to read from the disk, not the partition for that and that this won't work with SuperFloppy formatted disks (e.g. common USB drives are often not partitioned with MBR/GPT, but have a file system starting at sector zero). See also: https://en.m.wikipedia.org/wiki/Master_boot_record Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface bug or some new feature
On 06/01/19 11:42, denisgolovan wrote: Specifically 3.1.1 compiler compiles it and correctly prints "Double". 3.3.1 compiler refuses to compile it at all. Please comment if it's a bug or a new breaking feature. http://wiki.freepascal.org/User_Changes_Trunk#Methods_implementing_interface_methods_and_overloads Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface bug or some new feature
Am So., 6. Jan. 2019, 11:42 hat denisgolovan
geschrieben:
> Hi all
>
> I've been using 3.1.1 compiler for a long time and now I am trying to
> upgrade to 3.3.1 from trunk.
> However, I am stuck with some new behavior when using classes + interfaces.
> I've managed to reproduce it in a small example which follows.
>
> Specifically 3.1.1 compiler compiles it and correctly prints "Double".
> 3.3.1 compiler refuses to compile it at all.
> Please comment if it's a bug or a new breaking feature.
>
> //==
> program project1;
>
> {$mode objfpc}{$H+}
>
> uses
> {$IFDEF UNIX}{$IFDEF UseCThreads}
> cthreads,
> {$ENDIF}{$ENDIF}
> Classes
> { you can add units after this };
>
> type
> IIntf1 = interface
> procedure P(i:Integer);
> end;
>
> TClass1 = class(TInterfacedObject, IIntf1)
> procedure P(i:Integer);
> end;
>
> IIntf2 = interface(IIntf1)
> procedure P(f:Double);
> end;
>
> TClass2 = class(TClass1, IIntf2) // Error: No matching implementation
> for interface method "P(LongInt);" found
> procedure P(f:Double);
> end;
>
> procedure TClass1.P(i:Integer);
> begin
> WriteLn('Integer');
> end;
>
> procedure TClass2.P(f:Double);
> begin
> WriteLn('Double');
> end;
>
> var v2:TClass2;
> begin
> v2:=TClass2.Create;
> v2.P(0.0);
> v2.Free;
> end.
>
The default visibility for classes without $M+ is private. Thus TClass1.P
is private. An interface implementation does not have access to private
methods of a parent class. So you need to declare P as protected for this
to work.
Though to be fair in the specific example you gave I think that it should
work as both are within the same unit. We'll need to check that...
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface bug or some new feature
06.01.2019, 14:57, "Jonas Maebe" : > http://wiki.freepascal.org/User_Changes_Trunk#Methods_implementing_interface_methods_and_overloads > > Jonas Thanks, Jonas. That was precisely the cause for my trouble. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface bug or some new feature
06.01.2019, 15:00, "Sven Barth via fpc-pascal" : The default visibility for classes without $M+ is private. Thus TClass1.P is private. An interface implementation does not have access to private methods of a parent class. So you need to declare P as protected for this to work. Though to be fair in the specific example you gave I think that it should work as both are within the same unit. We'll need to check that... Yes. That was another real issue in my project.However I managed to get it.Thanks for quick help. -- Regards,Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface bug or some new feature
Am 06.01.2019 um 13:30 schrieb denisgolovan: 06.01.2019, 15:00, "Sven Barth via fpc-pascal" : The default visibility for classes without $M+ is private. Thus TClass1.P is private. An interface implementation does not have access to private methods of a parent class. So you need to declare P as protected for this to work. Though to be fair in the specific example you gave I think that it should work as both are within the same unit. We'll need to check that... Yes. That was another real issue in my project. However I managed to get it. Thanks for quick help. Slight correction: the default visibility is Public, not Private, so that shouldn't have been the problem with the specific example. :/ Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface bug or some new feature
Am 06.01.2019 um 12:56 schrieb Jonas Maebe: On 06/01/19 11:42, denisgolovan wrote: Specifically 3.1.1 compiler compiles it and correctly prints "Double". 3.3.1 compiler refuses to compile it at all. Please comment if it's a bug or a new breaking feature. http://wiki.freepascal.org/User_Changes_Trunk#Methods_implementing_interface_methods_and_overloads But shouldn't that specifc example work? TClass1.P is public here, not private. Also unlike FPC Delphi does not give the following warning: Warning: An inherited method is hidden by "P(Double);" Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface bug or some new feature
On 06/01/19 14:00, Sven Barth via fpc-pascal wrote: Am 06.01.2019 um 12:56 schrieb Jonas Maebe: On 06/01/19 11:42, denisgolovan wrote: Specifically 3.1.1 compiler compiles it and correctly prints "Double". 3.3.1 compiler refuses to compile it at all. Please comment if it's a bug or a new breaking feature. http://wiki.freepascal.org/User_Changes_Trunk#Methods_implementing_interface_methods_and_overloads But shouldn't that specifc example work? TClass1.P is public here, not private. It's unrelated to public and private (that is covered in http://wiki.freepascal.org/User_Changes_Trunk#Visibility_of_methods_implementing_interface_methods ). It's only about overloads. If you do not declare a method as "overload", the compiler will now stop searching the class hierarchy as soon as it finds a class that declares a method with the right name. It already did this when calling methods, now it also does it for interface method resolution. Also unlike FPC Delphi does not give the following warning: Warning: An inherited method is hidden by "P(Double);" At least Kylix fails to compile the test program: Borland Delphi for Linux Version 14.5 Copyright (c) 1983,2002 Borland Software Corporation tt.pp(31) Error: Declaration of 'P' differs from declaration in interface 'IIntf2' tt.pp(49) Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
> On Jan 6, 2019, at 1:28 AM, Sven Barth via fpc-pascal > wrote: > > Just think about it logically: B and C can't be anything else than const, so > why would we need to repeat it? I’m not saying anyone would actually write that generic but if it does appear what terminator is used? A more clear example is: . It would make more sense to say of course but it could appear the other way. Maybe I’m not understand you though. For now I just required all const lists separated with ; since that was your first suggestions, i.e. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
Last question I have I think. Is this the best way to get "pretty name" string for a set? Having to loop through the entire range of the set is not so great but I don’t see another way. I feel like there should be some utility functions to get names for ord defs also but I just did a crude string conversion for now. new(ps); ps^:=tsetconstnode(node).value_set^; sym:=cconstsym.create_ptr(undefinedname,constset,ps,fromdef); setdef:=tsetdef(tsetconstnode(node).resultdef); enumdef:=tenumdef(setdef.elementdef); prettyname:='['; for i := setdef.setbase to setdef.setmax do if i in tsetconstnode(node).value_set^ then begin enumsym:=enumdef.int2enumsym(i); if assigned(enumsym) then enumname:=enumsym.realname else if enumdef.typ=orddef then begin if torddef(enumdef).ordtype=uchar then enumname:=chr(i) else enumname:=tostr(i); end else enumname:=tostr(i); if length(prettyname) > 1 then prettyname:=prettyname+','+enumname else prettyname:=prettyname+enumname; end; prettyname:=prettyname+']'; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
Just wanted to say, I've been playing around with Ryan's github branch that
contains this functionality and I'm loving it! It really opens up a ton of
interesting possibilities in general, and also a lot of potential for
optimization via constant folding for generic containers that wasn't really
possible previously. Here's a more "advanced" example I threw together of
the kinds of things you can actually do with this (I'm aware the final
syntax for the declarations is going to be slightly different, not that it
matters really):
program Example;
{$Mode ObjFPC}{$H+}{$J-}
{$ModeSwitch AdvancedRecords}
{$PointerMath On}
type
generic TStaticList = record
public type
TStaticListEnumerator = record
public type PT = ^T;
strict private
FFirst, FLast, FCurrent: PT;
public
class function Create(var List: TStaticList): TStaticListEnumerator;
inline; static;
function MoveNext: Boolean; inline;
property Current: PT read FCurrent;
end;
strict private
Items: array[L..H] of T;
public
function Low: PtrUInt; inline;
function High: PtrUInt; inline;
procedure Initialize; inline;
function GetEnumerator: TStaticListEnumerator; inline;
end;
class function TStaticList.TStaticListEnumerator.Create(var List:
TStaticList): TStaticListEnumerator;
begin
with Result do begin
FFirst := @List.Items[L];
FLast := @List.Items[H];
FCurrent := FFirst - 1;
end;
end;
function TStaticList.TStaticListEnumerator.MoveNext: Boolean;
begin
Inc(FCurrent);
Result := (FFirst <> FLast) and (FCurrent <= FLast);
end;
function TStaticList.Low: PtrUInt;
begin
Result := L;
end;
function TStaticList.High: PtrUInt;
begin
Result := H;
end;
procedure TStaticList.Initialize;
var I: PtrUInt;
begin
for I := Low() to High() do Items[I] := T(I);
end;
function TStaticList.GetEnumerator: TStaticListEnumerator;
begin
Result := TStaticListEnumerator.Create(Self);
end;
var
AsciiList: specialize TStaticList;
P: PChar;
begin
AsciiList.Initialize();
for P in AsciiList do Write(P^);
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
> On Jan 6, 2019, at 1:31 PM, Ben Grasset wrote: > > generic TStaticList = record > This is exactly the reason I added the feature, there’s no way to extend static arrays otherwise! Beyond this one thing I have no idea what to use them for. ;) Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
On Sun, Jan 6, 2019 at 4:23 PM Ryan Joseph wrote: > This is exactly the reason I added the feature, there’s no way to extend > static arrays otherwise! Beyond this one thing I have no idea what to use > them for. ;) > I've got a bunch of stuff in mind actually that I'm waiting on the "final" version for before I start getting into too seriously. There's a lot that's possible as far as custom string types and such if you combine this with operator overloading. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
Since we introduced “const” keywords to generic params does it make sense to use an optional “type” keyword also? That just occurred to me as something worth discussing. No opinion either way except there’s a inconsistency now which may bother some people. generic TStuff = record end; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] inlining functions
On 03/01/19 00:10, Benito van der Zander wrote: The one-pass thing is probably the reason it now complains about all inline functions in dependency cycles, unit A uses unit B that uses unit A. Then unit A can't inline something unit B. Any way around that? Not besides breaking your dependency cycles. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
Am So., 6. Jan. 2019, 19:07 hat Ryan Joseph geschrieben: > Last question I have I think. > > Is this the best way to get "pretty name" string for a set? Having to loop > through the entire range of the set is not so great but I don’t see another > way. I feel like there should be some utility functions to get names for > ord defs also but I just did a crude string conversion for now. > I don't think that there is a better way. Also up to now it wasn't necessary for the compiler to do this, thus there are no utility functions for it. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
Am So., 6. Jan. 2019, 22:38 hat Ryan Joseph geschrieben: > Since we introduced “const” keywords to generic params does it make sense > to use an optional “type” keyword also? That just occurred to me as > something worth discussing. No opinion either way except there’s a > inconsistency now which may bother some people. > > generic TStuff = record end; > We can always add it in later if we think it's needed. Let's keep it out for now. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
I updated the github with the requested changes. Is that everything? I’ll submit a patch if so. https://github.com/genericptr/freepascal/tree/generic_constants Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
You still have two C-style operator += instances in pgenutil.pas FYI, that don't compile with the default settings. On Sun, Jan 6, 2019 at 8:36 PM Ryan Joseph wrote: > I updated the github with the requested changes. Is that everything? I’ll > submit a patch if so. > > https://github.com/genericptr/freepascal/tree/generic_constants > > Regards, > Ryan Joseph > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
Also, there's: pgenutil.pas(158,28) Warning: Class types "tenumdef" and "torddef" are not related which breaks compilation because the compiler is built with -sew turned on if you do it through the normal makefiles. I think you need tests before you do a patch, also? (Unless you already have them ready somewhere and just didn't upload them yet.) On Sun, Jan 6, 2019 at 8:36 PM Ryan Joseph wrote: > I updated the github with the requested changes. Is that everything? I’ll > submit a patch if so. > > https://github.com/genericptr/freepascal/tree/generic_constants > > Regards, > Ryan Joseph > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Small typo in User_Changes_Trunk ?
Hi, reading http://wiki.freepascal.org/User_Changes_Trunk#Modeswitch_TypeHelpers_in_Delphi_modes_enables_type_helper-syntax there is: Remedy: The only problems arise if one disabled the modeswitch on purpose which now longer disallows the extension of primitive types. Is there missing "no"?: Remedy: The only problems arise if one disabled the modeswitch on purpose which now *no* longer disallows the extension of primitive types. -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
