Re: [fpc-devel] Publish some of FPC's internal cross-platform functionality

Am 10.03.2019 um 11:43 schrieb Anton Shepelev: Michael Van Canneyt to Anton Shepelev: Thank you, but how do I translate the return value of GetLastOSError into a value of InOutRes? The translation functions are privately implemented in sysos.inc . You can copy them. It is open source, after a

Re: [fpc-devel] Publish some of FPC's internal cross-platform functionality

Anton Shepelev schrieb am Sa., 9. März 2019, 18:09: > It would relieve the programmer of writing conditionally > compiled OS-specific code sections for such basic operations > as are already implemented in FreePascal's internals. I, > for example, have to do it whenever my Windws/Unix program >

Re: [fpc-devel] Regressions on i386-win32 and x86_64-win64

Am 02.03.2019 um 22:57 schrieb J. Gareth Moreton: Hi Nikolai, I don't even know the testsuite URL myself - I just run the regression tests as found under "fpc/tests", which is fairly public given there's a readme file there explaining how to run them. Nikolai is talking about the result page

Re: [fpc-devel] Regressions on i386-win32 and x86_64-win64

Am 02.03.2019 um 17:59 schrieb J. Gareth Moreton: It might need double-checking, but I'm getting a couple of regressions on the trunk for i386-win32 and x86_64-win64: Failed, compilation successful webtbf/tw4893d.pp 2018/12/06 07:01:14 Failed, compilation successful webtbf/tw4893e.pp 2018/12/06

Re: [fpc-devel] Getting built-in string type

Am 28.02.2019 um 03:11 schrieb Ryan Joseph: Sending this again to see if it gets through (posts getting blocked again). On Feb 26, 2019, at 2:43 PM, Ryan Joseph wrote: In my implicit generic specialization code I have one place where I get a string const node (stringconstn) which the resultd

Re: [fpc-devel] Implicit cast from Char/String to array of Char

Am 25.02.2019 um 08:09 schrieb Ondrej Pokorny: Hello! Implicit cast from Char/String to array of Char: is this a wanted behavior or is it a compiler bug? (Btw. MODE DELPHI behaves the same). program Project1; {$mode objfpc}{$H+} procedure A(AC: array of Char); var   C: Char; begin   for C in

Re: [fpc-devel] Good timing metric test program?

J. Gareth Moreton schrieb am Mo., 25. Feb. 2019, 19:14: > The compiler isn't a valid case because the input source is different > (because of the very changes made to said compiler). It needs to be a > project that doesn't share anything with the compiler (except the run-time > libraries), so th

Re: [fpc-devel] "Blank slate" next version of FPC

Am 22.02.2019 um 07:06 schrieb Paul van Helden: On Fri, Feb 22, 2019 at 2:35 AM Ben Grasset > wrote: On Sat, Feb 16, 2019 at 5:44 PM Benito van der Zander mailto:ben...@benibela.de>> wrote it can turn out the enumerators are slower than an old schoo

Re: [fpc-devel] "Blank slate" next version of FPC

Am Mi., 20. Feb. 2019, 20:45 hat gabor geschrieben: > W dniu 2019-02-16 o 23:37, Benito van der Zander pisze: > > So are inline variables coming soon? > > > http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html > > Who cares ininline variables since we do not have dynamic pack

Re: [fpc-devel] "Blank slate" next version of FPC

Am Mi., 20. Feb. 2019, 12:07 hat Nikolai Zhubr geschrieben: > So I'm just wondering, what is wrong with such approach that it is > considered so harmfull for Pascal? (Not talking here about possible > excessive complexity of actual implementation in compiler, and not > talking about the exact syn

Re: [fpc-devel] "Blank slate" next version of FPC

Am Mi., 20. Feb. 2019, 08:36 hat Paul van Helden geschrieben: > and FPC's goal to remain Delphi-compatible. >>> >>> >>> So are inline variables coming soon? >>> http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html >>> >> >> We have already decided internally that this feature

Re: [fpc-devel] "Blank slate" next version of FPC

