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

On 3/9/19 1:06 PM, Anton Shepelev wrote: Whenever the programmer grows annoyed of jumping to the declaration section and back to code, he knows it is time to cut his spaghetti into more manageable parts. BINGO! give this man a cigar! FWIW: this annoyance at jumping back and forth is also a

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

Hi, 09.03.2019 21:06, Anton Shepelev: [...] Pascal is a language where declaration and use of variables is separated. It makes it easy to see what [...] a := a + Func1( b ); int b := Func2( a ); a := a - Func3( b ); Also worth reference are Bart's thoughts on the subject, in two

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

Sven Barth: > Pascal is a language where declaration and use of > variables is separated. It makes it easy to see what > variables are declared and what type they are. Inline > variables mess this up as a variable can be declared > somewhere inside the code. I use C++ to earn my living. I >

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

> The compiler already supports keeping records in registers under the same > conditions, but only up to a certain size (two native registers) and only > using the > same layout as they would have in memory (so no explicit splitting out fields > into separate registers). Using record fields as

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

> On Feb 24, 2019, at 9:14 AM, Marco van de Voort > wrote: > > Yes. Can it be turned off? I don’t use FPC with exceptions and I don’t even use the RTL usually so I don’t need these. Honestly this should have a mode switch if it’s impacting all code regardless of whether a program actually

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

On 24/02/2019 17:23, Ryan Joseph wrote: On Feb 24, 2019, at 10:48 AM, Jonas Maebe wrote: It's is an inherent part of the "class" feature. Without it, any exception that gets thrown in a constructor (or in any code called by a constructor) will cause memory leaks. Not very useful if we

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

> On Feb 24, 2019, at 10:48 AM, Jonas Maebe wrote: > > > It's is an inherent part of the "class" feature. Without it, any exception > that gets thrown in a constructor (or in any code called by a constructor) > will cause memory leaks. Not very useful if we don’t use exceptions though. :)

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

On 24/02/2019 16:48, Jonas Maebe wrote: You can disable these exception frames with {$implicitexceptions off}. If you want to disable it for TObject, you have to recompile the system unit with that switch, since the code for TObject's constructor is inside that unit. ld never do this.

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

Op 2019-02-24 om 15:40 schreef Florian Klämpfl: Am 24.02.19 um 15:22 schrieb Marco van de Voort: it bothers you, help making exceptions cheaper (table based exceptions/seh) Actually, it is only cheaper if no exceptions are raised. Raising an exception is very expensive when the table

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

On 24/02/2019 16:06, Ryan Joseph wrote: On Feb 24, 2019, at 9:22 AM, Marco van de Voort wrote: It is part of the language, people have lived with it over 20 years. If it bothers you, help making exceptions cheaper (table based exceptions/seh) I must say that’s disappointing because FPC is

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

> On Feb 24, 2019, at 9:22 AM, Marco van de Voort > wrote: > > Not that I know. Maybe $implicitexceptions off where the class is declared, > but I doubt it. > >> I don’t use FPC with exceptions and I don’t even use the RTL usually so I >> don’t need these. Honestly this should have a

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

On 24/02/2019 15:36, Martin Frb wrote: On 24/02/2019 15:24, Jonas Maebe wrote: On 24/02/2019 15:22, Marco van de Voort wrote: It is part of the language, people have lived with it over 20 years. If it bothers you, help making exceptions cheaper (table based exceptions/seh) They're already

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

Am 24.02.19 um 15:22 schrieb Marco van de Voort: it bothers you, help making exceptions cheaper (table based exceptions/seh) Actually, it is only cheaper if no exceptions are raised. Raising an exception is very expensive when the table driven approach is used.

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

On 24/02/2019 15:24, Jonas Maebe wrote: On 24/02/2019 15:22, Marco van de Voort wrote: It is part of the language, people have lived with it over 20 years. If it bothers you, help making exceptions cheaper (table based exceptions/seh) They're already working for Linux/i386 and LLVM targets

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

