Re: [fpc-devel] Compile time functions

Thorsten Engler schrieb am So., 29. Juli 2018, 04:40: > type > > TMyClass = class of TMyObject; > > TMyObject = class > > procedure InstanceMethod; //Self = TMyObject, can be virtual > > class procedure ClassMethod; //Self = TMyClass, can be virtual > > class procedure

Re: [fpc-devel] Why/how does the compiler have a non-trivial numberofmemory leaks after over two decades of development?

Am 30.07.2018 um 19:55 schrieb J. Gareth Moreton: Correct me if I'm mistaken, but I believe one shortcoming with the Free Pascal Compiler, despite its speed, is that it isn't multi-threaded.  It can't compile multiple independent units at once, and probably won't be able to for a while due to

Re: [fpc-devel] Why/how does the compiler have a non-trivialnumberofmemory leaks after over two decades of development?

Am 30.07.2018 um 19:49 schrieb J. Gareth Moreton: The trouble is, these allocation failures are designed for C programs, where "malloc" returns NULL if memory isn't allocated.  Free Pascal's GetMem raises an exception instead. Granted, it shouldn't be too much of a struggle to implement a

Re: [fpc-devel] Compile time functions

J. Gareth Moreton schrieb am Sa., 28. Juli 2018, 19:34: > I did wonder about that, but wasn't sure how it would affect things where > inheritance is concerned. I dare ask, do you have an example of a class > method that you would consider pure? > They don't have inheritance. If they have the

Re: [fpc-devel] Compile time functions

J. Gareth Moreton schrieb am Sa., 28. Juli 2018, 18:49: > Another little progress update with implementing pure functions. > > 1. In my code (not submitted yet), the compiler now recognises and accepts > the 'pure' directive. There are a number of other directives that it can't > be used with

Re: [fpc-devel] Why/how does the compiler have anon-trivialnumberofmemory leaks after over two decades of development?

J. Gareth Moreton schrieb am Mo., 30. Juli 2018, 23:20: > Apologies if these things seem trivial. I probably need to read the > documentation cover to cover to learn about these global state variables. > > I am a bit surprised that hitting out of memory exceptions causes > incorrect error

Re: [fpc-devel] FreeInstance

Ryan Joseph schrieb am Mi., 1. Aug. 2018, 17:28: > > > > On Aug 1, 2018, at 9:17 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > Search the compiler's source for the string 'FREEINSTANCE'; you'll find > two locations, one in

Re: [fpc-devel] Exceptions on wiki

Kirinn schrieb am Mi., 1. Aug. 2018, 23:30: > Hi all, > > Inspired by Gareth aka. Kit's infectious enthusiasm, and the recent long > discussion on exceptions on this list, I wrote up an article on > Exceptions on the FPC wiki. (Strangely enough we didn't have one before.) > >

Re: [fpc-devel] Little question about the

J. Gareth Moreton schrieb am Fr., 10. Aug. 2018, 18:44: > Thanks Sven, > > Sorry if I'm bringing up obvious points. I've set "pure" to be > interface-only - it's a little tricky because if you now specify it in the > main source file, it says that it can't be used in the implementation >

Re: [fpc-devel] Little question about the "First Pass"

J. Gareth Moreton schrieb am Mi., 8. Aug. 2018, 23:45: > Hi everyone, > > So I'm making progress with my pure function implementation, or something > passing as an early alpha prototype. I do have a question though... when > the "firstpass" routines are called, have all the procedures been

Re: [fpc-devel] Why/how does the compiler have a non-trivial number of memory leaks after over two decades of development?

Am 30.07.2018 um 02:58 schrieb Ben Grasset: Call trace for block $5E642220 size 56   $0001DB6B   $0001000A35ED  TNODE__ALLOCOPTINFO,  line 973 of node.pas   $000100164889  SETEXECUTIONWEIGHT,  line 366 of optutils.pas   $0001000C2873  FOREACHNODESTATIC,  line 321 of

Re: [fpc-devel] Why/how does the compiler have a non-trivial number of memory leaks after over two decades of development?

Am 30.07.2018 um 02:58 schrieb Ben Grasset: Call trace for block $7CDCDD60 size 416   $0001DA72   $0001BF6A   $000100217BB0  TCGCALLPARANODE__CREATE,  line 146 of ncgcal.pas   $000100138E6D  TINLINENODE__HANDLE_READ_WRITE, line 1364 of ninl.pas   $00010013F731 

