Re: [fpc-pascal] fcl-passrc with Objective-c
Michael Van Canneyt schrieb am Mi., 2. Okt. 2019, 16:37: > > > On Wed, 2 Oct 2019, Ryan Joseph wrote: > > > How well can the parser handle the objective-c mode? At my first attempt > it seemed to fail pretty early on so I’m not sure it’s even supported. > > Correct, it is not supported. > > I don't even know what the allowed syntax is. From your example I see > 'required' and 'Optional' - definitely things that are not supported. > > AFAIK "objcprotocol" is also not supported, so my guess is that it thinks > this is a type alias, which explains the error message. > I suppose that the documentation is still rather up to date regarding that: https://www.freepascal.org/docs-html/current/ref/refch11.html#x128-1511 Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] threads, memory barriers and RTLeventSetEvent / RTLeventWaitFor
Martin schrieb am Di., 1. Okt. 2019, 17:19: > I am currently looking at a strange issue in FpDebug. > > The main thread loads a lot of data from a file, and creates various > objects. > > Then some code is executed in a sub-thread. The timing of that > (start/stop of the 2 threads) is handled by RTLeventSetEvent / > RTLeventWaitFor. > This code does not seem to find (some of/ all?) the data. (for > comparison, on windows the same code continues to run in the main > thread, and finds the data). > > So the suspicion arises that maybe the thread has older data cached? > > Therefore my question: > Does RTLeventSetEvent / RTLeventWaitFor make sure memory is synchronized > between threads? > > //MAIN thread > procedure TFpDebugDebugger.ExecuteInDebugThread(AMethod: > TFpDbgAsyncMethod); > begin >assert(not assigned(FFpDebugThread.AsyncMethod)); >FFpDebugThread.AsyncMethod:=AMethod; >RTLeventSetEvent(FFpDebugThread.StartDebugLoopEvent); >RTLeventWaitFor(FFpDebugThread.DebugLoopStoppedEvent); >RTLeventResetEvent(FFpDebugThread.DebugLoopStoppedEvent); >FFpDebugThread.AsyncMethod:=nil; > end; > > // OTHER thread > procedure TFpDebugThread.Execute; > begin > ... > repeat > RTLeventWaitFor(FStartDebugLoopEvent); > RTLeventResetEvent(FStartDebugLoopEvent); >if assigned(FAsyncMethod) then > begin > try >FAsyncMethod(); > finally >RTLeventSetEvent(FDebugLoopStoppedEvent); > end; > end; > until Terminated; > end; > The functions themselves AFAIK don't have any memory barriers, so it would depend solely on the OS primitives. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] for-in loop cast
Ryan Joseph schrieb am Do., 26. Sep. 2019, 17:37: > Question I’ve always had. Why do I need to cast “value” to “pointer" > otherwise I get: Incompatible types: got "Pointer" expected “TObject” > error?. I don’t find this very helpful and it doesn’t really make sense > even. > > var > list: TObjectList; > value: TObject; > begin > for pointer(value) in list do > ; > Aside from what Ben wrote I wonder whether such a cast should be able to compile at all... 🤔 And we should probably add a proper TObject enumerator to TObjectList. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC docs about FindFirst
Ched schrieb am So., 22. Sep. 2019, 21:11: > Hello, > > > Le 22.09.19 à 16:59, Michael Van Canneyt a écrit : > > > > > > On Sun, 22 Sep 2019, AlexeyT wrote: > > > >> https://www.freepascal.org/docs-html/rtl/sysutils/findfirst.html > >> > >> 1) add to the list of attribs the value faAnyFile. > > > > Done. > >> > >> 2) correct the example: call FindClose only inside block "if > FindFirst(..)=0" > > > > This is already so in trunk. > > > > Michael. > > > From https://www.freepascal.org/port.html about porting Turbo Pascal > codes: > > > the dos unit Findfirst() call must always be followed by a Findclose to > release some resource. > > What's right ? > Both. AlexeyT and Michael are talking about SyeUtils.FindFirst/FindNext/FindClose while the page you mentioned is about Dos.FindFirst/FindNext/FindClose. Same names, but different units with slightly different behavior. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [Lazarus] It's alive !
Am 21.09.2019 um 15:22 schrieb Michael Van Canneyt via lazarus: Hello, Finally, the moment has come: https://www.youtube.com/watch?v=xos2MnVxe-c Following up on a bounty offered, Dmitry Boyarintsev has accomplished milestone one in the implementation of FPC's webassembly backend. And: It's alive ! :-) The first result can be seen here: https://www.freepascal.org/~michael/lyff/ Conway's game of life written using FPC: - FPC itself for the WebAssembly Backend library. - pas2js for the necessary Javascript front end and GUI code. Although I can't imagine why you would want to, you can also load the webassembly from plain Javascript: https://www.freepascal.org/~michael/lyff/lyffjs.html Whoever thought Pascal is dead, should now think otherwise. It's very much alive ! Enjoy, Michael. PS. More info about the webassembly efforts will be assembled here: https://wiki.freepascal.org/WebAssembly It's a bit cursory at the moment, but will be improved as things evolve - once it's alive, it tries to stay alive ;) Awesome! Kudos to Dmitry. :) I'm looking forward to see this integrated into trunk. Implementing the RTL (at least as much as is possible within the constraints of the WebAssembly environment) will probably be quite some effort as well. ;) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Overloading Inc and Dec procedures?
LacaK schrieb am Mi., 18. Sep. 2019, 13:38: > Hi *, > > seems, that overloading of Inc, Dec internal compiler procedures is not > allowed. > Is it by intention or can it be fixed (adding overload keyword to system > function definitions?). > Yes, this is by intention and no, it can't be fixed. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Calculating Pixels to represent 3D coordinates
James Richters schrieb am Di., 17. Sep. 2019, 16:15: > I'm curious if Freepascal has any package available that would calculate > X,Y screen pixels based on 3D X,Y,Z data at some given rotations. I'm > using Agg-Pas with PTC-Graph in a console application on Windows. I'm not > sure what the technical term is for figuring out what pixels are used to > represent 3D coordinates on a 2D screen, but I'm hoping maybe there is > something that just does the calculations that I can use in conjunction > with Agg-Pas and PTC-Graph instead of moving to a complete graphics package. > You're essentially looking for a software renderer/rasterizer. Lookup things like projection matrix and model view matrix. You can also take a look at the "Ray Tracing in one weekend" books ( https://github.com/RayTracing/raytracing.github.io ) to get a feeling for what's required. In the end you might be better served to use a graphics package or at least OpenGL. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illegal counter variable?
James Richters schrieb am Mi., 11. Sep.
2019, 16:24:
> How do you get ‘By’ to work? I have downto working but if I try ‘By’ I
> get
>
>
>
> Fatal: Syntax error, "DO" expected but "identifier BY" found
>
Did you see anywhere that said that this bug report was resolved and the
patch integrated into trunk?
>
> If FPC is going to support downto and by, why not also support changing
> the control variable when not in {$Mode TP} as well, and just make a note
> that doing so may not be compatible with other pascal compilers.. but who
> cares anyway FPC is better than all the others anyway 😊
>
There is no interest in lifting that restriction. Out of the dialects that
FPC supports TP is the only one that does not. Even Wirth advised against
allowing it.
Also FPC already supports downto. Just like TP and Delphi do...
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illegal counter variable?
Christo Crause schrieb am Mi., 11. Sep. 2019, 09:54: > > On Wed, Sep 11, 2019 at 7:06 AM Ralf Quint wrote: > >> On 9/10/2019 4:26 PM, wkitt...@windstream.net wrote: >> > On 9/9/19 10:11 AM, James Richters wrote: >> >> Pascal doesn't have things like step... >> > >> > hunh??? i don't think that's right but i'm just catching up after >> > several 10+ hours days of $job... >> > >> > i know that i've written code in the past that did use something to >> > step X numbers per run through the look and it did not involved >> > manually incrementing the loop var... >> > >> > >> I am not aware of any Pascal implementation that does have a STEP >> parameter for FOR loops, and I am programming in Pascal at least as long >> as you... ;-) >> > > FPC documentation: > https://www.freepascal.org/docs-html/ref/refsu58.html#x164-18600013.2.4 - > at least FPC doesn't allow specifying an increment size. Several other > languages do allow specifying an increment (nice list of for loop > constructs with specified increment in various languages: > https://www.rosettacode.org/wiki/Loops/For_with_a_specified_step). Modula-2 > or Oberon-2 code snippets could perhaps be mistaken for Pascal through the > mists of time. > Well, we do have a patch for "for ... (down)to ... by" support: https://bugs.freepascal.org/view.php?id=25549 Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
fredvs schrieb am Sa., 31. Aug. 2019, 22:00: > Hello Sven. > > > Just look at the changes: ... > > OK, but before I have to check my stock of aspirin. > I think I'm going to need a lot this time. > > Many thanks Sven to help me in that complete darkness. > Alternatively try alcohol. ;) And I suggest you to extract code into small test programs so that you can test them independently of msegui and play around more easily. Maybe try to retrieve the necessary information yourself without using the msegui code to get a feeling for the RTTI - you'll need it. ;) Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Am 31.08.2019 um 18:24 schrieb fredvs: Hello. Type information contains reference to attribute table Old behavior: The first field of the data represented by TTypeData is whatever the sub branch of the case statement for the type contains. New behavior: The first field of the data represented by TTypeData is a reference to the custom attributes that are attributed to the type, only then the type specific fields follow. Reason: Any type can have attributes, so it make sense to provide this is a common location instead of having to parse the different types. Remedy: If you use the records provided by the TypInfo unit no changes should be necessary (same for the Rtti unit). If you directly access the binary data you need handle an additional Pointer field at the beginning of the TTypeData area and possibly correct the alignment for platforms that have strict alignment requirements (e.g. ARM or M68k). Aaargh, it seems that msegui uses direct access so the second remedy is needed. Every advice how to use that remedy, tips where to look, how to do, is, of course, very welcome. Just look at the changes: https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/typinfo.pp?r1=42373&r2=42375 If you have code that tries to access the type information you need to take that field into account. Same for properties, where especially this one is important: https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/typinfo.pp?r1=42358&r2=42365 When you iterate from one PPropInfo you need to take that into account or use the appropriate functions of the TypInfo unit. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
Am 31.08.2019 um 14:31 schrieb fredvs: Hello everybody and specially Sven Barth. With last trunk of fpc, msegui is no more compatible with fpc. After big fight, it appears that commit of Sven Barth on Jul 13 2019, rev 42375 breaks compatibility ---> "as attributes can be part of any type they are best suited in a common part of TTypeData" Could you give some light what to change to restore compatibility? The problems are with loading files, some structure are no more recognized. Note that there are no error message at compilation, nor when loading the files (so difficult to debug). Do you have a plan to give some infos of all what is changed in fpc and how to restore compatibility? https://wiki.freepascal.org/User_Changes_Trunk#Type_information_contains_reference_to_attribute_table I assume your code in msegui directly accesses the RTTI instead of using the types provided by the TypInfo unit. This is bound to break here and then when the RTTI is extended. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
schrieb am Di., 27. Aug. 2019, 01:38: > If anybody would like a near silent POWER9 system at home, > I can really recommend the new Blackbird mainboard with CPU bundles > from Raptor CS. The lower cost 4-core CPU uses so little power you > hardly even need a fan for it. > If only it wouldn't still be so damn expensive... I'm still a bit miffed that I didn't purchase one of the refurbished Tyan servers with a POWER8 for 250€ a few months ago... Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
schrieb am Mo., 26. Aug. 2019, 19:53: > Hello, > > trying to recompile now ... since ppc64le support is not in 3.0.4, I > suppose I need to use a more recent version to compile it. So there is > no advantage in cross-compiling and I might as well try it with the > latest native fpc compiler? > > So I need to fix compiler errors myself, is that correct, such as this: > sysosh.inc(19,1) Error: Forward type not resolved "Boolean8" > bugs.freepascal.org/view.php?id=35676 > > I wonder how the precompiled FPC for ppc64le is made, if trunk > cannot compile itself? > FPC 3.0.4 is still the latest release and thus currently the only supported compiler. In case of ppc64le you need to indeed cross compile though as long as you have the binutils it's as simple as make clean all CPU_TARGET=ppc64le BINUTILSPREFIX=ppc64le-elf- FPMAKEOPT="-T N" - j N Whereby you need to adjust BINUTILSPREFIX to whatever prefix your binutils have and N to e.g. your number of cores. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppc64le ABI problem
Florian Klämpfl schrieb am Mo., 26. Aug. 2019, 14:01: > Am 26. August 2019 00:59:16 schrieb tobiasgie...@gmail.com: > > > Hello, > > > > > > while examining a crash when running Lazarus on ppc64le, I found the > > following issue in function calls. > > > > > > Calls to functions with more than eight parameters seem to be > > implemented differently from how gcc does it in a C program. > > > > > > gcc uses the memory location 96(r1) for the ninth parameter, but FPC > > uses 112(r1). > > > > > > Therefore, calls to XGetWindowProperty crash. This function has 12 > > parameters. gcc puts the four last ones into 96(r1), 104(r1), 112(r1), > 120(r1), > > and FPC into 112(r1), 120(r1), 128(r1), 136(r1). > > > > > > What can be done about this? > > Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a > temporary test. > Line 302 in case anyone is wondering (thankfully that's the only "48" in that fike (plus its preceeding comment) ^^') Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Am 15.08.2019 um 00:39 schrieb Jean SUZINEAU: Le 14/08/2019 à 23:18, Martin a écrit : inc(CALL_LVL [ LOCAL_CALL ],1) Yes, "inc" does not work for properties. But neither does +=. I agree and in the case of a property I think it would be cleaner to code an Inc method directly in the class, or eventually in a class helper, to write something like: CALL_LVL [ LOCAL_CALL ].Inc(1) In case of property, it's likely that you'll even be able to optimize the code, trimming some lines of the getter and the setter in you Inc method. Please note that this won't work if CALL_LVL is a property and the returned type is a record is the returned value will be a temporary variable, thus you'd increase the value of the temp, but not of the one stored in the class. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Michael Van Canneyt schrieb am Mi., 14. Aug. 2019, 18:24: > Basically any operation that requires an address is not allowed. > That += is using an address is an implementation detail of the compiler. > Same as Inc() or In/Exclude(). I don't know the exact reason for this > limitation, > but it's bound to be a good one, otherwise it would have been lifted a > long time > ago... > The restriction regarding taking an address was only started to be enforced in 2.4.0 (see https://wiki.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields) and further extended to records in 2.6.0 (see https://wiki.freepascal.org/User_Changes_2.6.0#Taking_the_address_of_fields_of_record_properties ). The idea is to have properties backed by a field and backed by methods behave identically. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Ryan Joseph schrieb am Mi., 14. Aug. 2019, 18:04:
>
>
> > On Aug 14, 2019, at 11:52 AM, Joost van der Sluis wrote:
> >
> > Roflol... yeah... people do not use Pascal because they have to type:
> > i := i + 1;
> >
> > Sure.
>
> I’m once again shocked that anyone would be against such syntaxes as += so
> maybe the compiler needs to put them behind a modeswitch. Given what Sven
> said I’m surprised they didn’t do this from the start. Even “out” is behind
> a mode switch after all.
>
They already are, but not a modeswitch, but a directive: {$COperators
On/Off}. Probably from a time before modeswitches were introduced.
It's even per default off. The default fpc.cfg however enables them...
And "out" is behind a modeswitch because modes like TP and ISO don't know
that concept.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Martok schrieb am Di., 13. Aug. 2019, 14:44: > Am 12.08.2019 um 11:31 schrieb Sven Barth via fpc-pascal: > > The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b", > so > > except for using a temp to avoid duplicate calculation of "a" in how far > is this > > not the long form? > > No, I meant it doesn't re-parse as its long form, which is why it has some > limitations. In this case for example handle_propertysym does not know it > is > actually seeing an assignment. > > I don't think the compiler can do this? Macros are expanded on the scanner > level, token stream injection is not a thing in FPC, AFAICS? > It could be done, but property support for the C operators is not *desired*. See the entry of the function you posted: properties are explicitly rejected. In general the C operators are not desired. They where added way in the past in a weak moment and I don't think they'd be added today if FPC wouldn't have them already. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Martok schrieb am Mo., 12. Aug. 2019, 10:18: > Am 12.08.2019 um 09:40 schrieb Michael Van Canneyt: > > > > This question pops up from time to time since 15 years if not more. > > Fun fact: questions asking why this doesn't work have a higher Google > ranking > than the manual for "COPERATORS" ;-) > > @Ryan: as with all things FPC, ignore the manual, read the parser: > < > https://github.com/graemeg/freepascal/blob/4e6c609/compiler/pexpr.pas#L221 > > > > Turns out c-operators do not actually translate to their long form but > instead > have special, duplicated handling. Because of course they do. > The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b", so except for using a temp to avoid duplicate calculation of "a" in how far is this not the long form? Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Am 11.08.2019 um 18:33 schrieb Ryan Joseph:
Is this a bug? It should resolve to:
d.setter(d.getter + 10)
but it doesn’t seem to be working.
{$mode objfpc}
{$modeswitch advancedrecords}
program test;
type
TData = record
x: integer;
end;
type
TVec2Helper = record helper for TData
function Getter: integer;
procedure Setter(newValue: integer);
property Get: integer read Getter write Setter;
end;
function TVec2Helper.Getter: integer;
begin
result := x;
end;
procedure TVec2Helper.Setter(newValue: integer);
begin
x := newValue;
end;
var
d: TData;
begin
d.get += 10; // ERROR: Variable identifier expected
end.
This is forbidden by design.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PPCJVM Android JVM target and building to dex
Mgr. Janusz Chmiel schrieb am Sa., 3. Aug. 2019, 11:48: > Many of advanced users and developers have tried PPCJVM. It is really > possible to create fully functioning Android applications. And because > it is even possible to access methods from previously compiled .jar > files including Mysql.jar and others, Pascal language have very big > potential. > But it has a very remarkable hook. > Latest JDK for WIndows from Oracle do not support old versions of Apache > ANT, so it is not possible to build .dex files from classes, which have > been previously generated by using PPCJVM. > So The future or Pascal compilation to .dex fomrat is severely > disadvantaged. Because old JDK 7 X release can produce .dex files and > only specific versions of Android build tools. > So The reality is, that PPCJVM can produce reliable classes, but there > is not too much projects, which can convert those .class files to dex > format. > Does somebody of you know about The solution to this issue? > I Am afraid, that this situation can lead to The fact, that PPCJVM will > not support ANDROID target JVM for too long times. If something positive > will not happen to generate while using newest JRE and JDK. > Hmm? The important part of converting the .class files to classes.dex is the dx utility which is part of the Android toolchain. Apache ANT is only a build system like Make or Gradle (which seems to be /the/ hype for Android development). My first PPCJVM Android app I even built without any build scripts completely by hand (see here: https://wiki.freepascal.org/FPC_JVM_Android_Development#Building_an_Android_application ). The process might be a bit more involved nowadays, but in principle it will still be the same. TL;DR: the compiler is not the problem. But maybe the build chain needs to be adjusted. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
fredvs schrieb am Fr., 2. Aug. 2019, 18:32: > > cause the type information is read only. > > Yes, it is why I will not jump into that proposition. > > > And if someone is not able to check for a simple flag then they shouldn't > > work with the RTTI. > > Huh, like in your code-fix? > > ;-) > > Ok, all is ok, many thanks Sven and have a perfect summer. > The check for the flag worked. It's the remainder of the code that's broken. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
fredvs schrieb am Fr., 2. Aug. 2019, 15:11:
> Hello Sven.
>
> > {$if declared(AlignTParamFlags)}
> Excellent!
>
> If, by chance, you're running out of ideas for new methods for fpc 3.3.1
> trunk and have nothing to do or you're bored...
> For people that are not fan of headaches (so not for me), add this method:
> RemovepfHiddeninTParamFlags(Pparamlist).
> This should be used the same way that for AlignTParamFlags(Pparamlist),
> just
> before assigning the flags.
>
That is something each application needs to handle itself as the list
management needs to be handled by itself cause the type information is read
only.
And if someone is not able to check for a simple flag then they shouldn't
work with the RTTI.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
fredvs schrieb am Fr., 2. Aug. 2019, 13:27:
> > No, It's > 030300, but your version of trunk is too old, the function
> > was only added a few days ago.
>
> Ha, ok. (but a few tricky, a new number for a new feature would be ok too).
>
By definition only the latest version of trunk is considered supported.
Also that's the version number of the compiler. That won't be increased for
every little thing that gets added.
That said instead of checking for the version you can also check for the
existence of the function:
{$if declared(AlignTParamFlags)}
This works with any identifier that is in scope (e.g. in this case the
TypInfo unit must be used, but that is the case here anyway).
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
Am 02.08.2019 um 03:01 schrieb fredvs:
Hello.
{$if FPC_FULLVERSION >= 030300}
paramlist1 := AlignTParamFlags(paramlist1);
{$endif}
Hum, with fpc 3.3.1. [2019/04/24] there is that error message:
msedesignparser.pas(694,43) Error: Identifier not found "AlignTParamFlags".
Could it be that the full-version used for "AlignTParamFlags" is 030302 ?
{$if FPC_FULLVERSION >= 030302}
paramlist1 := AlignTParamFlags(paramlist1);
{$endif}
?
No, It's > 030300, but your version of trunk is too old, the function
was only added a few days ago.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
fredvs schrieb am Mo., 29. Juli 2019, 11:42: > > You should also use 030100 here as that was added at the same time as the > switch to Word size. > > Ha, ok (so Martin only had begin the work for 030100, I was thinking that > fpc > 030100 = fpc > 3.0.0., like fpc 3.0.2. or fpc 3.0.4). > > So the logic is ok, fpc > 030100 = fpc > 3.1.0. > The full version numbers for 3.0.0, 3.0.2 and 3.0.4 are 03, 030002 and 030004 respectively. And 3.1.1 is 030101 and can simply be checked for with > 030100 which is also always > 0300xx. ;) Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
fredvs schrieb am So., 28. Juli 2019, 22:26:
> >. I think it /should/ work however if you add a "{$if > FPC_FULLVERSION >=
> 030300}
>
> Oops, sorry, you writed it already: if > FPC_FULLVERSION >= 030300
>
> OK thanks.
>
> Huh, and for:
>
> > if FPC_FULLVERSION >= 030200 (not sure of the number)
> >then use pfHidden flag.
>
> Is 030200 the right number?
>
You should also use 030100 here as that was added at the same time as the
switch to Word size.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
Am 28.07.2019 um 16:02 schrieb fredvs: It's not beautiful if you mean that, but it will work... OK, I will make it nicer. Well, nicer would be if you'd do it inside the main for-loop. Oh and just in case you want more headaches... Yes, please, I adore it. By the way, about headache, may I ask what number of FPC_FULLVERSION will be used for that wonderful new feature? What do you mean? If you mean the AlignTParamFlags then I already showed that? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
Am 28.07.2019 um 15:10 schrieb fredvs:
I'm no fan of those nested with-blocks
Same for me.
Did you see my fixes, do you agree with it ?
It's not beautiful if you mean that, but it will work...
Oh and just in case you want more headaches: the current code will bomb
on current FPC trunk on targets that have strict alignment requirements
(e.g. ARM). I think it /should/ work however if you add a "{$if
FPC_FULLVERSION >= 030300}po1 := AlignTParamFlags(po1);{$endif}"
directly before the assignment to "flags".
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
Am 28.07.2019 um 03:02 schrieb fredvs: PS: If you know what makes the problems in your code, I am very curious to know what is the solution. I'm no fan of those nested with-blocks so I definitely won't try to fix that code. Regrds, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
Am 27.07.2019 um 19:02 schrieb fredvs:
Imho, it seems that in your code "if not (pfHidden in flags) then" was
placed one "end;" too far.
That's what I meant in the mail you replied to.
Am 27.07.2019 um 19:07 schrieb fredvs:
Sven, did you try a simple code, it seems that "$self" first parameter is
always added into params list, even if you filter it with "pfHidden" flag.
This example works as intended:
=== code begin ===
program tmethodinfo;
{$mode objfpc}{$H+}
uses
typinfo, classes, sysutils;
{$M+}
type
TMyMethod1 = procedure(const aSender: TObject) of object;
TMyMethod2 = function(var aArg: LongInt; aArr: array of LongInt):
String of object;
{$M-}
function FuncToString(aTI: PTypeInfo): String;
var
td: PTypeData;
pb: PByte;
args: TStrings;
flags: TParamFlags;
res, s, prefix, argname, argtype: String;
i: SizeInt;
begin
if aTI^.Kind <> tkMethod then
raise Exception.Create('Method type information expected');
td := GetTypeData(aTI);
args := TStringList.Create;
try
args.Delimiter := ';';
args.QuoteChar := #0;
pb := @td^.ParamList;
for i := 0 to td^.ParamCount - 1 do begin
flags := TParamFlags(PWord(pb)^);
Inc(pb, SizeOf(TParamFlags));
argname := PShortString(pb)^;
Inc(pb, SizeOf(Byte) + Length(argname));
argtype := PShortString(pb)^;
Inc(pb, SizeOf(Byte) + Length(argtype));
if pfHidden in flags then
Continue;
prefix := '';
if pfConst in flags then
prefix := 'const'
else if pfConstRef in flags then
prefix := 'constref'
else if pfVar in flags then
prefix := 'var'
else if pfOut in flags then
prefix := 'out';
s := '';
if prefix <> '' then
s := prefix + ' ';
s := s + argname + ': ';
if pfArray in flags then
s := s + 'array of ';
s := s + argtype;
args.Add(s);
end;
if td^.MethodKind in [mkFunction, mkClassFunction] then
res := PShortString(pb)^
else
res := '';
Result := '';
if td^.MethodKind in [mkClassFunction, mkClassProcedure,
mkClassConstructor, mkClassDestructor] then
Result := 'class ';
if td^.MethodKind in [mkClassFunction, mkFunction] then
Result := Result + 'function '
else if td^.MethodKind in [mkClassProcedure, mkProcedure] then
Result := Result + 'procedure '
else if td^.MethodKind in [mkConstructor, mkClassConstructor] then
Result := Result + 'constructor '
else if td^.MethodKind in [mkDestructor, mkClassDestructor] then
Result := Result + 'destructor '
else
Result := Result + 'unknown ';
Result := Result + aTI^.Name + ' ';
if args.Count > 0 then
Result := Result + '(' + args.DelimitedText + ')';
if res <> '' then
Result := Result + ': ' + res;
finally
args.Free;
end;
end;
begin
Writeln(FuncToString(TypeInfo(TMyMethod1)));
Writeln(FuncToString(TypeInfo(TMyMethod2)));
end.
=== code end ===
And will print the following:
=== code begin ===
procedure TMyMethod1 ( const aSender: TObject )
function TMyMethod2 ( var aArg: LongInt ; aArr: array of LongInt ):
AnsiString
=== code end ===
So it definitely works, now you only need to figure out the problem in
your code.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
fredvs schrieb am Sa., 27. Juli 2019, 17:54: > Hello Sven. > > > That said the code I showed you had an issue which might explain the > > behaviour you got: > > I did try your new code but get that error message at compilation: > > msedesignparser.pas(722,11) Error: Incompatible types: got "TParamFlag" > expected "methodflagty" > msedesignparser.pas(2238) Fatal: There were 1 errors compiling module, > stopping > Fatal: Compilation aborted > > > ---> Line 722,11 = "if not (pfHidden in flags) then" > Ah, right, of course. You need the part I added *inside* the with block of params[count]. My fault (I'm doing this here on the fly, not testing it). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
Am 26.07.2019 um 14:50 schrieb fredvs:
But, imho, there is problem with the behavior of fpc-ptypeinfo and filter in
TParamFlags.
Dont worry, I will not annoy you with this.
There is no problem with PTypeInfo or TParamFlags. The tests for these
functionalities pass without any issues on multiple platforms.
You should fix the cause (ignoring hidden parameters) and not the
symptoms (hidding "$self"), because the latter will cause you a headache
further down (e.g. if you have a function with an open array parameter
which will have a "$highArgN" parameter for each open array).
That said the code I showed you had an issue which might explain the
behaviour you got:
=== code begin ===
for int1:= 0 to paramcount - 1 do begin
with params[int1] do begin
// replace previous line with:
with params[count] do begin
flags:= tparamflags(
{$ifdef
mse_fpc_3_2}wordset{$else}byteset{$endif}(pbyte(po1)^));
inc(po1,{$ifdef mse_fpc_3_2}2{$else}1{$endif});
// the following code block of mine
{$ifdef mse_fpc_3_2}
// skip hidden parameters ($self, $high, etc.)
if pfHidden in flags then
Continue;
{$endif}
Inc(count);
// up until here, needs to be further down (see below)
// so remove this block again
name:= getshortstring(po1);
typename:= getshortstring(po1);
if (typename = 'WideString') or (typename = 'UnicodeString') then
begin
typename:= 'msestring';
end
else begin
if typename = 'LongInt' then begin
typename:= 'Integer';
end
else begin
if typename = 'Double' then begin
typename:= 'Real';
end;
end;
end;
end; // I think this is the end of the with-clause
// we adjust the code a little bit as the continue is not needed at this
location
// this way we always increase the count on < 3.2 and only if it's not
hidden
// on >= 3.2; we need to put this at the end so that po1 is advanced
correctly
{$ifdef mse_fpc_3_2}
// skip hidden parameters ($self, $high, etc.)
if not (pfHidden in flags) then
{$endif}
Inc(count);
end;
=== code end ===
This should hopefully solve the issue.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
fredvs schrieb am Fr., 26. Juli 2019, 09:06:
> > It would help more if you'd point me exactly at the code in question.
>
> OK, now that you see the problem, here the code in mse-ide project:
>
> In msedesignparser.pas, procedure getmethodparaminfo: (Please take a look
> at
> the // in code that follow --> paramlist has one more entry in fpc 320)
>
I'll do my changes inline:
>
> procedure getmethodparaminfo(const atype: ptypeinfo;
> var info: methodparaminfoty);
>
> function getshortstring(var po: pchar): string;
> begin
>setlength(result,byte(po^));
>inc(po);
>move(po^,pointer(result)^,length(result));
>inc(po,length(result));
> end;
>
> type
> pparamflags = ^tparamflags;
> paramrecty = record
>Flags : TParamFlags;
> end;
> var
> isfunction: boolean;
> int1: integer;
>
count: Integer;
> po1: pchar;
> begin
> with info do begin
> kind:= methodkindty(-1);
> params:= nil;
> if (atype^.Kind = tkmethod) then begin
>with gettypedata(atype)^ do begin
> kind:= tmethodkindtomethodkind[methodkind];
> int1:= paramcount;
> isfunction:= methodkind = mkfunction;
> if isfunction then begin
> inc(int1);
> end;
> if isfunction or (methodkind = mkprocedure) then begin
> setlength(params,int1);
>
> po1:= @paramlist;
>
count := 0;
>
> // there is now one more first parameter that must be ommited
>
>for int1:= 0 to paramcount - 1 do begin
> with params[int1] do begin
>
// replace previous line with:
with params[count] do begin
>flags:= tparamflags(
> {$ifdef mse_fpc_3_2}wordset{$else}byteset{$endif}(pbyte(po1)^));
>inc(po1,{$ifdef mse_fpc_3_2}2{$else}1{$endif});
>
{$ifdef mse_fpc_3_2}
// skip hidden parameters ($self, $high, etc.)
if pfHidden in flags then
Continue;
{$endif}
Inc(count);
>name:= getshortstring(po1);
>typename:= getshortstring(po1);
>if (typename = 'WideString') or (typename = 'UnicodeString') then
> begin
> typename:= 'msestring';
>end
>else begin
> if typename = 'LongInt' then begin
> typename:= 'Integer';
> end
> else begin
> if typename = 'Double' then begin
> typename:= 'Real';
> end;
> end;
>end;
> end;
> end;
>
// adjust array now that we know the real count
SetLength(params, count);
> if isfunction then begin
> params[high(params)].typename:= getshortstring(po1);
> end;
> end;
>end;
> end;
> end;
> end;
>
To resume: if somebody knows how to not add by default the first $self
> parameter in paramlist, I vote for that solution.
>
The above changes should help.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
fredvs schrieb am Do., 25. Juli 2019, 15:08: > Re-re hello. > > Maybe with video it will be more easy to explain the problem. > It would help more if you'd point me exactly at the code in question. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
fredvs schrieb am Mi., 24. Juli 2019, 08:10:
> Hello.
>
> > Check for pfHidden.
>
> Thanks Sven for helping.
> But I do not catch how to hide those "self" parameter.
>
> IMHO, the guilty is here, in Martin's code msedisignparser.pas
> (Sadly I did not find any example how to use TParameterFlag.
> The goal is to ignore first parameter if fpc >= 3.2.x)
> ___
>
> procedure getmethodparaminfo(const atype: ptypeinfo;
> var info: methodparaminfoty);
> begin
> ...
> for int1:= 0 to paramcount - 1 do begin
> with params[int1] do begin
>
> -> Here flags must be adapted for fpc 3.2.0
>
> flags:= tparamflags(
> {$ifde mse_fpc_3_0_2}wordset{$else}byteset{$endif}(pbyte(po1)^));
>inc(po1,{$ifdef mse_fpc_3_2}2{$else}1{$endif});
>
Shouldn't the first $ifdef check for mse_fpc_3_2 as well?
I don't know the surrounding code, but in the end you should skip to insert
the parameter into whatever structure you're generating if "pfHidden in
flags", but you nevertheless need to advance your pointer to the next
parameter.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TParamFlags and fpc 3.2.0.
fredvs schrieb am Di., 23. Juli 2019, 12:52: > Hello. > > I try to make msegui/mseide compatible with fpc 3.2.0. > > Thanks to Graeme fixes, interfaces of msegui is now compatible with fpc > 3.2.0. > > But there is still problem with the use of TParamFlags with fp 3.2.0 and > mseide. > > Now, using TParamFlags add by default "$self: Pointer" parameter, example: > > procedure onexec($self: Pointer; const sender: Tobject); > > How to hide that "$self: Pointer" parameter and have the same behavior as > fpc 3.0.2 / fpc 3.0.4 ? > > How to use TParamFlags to have the same result as using fpc 3.0.2 / fpc > 3.0.4 ? > Check for pfHidden. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Warning: Symbol "faHidden" is not portable
James Richters schrieb am Fr., 19. Juli 2019, 19:32: > I'm using Windows 10, but I may in the future want to make a Linux version > of my program. I guess that's what the warning is about.. that fAHidden > won't detect hidden files on some operating systems? > Correct. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Initial support for Custom Attributes
Hello together!
Today FPC has finally gained initial support for Custom Attributes. The
work had initially been done by Joost van der Sluis almost 6 years ago
and Svetozar Belic had adjusted the code for trunk. So thank you both
for that work even if it took quite some time until it was finally
integrated into trunk.
What are attributes?
Custom Attributes allow you to decorate (currently) type definitions and
published properties of classes with additional metadata that can be
queried using the RTTI. What can attributes be used for? You can use
them to mark classes with the name of its corresponding database table
or ithe base path for a web service class.
How are attributes declared?
Attributes are simply classes that descend from the new System type
TCustomAttribute. The important part are the constructors of the class.
These can be used to pass additional parameters to the attribute (like
the table name or path).
How are attributes used?
Attributes are bound to a type or property by using one or multiple
attribute clauses in front of the type or property. For types it must be
a type definition (e.g. a class, a record, an enum, etc.) or a unique
type redeclaration (e.g. "TLongInt = type LongInt"). Mere type renames
(e.g. "TLongInt = LongInt") are not allowed.
Attribute clauses are only available if the new modeswitch
PREFIXEDATTRIBUTES is set which is the default in mode Delphi and
DelphiUnicode.
The syntax of a attribute clause is the following:
ATTRIBUTECLAUSE::='[' ATTRIBUTELIST ']'
ATTRIBUTELIST::=ATTRIBUTE [, ATTRIBUTELIST ]
ATTRIBUTE::=IDENTIFIER [ ( PARAMLIST ) ]
PARAMLIST::=CONSTEXPR [, PARAMLIST ]
The IDENTIFIER is either the name of the attribute class as is or the
attribute class' name can end in "Attribute" (casing irrelevant) and
then the name may be used without the "Attribute" suffix.
Take the following example:
=== code begin ===
program tcustomattr;
{$mode objfpc}{$H+}
{$modeswitch prefixedattributes}
type
TMyAttribute = class(TCustomAttribute)
constructor Create;
constructor Create(aArg: String);
constructor Create(aArg: TGUID);
constructor Create(aArg: LongInt);
end;
{$M+}
[TMyAttribute]
TTestClass = class
private
fTest: LongInt;
published
[TMyAttribute('Test')]
property Test: LongInt read fTest;
end;
{$M-}
[TMyAttribute(1234)]
[TMy('Hello World')]
TTestEnum = (
teOne,
teTwo
);
[TMyAttribute(IInterface), TMy(42)]
TLongInt = type LongInt;
constructor TMyAttribute.Create;
begin
end;
constructor TMyAttribute.Create(aArg: String);
begin
end;
constructor TMyAttribute.Create(aArg: LongInt);
begin
end;
constructor TMyAttribute.Create(aArg: TGUID);
begin
end;
begin
end.
=== code end ===
Querying attributes:
Attributes can be accessed by both the TypInfo and Rtti units.
For the TypInfo unit the ways to access attributes are as follows:
For types:
- use the AttributesTable field in TTypeData
- use GetAttributeTable on a PTypeInfo
- use GetAttribute on the attribute table together with an index to get
a TCustomAttribute instance
For properties:
- use the AttributesTable of TPropInfo
- use GetAttribute on the attribute table together with a nindex to get
a TCustomAttribute instance
- use GetPropAttribute on the PPropInfo together with an index to get a
TCustomAttribute instnace
For the Rtti unit the ways to access attributes are as follows:
For types:
- use GetAttributes on the TRttiType of the type in question
For properties:
- use GetAttributes on the TRttiProperty of the property in question
How is the compatibility of the attributes feature:
The feature itself is Delphi compatible except FPC is much more
unforgiving regarding unbound properties: if the attribute class is not
known or the attribute clauses are not bound to a valid type or property
the compiler will generate an error.
The RTTI however is not considered Delphi compatible, but it covers the
same functionality. Contrary to Delphi which uses Invoke to create the
attribute instance FPC uses a constructor function which has the
advantage that it works on systems that don't have full Invoke support.
Additionally using the PREFIXEDATTRIBUTES modeswitch disables the
directive clauses for functions, methods and procedure/method types:
The following is not allowed anymore with the modeswitch enabled:
=== code begin ===
procedure Test; [cdecl];
begin
end;
=== code end ===
Just in case: this feature won't be part of 3.2.
The wiki pages New Features Trunk and User Changes Trunk will be updated
soon with the new information.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compile fpc twice or only once during install?
Christo Crause schrieb am Fr., 12. Juli 2019, 15:30: > > On Fri, 12 Jul 2019, 14:19 Bo Berglund, wrote: > >> When I install FPC/Lazarus on new Linux systems I use a script I wrote >> several years ago. It is cofigured for the actual versions to install >> but otherwise it is self-contained. >> >> What it does concerning fpc is: >> - Get the tagged version of the sources from svn (typically 3.0.4) >> - Get the seed compiler 3.0.0, which I have stored on my website >> - Build all using the seed compiler >> - Install sources etc. >> >> Now I wonder if I should add a second "make all" after pointing to the >> newly built 3.0.4 such that the final result is fpc 3.0.4 built from >> sources compiled by itself? >> >> Or is this superfluous? >> > > AFAIK the make file cycle through the compiler build process 3, starting a > new cycle with the compiler from the previous cycle. So no need to make all > a 2nd time, it is implicit in the make file recipe. > Correct. In fact it also throws in an additional WPOCYCLE (two compilations) to optimize the compiler further. ;) Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] specify variable name with string variable
James Richters schrieb am Mo., 8. Juli
2019, 22:44:
> SetStoragePinByName('Ini_Opto_Enable_Positive_Pin', True) ;
>
> And it would somehow get the value of 'Ini_Opto_Enable_Positive_Pin
>
That indeed sounds like something where you could use classes together with
published properties. At least if you're willing to spend a bit of effort.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementation of variant records
Am 07.07.2019 um 12:54 schrieb Sven Barth:
Am 07.07.2019 um 02:55 schrieb Ralf Quint:
On 7/6/2019 12:21 PM, Florian Klaempfl wrote:
Am 05.07.2019 um 13:53 schrieb Ralf Quint:
Shouldn't a PACKED Record guarantee that values are aligned at the
byte
level?
It does in TP, but the ISO says only that it shall be economised.
Well, the ISO is probably what has done most of the damage to Pascal.
AFAIK, the ISO doesn't not actually specify any "packed record" per
se, but there is an explicit PACK and UNPACK procedures to more
economically store sets and arrays (and possibly records, I would
have to look up the ISO text to be certain). For example this would
be something to create bit fields, pretty much the only feature of C
that I sometimes miss in (Free)Pascal.
You mean like this?
=== code begin ===
struct Test
{
uint8_t field1;
uint16_t bfield1 : 1;
uint16_t bfield2 : 1;
uint16_t bfield3 : 3;
uint16_t bfield4 : 5;
uint16_t bfield5 : 1;
uint16_t field2;
};
=== code end ===
=== code begin ===
type
TTest = bitpacked record
field1: UInt8;
bfield1: 0..1;
bfield2: 0..1;
bfield3: 0..7;
bfield4: 0..31;
bfield5: 0..1;
pad: UInt8; // needed due to bitpacked
field2: UInt16;
end;
=== code end ===
Small correction: there needs to be another "bpad: 0..31;" field between
bfield5 and pad, cause otherwise the pad field will be directly behind
the bfield5 one. This could of course be avoided by putting the bit
fields into a subrecord, though then of course there'd be the need for
an additional field name.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementation of variant records
Am 07.07.2019 um 02:55 schrieb Ralf Quint:
On 7/6/2019 12:21 PM, Florian Klaempfl wrote:
Am 05.07.2019 um 13:53 schrieb Ralf Quint:
Shouldn't a PACKED Record guarantee that values are aligned at the byte
level?
It does in TP, but the ISO says only that it shall be economised.
Well, the ISO is probably what has done most of the damage to Pascal.
AFAIK, the ISO doesn't not actually specify any "packed record" per
se, but there is an explicit PACK and UNPACK procedures to more
economically store sets and arrays (and possibly records, I would have
to look up the ISO text to be certain). For example this would be
something to create bit fields, pretty much the only feature of C that
I sometimes miss in (Free)Pascal.
You mean like this?
=== code begin ===
struct Test
{
uint8_t field1;
uint16_t bfield1 : 1;
uint16_t bfield2 : 1;
uint16_t bfield3 : 3;
uint16_t bfield4 : 5;
uint16_t bfield5 : 1;
uint16_t field2;
};
=== code end ===
=== code begin ===
type
TTest = bitpacked record
field1: UInt8;
bfield1: 0..1;
bfield2: 0..1;
bfield3: 0..7;
bfield4: 0..31;
bfield5: 0..1;
pad: UInt8; // needed due to bitpacked
field2: UInt16;
end;
=== code end ===
The size of both records is 6. :)
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Developing a mini ERP / web based development
Graeme Geldenhuys schrieb am So., 7. Juli 2019, 11:45: > Does FPC support annotations yet? > In the Object Pascal world they are called custom attributes, are accessible through the RTTI and their syntax is [AttributeName(Arguments)]. There exists a branch with them and it's "just" a matter of integrating them into trunk. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Virtual object methods
Am 02.07.2019 um 19:43 schrieb Michael Van Canneyt: On Tue, 2 Jul 2019, Ryan Joseph wrote: On Jul 2, 2019, at 10:32 AM, Michael Van Canneyt wrote: It overwrites the first. There is no such thing as '2 VMT tables'. That’s what I thought. How costly is this? Not sure what it’s doing under the hood but I’d like to know more. As far as I know, it just moves a pointer in place, see: https://www.freepascal.org/docs-html/current/prog/progsu166.html#x210-2240008.2.12 Looking at the code posted by Marco and what fpc_help_constructor does it seems to be a bit more... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Troubles with SQLDBRESTBridge
Michael Van Canneyt schrieb am Di., 2. Juli 2019, 08:20: > > > On Mon, 1 Jul 2019, Sven Barth via fpc-pascal wrote: > > > Am 01.07.2019 um 23:18 schrieb Michael Van Canneyt: > >> > >>> > >>> By the way: is it correct that the sqldbrestdataset currently does > >>> not support editing/inserting/deleting entries? Do you plan to change > >>> this? > >> > >> Ehm, no, of course it is supposed to support that. It would not be > >> much good if it didn't :-) > >> > >> Do you get errors ? > > No. If I use the JSONClient example, list the Users resources, then edit > > an entry and commit all looks fine so far. However if I then use Get > > Resource Data again the original data will be restored (also a look into > > the database showed no change). Same when I add a new entry (btw: is it > > normal that all rows in the grid appear to be empty after pressing the > > Insert button and if I enter new data the other rows appear to have that > > data as well?) or delete one. > > As far as I know, the JSON client does not apply updates to the server ? > Neither does the bufdataset client. That simply has not been coded. > > I test all GET/PUT/POST/DELETE with curl or wget. > and with some pas2js & TMS Web Core clients, with those I know that the > updates are coded. > Well, my plan is a desktop application that uses a web server backend. So I had hoped for a ready-made solution. Seems like I'll have to implement that in the SQLDBRestClient myself... Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Troubles with SQLDBRESTBridge
Am 01.07.2019 um 23:18 schrieb Michael Van Canneyt: By the way: is it correct that the sqldbrestdataset currently does not support editing/inserting/deleting entries? Do you plan to change this? Ehm, no, of course it is supposed to support that. It would not be much good if it didn't :-) Do you get errors ? No. If I use the JSONClient example, list the Users resources, then edit an entry and commit all looks fine so far. However if I then use Get Resource Data again the original data will be restored (also a look into the database showed no change). Same when I add a new entry (btw: is it normal that all rows in the grid appear to be empty after pressing the Insert button and if I enter new data the other rows appear to have that data as well?) or delete one. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Troubles with SQLDBRESTBridge
Am 24.06.2019 um 09:30 schrieb Michael Van Canneyt: With the sample module, I tested all possible cases: I updated both FPC and Lazarus and also tested the sample module. However those variants BasePath empty don't work. I get an exception at line 2053 of sqldbrestbridge.pp. It seems that BasePaths is an array of length 1 containing an empty string... :/ Don't know if that's supposed to be returned by the Split() method or not if the input string is empty... By the way: is it correct that the sqldbrestdataset currently does not support editing/inserting/deleting entries? Do you plan to change this? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Wiki: platform defines
Alexey Tor. schrieb am Fr., 28. Juni 2019, 12:16: > https://wiki.freepascal.org/Platform_defines#Operating_system_defines > > I 've added all defines of OS. You can tell me if it's not ok. Missed > one item: 'nativent' target. Seems some Win32 target? why new? Why it > don't have extradefines "windows"? > > > https://github.com/graemeg/freepascal/blob/master/compiler/systems/i_nativent.pas It's a target that sits directly above the NT kernel, but below the Win32 subsystem. It can essentially be used to develop drivers and NT subsystems. See also: https://wiki.freepascal.org/Target_NativeNT As such defining "WINDOWS" would be wrong as code using the Win32 API would not work there. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String conversions
Am 27.06.2019 um 07:10 schrieb Sven Barth: Am 26.06.2019 um 23:36 schrieb Ryan Joseph: On Jun 26, 2019, at 3:28 PM, Ben Grasset wrote: I think Ryan probably meant his own custom types. And certainly, you can do some interesting stuff with operator overloading that mostly avoids the normal AnsiString overhead. Here's an example. Yes indeed. FPC already has an overwhelming amount of string types. As I said though a SetCapacity option for growing would be nice (for dynamic arrays also) because += is such a common operation. As it stands I often don’t use dynamic arrays (and now ansistring) because of growing limitations, which is a shame really. No. That would mean an additional entry in the metadata of strings and arrays and those are already big enough in my opinion compared to the data they're handling. If one needs capacity based handling for these types then one should use helper types. Note: with which I mean types like TStringBuilder, not type helpers. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] String conversions
Am 26.06.2019 um 23:36 schrieb Ryan Joseph: On Jun 26, 2019, at 3:28 PM, Ben Grasset wrote: I think Ryan probably meant his own custom types. And certainly, you can do some interesting stuff with operator overloading that mostly avoids the normal AnsiString overhead. Here's an example. Yes indeed. FPC already has an overwhelming amount of string types. As I said though a SetCapacity option for growing would be nice (for dynamic arrays also) because += is such a common operation. As it stands I often don’t use dynamic arrays (and now ansistring) because of growing limitations, which is a shame really. No. That would mean an additional entry in the metadata of strings and arrays and those are already big enough in my opinion compared to the data they're handling. If one needs capacity based handling for these types then one should use helper types. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Troubles with SQLDBRESTBridge
Michael Van Canneyt schrieb am Mo., 24. Juni 2019, 09:30: > > > On Sun, 23 Jun 2019, Sven Barth via fpc-pascal wrote: > > >>>>> - localhost:8080/metadata works > >>>>> - localhost:8080/users returns "INVALID RESOURCE" > >>>> > >>>> Because it has rdoConnectionInURL set, and so you must do > >>>> localhost:8080/expenses/users > >>> > >>> Ahh! Hadn't seen that this option is active... Okay, then it > >>> indeed works as expected, both with and without rdoConnectionInURL. > >>> > >>> By the way: I noticed a slight annoyance, but I don't know whether > >>> one can really do something about that: When I set rdoConnectionInURL > >>> to False inside the object inspector it turns on again, because > >>> rdoConnectionResource is set. Took me a moment to look at the source > >>> code to see that I need to disable rdoConnectionResource first. Don't > >>> know what a better solution would be... > >> > >> Funny you mention this, I was fooled myself yesterday, I also had to > >> look in > >> the sources :( > >> > >> One way would be to disable rdoConnectionResource if you disable > >> rdoConnectionInURL. I will add this. > > > > But wouldn't that lead to an analogous problem with > > rdoConnectionResource if rdoConnectionInURL is not set? > > I fixed this: if you disable rdoConnectionInURL, rdoConnectionResource is > disabled. If not, if rdoConnectionResource is included, rdoConnectionInURL > will be set too. > > I also fixed the use in a module. The module will set 'active' to false on > the dispatcher. Before handling the request, it takes the request and uses > pathinfo to set the routing parameters > > With the sample module, I tested all possible cases: > > No rdoConnectionInURL: > wget --auth-no-challenge --http-user=me --http-password=secret > http://localhost:8080/REST/metadata --content-on-error -O - -d > --auth-no-challenge > wget --auth-no-challenge --http-user=me --http-password=secret > http://localhost:8080/REST/users --content-on-error -O - -d > --auth-no-challenge > > rdoConnectionInURL set: > Basepath empty: > wget --auth-no-challenge --http-user=me --http-password=secret > http://localhost:8080/REST/metadata --content-on-error -O - -d > --auth-no-challenge > wget --auth-no-challenge --http-user=me --http-password=secret > http://localhost:8080/REST/expenses/metadata --content-on-error -O - -d > --auth-no-challenge > wget --auth-no-challenge --http-user=me --http-password=secret > http://localhost:8080/REST/expenses/users --content-on-error -O - -d > --auth-no-challenge > > BasePath set to Lola > wget --auth-no-challenge --http-user=me --http-password=secret > http://localhost:8080/REST/Lola/metadata --content-on-error -O - -d > --auth-no-challenge > wget --auth-no-challenge --http-user=me --http-password=secret > http://localhost:8080/REST/Lola/expenses/metadata --content-on-error -O - > -d --auth-no-challenge > wget --auth-no-challenge --http-user=me --http-password=secret > http://localhost:8080/REST/Lola/expenses/users --content-on-error -O - -d > --auth-no-challenge > > BasePath set to Lola/Pola > > wget --auth-no-challenge --http-user=me --http-password=secret > http://localhost:8080/REST/Lola/Pola/metadata --content-on-error -O - -d > --auth-no-challenge > wget --auth-no-challenge --http-user=me --http-password=secret > http://localhost:8080/REST/Lola/Pola/expenses/metadata --content-on-error > -O - -d --auth-no-challenge > wget --auth-no-challenge --http-user=me --http-password=secret > http://localhost:8080/REST/Lola/Pola/expenses/users --content-on-error -O > - -d --auth-no-challenge > > > I think I covered all cases. If I forgot one, do let me know... > > I will update the Wiki. > Awesome! Thank you! Though I don't know when I'll be able to test it next. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] why isn't the 'exit' in the finally end clause executed?
Am 23.06.2019 um 16:33 schrieb Jonas Maebe:
On 23/06/2019 09:08, Dennis wrote:
Using fpc 3.0.4, Lazarus 2.0, the following simple program
program tryfinally;
begin
try
Writeln('before finally');
finally
Writeln('inside finally. Before Exit');
exit; //
Re: [fpc-pascal] Troubles with SQLDBRESTBridge
Am 23.06.2019 um 11:31 schrieb Michael Van Canneyt: On Sun, 23 Jun 2019, Sven Barth via fpc-pascal wrote: Okay, independently of whether the REST module is the optimal solution or not, it should work, right? (and shouldn't the Wiki entry then mention the advantages/disadvantages of the two approaches? Cause when looking at the SQLDB REST module I thought "yay, less stuff to configure" and rolled with that) What exactly is less to configure ? :) Looking at the Wiki again I was fooled by the Datamodule having 8 bullet points, the SQLDBRestModule having 5, but the later simply shortening stuff with point five... So yeah... not really less to configure... My fault. ^^' It's OK. I will try to document it a little better. Would probably be best, thank you. :) By the way: I sometimes get a EStreamError *after* all data had been sent to the client. I have not yet found a reproducible way for this... Please make sure you have the latest version of everything: I had this a couple of times in case of an error. I fixed all occurrences, I hope. But if you find additional cases: let me know. Yes, I was using the latest version. But I'll try to find a reproduceable case. :) - localhost:8080/metadata works - localhost:8080/users returns "INVALID RESOURCE" Because it has rdoConnectionInURL set, and so you must do localhost:8080/expenses/users Ahh! Hadn't seen that this option is active... Okay, then it indeed works as expected, both with and without rdoConnectionInURL. By the way: I noticed a slight annoyance, but I don't know whether one can really do something about that: When I set rdoConnectionInURL to False inside the object inspector it turns on again, because rdoConnectionResource is set. Took me a moment to look at the source code to see that I need to disable rdoConnectionResource first. Don't know what a better solution would be... Funny you mention this, I was fooled myself yesterday, I also had to look in the sources :( One way would be to disable rdoConnectionResource if you disable rdoConnectionInURL. I will add this. But wouldn't that lead to an analogous problem with rdoConnectionResource if rdoConnectionInURL is not set? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Troubles with SQLDBRESTBridge
Am 23.06.2019 um 00:50 schrieb Michael Van Canneyt: On Sat, 22 Jun 2019, Sven Barth via fpc-pascal wrote: The REst Module has the additional disadvantage that you must have an initial /REST/ or whatever part in your URL. With the dispatcher on a datamodule, you can skip this if so desired... Okay, independently of whether the REST module is the optimal solution or not, it should work, right? (and shouldn't the Wiki entry then mention the advantages/disadvantages of the two approaches? Cause when looking at the SQLDB REST module I thought "yay, less stuff to configure" and rolled with that) What exactly is less to configure ? :) Looking at the Wiki again I was fooled by the Datamodule having 8 bullet points, the SQLDBRestModule having 5, but the later simply shortening stuff with point five... So yeah... not really less to configure... My fault. ^^' Cause with the changes you committed the example provided with Lazarus still does not work (even if I change MyDispatcher.Active to False and MyDispatcher.BasePath to 'REST'). The error is always "INVALID RESOURCE" which means that ExtractRestResourceName returned an empty string (which is logical, cause there neither exists a route that sets 'resource' nor is HandleMetadataRequest ever called). Ah. Documentation issue. If you use a restmodule, then I expect the resource to be provided using ?resourceParam=Name, not in the URL. See function TSQLDBRestDispatcher.ExtractRestResourceName(IO: TRestIO): UTF8String; Ah! But that isn't mentioned in the Wiki, right? Cause the Wiki only mentioned the URL based stuff and thus I assumed the SQLDBRESTModule to behave the same... By the way: I sometimes get a EStreamError *after* all data had been sent to the client. I have not yet found a reproducible way for this... We can of course change that to try and look in the URL as well using GetNextPathInfo on the request if the routes are not registered, that should work. But then it needs to be done early on in the HandleRequest because the rdoInConnection needs to be observed, so the path can be read only once. It will probably require a new rdoUseRequestPathInfo, which could be set by the restmodule... I will look at this. Would at least be nice to not have to care how one needs to call the server side... - localhost:8080/metadata works - localhost:8080/users returns "INVALID RESOURCE" Because it has rdoConnectionInURL set, and so you must do localhost:8080/expenses/users Ahh! Hadn't seen that this option is active... Okay, then it indeed works as expected, both with and without rdoConnectionInURL. By the way: I noticed a slight annoyance, but I don't know whether one can really do something about that: When I set rdoConnectionInURL to False inside the object inspector it turns on again, because rdoConnectionResource is set. Took me a moment to look at the source code to see that I need to disable rdoConnectionResource first. Don't know what a better solution would be... Further thing I noticed when testing BufClient and CSVClient: Changing the resource doesn't work there either. I don't get an exception like with JSONClient, but simply nothing happens. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Troubles with SQLDBRESTBridge
Am 22.06.2019 um 10:30 schrieb Michael Van Canneyt: On Fri, 21 Jun 2019, Sven Barth via fpc-pascal wrote: Hello together! I've played around a bit with the SQLDBRESTBridge and encountered some troubles which I wanted to check up here on the list whether those are indeed bugs or not before reporting them to Mantis. First of thanks for applying some of the patches and explaining the problems with the others. However see below. So I started to research what went wrong and found various points: - the metadata was coupled with the rdoConnectionInURL flag in TSQLDBRestDispatcher.DoRegisterRoutes instead of rdoExposeMetadata (see patch exposematadata.patch) This is not quite correct. The rdoConnectionInURL check is also necessary: Both connection/metadata and /metadata must work. connection/metadata is handled by HandleRequest (FindSpecialResource) So a special registration for metadata must be handled here. But there was indeed a bug in the code, I fixed it properly. Ah, now I get the intention. :) - then it turned out that the routes are only registered once the module was loaded and thus they would never be found so I adjusted TSQLDBRestModule.HandleRequest to call the router again (this of course required to change the BasePath of the TSQLDBDispatcher in the example to 'REST' instead of '') (see patch reroute.patch) - this point I'm definitely not sure whether it is the right solution (but in the end it works) This is not the correct solution. The module itself handles the routes: the module is registered e.g. under /REST and then the request is dispatched to the router, and the dispatcher will take care of the rest. This means of course that when you use a restmodule, the dispatcher 'RegisterRoutes' must not be called at all, and this can be achieved by setting Active to False. Maybe the meaning of active is a bit obtuse. I put a comment in when I made it, but if that goes unnoticed... In general, I added the rest module only for completeness. I think the simple datamodule approach (as demoed in restbridge demo) is the better way: this keeps the schema in memory. for cases where you want to control the connections through the REST api, this is needed anyway. The REst Module has the additional disadvantage that you must have an initial /REST/ or whatever part in your URL. With the dispatcher on a datamodule, you can skip this if so desired... Okay, independently of whether the REST module is the optimal solution or not, it should work, right? (and shouldn't the Wiki entry then mention the advantages/disadvantages of the two approaches? Cause when looking at the SQLDB REST module I thought "yay, less stuff to configure" and rolled with that) Cause with the changes you committed the example provided with Lazarus still does not work (even if I change MyDispatcher.Active to False and MyDispatcher.BasePath to 'REST'). The error is always "INVALID RESOURCE" which means that ExtractRestResourceName returned an empty string (which is logical, cause there neither exists a route that sets 'resource' nor is HandleMetadataRequest ever called). And regarding the comment of TSQLDBRestDispatcher.Active: - first of I simply expected the example to work as is, so I definitely didn't look at any comments - "Register or unregister HTTP routes" doesn't really say much and in what situations it should be used... Also I've tested the restbridge example provided with Lazarus. It works better (after fixing a compilation error in restserver.lpr at line 59 where "Header:=Header+'; Using SSL');" should be "Header:=Header+'; Using SSL';"), but not correctly either: - localhost:8080/metadata works - localhost:8080/users returns "INVALID RESOURCE" - and for some reason it prints that it's using SSL, but the 's'/'ssl' option isn't provided... :/ (ah, I just noticed why: TCustomHTTPApplication.GetUseSSL is empty :/ - probably should contain "Result:=HTTPHandler.UseSSL;" instead? Btw: is it by intention that the call to CheckOptions does not contain 's'/'ssl'?) Here is the output (I first tried "localhost:8080/metadata" and then "localhost:8080/users"): === output begin === [HTTP] From: 127.0.0.1; URL: /metadata [Resource] (User: ?) Resource: metadata; Operation: GET [Connection] (User: ?) Using connection to Host: ; Database: expenses.db [Result] (User: ?) Resource: metadata; Operation: GET; Status: 200; Text: OK [Result] (User: ?) Resource: ?; Operation: GET; Status: 404; Text: INVALID RESOURCE === output end === And yes, the JSON and Buf clients don't work either with that server example... I haven't tested more yet, so I don't know whether there are any further problems. :) Well, I yesterday created a
[fpc-pascal] Troubles with SQLDBRESTBridge
Hello together!
I've played around a bit with the SQLDBRESTBridge and encountered some
troubles which I wanted to check up here on the list whether those are
indeed bugs or not before reporting them to Mantis.
For the tests I've used FPC 3.0.4 and Lazarus 2.0 with the
SQLDBRESTBridge and the Lazarus examples being from trunk on Friday 14th
June.
As server I used the restmodule demo in
$lazarus/components/sqldbrest/demo/restmodule and changed it to use
SQLite3 instead of PostgreSQL.
For the client I used the jsonclient demo in
$lazarus/components/sqldbrest/demo/jsonclient.
I created the database using the expenses-sqlite.sql script in
$fpc/packages/fcl-web/examples/restbridge/expenses-sqlite.sql (and no I
didn't execute expenses-data.sql at first which will be important
further down ;) ).
I started the server and tried to access localhost:7331/REST/metadata (I
changed the port from 8080), but this resulted in a 404 error which was
displayed as an empty page (maybe something isn't correctly working
here?). Using localhost:7331/metadata resulted in a "Not found" exception.
So I started to research what went wrong and found various points:
- the metadata was coupled with the rdoConnectionInURL flag in
TSQLDBRestDispatcher.DoRegisterRoutes instead of rdoExposeMetadata (see
patch exposematadata.patch)
- then it turned out that the routes are only registered once the module
was loaded and thus they would never be found so I adjusted
TSQLDBRestModule.HandleRequest to call the router again (this of course
required to change the BasePath of the TSQLDBDispatcher in the example
to 'REST' instead of '') (see patch reroute.patch) - this point I'm
definitely not sure whether it is the right solution (but in the end it
works)
- then the problem was that the module's route ('REST/*/') took
precedence over the routes added by the TSQLDBRestDispatcher, so I
implemented a sorting of the routes so that more specific ones are
encountered first (see patch sort-routes.patch) - don't know whether
this is the right approach either, but this *is* a problem
- then the fact that TSQLDBRestModule is by default set to wkOneShot
lead to the routes being registered again or more precisely the old
routes being left over and pointing to a freed TSQLDBRestDispatcher
instance; thus I added a call to UnRegisterRoutes to
TSQLDBRestDispatcher.Destroy (see unregister-routes.patch)
With these changes the server worked, but then I encountered two
problems in the client:
- if the database table is empty an empty JSON object ('{}') is returned
resulting in the client complaining about the missing metadata (after
this I executed the expenses-data.sql script)
- when changing from one resource to another I got an exception that the
operation is not possible on an active dataset; I solved this for me by
closing the dataset before executing LoadFromStream (see patch
jsonclient.patch)
And an additional note regarding the expenses-sqlite.sql script. The
intention appears to be that the ID columns are auto increment. This
will however *only* work if the type of the columns is "integer primary
key". "bigint primary key" won't work here. See also:
https://www.sqlite.org/autoinc.html
Thus as with patch expenses-sqlite.sql I updat the SQL script for that
database.
If these are indeed bugs I'll either commit the patches as is (e.g. the
one for the SQLite script is rather surely a bug) or open a bug report
for the more complex ones.
I haven't tested more yet, so I don't know whether there are any further
problems. :)
Regards,
Sven
diff --git a/packages/fcl-web/src/restbridge/sqldbrestbridge.pp b/packages/fcl-web/src/restbridge/sqldbrestbridge.pp
index 6dc839c2..76a3465d 100644
--- a/packages/fcl-web/src/restbridge/sqldbrestbridge.pp
+++ b/packages/fcl-web/src/restbridge/sqldbrestbridge.pp
@@ -668,11 +668,14 @@ begin
FConnectionsRoute:=HTTPRouter.RegisterRoute(res+C,@HandleConnRequest);
FConnectionItemRoute:=HTTPRouter.RegisterRoute(res+C+'/:id',@HandleConnRequest);
end;
- if (rdoConnectionInURL in DispatchOptions) then
+ if (rdoExposeMetadata in DispatchOptions) then
begin
C:=Strings.GetRestString(rpMetadataResourceName);
FMetadataRoute:=HTTPRouter.RegisterRoute(res+C,@HandleMetaDataRequest);
FMetadataItemRoute:=HTTPRouter.RegisterRoute(res+C+'/:id',@HandleMetaDataRequest);
+end;
+ if (rdoConnectionInURL in DispatchOptions) then
+begin
Res:=Res+':connection/';
end;
Res:=Res+':resource';
diff --git a/packages/fcl-web/src/restbridge/sqldbrestmodule.pp b/packages/fcl-web/src/restbridge/sqldbrestmodule.pp
index 0fb7cae1..d13e45d5 100644
--- a/packages/fcl-web/src/restbridge/sqldbrestmodule.pp
+++ b/packages/fcl-web/src/restbridge/sqldbrestmodule.pp
@@ -14,6 +14,7 @@ Type
TSQLDBRestModule = Class (TSessionHTTPModule)
private
FDispatcher: TSQLDBRestDispatcher;
+FRecursive: Boolean;
procedure SetDispatcher(AValue: TSQLDBRestDispatcher);
Protected
Procedure Notification(ACom
Re: [fpc-pascal] OpenBSD platform define
Alexey Tor. schrieb am Fr., 21. Juni 2019, 13:10: > I cannot find such in the https://wiki.freepascal.org/Platform_defines - > its missed? > It's missing in the listing as is DragonFlyBSD and some others (e.g. the three supported Nintendo consoles). Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Class field property access
Ryan Joseph schrieb am Fr., 7. Juni 2019, 14:00: > > > > On Jun 7, 2019, at 2:51 AM, Michael Van Canneyt > wrote: > > > > What kind of behaviour are you referring to. > > Something wrong with my mail server causing your server to block me (Jonas > said my server didn’t handle greylisting correctly). Easier to just re-sub > using gmail for now. > Michael meant this: > But my point is Pascal allows this kind of behavior so why are properties > different? > > > >> Who cares if there is an additional level of indirection? > > > > Because the indirection may not be there. The compiler cannot guarantee > that, thus leading to access violations. > > > > You can use a getter function to get the desired property. In the getter > you > > can decide what to do: create the b instance (sometimes a valid choice) > or raise an error. > > > > But the compiler cannot take this decision for you, so b.x is not > allowed. > > I really have to question the wisdom of this. The code below works in > 3.0.4 and is completely safe. I understand there was delphi compatibility > and problems with published properties however but that could have been > worked around easily. Maybe it’s a not big deal in the grand scheme of > things but writing boiler plate like getters/setters is not fun. > > type > TB = class > x: integer; > end; > > type > TA = class > private > b: TB; > public > property x: integer read b.x write b.x; > procedure AfterConstruction; override; > end; > > > procedure TA.AfterConstruction; > begin > b := TB.Create; > end; > > var > a: TA; > begin > a := TA.Create; > a.x := 100; > writeln(a.x); > end. > Only because this example appears safe does not mean that the whole concept is safe. A class might initialize b only later on and with a direct property you'll only get an access violation. So you'll need a getter anyway to provide a better exception type. Or to dynamically create the object instance. I see no reason to revert this change. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Class field property access
Michael Van Canneyt schrieb am Fr., 7. Juni 2019, 08:52: > > This appears to be a regression since 3.0.4 also. Did you specifically > > disable this in 3.3.1? Sorry I’m not understanding this one. > > If it was allowed in previous versions, this was by accident allowed during > parsing and most likely simply didn't work in reality. > Correct: http://wiki.freepascal.org/User_Changes_Trunk#Property_field_access_lists_no_longer_allows_classes Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error? No range checks in mode delphi?
Anthony Walter schrieb am Di., 4. Juni 2019, 03:27:
> That fixes it, but then the question is why does {$mode delphi} differ
> from {$mode objfpc}?
>
Mode ObjFPC is stricter in some cases. While mode Delphi cares for Delphi
compatibility.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Class field property access
Ryan Joseph schrieb am Mo., 3. Juni 2019, 16:36: > I found a restriction in properties which is a little disappointing. I get > there’s probably some objective of safety but Pascal is a direct memory > access language so I don’t understand why properties have this unique > restriction when I could do the same thing using functions (pointers can’t > be dereferenced in properties either). Shouldn’t I as the programmer get to > decide whether the property is safe or not based upon when I call it? > > type > TB = class > x: integer; > end; > > type > TA = class > private > b: TB; > public > property x: integer read b.x; // ERROR: Must be a record/object > type > end; > The b field could be Nil and the class might not provide any functionality to check for that. In addition to that it's an additional indirection while records/objects merely require an offset. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Convert codepages back to UTF8
Alexey Tor. schrieb am Di., 28. Mai 2019, 14:44:
> Ok, I got it. But I wonder: if my code changes codepage of a "string" to
> e.g. 1250, will all Lazarus string functions work ok with such changed
> string? For ex, will Pos('Петя', s) work?
>
Depends on what you do with the returned value. Lazarus uses UTF-8 by
default, thus the constant would be in UTF-8 as well and Pos() takes two
AnsiString parameters, thus CP_ACP. So the constant is passed along as is
and s is converted to UTF-8. Depending on the encoding of the characters
you might get a different position, thus you should ensure that both of
your strings have the same type (not tested) or you should work simply in
UTF-8 and only convert for input/output purposes.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Convert codepages back to UTF8
Martok schrieb am Mo., 27. Mai 2019, 15:14: > Am 27.05.2019 um 14:30 schrieb Sven Barth via fpc-pascal: > > Alexey Tor. > <mailto:aaa5...@ya.ru>> schrieb am Mo., 27. Mai 2019, 13:15: > > > > LazUtils.LConvEncoding can convert utf8 to codepage (not many > codepages) > > and vice versa. > > > > FPC 3 can convert utf8 to codepage - via SetCodePage(s, codepage, > true). > > But how can FPC convert back - codepage to utf8? Does such way exist? > > > > > > Use CP_UTF8 as code page for SetCodePage or assign the string to a > UTF8String > > variable. > > Although be advised that if your SystemCodePage is not a Unicode codepage, > there > will be data loss due to (sometimes unexpected) internal conversions, > regardless > of the current dynamic string code page. > As Graeme wrote that shouldn't be the case when converting to UTF-8. And for everything else you need to either use string variables with the correct static encoding or RawByteString to avoid conversions. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Convert codepages back to UTF8
Alexey Tor. schrieb am Mo., 27. Mai 2019, 13:15: > LazUtils.LConvEncoding can convert utf8 to codepage (not many codepages) > and vice versa. > > FPC 3 can convert utf8 to codepage - via SetCodePage(s, codepage, true). > But how can FPC convert back - codepage to utf8? Does such way exist? > Use CP_UTF8 as code page for SetCodePage or assign the string to a UTF8String variable. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Checking if a TStringList already exists
James Richters schrieb am Di., 21. Mai 2019, 15:48: > I don’t seem to have FreeThenNil I’m using FPC 3.0.4RC1 I don’t use > Lazarus.. maybe it’s a Lazarus thing… or maybe it’s in a different unit > Correct, it's part of Lazarus. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Checking if a TStringList already exists
James Richters schrieb am Mo., 20. Mai 2019, 15:23: > Thank you very much for the explanation and examples of this! I am glad > you pointed out the FreeAndNill() function, I will defiantly be needing > that. > Though you need to keep in mind that only that single variable will be set to Nil. Should there be other variables or fields that point to the same object instance they will stay as non-Nil. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Detecting console close with red X on windows
James Richters schrieb am So., 19. Mai 2019, 19:10: > Thanks!That was quite helpful! I have a test program kind of > working. > > I notice I only get 5 seconds to do what I am going to before it closes, > and I also notice that my program can no longer respond to keystrokes after > I hit the red X.How do other programs get around this? For example if > I open word for windows and type something and hit the X it asks if I want > to save it and will wait indefinitely for a response. Is this a > limitation because I am running console application,Is there a way I > can do this with my console application as well > Correct, that is a limitation of the console no matter the operating system. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unexpected termination with no errors
Karoly Balogh (Charlie/SGR) schrieb am Mi., 15. Mai 2019, 18:40: > Hi, > > On Wed, 15 May 2019, Sven Barth via fpc-pascal wrote: > > >> (Sidenote: I've been pondering for a while if I should report this as a > >> bug. I think the RTL should put a try-except around there, to show a > >> stacktrace on unhandled exceptions, just like the main thread dying > >> does, but who knows which Delphi de-facto standard behavior would that > >> violate, so meh...) > > > > That is already the case at least for TThread descendants as can be seen > > in rtl/unix/tthread.inc, ThreadFunc. This is needed for the > > FatalException field. > > Hmm, I see, indeed. Should have checked the source code, but I never > cared... -.-' Well, the stacktrace is stilly only printed on DEBUG_MT, if > i'm correct?, so from the developer's perspective, the thread is still > dying 'silently', and sometimes it's hard to identify if your thread went > away or just blocked, when seeing an issue... Anyway, not important and > unrelated here. > It won't terminate quietly, because FatalException will be set in that case (of course assuming that FreeOnTerminate is false). This means that the user must actively check whether a thread crashed. But that would be the necessary with any other mechanism as well, cause we don't want to automatically print a stack trace as the developer might not want that or it might not even be possible (e.g. writing to StdOut or StdErr would not be possible on Windows for GUI applications). Though maybe one could add an event that is triggered when an exception had been raised. That would give the developer the opportunity to handle the exception when it occurred. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unexpected termination with no errors
Karoly Balogh (Charlie/SGR) schrieb am Mi., 15. Mai 2019, 15:25: > Hi, > > On Wed, 15 May 2019, James Richters wrote: > > > Has anyone encountered anything like this before or know how I can make > > sure I always get the maximum amount of debugging info when my program > > crashes? > > Is it a subthreaded app? > > The only case when I noticed something similar (under Linux though), when > a certain subthread throws an exception, it just silently disappears > without any further handling. It doesn't throw any exception, unless you > wrap the entire Execute method in a try-except. > > (Sidenote: I've been pondering for a while if I should report this as a > bug. I think the RTL should put a try-except around there, to show a > stacktrace on unhandled exceptions, just like the main thread dying does, > but who knows which Delphi de-facto standard behavior would that violate, > so meh...) > That is already the case at least for TThread descendants as can be seen in rtl/unix/tthread.inc, ThreadFunc. This is needed for the FatalException field. One could argue whether the BeginThread API should protect the function as well though... 🤷♀️ Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot net dll in free pascal?
Luca Olivetti schrieb am Di., 14. Mai 2019, 09:13: > El 14/5/19 a les 0:15, Sven Barth via fpc-pascal ha escrit: > > > The file command under Linux says: > > Siemens.Engineering.dll: PE32 executable (DLL) (console) Intel 80386 > > Mono/.Net assembly, for MS Windows > > > > > > You could try to host the .Net CLR. I've never done it, but there exists > > code for that for Delphi: > > https://sourceforge.net/projects/dotnetruntimelibraryfordelphi/ > > So that should be possible in FPC as well. > > > Thank you but: > > "Delphi or RAD Studio has not been installed on this computer. The .Net > Runtime Library for Delphi Trial Edition 6.0.6.0 requires an installed > and licensed Delphi or RAD Studio 2010, XE, XE2 and higher versions". > Hmm... I did not see that this is a commercial solution. What is something like that doing on SourceForge?! -.- Well as an alternative you can try the .Net hosting code from the JCL, though I don't know what changes you'd need to do to get the necessary units working with FPC: https://github.com/project-jedi/jcl/blob/master/jcl/source/windows/JclDotNet.pas https://adamjohnston.me/delphi-dotnet-interop-with-jvcl/ Also it seems that this code requires the assembly to have a COM visible API, so you'd need to test this. Alternatively here is an example by Microsoft to host the CLR yourself. https://code.msdn.microsoft.com/CppHostCLR-e6581ee0 In both cases you'll have to create type library imports for mscoree and mscorlib. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot net dll in free pascal?
Luca Olivetti schrieb am Mo., 13. Mai 2019, 23:14:
> A sizeable part of my day job is to program PLCs in the worst software
> environment ever (for the curious, simatic tia portal, actually I'm
> mostly using the older, only marginally better, step 7, but the times
> they are a-changin').
> Said piece of sh^H^Hfine engineering, provides a dll to automate some
> tasks, however, being a steaming pile of...fine engineering, it's made
> with dot net and the instructions on how to use it only mention visual
> something (page 12 of this document
>
> https://support.industry.siemens.com/cs/attachments/108716692/108716692_TIA_Openness_GettingStartedAndDemo_V14SP1_en.pdf
> ).
>
> Is it possible to someway use it with fpc?
> I tried the "import type library.." menu item that lazarus provides with
> no success ("error loading the dll", strangely enough localized even if
> my lazarus is in english, so I suppose that comes from windows).
>
> The file command under Linux says:
> Siemens.Engineering.dll: PE32 executable (DLL) (console) Intel 80386
> Mono/.Net assembly, for MS Windows
>
You could try to host the .Net CLR. I've never done it, but there exists
code for that for Delphi:
https://sourceforge.net/projects/dotnetruntimelibraryfordelphi/
So that should be possible in FPC as well.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem linking external libs on Linux
Anthony Walter schrieb am So., 12. Mai 2019, 20:42: > Okay, so I need to install the dev versions of any package I want to link > against. But when my program is distributed it will link at load time > correctly to the non dev versions. > It links against the version the development version linked against. If the user has a different version installed (even if they have the development package installed) the application won't load of course. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem linking external libs on Linux
Anthony Walter schrieb am So., 12. Mai 2019, 18:41: > For example suppose I want to write some pascal code linking to an > external functions like so: > > const > libsdl2 = 'libSDL2-2.0.so.0'; > > function SDL_Init(flags: Uint32): LongInt; cdecl; external libsdl2; > procedure SDL_Quit; cdecl; external libsdl2; > > And when I try to compile the linking will likely failed because something > is happening where the libsdl2 constant of 'libSDL2-2.0.so.0' is being > converted to 'SDL2-2.0' at some point during the compilation or linking > stage when working on Linux. > This is indeed how it is supposed to work. You are supposed to link against the development library so that the linker can pick up the correct, real library. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature Announcement: Support for multiple active helpers per type
Am 10.05.2019 um 22:21 schrieb Mattias Gaertner via fpc-pascal: On Fri, 10 May 2019 21:56:56 +0200 Sven Barth via fpc-pascal wrote: [...] We are pleased to announce that Free Pascal now supports the usage of multiple active helper types per extended type. This feature has been developed by Ryan Joseph, so thank you very much Ryan. Thanks Ryan! [...] program testA; uses test1, test2; var o: TObject; begin Writeln(o.Func); // will print 2 end. program testB; uses test2, test1; var o: TObject; begin Writeln(o.Func); // will print 1 end. Ehm, these two examples only demonstrates that the last helper wins. They do not demonstrate multihelpers, do they? Well, if you'd add the methods from the first test you'd see that both helpers are available and that for Func the last helper wins... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Feature Announcement: Support for multiple active helpers per type
Hello together!
We are pleased to announce that Free Pascal now supports the usage of
multiple active helper types per extended type. This feature has been
developed by Ryan Joseph, so thank you very much Ryan.
To enable this feature you need to use the new modeswitch multihelpers.
This will then result in the following code to compile:
=== code begin ===
{$mode objfpc}
{$modeswitch typehelpers}
{$modeswitch multihelpers}
type
TObjectHelper1 = type helper for TObject
procedure Foo;
procedure Foobar;
end;
TObjectHelper2 = type helper for TObject
procedure Bar;
procedure Foobar;
end;
procedure TObjectHelper1.Foo;
begin
Writeln('Foo');
end;
procedure TObjectHelper1.Foobar;
begin
Writeln('Foobar1');
end;
procedure TObjectHelper2.Bar;
begin
Writeln('Bar');
end;
procedure TObjectHelper2.Foobar;
begin
Writeln('Foobar2');
end;
var
o: TObject;
begin
o.Foo;
o.Bar;
o.Foobar; // this will call TObjectHelper2.Foobar
end.
=== code end ===
As can be seen in the example above if a member is present in multiple
helpers then it will be resolved by the usual scoping rules. More common
is however is to have helpers in different units:
=== code begin ===
unit test1;
{$mode objfpc}
{$modeswitch typehelpers}
interface
type
TObjectHelper1 = type helper for TObject
function Func: LongInt;
end;
implementation
function TObjectHelper1.Func: LongInt;
begin
Result := 1;
end;
end.
unit test2;
{$mode objfpc}
{$modeswitch typehelpers}
interface
type
TObjectHelper2 = type helper for TObject
function Func: LongInt;
end;
implementation
function TObjectHelper2.Func: LongInt;
begin
Result := 2;
end;
end.
program testA;
uses
test1, test2;
var
o: TObject;
begin
Writeln(o.Func); // will print 2
end.
program testB;
uses
test2, test1;
var
o: TObject;
begin
Writeln(o.Func); // will print 1
end.
=== code end ===
Sidenote: yes, modeswitch typehelpers also allows "type helper" to be
used with classes and records.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Turbo Pascal 3 graphics
Kevin Lyda schrieb am Mi., 8. Mai 2019, 10:58: > Amazingly I still have a number of my high school computer science > projects which were written in Turbo Pascal 3. And a few are almost > not horribly embarrassing. > > I'd like to port them to fpc and write up the experience but I know > what the huge issue is: it uses the graphics.bin library which was > brought in with graph.p - a snippet of which is at the bottom of this > email. > > It did something like turtle graphics and worked on CGA type systems > which were comically limited. Still, it would be neat to see it run > outside of DOSBox. > > So I'm wondering what my options are with FPC graphics. Looking > through the code I used Draw, GotoXY, Palette, Circle and Fillshape - > as well as IO functions like write, read and keypressed. > > Any suggestions appreciated, thanks, > You could simply use one of the Graph units provided by FPC (e.g. PtcGraph). Though depending on the unit the colors might be 32-bit values instead of 16-bit ones. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC require glibc?
Michael Van Canneyt schrieb am Di., 7. Mai 2019, 08:32: > > > On Mon, 6 May 2019, Nozz via fpc-pascal wrote: > > > On Monday, May 6, 2019 10:48 PM, Sven Barth > wrote: > > > >> Nozz via fpc-pascal schrieb am Mo., > 6. Mai 2019, 22:18: > >> > >>> Empty Message > >> > >> Depends on what you're using (and the platform). E.g. the compiler > itself runs without glibc on Linux, but if you need to use threads for > example that changes. Also if you link against libraries like GTK or Qt you > also indirectly link to glibc and the RTL's initialization code will change > due to this. > >> On some targets (e.g. macOS) using the C library is a must. > >> > >> Regards, > >> Sven > > > > Thanks, if I want to compile a program for Alpine Linux (musl libc > instead of glibc) , is my best option to compile FPC&Lazarus from source? > > That should not be necessary. > > The programs that need the C library use the system installed C library. > If this is libc instead of glibc, then that will be used, there is no > explicit reference to gnu libc. > It depends whether the musl libc also leads to the inclusion of "libc.so.6" in the ELF files. If yes, then all should be good (except if not all calls are available, but then recompilation wouldn't help either), if not everything needs to be rebuild so that the correct C library is entered in the ELF. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC require glibc?
Am 07.05.2019 um 00:16 schrieb Nozz via fpc-pascal: On Monday, May 6, 2019 10:48 PM, Sven Barth wrote: Nozz via fpc-pascal <mailto:fpc-pascal@lists.freepascal.org>> schrieb am Mo., 6. Mai 2019, 22:18: Empty Message Depends on what you're using (and the platform). E.g. the compiler itself runs without glibc on Linux, but if you need to use threads for example that changes. Also if you link against libraries like GTK or Qt you also indirectly link to glibc and the RTL's initialization code will change due to this. On some targets (e.g. macOS) using the C library is a must. Regards, Sven Thanks, if I want to compile a program for Alpine Linux (musl libc instead of glibc) , is my best option to compile FPC&Lazarus from source? As a first step you could simply test whether the existing binaries work, cause the C library is entered as "libc.so.6" into the ELF file. If it doesn't start and complains about a missing library then you should recompile both from source. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC require glibc?
Nozz via fpc-pascal schrieb am Mo., 6. Mai 2019, 22:18: > Empty Message > Depends on what you're using (and the platform). E.g. the compiler itself runs without glibc on Linux, but if you need to use threads for example that changes. Also if you link against libraries like GTK or Qt you also indirectly link to glibc and the RTL's initialization code will change due to this. On some targets (e.g. macOS) using the C library is a must. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Improve message "Wrong ppu found"
leledumbo via fpc-pascal schrieb am Sa.,
27. Apr. 2019, 15:14:
> > Please provide a real example of a compiler output, cause I can't find
> "Wrong ppu found" in the sources.
>
> I think what he meant is:
>
> $ grep -i 'wrong ppu version' -r *
> pkgutil.pas: Comment(V_Error,'Wrong PPU Version
> '+tostr(ppuversion)+' in '+PPUFn);
> utils/ppufiles.pp: Error('Error: Wrong PPU Version : '+PPUFn,false);
> utils/ppumove.pp: Error('Error: Wrong PPU Version '+tostr(ppuversion)+'
> in '+PPUFn,false);
>
The first shouldn't really be visible as it's a consistency check (and does
print a version) and the other two are from compiler utilities, not the
compiler itself.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TThread.OnTerminate never called
Dennis schrieb am Sa., 27. Apr. 2019, 05:22: > > > Sven Barth via fpc-pascal wrote: > > Am 21.04.2019 um 18:22 schrieb Dennis: > >> I am using FPC 3.0.4 Lazarus 2.00 on windows 64 > >> > >> I created a subclass of TThread and found out that the > >> TThread.OnTerminate event was never called (I already assigned it). > >> Also, I search the source code of TThread in classeh.inc and found > >> that there was no calling of FOnTerminate nor OnTerminate > >> > >> Is it supposed to be a dummy place holder? > >> I don't use Delphi any more. Is this behaviour the same as Delphi? > >> > >> Thanks in advance. > > > > How did you test it? OnTerminate is called using Synchronize so if you > > use a command line program to test it you need to make sure to call > > CheckSynchronize otherwise you'll never see it being called. In a LCL > > program that should work without any further action. > > > I am using the debugger to break on the Event assigned to OnTerminate. > That breakpoint was never reached. > I am using the FpDebug internal Dwart-debugger (beta) > Can you tell me what the code of calling synchronize(OnTerminate) is? I > cannot find it in the FPC source. > Dennis > I'm not asking whether you used a debugger, I'm asking whether you used a command line program or a GUI program to test it. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Improve message "Wrong ppu found"
Am 24.04.2019 um 10:14 schrieb Alexey Tor.: Suggestion: in the message $subj, can you add FPC version of that PPU? so it will be "Wrong PPU found [FPC 2.7.8]" when FPC needs PPU for 3.2.0. Please provide a real example of a compiler output, cause I can't find "Wrong ppu found" in the sources. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TThread.OnTerminate never called
Am 21.04.2019 um 18:22 schrieb Dennis: I am using FPC 3.0.4 Lazarus 2.00 on windows 64 I created a subclass of TThread and found out that the TThread.OnTerminate event was never called (I already assigned it). Also, I search the source code of TThread in classeh.inc and found that there was no calling of FOnTerminate nor OnTerminate Is it supposed to be a dummy place holder? I don't use Delphi any more. Is this behaviour the same as Delphi? Thanks in advance. How did you test it? OnTerminate is called using Synchronize so if you use a command line program to test it you need to make sure to call CheckSynchronize otherwise you'll never see it being called. In a LCL program that should work without any further action. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc 3.2: "Declaration of type TTypeList changed"
Am 25.04.2019 um 22:23 schrieb Luca Olivetti: Hello, as per the subject, I've been bitten by this change: http://wiki.freepascal.org/User_Changes_Trunk#Declaration_of_type_TTypeList_changed This code (FTasks is a specialization of TFPGList) for i:=0 to FTasks.Count-1 do begin FTasks.List^[i].rackData:=FindRack(FTasks[i].rack); FTasks.List^[i].cellData:= FindCell(FTasks[i].rackData,FTasks[i].cell); end; worked before. Now it compiles with no warnings but it segfaults. (This is just an example, there are other instances where I use List^[] and they also segfault). I changed the above code to be LocTask:=FTasks[i]; LocTask.RackData:=...; LocTask.CellData:=; FTasks[i]:=LocTask; but I don't understand why the former implementation bombs. The change in the definition of TTypeList shouldn't have that effect, besides, as I said, I get no warning compiling the code (apart from the ton of messages about the assignment not inlined). Seems I forgot to correctly adjust the GetList methods. I fixed that in trunk now and will arange for a merge to 3.2. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] class operator enumerator
Am 24.04.2019 um 15:31 schrieb Ryan Joseph: On Apr 24, 2019, at 12:30 AM, Ben Grasset wrote: Seems like it's mixed up in some way with the FPC-style enumerator operator, so the "class" version is recognized but not actually implemented currently or something. The normal way for classes/records/objects is to implement a GetEnumerator function, anyways. Here's an expanded-on version of your example, using your generic constants feature: I think they just forget to disable the operator for records but I believe the operator function works as intended however. It should probably best be forbidden for class operators considering there is the GetEnumerator way to add one (and it even works with helpers). Regadrs, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record helper properties
Am 24.04.2019 um 15:28 schrieb Ryan Joseph: On Apr 24, 2019, at 2:27 AM, Michael Van Canneyt wrote: I would think this should be allowed, yes. I see no reason to disallow it. Agreed but Sven says something about published fields though. The property just acts as simple alias so I don’t understand what the problem could be either. I’ll put this on my to-do list to fix in the compiler if it’s permitted. No, you're not permitted. The issues that would currently appear with published properties will also appear with non-published ones once support for extended properties is added. And I definitely don't want to fiddle around with that only because someone didn't like to write some boilerplate code. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record helper properties
Ryan Joseph schrieb am Di., 23. Apr. 2019, 21:54: > So I remember now that any fields are not allowed in helpers. Can anyone > explain why this must be the case or if it could be fixed? > A helper can not access its extended type in its interface, only in its implementation (and yes, this gets important if published properties are involved, which a helper may declare as well). Use a getter as a workaround. If you use "inline" chances are high that it will be nearly equal code as if you used a direct access. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Resolving math expression as input from user
Am 23.04.2019 um 12:04 schrieb James Richters: I'm trying to figure out if there is some function available that would take a string as input and return a double value that is the complete evaluation of the string? So when asked for a numeric input, the user could just put in a number like 6.28 but also put in a formula like SQRT(2) or (3*(8+Q))/9.3 or Hypot(I,J) etc... using any random math operations in combination with math functions and variables, without editing the code to create an expression to evaluate the formula. [snip] Any Ideas? You could take a look at fpexprpars. See also here: http://wiki.freepascal.org/How_To_Use_TFPExpressionParser Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] how to customize so Pandroid would be usable from Lazarus for windows
Am 18.04.2019 um 12:46 schrieb Tomas Hajny: On Thu, April 18, 2019 12:32, Mgr. Janusz Chmiel wrote: . . I have also started to transform build.sh to Windows batch file. Which issues AM I facingnow? . . echo ppcjvm - $TYPHON/fpc/fpc64/bin/x86_64-linux/ppcjvm $environment_variable in shell scripts = %environment_variable% in Windows batch files. . . I have modified The builddebug.sh script which is available inside C:\usr\local\pandroid\example\Vibrator\android folder But I do not know, if I can replace fi command by pause? . . "fi" (in shell scripts) = "$ENDIF" (in Pascal); there's no alternative to that in the Windows batch files, because those only allow executing a single command based on the result of the "if" condition. If longer blocks of commands need to be invoked, the Windows batch file alternative is either moving those blocks to another batch file (and calling that batch file in from the IF condition), or using a label and goto in the batch file. Huh? What about === code begin === if CONDITION ( BLA1 BLA2 BLA3 ) === code end === I'm using that construct quite often at work... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Really Strange Speed Problems - FPC & Neural Networks
Am 17.04.2019 um 10:01 schrieb Joao Schuler: Hello, It's better not to reply to an existing mail with a completely new topic, cause now your mail is burrowed deep in the "Lazarus Release 2.0.2" thread. Better write directly to the list without replying. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus Release 2.0.2 - suggestions
Rainer Stratmann schrieb am Di., 16. Apr. 2019, 13:47: > Are there plans to merge some windows? > > Like here (best solution): > https://cdn.portableapps.com/GeanyPortable.png > > Because I think it is no more up to date. > I don't know any other Software that uses so many windows across the whole > desktop. It would be more userfriendly to merge at least the main window > with > the code window. So that on top of the code window there are the buttons > of > the main window. Also the output window could be one tab of the search > window. > You can install the AnchorDockingDsgn package and have all windows integrated (except for forms which need an additional package). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can FPC optimize: if (s[i]='a') or ...
Am 15.04.2019 um 09:06 schrieb Bernd Oppolzer: Am 15.04.2019 um 08:29 schrieb Tomas Hajny: On Mon, April 15, 2019 07:52, Bernd Oppolzer wrote: . . On Samstag, 13. April 2019 22:30:55 CEST Alexey Tor. wrote: . . Can FPC optimize it so it only reads s[i] once (to register), not 3 times? . . True for New Stanford Pascal: . . I fail to see how is this related to FPC or the question of the original poster (who was explicitly asking about FPC). Could we stay on topic, please? Tomas (one of FPC mailing list moderators) well, I was hoping for an answer out of the FPC community what FPC does to the different codings, so that the users can get some guidelines out of it (for example: common subexpressions in locigal expressions are not eliminated, so it is better to use the IN syntax - or maybe the other way round). My mails were meant to motivate this :-) but so far only suggestions how to optimize at the source code level. (and of course: because FPC is sort of inspiration for my work, I would like to see what FPC does in this cases and to compare it with what I have) Sorry about that ... And you can't just test yourself? After all FPC is free and provides a "-al" option that keeps the assembly code around... Anyway, take this code: === code begin === var c: Char; begin c := 'A'; if (c = 'a') or (c = 'b') or (c = 'c') then c := 'B'; if c in ['a', 'b', 'c'] then c := 'B'; if c in ['a', 'g', 'l'] then c := 'B'; end. === code end === The result on x86_64 with -O- will be this: === code begin === # [9] c := 'A'; movb $65,U_$P$TMW_$$_C(%rip) # [10] if (c = 'a') or (c = 'b') or (c = 'c') then cmpb $97,U_$P$TMW_$$_C(%rip) je .Lj3 jmp .Lj4 .Lj4: cmpb $98,U_$P$TMW_$$_C(%rip) je .Lj3 jmp .Lj5 .Lj5: cmpb $99,U_$P$TMW_$$_C(%rip) je .Lj3 jmp .Lj6 .Lj3: # [11] c := 'B'; movb $66,U_$P$TMW_$$_C(%rip) .Lj6: # [12] if c in ['a', 'b', 'c'] then movzbl U_$P$TMW_$$_C(%rip),%eax subl $97,%eax cmpl $3,%eax jb .Lj7 .Lj7: jc .Lj8 jmp .Lj9 .Lj8: # [13] c := 'B'; movb $66,U_$P$TMW_$$_C(%rip) .Lj9: # [14] if c in ['a', 'g', 'l'] then movzbl U_$P$TMW_$$_C(%rip),%eax cmpl $97,%eax je .Lj10 cmpl $103,%eax je .Lj10 cmpl $108,%eax je .Lj10 .Lj10: je .Lj11 jmp .Lj12 .Lj11: # [15] c := 'B'; movb $66,U_$P$TMW_$$_C(%rip) === code end === With -O2 it will be this: === code begin === # Var c located in register dl # [9] c := 'A'; movb $65,%dl # [10] if (c = 'a') or (c = 'b') or (c = 'c') then cmpb $97,%dl je .Lj3 cmpb $98,%dl je .Lj3 cmpb $99,%dl jne .Lj6 .Lj3: # [11] c := 'B'; movb $66,%dl .Lj6: # [12] if c in ['a', 'b', 'c'] then movzbl %dl,%eax subl $97,%eax cmpl $3,%eax jnc .Lj9 # [13] c := 'B'; movb $66,%dl .Lj9: # [14] if c in ['a', 'g', 'l'] then movzbl %dl,%eax cmpl $97,%eax je .Lj11 cmpl $103,%eax je .Lj11 cmpl $108,%eax je .Lj11 jne .Lj12 .Lj11: # [15] c := 'B'; movb $66,%dl === code end === So it optimized the variable access into a register, but the first if-condition is more like the third if-condition than the second. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optional param modifier
Am 14.04.2019 um 23:48 schrieb Martin Frb: As for "documentation". I disagree with the way it is done in oxygen. But I am not sure I have any good alternative. For me a class contract (require/ensure) is part of the interface. So it would have to be like (and similar for plain procedures, no class) // can be all on one line type TFoo= class function DoTheFooThing(Foo1, Foo2: TFoo): Tbar; requires assigned(Foo1) or assigned(Foo2): 'Need at least 1 foo, for the connection'; guarantees // better than ensure assigned(result); result.KnowsMyFoo = true: 'Connection exists'; // the =true is redundant procedure DoTheBar; end; So reading this declaration, you immediately know what is valid. And if custom messages are give, they may tell you way It is to be noted, that requires and guarantees contain conditions (expressions), not pascal code. So technically it is ok, that they are in the interface and not implementation. If I want something in the implementation, I can use normal "assert" (which by the way, have often great documenting value) The problem is that both "require" and "ensure" can check for fields as well (think of a setter for example or something that changes the state). Thus you could use a field name that the compiler does not yet know. So you would need to order your methods in a order dictated by the compiler due to the method's implementation instead of an order of your own choosing. And yes, that would also be a problem with "class invariants", though there it's more clear if we say that only identifiers can be used that have been declared before as it's the same with properties and their setters/getters. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optional param modifier
Am 15.04.2019 um 01:19 schrieb Ryan Joseph:
On Apr 14, 2019, at 7:08 PM, Martin Frb wrote:
Almost. assert takes the condition itself
assert(condition_that_must_be_true, 'error message')
so it would be
assert(name<>'', 'requires "name <> " failed for CreateHero');
You can already insert such asserts yourself. assert exists.
If you compile with -Sa then they are compiled in the code, otherwise not.
From the compilers perspective isn’t it faster to test the condition first in
an if statement so the assert function doesn’t get called? Assert tests for
false also so it needs to invert the test to “name = ‘’” which is not how the
“requires” statement is worded.
An Assert() might look like a mere procedure call, but it's in fact an
intrinsic. If assertions are disabled ({$ASSERTIONS OFF}) then it
completely does not exist and otherwise it's the check followed by a
call to 'fpc_assert'.
Also an assertion "fires" if it's condition is False, so Assert() would
do the same check as "requires" or "ensure" need:
requires
Assigned(MyArg)
becomes
Assert(Assigned(MyArg), ...);
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optional param modifier
Am 14.04.2019 um 16:05 schrieb Ryan Joseph:
On Apr 14, 2019, at 3:15 AM, Sven Barth via fpc-pascal
wrote:
Your idea requires exceptions as well. The compiler is not capable checking
whether valid entries are passed in at compile time except for simple, constant
cases, so runtime checks are needed and the only way to abort something is by
exceptions.
My idea didn’t require the procedure to exit so I don’t see where an exception
would be needed. It just says if a param was flagged you would need to check
for nil before dereferencing other you get a compile time error.
As already said by Martin: the compiler *can not* determine all cases
whether the parameter is Nil or not, so it *must* be done at runtime to
ensure this. Otherwise the feature is just as useful as this:
=== code begin ===
{$macro on}
{$define optional:=}
procedure Blubb(aArg: TObject optional);
begin
end;
=== code end ===
I like the idea (because it feels Pascalish) to make a code section that checks
requirements but the exit condition is up for debate. I personally wouldn’t use
the feature if it meant I need to start the tedious process of wrapping
everything in try blocks and taking on what performance costs there are to
exceptions (we can’t opt into exceptions via modeswitch so I don’t know what
those things are doing and where they are).
As Martin said: this is an error condition like an Assert that should
trigger during development with the default result being a termination
of the application.
We have custom error systems in our code also so forcing everyone into
exceptions would not be nice. I could imagine a bail condition that was jumped
to but it would have to be in the code section. That’s usually how we do it now
anyways so it shouldn’t be too strange.
function MakeHero (name: string; hp: integer; level: integer): THero;
require
name <> ‘’;
hp > 0;
(level > 0) and (level < 10);
begin
…
bail
MyCustomErrorHandler(‘MakeHero() params are invalid’);
exit(THero.Invalid);
end;
Invalid contracts are an error that should trigger during development,
but not necessarily when released. So coupling them with the default
exception mechanism is a valid solution.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
Am 14.04.2019 um 17:03 schrieb Ryan Joseph:
On Apr 13, 2019, at 10:07 PM, Ben Grasset wrote:
E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure am glad that
{$mode ObjFPC} does not allowed advanced records. It would be specifically bad if it
did!" because it just doesn't matter if they weren't using advanced records to start
with. It's just a lot of minor rules that nobody can really explain but that tend to add
up in relatively annoying ways.
I like what Jonas did for the ObjC mode switch where he named them with
versions. Maybe a {$mode objfpc2} one day.
My idea was to maybe add a mode ObjFPCExt or ObjFPCAdv which is quite a
bit less conservative and might break backwards compatibility a bit more
often when new features are added.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
Am 14.04.2019 um 04:07 schrieb Ben Grasset:
I dunno about setting them globally, but generally I do find
modeswitches rather annoying, as the combination of features is pretty
arbitrary, and they mostly just *disallow* things that couldn't break
the code of people who weren't using those features to begin with if
they were allowed.
E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure
am glad that {$mode ObjFPC} does not allowed advanced records. It
would be specifically bad if it did!" because it just doesn't matter
if they weren't using advanced records to start with. It's just a lot
of minor rules that nobody can really explain but that tend to add up
in relatively annoying ways.
The thing is that we do try to be backwards compatible and thus rather
conservative with mode ObjFPC. E.g. the following code compiles without
the modeswitch set, but not with:
=== code begin ===
program tmw;
{$mode objfpc}
type
TTest = record
private: LongInt;
public: LongInt;
protected: LongInt;
strict: Longint;
end;
begin
end.
=== code end ===
This hasn't always been done optimally in the past, e.g. when I added
class helper support back in '12 or so I didn't protect the changes
behind a modeswitch. Something I would not do today.
Also the modeswitch itself is definitely required as definitely not all
language modes should support advanced records by default (e.g. TP or ISO).
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optional param modifier
Ryan Joseph schrieb am So., 14. Apr. 2019, 00:17: > > > > On Apr 13, 2019, at 6:01 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > Well, there is Oxygene's concept of Class Contracts (see > > https://docs.elementscompiler.com/Concepts/ClassContracts/ ), so if > > anything in that direction would be done I'd be inclined towards their > > syntax (and I've played with the idea to implement this in FPC for quite > > some time already). > > That’s an interesting idea. It’s certainly common that you test for these > conditions at the top of the function and have bail out conditions so it > makes sense to pull it out into syntax. But it has to rely on exceptions > and all that overhead? That’s not so great if so. Your idea requires exceptions as well. The compiler is not capable checking whether valid entries are passed in at compile time except for simple, constant cases, so runtime checks are needed and the only way to abort something is by exceptions. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