On 24/02/2019 15:22, Marco van de Voort wrote: It is part of the language, people have lived with it over 20 years. If it bothers you, help making exceptions cheaper (table based exceptions/seh) They're already working for Linux/i386 and LLVM targets in de debug_eh branch. And of course for

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

Op 2019-02-24 om 15:19 schreef Ryan Joseph: On Feb 24, 2019, at 9:14 AM, Marco van de Voort wrote: Yes. Can it be turned off? Not that I know. Maybe $implicitexceptions  off where the class is declared, but I doubt it. I don’t use FPC with exceptions and I don’t even use the RTL

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

Op 2019-02-23 om 15:35 schreef Ryan Joseph: Here’s this implicit try/finally block on heap allocation thing again. Can someone please explain this? Some months ago someone complained FPC was doing this on all TObject.Create calls. Is that true? Yes.

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

> On Feb 21, 2019, at 7:34 PM, Ben Grasset wrote: > > The trick with enumerators is to never make them classes, and use advanced > records instead, I've found. This way you avoid the heap allocation and the > implicit try/finally. Also make sure you inline the MoveNext and GetCurrent! >

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

Indeed, most of the instructions for bit extracting appeared later for SSE and AVX.  I did find one instruction that works with general-purpose registers, named BEXTR, but it only extracts contiguous bits and requires BMI1. Gareth aka. Kit On Sat 23/02/19 10:27 , Jonas Maebe

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

On 23/02/2019 01:30, J. Gareth Moreton wrote: Given that the reference is an offset from %rbp, the compiler will know for sure that the variable is local, so there won't be any problems with multi-threading that prevents a lot of temporary register storage for safety reasons. Unpacking

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

I feel like a beginner when I say that I've never used advanced records or enumerators before, or the "for-in" loop.  There's definite room for improvement there though, for sure. I think the problem with the compiler is that it seeks to keep the record together in concurrent storage.  Storing

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

There's not really any way to do what that does with a normal for loop without copying the array though, which is whole point basically. Here's the actual assembly I get from FPC for "main": .section .text.n_main,"x" .balign 16,0x90 .globl PASCALMAIN PASCALMAIN: .globl main main: .Lc12:

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

Hi, The trick with enumerators is to never make them classes, and use advanced records instead, I've found. This way you avoid the heap allocation and the implicit try/finally. Also make sure you inline the MoveNext and GetCurrent! that's what I do. But the generated assembly is still

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

On Fri, Feb 22, 2019 at 1:07 AM Paul van Helden wrote: > How do you make a (for in) enumerator with a record? I don't use them for > exactly this reason, and they did seem to be another useful language > feature that turned out to be poorly implemented by Embarcadero. (Haven't > checked with

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

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

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 > wrote > >> it can turn out the enumerators are slower than an old school loop >> > > The trick with enumerators is to never make them classes, and use advanced > records instead, I've

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

On Sat, Feb 16, 2019 at 5:44 PM Benito van der Zander wrote > it can turn out the enumerators are slower than an old school loop > The trick with enumerators is to never make them classes, and use advanced records instead, I've found. This way you avoid the heap allocation and the implicit

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

On Sun, Feb 17, 2019 at 3:15 AM Florian Klämpfl wrote: > This is a property of production compiler code. > I'm not sure about that. I don't think FPC's codebase is (for the most part) a mess, although the style is a little bit inconsistent sometimes.

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

Am 21.02.19 um 06:19 schrieb Ondrej Pokorny: Am 20.02.19 um 21:33 schrieb Florian Klämpfl > Am 20.02.19 um 08:36 schrieb Paul van Helden: > As a big >/fan of the Pascal language, I'd rather break compatibility and see the /> >/language evolve than the stoic attitude of the core devs as seen

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

On 2/20/19 12:58 PM, James via fpc-devel wrote: Someone pointed out that a main goal of Pascal was to keep one from shooting oneself in the foot. It is this spirit that I think should be extended (if possible) to adopt at least the memory safe aspect of Rust. There are other programming

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