Re: [fpc-devel] Adding procedures using nodes

Am 04.08.2018 um 01:17 schrieb Ryan Joseph: On Aug 2, 2018, at 2:41 PM, Ryan Joseph wrote: So the way FreeInstance is called by adding it within a destructor isn’t exactly what I needed because it requires a destructor actually be present in the class. The next thing I’d like to try is

Re: [fpc-devel] sizeof member in class procedure

Am 15.08.2018 um 00:30 schrieb Benito van der Zander: Hi, why is sizeof on object/class fields sometimes allowed and sometimes not? type TTest = object   f: integer;   class procedure test; end; class procedure TTest.test; begin   writeln(sizeof(f)); // does not compile  

Re: [fpc-devel] Question about Word128

Aelita schrieb am Di., 7. Aug. 2018, 09:53: > Hello! > > My name is Aelita and for many years I have been fruitfully using your > wonderful freepascal > for my research in algebra, geometry and physics. > Thank you for your inspirational work! > > I'm very interested in seeing the numbers

Re: [fpc-devel] Free Pascal 3.0.6

LacaK schrieb am Mo., 6. Aug. 2018, 10:58: > > >> Are there plans to release version 3.0.6 later this year? > > No. There will probably no 3.0.x anymore. (and even if, it would have > mostly > > minor RTL fixes, no sensitive compiler fixes). > It would be nice have at least one maintenance

Re: [fpc-devel] SizeOf( const typcasted as shortstring)

Dmitry Boyarintsev schrieb am Mo., 13. Aug. 2018, 00:12: > On Sun, Aug 12, 2018 at 5:40 PM Bart wrote: > >> const >> x = ShortString('abc'); >> begin >> writeln(SizeOf(x)); >> end. >> >> Delphi (7) prints 256, fpc prints 3. >> >> Is that a bug or an implementation detail? >> > >

Re: [fpc-devel] Little question about the "First Pass"

Gareth sent me the following two mails in private, but they were ment for the list: Am 09.08.2018 um 16:18 schrieb J. Gareth Moreton: Thanks Sven. Normally I would agree with "pure" only belonging in the interface section, but it causes problems when you try to put a pure function inside the

Re: [fpc-devel] Compile time functions

Martok schrieb am Fr., 20. Juli 2018, 23:20: > > What do you think? > The main problem is that not all functions that would be eligible for your approach are also declared as inline thus their node trees would not be stored inside the PPU and thus you could not work with them. Additional

Re: [fpc-devel] Progress of pure function research

Ryan Joseph schrieb am Mi., 18. Juli 2018, 01:27: > > > > On Jul 15, 2018, at 11:01 PM, J. Gareth Moreton < > gar...@moreton-family.com> wrote: > > > > So far I'm mostly researching how the node builder works, specifically > how inline > > functions are handled, since that's a situation where a

Re: [fpc-devel] Issue #32913

R0b0t1 schrieb am Sa., 14. Juli 2018, 21:11: > > Control flow statements are allowed in an EXCEPT block. Come to think of > it, > > didn't we have another TRY/FINALLY/EXCEPT nesting issue that might have > > something to do with that? > > > > If the above is true then this confuses me. Except

Re: [fpc-devel] Compile time functions

Martok schrieb am Sa., 21. Juli 2018, 17:12: > Am 21.07.2018 um 02:08 schrieb Sven Barth via fpc-devel: > > The main problem is that not all functions that would be eligible for > your > > approach are also declared as inline thus their node trees would not be > stor

Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures

Am 22.07.2018 um 10:31 schrieb Christo: I'm trying to change the build process for target AVR so that different sub architectures end up in different subfolders.  At the moment the default behaviour is that e.g. the RTL object files are saved to ./rtl/units/avr-embedded, regardless of the

Re: [fpc-devel] Test changes in e.g. a package

Bart schrieb am Mi., 18. Juli 2018, 23:36: > On Wed, Jul 18, 2018 at 1:39 PM, Michael Van Canneyt > wrote: > > > In general: no. > > OK > I pity the compiler devels, especially in the past with slower hardware. > The compiler devels more often than not only work with the compiler and RTL

Re: [fpc-devel] Operator overload error when using type restrictions