Am 19.02.2019 um 11:12 schrieb George Bakhtadze: Also third party library developers suffering from absence of a dependency manager (yes, I'm aware of Online Package Manager). Recently was started a project of such tool. But it's initiator doesn't use FPC so FPC compatibility for it will have t

Re: [fpc-devel] "Blank slate" next version of FPC

Am So., 17. Feb. 2019, 04:42 hat Ben Grasset geschrieben: > The idea that it is "bloated" as I sometimes hear doesn't make a whole lot > of sense, for one. FPC does not magically add things you don't use to your > binary. How would that work? Why would you think it did? It's illogical. > For som

Re: [fpc-devel] "Blank slate" next version of FPC

Am Sa., 16. Feb. 2019, 23:44 hat Benito van der Zander geschrieben: > > > but we try as much as possible to break old code. > > > I have noticed that. All my code has been broken by the codepage aware > strings and TEncoding > Introduction of the codepage aware AnsiString was one of the disrupti

Re: [fpc-devel] "Blank slate" next version of FPC

Am Sa., 16. Feb. 2019, 09:58 hat Michael Van Canneyt geschrieben: > > > On Sat, 16 Feb 2019, J. Gareth Moreton wrote: > > > Hm, fair enough. Seems a bit strange to not like a new feature, although > > Delphi did start getting a bit bloated in places. Ah well! > > Compatibility is never a bad th

Re: [fpc-devel] "Blank slate" next version of FPC

Am Fr., 15. Feb. 2019, 10:07 hat James via fpc-devel < fpc-devel@lists.freepascal.org> geschrieben: > I'm interested in starting (or joining) a discussion on the next (*non* > backwards compatible) version of FPC. Instead of being classically object > oriented, there is merit in examining a model

Re: [fpc-devel] commits for merging to 3.2 ?

Am Mo., 11. Feb. 2019, 15:13 hat Marco van de Voort < c...@pascalprogramming.org> geschrieben: > Op 2/11/2019 om 2:38 PM schreef Sven Barth via fpc-devel: > > > If Sven says to merge them, I will. >> > > If the testsuite isn't saying otherwise you have a green

Re: [fpc-devel] commits for merging to 3.2 ?

Am Mo., 11. Feb. 2019, 10:07 hat Marco van de Voort < c...@pascalprogramming.org> geschrieben: > > Op 2/10/2019 om 9:47 PM schreef Martin: > > I am not sure if there is a place for the indent to merge (or absent > > thereof) can be checked? > > > > Once merged, the svn log, but before? Will the

Re: [fpc-devel] Suspicion about TThread.Synchronize

Am Mi., 6. Feb. 2019, 18:45 hat Luca Olivetti geschrieben: > El 6/2/19 a les 17:05, Sven Barth via fpc-devel ha escrit: > > Am Mi., 6. Feb. 2019, 11:27 hat Luca Olivetti > <mailto:l...@ventoso.org>> geschrieben: > > > > Of course I cannot reproduce the

Re: [fpc-devel] Suspicion about TThread.Synchronize

Am Mi., 6. Feb. 2019, 11:27 hat Luca Olivetti geschrieben: > Of course I cannot reproduce the issue with a simpler test program :-/ > Without a way to test it I can't do anything. So either you need to find the issue yourself or you need to manage to create a simpler example. Regards, Sven > _

Re: [fpc-devel] Detecting SSE and AVX compiler options

Am Mo., 4. Feb. 2019, 14:15 hat J. Gareth Moreton geschrieben: > Oh right, okay, so x86_64-win64 is Double (even though Extended is > supported), but other x86_64 platforms are Extended, right? A little bit > odd, but I'll keep an eye out in that case. > Correct. Though Extended is not considere

Re: [fpc-devel] Detecting SSE and AVX compiler options

Am So., 3. Feb. 2019, 18:29 hat J. Gareth Moreton geschrieben: > To reassure, I'm aware that "float" is normally "extended" outside of > x86_64, and I would keep my changes constrained to that platform. > This statement is not correct: the default floating point type for nearly all of FPC's plat

Re: [fpc-devel] Detecting SSE and AVX compiler options

Am So., 3. Feb. 2019, 07:28 hat J. Gareth Moreton geschrieben: > As an example of a function that can benefit from a speed-up under > x86_64... the floor() and floor64() functions: > > function floor64(x: float): Int64; > begin > Result:=Trunc(x)-ord(Frac(x)<0); > end; > Please keep in m

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] 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 year

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 make

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; in

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 only

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 s

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 obj

Re: [fpc-devel] ref count types / threadsave question

Am Do., 3. Jan. 2019, 13:25 hat Benito van der Zander geschrieben: > Hi, > > > > The issue I was talking about is the fact that atomic operations do > function as global memory synchronisation operations across all cores (at > least not on all architectures). If core 1 atomatically increases refc

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 a

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 separ

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 - fpc-devel@lists.freepa

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] 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 b

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 needs

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] 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 > > clas

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 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] 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 RA

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] 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 varia

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 variables,

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) f

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] 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] 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: < > cal4d7fjpfx-yst6z

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: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 advant

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

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

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 th

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 didn't

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 (depend

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, and in t

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

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, Excep

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] 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

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 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()

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 ByteBoo

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] 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] 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,', Separator

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] 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] 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] 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] 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   writeln(s

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? >> > > Implementati

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 > section

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 ma

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 compi

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 Word128

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 releas

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 add

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] 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 nu

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.) > > http://wiki.freepasc

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 l

Re: [fpc-devel] FreeInstance

Ryan Joseph schrieb am Di., 31. Juli 2018, 22:29: > > > > On Jul 31, 2018, at 9:56 AM, Ryan Joseph > wrote: > > > > then how does it get invoked then? there must be some node added > somewhere but I can’t find it. > > I’m still trying to find this with no luck. I suspect there’s a call node > ad

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 message

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 custo

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 t

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

Michael Van Canneyt schrieb am Mo., 30. Juli 2018, 15:30: > Obviously provided you don't install another mechanism that does this and > don't raise exceptions manually, which - AFAIK - is the case in the > compiler... > The compiler does use exceptions when the compilation needs to be aborted e.

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

J. Gareth Moreton schrieb am Mo., 30. Juli 2018, 13:31: > I've noticed that the compiler doesn't use > try...finally blocks to help with freeing > blocks. I'm not sure why this is the case, > but might be speed related. > Correct. Even implicit try-finally frame generation is disabled for the co

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 StaticClass

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 mo

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] 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 rest

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 subar

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 > stored &

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 benefit

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 direct

<    1   2   3   4   5   6   7   8   >