Am 20.02.19 um 21:33 schrieb Florian Klämpfl > Am 20.02.19 um 08:36 schrieb Paul van Helden: > As a big >/fan of the Pascal language, I'd rather break compatibility and see the /> >/language evolve than the stoic attitude of the core devs as seen on this /> >/list. / People could change this

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

Well, I asked for discussion, and it was given. Thank you all for your input. To be clear, although I *literally* wrote the words "non backwards compatible", I did not mean it. I should have said that there should be a new compiler mode to access new features. In Rust, there is the concept of

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

>. For us inline variables is one of the most horrid if not *the* most horrid >thing Embarcadero could have done to Object Pascal. Can you tell us why ? (In C I often declare variables just before using them and I indeed would even like to do “for (int i = 0; i<10; i++) {a[i] = a[i+1];} ☺

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

> If Oxygene was open source and (CPU) native, Oxygen *is* CPU native (optionally). But not open source, and of course there are a lot more drawbacks regarding fpc/Lazarus. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

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

On the contrary... I'm all for new features if they gel well with the language, although I try to research and theorise how they can benefit the compiler and the code it generates.  My current patches haven't been as well-received as I had hoped, possibly due to lack of documentation and provable

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

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

Hi, 20.02.2019 23:33, Florian Klämpfl: Am 20.02.19 um 08:36 schrieb Paul van Helden: > As a big fan of the Pascal language, I'd rather break compatibility and see the language evolve than the stoic attitude of the core devs as seen on this list. People could change this attitude by

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

20.02.2019 21:28, Giuliano Colla: [...] Moreover, using a modern tool such as Lazarus, you never need to scroll 1000 lines to find a declaration: you just press alt+Up to go to the declaration of the symbol over the cursor, and Ctrl+H to go back to the line of code. It's a bit like car

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

Hi, 20.02.2019 23:56, wkitt...@windstream.net: [...] How this example is different from e.g. using normally declared "I, J: Integer" and employing "J" as a loop variable? Wouldn't it do the same error anyway? i think he's pointing out the two instances of var I in the code... one at the

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

On 2/20/19 1:28 PM, Giuliano Colla wrote: Keeping all declarations separated from code is just good programming practice. Mixing declaration and code is bad programming practice, IMO, and I appreciate Pascal for not supporting it. this falls in the same line as keeping business logic separate

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

On 2/20/19 2:08 PM, Nikolai Zhubr wrote: 20.02.2019 18:24, Dimitrios Chr. Ioannidis via fpc-devel: [...]  I'd like to see an example how this is less safe. Well one of the answer in the Cantu blog has this ( which I changed to lets say a "real world" relative big function ) : How this

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

Am 20.02.19 um 08:36 schrieb Paul van Helden: > As a big fan of the Pascal language, I'd rather break compatibility and see the language evolve than the stoic attitude of the core devs as seen on this list. People could change this attitude by contributing to FPC. But very few do constantly

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

On Wed, Feb 20, 2019 at 4:28 PM Nikolai Zhubr wrote: > > [...] > > On the other hand, I've been biten plenty by the already existing name > clashes like: > >with Button1 do >begin > Left := ClientWidth div 2; > . > > and here nothing can probably be done to help at compiler

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

On Wed, Feb 20, 2019 at 1:50 PM Kostas Michalopoulos wrote: > > > and Niklaus Wirth might not throw a curse in us. > > Considering we're talking about a dialect with three different > incompatible yet mostly overlapping object systems, i think the curse > has already been cast long long ago :-P.

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

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 packages yet? Regards, Michał.

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

Hi, 20.02.2019 21:28, Giuliano Colla: [...] I have just met such a situation: I ported from C++ to Pascal an algorithm for the computation of the kinematics of a Delta Robot, and I was badly bitten. In that case you are just dealing with X,Y,Z coordinates, and Theta0,Theta1,and Theta2 angles,

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

On 20/02/2019 19:56, Nikolai Zhubr wrote: 2) Nested loops exist. If in the middle of such a 1000 line for-loop, I want to declare another loop, then I need to find a free identifier for that variable.  Today, I can do that by looking at the declaration on top of the procedure (and afaik

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

* Just to note there is a choice - not pitching one is better just, there is someone doing it * There is a choice of course... built using FPC. I wrote ModernPascal. We do not focus on Windows support as much as other platforms FPC is available for. Per grammar, MP2 (current build) was designed to

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

Hi, 20.02.2019 18:24, Dimitrios Chr. Ioannidis via fpc-devel: [...] I'd like to see an example how this is less safe. Well one of the answer in the Cantu blog has this ( which I changed to lets say a "real world" relative big function ) : How this example is different from e.g. using

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

Hi, 20.02.2019 17:56, Martin Frb: 1) "for" (and other) loops with a long body also exist. So the problem is still there, if I encounter "i" in the middle of a This is correct. Inline declaration will not be able to solve all problems in the galaxy, it could just help to relieve some of them.

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

