Re: [fpc-devel] A small laugh!

On Tue, Jul 23, 2019 at 7:53 AM J. Gareth Moreton wrote: > > Hi everyone, > > This is to Sven in particular, since he always gets on my case when I go > against the compiler's coding standards in my patches, but otherwise > this picture is posted here for the humour! I'm sure a few people can >

Re: [fpc-devel] Submitting patches using git

On Sat, Jul 20, 2019 at 5:14 PM Ryan Joseph wrote: > > > On Jul 20, 2019, at 4:02 PM, Martin Frb wrote: > > > > "origin/master" is the not modified trunk? > > No, what I did was fork https://github.com/graemeg/freepascal and then a > create new feature branches based on master. “origin” I

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Thu, Jul 4, 2019 at 2:32 AM Sven Barth via fpc-devel wrote: > > [...] > Even if one would say that the whitespace at the start of a line is > discarded that wouldn't make everyone happy, cause then code like the > example Ben showed in his mail from today wouldn't work: > > === code begin ===

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On Wed, Jul 3, 2019 at 5:20 PM Ben Grasset wrote: > > On Wed, Jul 3, 2019 at 3:27 PM gabor wrote: >> > [...] > const SA = ` > This is a multiline > string using hypothetical backticks. > Imagine it was fully syntax-highlighted > like normal strings and the comment > above are. > `; >

Re: [fpc-devel] modeswitch multihelpers

On Mon, May 13, 2019 at 7:09 AM Ondrej Pokorny wrote: > > On 13.05.2019 11:59, Stefan Glienke wrote: > > When I wrote "existing code" I was referring to the future when people turn > > this on for their code and then helpers get changed and not "today existing > > code". > > The problem is the

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

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

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] Why/how does the compiler have a non-trivial number ofmemory leaks after over two decades of development?

On Mon, Jul 30, 2018 at 3:31 PM, R0b0t1 wrote: > On Mon, Jul 30, 2018 at 11:42 AM, Marcos Douglas B. Santos > wrote: >> On Mon, Jul 30, 2018 at 12:29 PM, R0b0t1 wrote: >> >> [...] > > If a program isn't long running I see programmers tend to not care > about

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

On Mon, Jul 30, 2018 at 9:14 AM, Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > 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

Re: [fpc-devel] FPC Macros: Could it be used for unit aliases?

On Wed, Jun 27, 2018 at 11:51 AM, Sven Barth via fpc-devel wrote: > Marcos Douglas B. Santos schrieb am Mi., 27. Juni 2018, > 14:37: >> >> Sven and all, >> Is there any change to implement this? > > > Not from me. I don't care about that. Thanks for your si

Re: [fpc-devel] FPC Macros: Could it be used for unit aliases?

Sven and all, Is there any change to implement this? Thanks. Best regards, Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC Macros: Could it be used for unit aliases?

On Sun, Jun 24, 2018 at 5:49 PM, Marcos Douglas B. Santos wrote: > Instead, I prefer using fully qualified names and just adjust in some > contexts that *there is* already a conflict name. > In other words, `uses foo as bar;` will be use per unit. It is not to > intent "rena

Re: [fpc-devel] FPC Macros: Could it be used for unit aliases?

On Sun, Jun 24, 2018 at 4:06 PM, Sven Barth via fpc-devel wrote: > Am 24.06.2018 um 16:49 schrieb Marcos Douglas B. Santos: >> >> Hypothetically, let's suppose that Windows and Graphics unit belongs >> to `FPC.RTL.` namespace, a "long name". >> Usin

[fpc-devel] FPC Macros: Could it be used for unit aliases?

In another thread[1] Sven Barth explained to me how to use macros properly following my example before. However, I think this could be used as a syntax sugar for unit aliases on the code — not about paths. Graeme and me have already proposed[2] this years ago. I am against to include more

Re: [fpc-devel] FPC fails on overload

On Mon, Jun 18, 2018 at 5:01 PM, Florian Klämpfl wrote: > Am 18.06.2018 um 22:00 schrieb David Jenkins: >> >> This is something that has just recently stopped working for us(with >> update >> to current trunk). We previously were using trunk rev 36812 with no >> problems. > > > Please submit a

Re: [fpc-devel] FPC fails on overload

On Mon, Jun 18, 2018 at 3:04 PM, David Jenkins wrote: > The following code: > > > {$MODE DELPHI} > > program CharOverload; > > uses > SysUtils; > > procedure Foo(const aArg: UnicodeString); overload; > begin > WriteLn('WideString: ', aArg); > end; > > procedure Foo(c: WideChar); overload; >

Re: [fpc-devel] Closures / anonymous methods

On Thu, Jul 20, 2017 at 9:56 PM, Blaise Thorn wrote: > There has been some feature-level progress; in particular, capturing across > arbitrary level of nested and nameless routines is now supported, along with > proper lifetime management. > > Sven has read-write access to the