Am 25.07.2018 um 01:11 schrieb African Wild Dog: Hello, Please confirm if this is a bug or my mistake. When i try to overload a assignment operator on a generic class with type restriction i get this error: "Impossible to overload assignment for equal types". However, if i remove the type

Re: [fpc-devel] Default properties

Ryan Joseph schrieb am Fr., 7. Sep. 2018, 11:59: > I’m moving my technical questions about default properties here so I don’t > clutter up the other list. I’m still new to the compiler please bear with > me. > > The first problem I’m having is how to resolve duplicate functions with > overloads.

Re: [fpc-devel] Pure function Wiki page

J. Gareth Moreton schrieb am Mi., 11. Juli 2018, 15:13: > float128 does sound like a good solution > overall. I'm not sure where to begin with > that though, or even what to call it for > Pascal, since "float128" is distinctly C- > like! It could be something to put on my > list of possible

Re: [fpc-devel] Pure function Wiki page

Ryan Joseph schrieb am Mo., 9. Juli 2018, 08:45: > > > > On Jul 8, 2018, at 8:50 AM, J. Gareth Moreton > wrote: > > > > With some blessing from Florian on the concept, I've set up a Wiki page > discussing the design proposals for the support of pure functions, as well > as some explanation on

Re: [fpc-devel] Wrong docs: not initialized global variables

Martok schrieb am Do., 5. Apr. 2018, 16:29: > > From this rule, it follows that every variable must be explicitly > initialized [...] > > Be it with an assignment or an 'var a: type = someonstant;'. > ... for which the syntactic sugar was rejected not two weeks ago. >

Re: [fpc-devel] Dangerous optimization in CASE..OF

Ondrej Pokorny <laza...@kluug.net> schrieb am Fr., 13. Apr. 2018, 21:16: > On 13.04.2018 14:08, Sven Barth via fpc-devel wrote: > > Ondrej Pokorny <laza...@kluug.net> schrieb am Fr., 13. Apr. 2018, 12:52: > >> I introduced the AS operator for enumerations in

Re: [fpc-devel] Dangerous optimization in CASE..OF

Thorsten Engler schrieb am Sa., 21. Apr. 2018, 14:12: > > -Original Message- > > From: fpc-devel On Behalf Of > > Martok > > Sent: Saturday, 21 April 2018 21:39 > > To: fpc-devel@lists.freepascal.org > > Subject: Re:

Re: [fpc-devel] Dangerous optimization in CASE..OF

Alexander Grotewohl schrieb am Sa., 21. Apr. 2018, 16:40: > To be honest I agree with what he's saying. We're bending enums to do > things normal people just wouldn't (and shouldn't) do. > > And seriously, "Delphi, Delphi, Delphi!" .. why don't we strive for > something a

Re: [fpc-devel] What's the status on the "record default field" functionality?

Ben Grasset schrieb am So., 15. Apr. 2018, 09:05: > AFAIK it's been working for over a year in a separate branch. The smart > pointer example demos worked perfectly as far as I could tell. Is there a > particular reason it hasn't been added to the main codebase the way >

Re: [fpc-devel] Creating Generic Object

Bart <bartjun...@gmail.com> schrieb am Mo., 16. Apr. 2018, 12:18: > On Mon, Apr 16, 2018 at 7:53 AM, Sven Barth via fpc-devel > <fpc-devel@lists.freepascal.org> wrote: > > >> This is very nice feature since I do not need define every Map/List/etc > >>

Re: [fpc-devel] Creating Generic Object

Amir schrieb am So., 15. Apr. 2018, 23:51: > Hi all, > >Currently, FPC allows declaring objects as > var >MyMap: specialize TFPGMap; > > This is very nice feature since I do not need define every Map/List/etc > as a separate type. > > But to create

Re: [fpc-devel] Multiple variable initialization

Anthony Walter schrieb am Sa., 24. März 2018, 14:51: > If you were going to patch I'd also consider allowing: > > program Test; > var > B, C: Integer = 0, 1; // sets B = 0, and C = 1 > begin > end. > No, that is only confusing. Regards, Sven

Re: [fpc-devel] Wrong docs: not initialized global variables

Ondrej Pokorny schrieb am Sa., 24. März 2018, 20:49: > This is not correct. Global simple variables are always initialized. At > least in Delphi it is so: > http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Variables_(Delphi) "If > you do not explicitly initialize a global