Il 20/02/2019 19:11, Nikolai Zhubr ha scritto: Now it is getting even more curious. Admittedly I don't use C too much (and C++ even less so, approximately never), maybe that is why I do not understand your reasoning. Could you maybe give an example of such problematic inline declaration and

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

Hi Sven, 20.02.2019 16:51, Sven Barth via fpc-devel: [...] Pascal is a language where declaration and use of variables is separated. I can understand that a language can (and should) try to follow some aesthetic tradition (which, btw, has already been horribly broken many times, imho,

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

> and Niklaus Wirth might not throw a curse in us. Considering we're talking about a dialect with three different incompatible yet mostly overlapping object systems, i think the curse has already been cast long long ago :-P. ___ fpc-devel maillist -

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

Hi, Στις 20/2/2019 4:46 μ.μ., ο Paul van Helden έγραψε: On Wed, Feb 20, 2019 at 4:35 PM Dimitrios Chr. Ioannidis via fpc-devel > wrote:   Even if declaring variables as close as possible to where the variable will be used ( debugging wise not

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

On 20/02/2019 15:46, Paul van Helden wrote: On Wed, Feb 20, 2019 at 4:35 PM Dimitrios Chr. Ioannidis via fpc-devel > wrote:   Even if declaring variables as close as possible to where the variable will be used ( debugging wise not readability wise

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

On 20/02/2019 14:36, Paul van Helden wrote: So the argument against is: (1) split your long functions, because you should; and (2) Wirth didn't do it, so good it is not. Long functions *might* be an indication of bad design, but you know, sometimes I have a long function that doesn't make

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

(sorry for the pm, Paul, should have gone to list) Op 2/20/2019 om 3:32 PM schreef Paul van Helden: On Wed, Feb 20, 2019 at 3:52 PM Sven Barth via fpc-devel > wrote: Pascal is a language where declaration and use of variables is separated. It

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

On Wed, Feb 20, 2019 at 4:35 PM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Even if declaring variables as close as possible to where the variable > will be used ( debugging wise not readability wise ) leads to more correct > code, the problem is to avoid

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

Hi, Στις 20/2/2019 3:36 μ.μ., ο Paul van Helden έγραψε: > > 1. it makes it easier to see the whole picture just looking at the loop > > body, no need to scroll up; (The loop body might be just 10 lines of code, > > whereas the whole containing function sometimes has 1000s)

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

On Wed, Feb 20, 2019 at 3:52 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > > Pascal is a language where declaration and use of variables is separated. > It makes it easy to see what variables are declared and what type they are. > Inline variables mess this up as a

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

On Wed, Feb 20, 2019 at 10:25 AM Henry Vermaak wrote: > > On Wed, Feb 20, 2019 at 09:47:20AM -0300, Marcos Douglas B. Santos > wrote: > > On Wed, Feb 20, 2019 at 8:32 AM Henry Vermaak > > wrote: > > > I'm mostly more interested in limiting the scope to prevent > > > accidental use, like you. It

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

Hi, Στις 20/2/2019 3:25 μ.μ., ο Henry Vermaak έγραψε: On Wed, Feb 20, 2019 at 09:47:20AM -0300, Marcos Douglas B. Santos wrote: On Wed, Feb 20, 2019 at 8:32 AM Henry Vermaak wrote: I'm mostly more interested in limiting the scope to prevent accidental use, like you. It can also offer more

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

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

> > > > > 1. it makes it easier to see the whole picture just looking at the loop > > > body, no need to scroll up; (The loop body might be just 10 lines of > code, > > > whereas the whole containing function sometimes has 1000s) > > > > > > 2. it isoltates the scope of such variable(s), therefore

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

On Wed, Feb 20, 2019 at 09:47:20AM -0300, Marcos Douglas B. Santos wrote: > On Wed, Feb 20, 2019 at 8:32 AM Henry Vermaak > wrote: > > I'm mostly more interested in limiting the scope to prevent > > accidental use, like you. It can also offer more fine grained > > control of where managed

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

On Wed, Feb 20, 2019 at 8:32 AM Henry Vermaak wrote: > > On Wed, Feb 20, 2019 at 02:26:20PM +0300, Nikolai Zhubr wrote: > > 20.02.2019 13:21, Sven Barth via fpc-devel: > > [...] > > >And we don't agree here. For us inline variables is one of the most > > >horrid if not *the* most horrid thing

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

On Wed, Feb 20, 2019 at 8:07 AM Nikolai Zhubr wrote: > > Hi all, > > 20.02.2019 13:21, Sven Barth via fpc-devel: > [...] > > And we don't agree here. For us inline variables is one of the most > > horrid if not *the* most horrid thing Embarcadero could have done to > > Object Pascal. > > Could

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

On Wed, Feb 20, 2019 at 7:21 AM Sven Barth via fpc-devel wrote: > > And we don't agree here. For us inline variables is one of the most horrid if > not *the* most horrid thing Embarcadero could have done to Object Pascal. +1 Even this isn't break compatibility with past code, it turns the

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

On Wed, Feb 20, 2019 at 02:26:20PM +0300, Nikolai Zhubr wrote: > 20.02.2019 13:21, Sven Barth via fpc-devel: > [...] > >And we don't agree here. For us inline variables is one of the most > >horrid if not *the* most horrid thing Embarcadero could have done to > >Object Pascal. > > Could you

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

Hi all, 20.02.2019 13:21, Sven Barth via fpc-devel: [...] And we don't agree here. For us inline variables is one of the most horrid if not *the* most horrid thing Embarcadero could have done to Object Pascal. Could you elaborate a bit about it? While I'm not really sure what they have done

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

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

> > 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 is where we draw the > line. We won't implement it and we are also

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

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

Theoretically there is a way to refresh the language without breaking existing code - a new {$mode}. Or even completely new compiler will not break old code if it can handle .ppu generated by the current one. And there is much to improve. Not only add modern language features but in syntax

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

> codepage aware AnsiString was one of the disruptive changes that couldn't > really be avoided. IMHO, it could have been avoided (largely), but that would have come at the cost of less perfect compatibility with Delphi XE (which even more severely broke compatibility to previous Delphi

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

> . Syntax for parallel math (SIMD) In Oxygen, you have parallel loops and future variables. This can be used for defining parallelism in the syntax. I understand that currently RemObjects implemented this as a simple translation of the appropriate .Net framework API, and that it’s only

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

> Martin was a loner kind of guy, he did the most of the MSEGUI etc projects > alone too. A real Genius, but always happy to take part in very interesting discussions. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

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

Op 2019-02-16 om 09:50 schreef Mattias Gaertner via fpc-devel: le to break old code. Then you are not doing a good job. ;) Some have more old code than others :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

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

> On Feb 17, 2019, at 3:24 AM, Sven Barth via fpc-devel > wrote: > > Blaise is still working on it. Some bugs still need to be fixed and then he > needs to adjust the code to the points of criticism I had given. Most > importantly however are the missing tests. Even if the feature would be

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

On 17/02/19 9:12 PM, Florian Klämpfl wrote: Am 17.02.19 um 02:42 schrieb Neil Graham: I think for the most part, if any clean slate is needed for FPC it is for the Libraries and not the language.  A Class library that was built to support the language as it currently stands rather than

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

On 2/17/2019 12:15 AM, Florian Klämpfl wrote: Am 17.02.19 um 01:47 schrieb Ralf Quint: On 2/16/2019 12:43 AM, Florian Klämpfl wrote: but we try as much as possible to break old code. Really? =-O Ralf ;-) You should have noticed, you follow this list for years/decades ;)? Yup, it's

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

Am 17.02.19 um 04:48 schrieb Ben Grasset: His compiler code was / is just kind of an unreadable mess, to be perfectly honest. This is a property of production compiler code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

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

Am 17.02.19 um 02:42 schrieb Neil Graham: On 17/02/19 10:37 AM, Ralf Quint wrote: On 2/14/2019 9:28 PM, James via fpc-devel wrote: 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

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

On Fri, Feb 15, 2019 at 4:07 AM James via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > 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 with

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

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

On 2/16/2019 12:43 AM, Florian Klämpfl wrote: but we try as much as possible to break old code. Really? =-O Ralf ;-) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist -

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

Hi, there is NewPascal with improved memory safety/smart pointers: http://newpascal.org/ 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 and FPC's goal to remain Delphi-compatible. So

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

On Sat, 16 Feb 2019 13:37:44 -0800 Ralf Quint wrote: >[...] > Adding newfangled gadgets and gizmos might be all fine and dandy, but > don't force it down the throat of everyone as a must. I am not going > to throw away 40 years of libraries and snippets away and start from > scratch, just so

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

On 2/14/2019 9:28 PM, James via fpc-devel wrote: 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 with ad-hoc polymorphism like Rust. I am, like

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

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

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 thing though! Hm. 'a bit bloated' is the understatement of the year. I still

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