Re: [fpc-devel] Some RTL bug fixes and suggestions

NetSpirit schrieb am Mo., 26. März 2018, 16:10: > packages\pasjpeg > > Error usage after compile in -Mdelphiunicode mode. > In file 'packages\pasjpeg\src\jpeglib.pas' member > jpeg_error_mgr.format_message still uses AnsiString which is wrong. > Because at the end of file

Re: [fpc-devel] Fix CamelCase in unit and method names

Mark Morgan Lloyd schrieb am Do., 22. März 2018, 17:57: > On 22/03/18 15:30, Juha Manninen wrote: > > On Thu, Mar 22, 2018 at 3:15 PM, Denis Kozlov > wrote:> Please do... It has caused enough eye (OCD) stress over the years ;) > > +1Yes, it

Re: [fpc-devel] Fix CamelCase in unit and method names

R0b0t1 schrieb am Fr., 23. März 2018, 16:07: > > > > IMHO preferably not the unit names (as in 'unit XxX') - with case > > sensitive file names on Unix, this change might increase time for > > searching the respective file (somewhat). Obviously, all further > > references of

Re: [fpc-devel] Attn Sven: New flags related to management operators

Am 27.06.2018 um 13:02 schrieb Maciej Izak: 2018-06-22 21:08 GMT+02:00 Maciej Izak >: I see 4 options: 1. integration of FastRTTI 2. limited integration, only part of "FastRTTI" branch (only table with initialization operators and related compiler and

Re: [fpc-devel] Generics.Collections June update

Am 28.06.2018 um 08:52 schrieb Maciej Izak: * some new proper credits in few places Two questions regarding this: - who is DaThoX and in how far are they related to you and your work? (just out of curiosity) - why is it that you adjusted DaThoX' copyright range, but not yours at the top?

Re: [fpc-devel] 3.0.4 and Windows 64

Ozz Nixon schrieb am So., 30. Sep. 2018, 17:18: > A few years ago I acquired IP rights to Halcyon (xBase for Delphi/FPC). > For years, I have not had an issue, today, I am recompiling the suite (zero > code changes) - 3.0.4 Linux - no problems, 3.0.4 Mac - no problems. > However, 3.0.4 Windows -

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

Dmitry Boyarintsev schrieb am Fr., 12. Okt. 2018, 17:26: > > > On Fri, Oct 12, 2018 at 11:09 AM Dmitry Boyarintsev < > skalogryz.li...@gmail.com> wrote: > >> so, far the only reliable approach to fix the issue (for the current >> compiler version) is something like that: >> > > Maybe "Boolean8"

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

On 10/12/18 7:21 PM, Dmitry Boyarintsev wrote: > On Fri, Oct 12, 2018 at 1:07 PM Sven Barth via fpc-devel > mailto:fpc-devel@lists.freepascal.org>> > wrote: > > Dmitry Boyarintsev <mailto:skalogryz.li...@gmail.com>> schrieb am Fr., 12. Okt. 2018, > 17

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

Dmitry Boyarintsev schrieb am Sa., 13. Okt. 2018, 01:57: > On Fri, Oct 12, 2018 at 6:48 PM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Not quite: the Boolean16, Boolean32 and Boolean64 types were introduced >> because the libraries provid

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

Dmitry Boyarintsev schrieb am Fr., 12. Okt. 2018, 22:55: > On Fri, Oct 12, 2018 at 3:51 PM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> All the Pascal Boolean types are not "Integer types". You can't assign >> any of them to a In

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

Dmitry Boyarintsev schrieb am Fr., 12. Okt. 2018, 02:07: > On Thu, Oct 11, 2018 at 4:16 PM Jonas Maebe wrote: > >> However, the Objective-C BOOL type does not map to _Bool on x86-64, but >> to signed char. And values of that type indeed do need to (sign) >> extended. >> > > Should use of

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Simon Kissel schrieb am Do., 25. Okt. 2018, 08:54: > - Complete the LLVM branch of FPC. It looks like Jonas has stopped > working on it two years ago, which is a pity. > I personally don't think that LLVM is the way to go. It's essentially a moving target and adds an unnecessary dependency to

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Simon Kissel schrieb am So., 28. Okt. 2018, 12:30: > Hi Florian, > > > The %gs based approach works only for object files linked statically to > > the executable. In general there are four TLS access models on linux and > > at least three of them need to be supported, if one wants to support > >

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Simon Kissel schrieb am So., 28. Okt. 2018, 12:46: > Hi Florian, > > > But there is another pretty simple optimization opportunity in this > > area: make the FPC heap manager capable of using > > os-based memory reallocation. Kernel-based memory reallocation of > > large blocks has the big

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Am 28.10.2018 um 13:00 schrieb Simon Kissel: Additionally, in the current FPC code generator global variables behave mostly as volatile variables. With LLVM, that won't be the case (unless we mark all of their accesses as volatile, but that would obviously inhibit LLVM optimizations). This may

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Simon Kissel schrieb am So., 28. Okt. 2018, 12:39: > Hi Ben, > > > There's one more problem I forgot to mention in my first post, and it is > > probably a deal breaker for the original bounty: LLVM does not support > > Borland's fastcall calling convention for i386. So you would need to add >

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Michael Van Canneyt schrieb am Do., 25. Okt. 2018, 09:38: > > > On Sat, 20 Oct 2018, Simon Kissel wrote: > > > - Make Exception handling, TLS etc use the infrastructure that > > libpthread is providing > > TLS is handled already by libpthread. I doubt you will gain much there. > GCC has

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Michael Van Canneyt schrieb am Do., 25. Okt. 2018, 14:55: > > > On Thu, 25 Oct 2018, Sven Barth via fpc-devel wrote: > > > > >> Personally I am also in favour of a more open technique instead of a > >> technique which is proprietary to a platform,

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Michael Van Canneyt schrieb am Do., 25. Okt. 2018, 11:51: > > > On Thu, 25 Oct 2018, Sven Barth via fpc-devel wrote: > > > Michael Van Canneyt schrieb am Do., 25. Okt. > 2018, > > 09:38: > > > >> > >> > >> On Sat, 20 Oct 2018, Simon

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Ben Grasset schrieb am Sa., 27. Okt. 2018, 05:46: > On Thu, Oct 25, 2018 at 3:06 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Simon Kissel schrieb am Do., 25. Okt. >> 2018, 08:54: >> >>> - Complete the LLVM bran

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Am 25.10.2018 um 20:34 schrieb Jonas Maebe: On 25/10/18 20:13, Florian Klämpfl wrote: Am 25.10.2018 um 18:59 schrieb Jonas Maebe: On 20/10/18 16:07, Simon Kissel wrote: - Complete the LLVM branch of FPC. It looks like Jonas has stopped     working on it two years ago, which is a pity. I

Re: [fpc-devel] Array assignment operator

Am Mo., 5. Nov. 2018, 01:00 hat Gennady Agranov geschrieben: > On 11/4/2018 5:24 PM, Sven Barth via fpc-devel wrote: > > Am So., 4. Nov. 2018, 20:36 hat Gennady Agranov > geschrieben: > >> On 11/4/2018 11:24 AM, Sven Barth via fpc-devel wrote: >> >> Am So.,

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

Am Mo., 5. Nov. 2018, 04:43 hat Ben Grasset geschrieben: > I honestly have no idea. It's not an issue I've ever encountered, as I've > literally never built Lazarus with a toolchain that wasn't 64 bit. It would > seem to be the case though that it is indeed very possible (at some > level/point)

Re: [fpc-devel] Array assignment operator

Am So., 4. Nov. 2018, 12:23 hat Schindler Karl-Michael < karl-michael.schind...@web.de> geschrieben: > > > > Am 04.11.2018 um 12:00 schrieb Ben Grasset : > > > > From: Ben Grasset > > To: FPC-Devel users discussions > > Subject: Re: Array assignment operator > > Message-ID: < >

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Ben Grasset schrieb am So., 28. Okt. 2018, 00:29: > On Sat, Oct 27, 2018 at 1:38 PM Florian Klämpfl > wrote: > >> That it is useful to work on table based exception handling for all >> targets >> > > Not arguing with that at all. I was just trying to point out that I'm not > a fan of the idea

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Michael Van Canneyt schrieb am Do., 25. Okt. 2018, 09:38: > > > On Sat, 20 Oct 2018, Simon Kissel wrote: > > > - Make Exception handling, TLS etc use the infrastructure that > > libpthread is providing > > TLS is handled already by libpthread. I doubt you will gain much there. > > However,

Re: [fpc-devel] How to move this, but in FPC 32bit?

Am Di., 13. Nov. 2018, 00:05 hat Ozz Nixon geschrieben: > Its part of 30+ units. In the main units Initialization... > We can't help you if we don't have a complete code snippet that should compile as only then we can test it ourselves. Otherwise we e.g. need to guess the types of the

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Am Mi., 14. Nov. 2018, 14:46 hat Simon Kissel < simon.kis...@nerdherrschaft.com> geschrieben: > Hi Florian, > > you are a hero. In a very artificial benchmark which just consists > of threads and exception handlers, a 32 bit Linux executable now > is *twice as fast*! > Up to now only thread

Re: [fpc-devel] Array assignment operator

Am So., 4. Nov. 2018, 20:36 hat Gennady Agranov geschrieben: > On 11/4/2018 11:24 AM, Sven Barth via fpc-devel wrote: > > Am So., 4. Nov. 2018, 12:23 hat Schindler Karl-Michael < > karl-michael.schind...@web.de> geschrieben: > >> >> >> >

Re: [fpc-devel] String.Split inconsitent behaviour if Separators is [chars] vs [strings]

Bart schrieb am Sa., 29. Sep. 2018, 22:50: > Hi, > > Consider this example: > > program split; > {$mode objfpc} > {$h+} > > uses > sysutils; > > var > S: string; > A: TStringArray; > i: Integer; > > begin > S := '1 2 3 4 5'; > A := S.Split([#32],'"'); > writeln('S = ',S,',

Re: [fpc-devel] 3.0.4 and Windows 64

Am 03.10.2018 um 14:23 schrieb Ozz Nixon: Thank you for explaining. Since I am needing compatibility at the disk level (binary form)... does anyone know of a unit or some routines to read/write: Comp, Double, Extended byte for byte the same? (even if it translates to something different at run

Re: [fpc-devel] MDI problem and fix for Windows with Qt4/Qt5

Rudolf Cornelissen schrieb am Di., 4. Sep. 2018, 09:08: > Hi all, > > This is my first post here, I hope my input is considered helpfull. > > Anyhow, I am busy converting a Delphi MDI application (which I develop as > a daytime job) to Lazarus using Qt/Qt5. > Compared to Win32 Widgeset indeed Qt

Re: [fpc-devel] How to suppress warnings in code?

Martin Schreiber schrieb am Mi., 26. Sep. 2018, 17:14: > Hi, > How can individual warnings be suppressed in code in Free Pascal fixes_3_2? > {$warn off} seems not to work reliable in some projects if compiled > with -B. > Please provide concrete examples. Regards, Sven >

Re: [fpc-devel] AVR - Patches and open bugs to consider for next stable release

christo schrieb am So., 23. Sep. 2018, 21:43: > 34317 - remove redundant compile time warning when using an interrupt. > I've opened that for discussion on the core mailing list, cause it really makes no sense to use oldfpccall on any platform except i386 (cause nowhere else it's available) and

Re: [fpc-devel] Compiler directives in getopts unit

Am 17.01.2019 um 20:29 schrieb wkitt...@windstream.net: On 1/17/19 1:23 PM, Bart wrote: It seems this code at one time needed to be compilable with TP. AFAIK TP however does not support {$IF CONDITION} nor the Declared() macro(?), so the source should not be compilable anymore with TP? if we

Re: [fpc-devel] finalization

Am Di., 22. Jan. 2019, 10:55 hat Alexander via fpc-devel < fpc-devel@lists.freepascal.org> geschrieben: > Hi, > > I try use finalization in unit, but it not work. > > When press Ctrl+C and exit program uses this unit > PC-Speaker stay infinity play on interrupted tone. > When Ctrl+C use spkoff;

Re: [fpc-devel] Compiler directives in getopts unit

Am 18.01.2019 um 00:06 schrieb Michael Van Canneyt: As for the {$IF not Declared(Argv)} part: does that apply to a target that FPC supports or is also there just to be able to compile it with Delphi? If we keep it, then at least the comments should be updated. You can make the unit FPC

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

Am Sa., 15. Dez. 2018, 23:55 hat Nikolai Zhubr geschrieben: > Hi, > > Is there any easy way to see how exactly ppcrossarm.exe invokes > assembler (command-line arguments passed) during a cross-compiler build > and also to inspect intermediate .s files? > You can try -sh which should generate a

Re: [fpc-devel] Fwd: Re: fpc-devel Digest, Vol 175, Issue 29

Am Sa., 22. Dez. 2018, 17:38 hat Bart geschrieben: > On Sat, Dec 22, 2018 at 1:03 PM Franz Müller wrote: > > > But maybe there is an easy way to save the state of the random number > generator routine before sorting and to restore it when the sort is done? > > Save RandSeed and restore it after

Re: [fpc-devel] Type range in generic

Am Sa., 1. Dez. 2018, 08:44 hat Simon Jackson geschrieben: > GENERIC GHandle = CLASS > PROTECTED > it: Array [R] of T; > FUNCTION readIt(p: R): T; VIRTUAL; > PROCEDURE WriteIt(p: R; what: T); VIRTUAL; > PUBLIC > PROPERTY gimmeIt[p: R] READ ReadIt WRITE Writeit; DEFAULT; (* does this > work? x.y

Re: [fpc-devel] Type range in generic

Am So., 2. Dez. 2018, 10:50 hat Ryan Joseph geschrieben: > > > > On Dec 2, 2018, at 4:00 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > Please report as a bug. > > I don’t get a bug on this in the trunk version I’m usin

Re: [fpc-devel] Type range in generic

Am Mo., 3. Dez. 2018, 00:33 hat Simon Jackson geschrieben: > Just an idea. > > Class variables. If generics are used, then the same code can be used for > differing pointer types. (Classes) as long as a specifier on the "generic > class variable" and no generic specialize or <> is in the > >

Re: [fpc-devel] Abstract generics

Am Mo., 3. Dez. 2018, 15:16 hat Simon Jackson geschrieben: > Further to the ranges in generics discussion... more on generics > I've already mentioned my reasons against that. So throwing around strange syntax extensions does not help. At all. Regards, Sven

Re: [fpc-devel] The 15k bounty: Optimizing executable speed forLinux x86 / LLVM

Am Mi., 5. Dez. 2018, 00:06 hat J. Gareth Moreton geschrieben: > The more you learn! What is TLS, curiously? Given that I do a lot of my > work at the assembler level, I figure this is something I should know! > Thread Local Storage. For ELF they are pseudo instructions that the assembler

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Am Fr., 23. Nov. 2018, 12:15 hat Adriaan van Os geschrieben: > Simon Kissel wrote: > > > We know about a couple of bottlenecks (fpc_pushexceptaddr / > > RelocateThreadVar etc) which explain FPC's terrible multi-threading > > performance, but in general, FPC's code generator really is quite > > a

Re: [fpc-devel] Where to set proper alignment default of const strings?

Am 28.11.2018 um 19:51 schrieb Michael Ring: The more I dig the more I ask myself if not the rtl routine is to blame for the issue in the first place because it only takes alignment of the destination into account when doing it's job. Aligncount is calculated base on destination (which is

Re: [fpc-devel] Failure to recompile TAChart after FPC r40785 (committed by Jonas)

Am Mo., 7. Jan. 2019, 15:55 hat Werner Pamler geschrieben: > FPC trunk has not been very friendly to existing code recently... > > Today with r40792, the TAChart package fails to recompile: > "tadiagram.pas(347,38) Error: Only static methods and static variables > can be referenced through an

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Am Mi., 2. Jan. 2019, 09:44 hat Martok geschrieben: > * in ISO mode, there are 2 solutions: in Standard Pascal, not covering the > entire type is a compile-time error. In Extended Pascal, this is a runtime > error. Which one is followed usually? > ISO and Extended Pascal are handled as two

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Am Mi., 2. Jan. 2019, 11:08 hat Bart geschrieben: > On Wed, Jan 2, 2019 at 9:44 AM Martok wrote: > > > - If a case statement on an ordinal does not contain labels for all > values of > > the ordinal, and no else statement is given, raise a new warning > (W6059). This > > is actually defined as

Re: [fpc-devel] merge candidate 3.2 ?

Am Fr., 28. Dez. 2018, 19:16 hat Martin geschrieben: > Is this/Can this be a candidate for merging to 3.2? > https://bugs.freepascal.org/view.php?id=34640 I personally would say so. Regards, Sven > > ___ fpc-devel maillist -

Re: [fpc-devel] Graphical RAD IDE in FPC

Alexander via fpc-devel schrieb am Mo., 17. Sep. 2018, 07:20: > Lasarus use non native for FPC widgets, MSE non stable work. > Huh? Please explain that. Lazarus is *the* example for using native widgets and is one of the points the authors of MSE and fpGUI complain about with the LCL. Regards,

Re: [fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

Am So., 27. Jan. 2019, 00:01 hat John Doe geschrieben: > Not the right person to give a qualified answer to your question, but bare > record parameters in method signatures are kind of a problem throughout > various parts of the standard FPC and Lazarus libraries, I've noticed. > > It almost

Re: [fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

Am So., 27. Jan. 2019, 02:53 hat John Doe geschrieben: > However, I'm also quite simply unaware of any specific realistic scenario > where I would *ever* specify a un-prefixed record in a method (in my own > projects for example I actually haven't used anything but "var" and > "constref" for

Re: [fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

Am So., 27. Jan. 2019, 14:12 hat Walter Prins geschrieben: > On Sun, 27 Jan 2019 at 01:53, John Doe > wrote: > >> On Sat, Jan 26, 2019 at 7:44 PM Sven Barth via fpc-devel < >> fpc-devel@lists.freepascal.org> wrote: >> >>> Changing this behavior wou

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

Am 26.03.2019 um 01:08 schrieb Ben Grasset: On Mon, Mar 25, 2019 at 5:34 PM Ben Grasset > wrote: To be properly cross-platform, it should really generate something like "-Fu..\..\units\$fpctarget" I meant to say, "generate something like that specifically

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

Ben Grasset schrieb am Di., 26. März 2019, 13:47: > On Tue, Mar 26, 2019 at 2:33 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Those paths are not handled relative to the compiler binary, they are >> handled relative to the cur

Re: [fpc-devel] Packed record integers and x86_86

DJ Coertzen schrieb am Mi., 27. März 2019, 18:27: > Hi there, > > I need a solution for a packed record containing 4-byte 32-bit integers > and cardinals, and other byte 8 bit and word 16 bit sized variables to > overlay over a stream. > > Example: > *type* > * TMyBinaryHeader = packed record*

Re: [fpc-devel] implicit generic specialization modeswitch name

Am 24.03.2019 um 15:02 schrieb Ryan Joseph: For my patch https://bugs.freepascal.org/view.php?id=35261 I have named the modeswitch “implicitgenerics” but Florian liked the name “implicitfunctionspecialization” (long but clear were his words). Btw this is the mode switch will allows

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

schrieb am Mo., 25. März 2019, 03:31: > On 3/24/19 6:21 PM, Bart wrote: > > Extract from fpc.cfg from 3.0.4 (created by offcial installer) > > # searchpath for units and other system dependent things > > -FuC:\devel\fpc\3.0.4/units/$fpctarget > > -FuC:\devel\fpc\3.0.4/units/$fpctarget/* > >

Re: [fpc-devel] TRegistry and Unicode

Bart schrieb am So., 24. März 2019, 23:49: > On Sat, Mar 23, 2019 at 2:27 PM Bart wrote: > > > > I will look at it tomorrow. It has been a busy week. > > Thanks for applying. > Thanks to all of you for your advice and patience. > > Should the changes be documented at >

Re: [fpc-devel] implicit generic specialization modeswitch name

Bart schrieb am So., 24. März 2019, 17:44: > On Sun, Mar 24, 2019 at 5:18 PM Sven Barth via fpc-devel > wrote: > > > I agree with Florian that a better name is needed for the modeswitch > > ("implicitgenerics" as a different meaning in my opinion). But I do

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

Bart schrieb am Mo., 25. März 2019, 10:46: > On Mon, Mar 25, 2019 at 7:50 AM Sven Barth via fpc-devel > wrote: > > > Well, to be fair, the "\bla" ones are called "drive relative paths" as > they're always relative to the root drive of the current dir

Re: [fpc-devel] Aligned dynamic arrays

Am 29.03.2019 um 17:53 schrieb Ryan Joseph: First minor snag, fpc_dynarray_insert, fpc_dynarray_concat can allocate new arrays like SetLength can. Do we need to make aligned variants for these also? Using array + operators there is no possibility to set alignment. var a, b: array of

<    1   2   3   4   5   6   7   8   >