Am 16.02.19 um 09:50 schrieb Mattias Gaertner via fpc-devel: On Sat, 16 Feb 2019 09:43:32 +0100 Florian Klämpfl wrote: [...]but we try as much as possible to break old code. Then you are not doing a good job. ;) Oh :) ___ fpc-devel

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

On Sat, 16 Feb 2019 09:43:32 +0100 Florian Klämpfl wrote: >[...]but we try as much as possible to break old code. Then you are not doing a good job. ;) Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

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

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 thing though! Gareth aka. Kit On Sat 16/02/19 08:27 , Jonas Maebe jo...@freepascal.org sent: On 16/02/19 01:37, J. Gareth Moreton

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

On 16/02/19 01:37, J. Gareth Moreton wrote: One thing that does spring to mind though.,, what features of Delphi and FPC made the language unsuitable for Martin Schreiber, and is it anything we developers can possibly address in some way? He did not like new language features and RTL changes

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

Op 2/16/2019 om 1:37 AM schreef J. Gareth Moreton: That's an interesting project there. One thing that does spring to mind though.,, what features of Delphi and FPC made the language unsuitable for Martin Schreiber, and is it anything we developers can possibly address in some way? Martin

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

> I'm interested in starting (or joining) a discussion on the next (*non* > backwards compatible) version of FPC. Did you take a look at Oxygen (RemObjects Elements) ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

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

That's an interesting project there. One thing that does spring to mind though.,, what features of Delphi and FPC made the language unsuitable for Martin Schreiber, and is it anything we developers can possibly address in some way? Gareth aka. Kit On Fri 15/02/19 20:32 , Jonas Maebe

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

On 15/02/19 06:28, James via fpc-devel wrote: I'm interested in starting (or joining) a discussion on the next (*non* backwards compatible) version of FPC. As mentioned by others, that's not really something any of the current FPC developers are interested in working on. Martin Schreiber,

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

I can't speak for the senior developers, but I think there's a preference that backwards compatibility is maintained, at least between versions of FPC if not Delphi.  At least my preference is to attempt to better support the existing FPC - for example, I tend to do a lot of work and research

  1   2   >