Re: [fpc-devel] BacktraceStrFunc on linux x86_64?

On Mon, 1 May 2017, Nikolai Zhubr wrote: Hello all, I'm having some trouble to get BacktraceStrFunc to find line numbers. This is with fpc 3.0.0 on linux x86_64 (Centos 7 if it matters). If I compile the following example with #fpc -gl tt.pas I only get this output: Started... Exception:

Re: [fpc-devel] fpc-devel Digest, Vol 156, Issue 16

On Thu, 27 Apr 2017, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: >>> 1) Why not call it 3.0.4? >> I would also think that we should aim at a quick 3.0.4 then. > +1 Just a linux i386 version (where the problem is acute) or all plat

Re: [fpc-devel] fpc-devel Digest, Vol 156, Issue 16

On Thu, 27 Apr 2017, LacaK wrote: The only alternative would be to advise *nix users to use the 3.0.0 release instead. 3.0.0 has (IMO serious) bug involving calculations with currency datatype on some platforms (Win64, Arm): http://bugs.freepascal.org/view.php?id=28748 Bart my two

Re: [fpc-devel] tbits.NotBits

On Thu, 13 Apr 2017, Andrea Mauri wrote: any answer? I asked in the wrong place? where should I ask? You asked in the right place. I just didn't notice your first mail. I am not sure that what you did is supported. b.notbits(b) I am not sure that you can pass the same instance to b. Can

Re: [fpc-devel] Discussion about "Dynamic packages"

On Wed, 12 Apr 2017, Bishop via fpc-devel wrote: I had some fears concerning idea development of "Dynamic packages" in FreePascal and possible performance penalties of programs from these changes. This why i start this discussion and try wrote some of my ideas or/and proposal that, as i

Re: [fpc-devel] Compiler bug in macro handling?

On Wed, 12 Apr 2017, Giuliano Colla wrote: Hi honourable fpc developers! I found a strange error (both with fpc 2.6.4 and fpc 3.0.0, in Linux environment) The following snippet of code: {$MACRO ON} {$define Positiva:=False;} {$define Negativa:=True;} ... if HDCOUNT0 >= COUNT0

Re: [fpc-devel] LineInfo

On Tue, 4 Apr 2017, Sven Barth via fpc-devel wrote: Am 04.04.2017 08:52 schrieb "Martok" : Does it is possible that the LineInfo trace (-gl option) are broken (no output) in 3.0.2 version on Linux (at least)? Hm. Indeed. I can reproduce the issue :/ AFAIR

Re: [fpc-devel] LineInfo

On Mon, 3 Apr 2017, Marco Borsari via fpc-devel wrote: Does it is possible that the LineInfo trace (-gl option) are broken (no output) in 3.0.2 version on Linux (at least)? Hm. Indeed. I can reproduce the issue :/ Michael. ___ fpc-devel maillist

Re: [fpc-devel] Math and numlib

On Tue, 14 Mar 2017, Werner Pamler wrote: Thanks - unfortunately I've just uploaded a patch for unit typ implementing IsNaN and IsInfinity according to Michael's suggestion. But I think I'll withdraw the patch and replace it with one for a cleaned up typ unit. How about cleaning up also

Re: [fpc-devel] Math and numlib

On Mon, 13 Mar 2017, Werner Pamler wrote: Hi everybody - my first post here... At the moment I am spending some time with fpc's numlib and writing a wrapper for a more versatile fitting procedure. Are there any problems to add the unit math to the uses clause of some numlib units? I want

Re: [fpc-devel] Management operators : Copy and Clone confusion...

On Sat, 21 Jan 2017, Florian Klämpfl wrote: Am 19.01.2017 um 10:44 schrieb Michael Van Canneyt: At the risk of writing nonsense: I would think that a method name should give a clue as to what it actually does. In that sense AddRef/Clone seems better to me ? Even if it is used by types

Re: [fpc-devel] Management operators : Copy and Clone confusion...

On Thu, 19 Jan 2017, Maciej Izak wrote: Hi, in patch/feature proposed in http://bugs.freepascal.org/view.php?id=30687 we have Copy/Clone operators naming convention proposed by Florian (my initial idea was AddRef/Copy). I'd like to say that Copy/Clone naming convention is terrible in

Re: [fpc-devel] FPC 3.0.2rc1 available

On Tue, 27 Dec 2016, Чернов Дмитрий wrote: Guys, excuse me, but I want to remind about new version of the ENet library headers for FPC. http://bugs.freepascal.org/view.php?id=27891 This RC contains old version of these headers, AFAIK. That is on purpose.

Re: [fpc-devel] Improved RTTI compromise

On Wed, 7 Dec 2016, Sven Barth wrote: Am 07.12.2016 13:58 schrieb "Michael Van Canneyt" <mich...@freepascal.org>: On Wed, 7 Dec 2016, Sven Barth wrote: Trying to generate the exact same information as Delphi is IMHO not the right path. What is needed is an AP

Re: [fpc-devel] Improved RTTI compromise

On Wed, 7 Dec 2016, Michael Van Canneyt wrote: On Wed, 7 Dec 2016, Sven Barth wrote: Trying to generate the exact same information as Delphi is IMHO not the right path. What is needed is an API that gives you the info contained in the internal structures. That's what the RTTI unit

Re: [fpc-devel] Improved RTTI compromise

On Wed, 7 Dec 2016, Maciej Izak wrote: 2016-12-07 8:49 GMT+01:00 Michael Van Canneyt <mich...@freepascal.org>: I am not sure this is possible. The structures exposed in the typinfo interfacee mimic the info the compiler generates in the binary. If the compiler generates different inf

Re: [fpc-devel] Improved RTTI compromise

On Wed, 7 Dec 2016, Sven Barth wrote: Trying to generate the exact same information as Delphi is IMHO not the right path. What is needed is an API that gives you the info contained in the internal structures. That's what the RTTI unit is there for. It provides a higher level API to the

Re: [fpc-devel] Improved RTTI compromise

On Tue, 6 Dec 2016, Maciej Izak wrote: 2016-12-06 17:46 GMT+01:00 Michael Van Canneyt <mich...@freepascal.org>: The Delphi TypInfo unit also exposes the attributes. My message was unclear - I mean that we can hide incompatible part of TypInfo. Type TAttributeData is located in T

Re: [fpc-devel] Improved RTTI compromise

On Tue, 6 Dec 2016, Maciej Izak wrote: Hi, I was thinking about extended RTTI, and important RTTI.pas module (good start point with attributes is waiting 3 years). Seems that the only real reason why we don't have yet RTTI.pas in trunk is incompatibility of generated type info (as Jonas

Re: [fpc-devel] Raw ARC objects preview

On Tue, 8 Nov 2016, Jonas Maebe wrote: On 08/11/16 21:44, Maciej Izak wrote: One person from FPC core team suggested me to switch to C++/C# instead of discussing with them. Please quote me correctly. I did not make this suggestion. I said I am surprised that people feel the need to

Re: [fpc-devel] Closures / anonymous methods

On Wed, 26 Oct 2016, Paul van Helden wrote: Specially when they are as invasive as yours. You are in essence converting pascal to a C++ clone with this MO patch. Is it so bad that this is discussed thoroughly first ? +1 for Oxygene mode. An Oxygene mode to me will be like early Christmas

Re: [fpc-devel] Closures / anonymous methods

On Wed, 26 Oct 2016, Maciej Izak wrote: 2016-10-26 11:56 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: As long as it's really a separate mode (plus maybe modeswitches for selected features, that other modes might profit from) I don't see a problem with adding an Oxygen

Re: [fpc-devel] Closures / anonymous methods

On Wed, 26 Oct 2016, Sven Barth wrote: Am 26.10.2016 00:58 schrieb "Maciej Izak" : Many users likes more modern Pascal (for example oxygene mode is also one of NewPascal targets), FPC core team likes more old fashioned Pascal... I do not believe that core team would

Re: [fpc-devel] Closures / anonymous methods

On Tue, 25 Oct 2016, Maciej Izak wrote: Hi, I'd like to take over work on closures/anonymous methods: http://newpascal.org/compass.html (point #5). Patch/hg repository from original author has gone away but I have made copy. My working repository is here:

Re: [fpc-devel] GetLongOpts won't set flag when long option is found

On Mon, 10 Oct 2016, grouchysmurf wrote: Hi. I've been playing with GetLongOpts recently and I *think* I found a bug though this may be as well a required behaviour but I decided to report it anyway. GetLongOpts fails to set a flag even when directly told to so. Consider following

Re: [fpc-devel] Overflow in TMemoryStream?

On Mon, 12 Sep 2016, Michael Van Canneyt wrote: So it looks like a 32 vs. 64 bit issue. from the method Realloc : NewCapacity := (5*FCapacity) div 4; // 5*FCapacity can cause overflow Changing this to NewCapacity:=FCapacity + (FCapacity div 4) Will probably fix the issue. I

Re: [fpc-devel] Overflow in TMemoryStream?

On Sun, 11 Sep 2016, Martok wrote: Hi, yes, I can confirm this as an overflow, but on its own, it should be safe. Above 430MB, the stream doesn't grow by a quarter but just by however much was requested, luckily the branch fails before the wrong capacity could be set. Test: type TMS2 =

Re: [fpc-devel] TBufferedFileStream

On Sun, 4 Sep 2016, José Mejuto wrote: El 04/09/2016 a las 14:04, Michael Van Canneyt escribió: The second powerful reason is that I was not aware about TBufStream :) It's even documented. http://www.freepascal.org/docs-html/current/fcl/bufstream/index.html Hello, Sure :) But I'm

Re: [fpc-devel] TBufferedFileStream

On Sun, 4 Sep 2016, José Mejuto wrote: El 04/09/2016 a las 7:15, Michael Van Canneyt escribió: In the other hand a cache system is powerful than a buffered system if you are writing something like a filesystem over a TFileStream where you may need to jump here and there to read data, file

Re: [fpc-devel] TBufferedFileStream

On Sat, 3 Sep 2016, José Mejuto wrote: El 03/09/2016 a las 22:15, Michael Van Canneyt escribió: Added to the bugtracker implementation of TBufferedFileStream, there is one compatibility issue note in the bug entry. http://bugs.freepascal.org/view.php?id=30549 Nice. I have assigned

Re: [fpc-devel] TBufferedFileStream

On Sat, 3 Sep 2016, José Mejuto wrote: Hello, Added to the bugtracker implementation of TBufferedFileStream, there is one compatibility issue note in the bug entry. http://bugs.freepascal.org/view.php?id=30549 Nice. I have assigned this to myself. Out of curiosity: Why do you think

Re: [fpc-devel] Managed types and reference counts revisited

On Wed, 17 Aug 2016, Adriaan van Os wrote: Thanks for the clarification. I suggest the doc page to be changed accordingly. And also the test program there. And what do you want to see changed ? The test program shows the actual

Re: [fpc-devel] Update of ENet headers

On Wed, 3 Aug 2016, Чернов Дмитрий wrote: Hi again.   Year ago, I've proposed ENet headers, translated to Free Pascal, for adding to the standard distrubution. Recently I updated the headers, details are here: http://bugs.freepascal.org/view.php?id=27891#c93969   It would be nice to see

Re: [fpc-devel] NowUTC in FPC

On Mon, 1 Aug 2016, Denis Kozlov wrote: On 01/08/2016 07:59, Michael Van Canneyt wrote: But that would create duplicated code of LocalTimeToUniversal, UnixToDateTime, IncMilliSecond functions in SysUtils and DateUtils. So what ? It is essentially A+B*C or some variant of that. I try

Re: [fpc-devel] NowUTC in FPC

On Mon, 1 Aug 2016, Denis Kozlov wrote: On 30/07/2016 17:45, Michael Van Canneyt wrote: I don't see why you cannot perform simple additions in sysutils. But that would create duplicated code of LocalTimeToUniversal, UnixToDateTime, IncMilliSecond functions in SysUtils and DateUtils. So

Re: [fpc-devel] NowUTC in FPC

On Sat, 30 Jul 2016, Denis Kozlov wrote: On 30/07/2016 11:10, Michael Van Canneyt wrote: I had a look at it. Please modify the patch first, see comments in bugreport. The reason why I put UniversalTime (a.k.a. NowUTC) function in DateUtils is because of the dependency

Re: [fpc-devel] NowUTC in FPC

On Sat, 30 Jul 2016, Denis Kozlov wrote: Can somebody take a look and apply the patch please? I had a look at it. Please modify the patch first, see comments in bugreport. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, 28 Jul 2016, Maciej Izak wrote: 2016-07-28 16:37 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: Are there additional benefits I have missed ? Using nilable (I think nilable is better than nullable) records is terrible without default field: === code begin ===

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, 28 Jul 2016, Dmitry Boyarintsev wrote: On Thu, Jul 28, 2016 at 10:37 AM, Michael Van Canneyt < mich...@freepascal.org> wrote: [+] Default field (even if it is only syntactic sugar) can-o'worms: Wasn't there a discussion to have multiple default fields depending on th

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, 28 Jul 2016, Maciej Izak wrote: 2016-07-28 14:59 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: Because with the exception of the ^ operator, I see no need for any special constructions to achieve a "nullable type", except maybe some implicit constr

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, 28 Jul 2016, Maciej Izak wrote: 2016-07-28 13:30 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: Assume a is null before the call to test1: test1(a); That won't compile. 1. What happens if this procedure is empty, i.e. no write is performed ? (or it is per

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, 28 Jul 2016, Maciej Izak wrote: 2016-07-28 12:40 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: I don't see how you can solve nullable var parameters in native code. I'd like to present how TNullable works in my implementation (compilable and runable program ;)

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, 28 Jul 2016, Sven Barth wrote: Am 27.07.2016 23:27 schrieb "Jonas Maebe" : Before continuing, I think it would be a good idea to look at what the desired concept is exactly (transparent proxy objects/references, thin wrappers that allow to specify some

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Wed, 27 Jul 2016, Jonas Maebe wrote: On 27/07/16 22:47, Sven Barth wrote: Am 27.07.2016 21:04 schrieb "Maciej Izak" >: In that case SmartPtr/SmartObj/Nullable type has no sense for me. The basic purpose is excluded. You can do that today

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Wed, 27 Jul 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 27 Jul 2016: Why not introduce an address operator ? operator @ (T : MyType) : Pointer; It's only needed because Maciej wants the proxy type to behave differently from all other existing types. The solution

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Wed, 27 Jul 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 27 Jul 2016: On Wed, 27 Jul 2016, Maciej Izak wrote: TNullable = proxy record ... looks good for me, even better than pure record, the context is more clear. Yes. Exactly what Jonas wanted to achieve, I

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Wed, 27 Jul 2016, Maciej Izak wrote: 2016-07-27 13:11 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: Instance: ^T; default; ";" between default and type will not work. Sorry, typo :/ TNullable = proxy record ... looks good for me, even better

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Wed, 27 Jul 2016, Maciej Izak wrote: 3. "default" need to be transparent and usable with existing code base, some compiler magic is part of my further compiler development (I mean here "Storage Modifiers" and ARC objects in DelphiNextgen mode). With current approach is possible to pass

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Tue, 26 Jul 2016, Maciej Izak wrote: Hi, Finally I have a working implementation (not published yet) of Smart Pointers/ARC objects and Nullable (Nilable?) types. I think is worth to discuss a little about new "default modifier" (which is strictly related to mentioned structures). If

Re: [fpc-devel] TJSONDeStreamer can't handle such date format 'yyyy-MM-dd"T"hh:nn:ss"Z"'

On Tue, 19 Jul 2016, Luiz Americo Pereira Camara wrote: 2016-07-19 5:47 GMT-03:00 Michael Van Canneyt <mich...@freepascal.org>: On Tue, 19 Jul 2016, Dimitrios Chr. Ioannidis wrote: Exception class: EAssertionFailedError Exception message: "Correct extended valu

Re: [fpc-devel] TJSONDeStreamer can't handle such date format 'yyyy-MM-dd"T"hh:nn:ss"Z"'

On Tue, 19 Jul 2016, Sven Barth wrote: value" expected: <4,56> but was: <5> Exception class: EAssertionFailedError Exception message: "Correct value" expected: <4,56> but was: <5> at $00434358 TTESTJSONSTREAMER__ASSERTPROP, line 761 of testjsonrtti.pp Failure:

Re: [fpc-devel] TJSONDeStreamer can't handle such date format 'yyyy-MM-dd"T"hh:nn:ss"Z"'

On Tue, 19 Jul 2016, Dimitrios Chr. Ioannidis wrote: On 19/7/2016 10:54 πμ, Michael Van Canneyt wrote: On Mon, 18 Jul 2016, Stéphane Wierzbicki wrote: I have modified TJSONStreamer and TJSONDeStreamer class to handle ISO8601 dates by adding a new jsoDateTimeAsISO8601 option. Where

Re: [fpc-devel] Sven commit (r34087) breaks casting an object to an interface

On Fri, 15 Jul 2016, Maciej Izak wrote: Hi, change in mentioned FPC trunk r34087 totally breaks sparta dockedformeditor package (and probably many other things) see: http://forum.lazarus.freepascal.org/index.php/topic,27211.msg216064.html#msg216064

[fpc-devel] OData and Office365 REST API support

Hello, Long overdue, I have finally committed the initial version of the odata package in the FPC repository. This package provides the base for OData integration in your applications. OData is a standard adopted by the OASIS group: it describes data exchange through REST APIs. OData V4 and

Re: [fpc-devel] overflow error in Fpopendir

On Thu, 30 Jun 2016, Seth Grover wrote: At +123 I can see that $eax/$ebx contains the correct descriptor, 51345. However, when I print $bx in the debugger, it looks like a negative number, as if it had overflowed a signed 2-byte integer, so the function errors out. This causes the file

Re: [fpc-devel] fpc svn trunk building fails

On Sun, 5 Jun 2016, Karoly Balogh (Charlie/SGR) wrote: Hi, On Sun, 5 Jun 2016, Sandro Cumerlato wrote: fpc svn trunk version 33910 building fails with error: *..snip..* Compiling .\fcl-db\src\export\fpxmlxsdexport.pp Compiling .\fcl-db\src\sqldb\interbase\fbadmin.pp The

Re: [fpc-devel] FPC 3.0.2 release target

On Mon, 30 May 2016, Maciej Izak wrote: 2016-05-30 15:40 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: This is not an argument. Yes this is not an argument but reality. It blocks a lot of code. Certainly. I suffer from it myself from time to time, but such i

Re: [fpc-devel] FPC 3.0.2 release target

On Mon, 30 May 2016, Maciej Izak wrote: 2016-05-30 14:41 GMT+02:00 Sven Barth : Let me first finish the packages stuff as that will lead to a breaking change in the RTTI binary format (PPTypeInfo instead of PTypeInfo, necessary due to Windows' PE format) and I

Re: [fpc-devel] FPC 3.0.2 release target

On Mon, 30 May 2016, tha...@thaddy.com wrote: New feature. Belongs in 3.1.1. And the implementation is contested, which is the reason why it doesn't get merged to trunk. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] FPC 3.0.2 release target

On Sun, 29 May 2016, Ondrej Pokorny wrote: On 29.05.2016 10:33, Michael Van Canneyt wrote: We're set to create the branch at the end of May, which is about now. The last merges have been performed. I assume Marco will tag somewhere this week, and then building starts. Great! Do you have

Re: [fpc-devel] FPC 3.0.2 release target

On Sun, 29 May 2016, Juha Manninen wrote: Is there any estimate for FPC 3.0.2 release? FPC 3.0.0 was released already at November 26, over half a year ago. Fixes branches of both FPC and Lazarus have lots of important commits. Lazarus 1.6.2 + FPC 3.0.2 would make a nice and solid combination.

Re: [fpc-devel] SysUtils.GetEnvironmentVariable(String) still uses GetEnvironmentVariableA

On Mon, 23 May 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Mon, 23 May 2016: The typecase will not help you, since the result is an ansistring. The result will still be crippled. It would help when DefaultSystemCodePage is changed to UTF-8, as Lazarus does. Should

Re: [fpc-devel] SysUtils.GetEnvironmentVariable(String) still uses GetEnvironmentVariableA

The typecase will not help you, since the result is an ansistring. The result will still be crippled. The only solution for this is a unicode RTL. Michael. On Mon, 23 May 2016, Denis Kozlov wrote: P.S. A minor typo, GetEnvironmentVariableA should read GetEnvironmentStringsA. On 23 May

Re: [fpc-devel] Split advancedipc and advancedsingleinstance

On Tue, 10 May 2016, Luiz Americo Pereira Camara wrote: Hi, I'm looking for a ipc to send log messages between processes. Advancedipc recently added to trunk seems to do the job. I noticed that TAdvancedSingleInstance lives in the same unit as the ipc classes Any chance to split

Re: [fpc-devel] Management operators AddRef and Copy vs Copy

On Mon, 25 Apr 2016, Maciej Izak wrote: Finally I've decided to use Clone and Copy (as proposed by Florian). Should I adjust RTL inner functions to this? I mean renaming FPC_COPY to FPC_CLONE and FPC_ADDREF to FPC_COPY. Are these the assembler names of existing functions ? If so, the

Re: [fpc-devel] HPack for HTTP2

On Sun, 24 Apr 2016, José Mejuto wrote: Hello, Added entry in the bug tracker for HPack implementation for http2. http://bugs.freepascal.org/view.php?id=30058 If somebody whats to add it somewhere in fpc/fcl code base. It is based in Twitter's HPack Java implementation. It includes

Re: [fpc-devel] FPC implementation of attributes for language parts.

On Wed, 13 Apr 2016, Maciej Izak wrote: 2016-04-13 14:36 GMT+02:00 Sven Barth : *I* won't add it. I can do it after merging Joost's class attributes branch. No one really won't this but it is the must. IFDEF hell is much more visible for "constref/[ref] const"

Re: [fpc-devel] FPC implementation of attributes for language parts.

On Wed, 13 Apr 2016, Maciej Izak wrote: 2016-04-13 13:03 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: Sorry. This is simply very bad design. I agree with many points. Frankly, I was surprised that they did something like using attributes in that way. I try to unde

Re: [fpc-devel] FPC implementation of attributes for language parts.

On Wed, 13 Apr 2016, Maciej Izak wrote: Moved from: "Initialize/Finalize management operators and Default intrinsic". I'd like to keep Initialize/Finalize topic more clear ;P Small introduction: for selected language elements in Delphi is possible to use attributes. For example in Delphi we

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

On Tue, 12 Apr 2016, Maciej Izak wrote: 2016-04-12 15:33 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: Quite strange, Joost claimed the exact opposite :-) Maybe different approach than in Delphi, or I miss something. But as far as I can see, there is something like that:

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

On Tue, 12 Apr 2016, Maciej Izak wrote: 2016-04-12 14:48 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: I really don't think you should delegate such things to attributes. You make 2 completely unrelated language constructs suddenly related. A bad design decision. I thi

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

On Tue, 12 Apr 2016, Maciej Izak wrote: 2016-04-12 15:06 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: Attributes do not need Invoke ? Of course they need Invoke. When TRttiContext.GetType(TMyClassWithAttributes) is executed, deep inside GetType is executed constructor fo

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

On Tue, 12 Apr 2016, Maciej Izak wrote: 2016-04-12 14:33 GMT+02:00 Sven Barth : [Note: this is less a "I don't want it", but a "I don't like it"] phew! Note: these attributes are on my TODO list. Please don't do anything attribute related until I've merged

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

On Tue, 12 Apr 2016, Sven Barth wrote: Am 12.04.2016 12:01 schrieb "Maciej Izak" : another way is to introduce attributes for selected language elements in Delphi compatible way. For example in Delphi we have: TCustomAttribute = class(TObject) end; WeakAttribute

Re: [fpc-devel] Unicode paths

On Tue, 12 Apr 2016, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: I guess the only way, as always, is to have two duplicate systems on windows. One wide that is for unicode, (unicodestring paramstr and D2009 compatible tapplication), one for old legacy ansi

Re: [fpc-devel] Unicode paths

On Tue, 12 Apr 2016, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: They are not supported, because we get the original command line data using the ansi version of the API call (see setup_arguments() in rtl/win/syswin.inc). If this is "fixed", then we also have to

Re: [fpc-devel] FPC 3.0.2 release target

On Mon, 11 Apr 2016, Ondrej Pokorny wrote: What are the plans on releasing 3.0.2? We'd like to release Lazarus 1.6.2 - it would be good if it was released with FPC 3.0.2 because of the Currency bug. I also think so, we've already been merging the necessary fixes to fixes_3_x Now we need

Re: [fpc-devel] Unicode paths

On Mon, 11 Apr 2016, Mattias Gaertner wrote: Hi, Are there any plans to extend FPC to support Unicode file paths under Windows? Of course this also means the other tools, like fpcres, fpmake and fppkg. Would this require a new flag? The rtl already support this. But none of the tools

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On Sat, 26 Mar 2016, C Western wrote: On 26/03/16 09:19, Michael Van Canneyt wrote: I have implemented a new property TStringsSortStyle = (sslNone,sslUser,sslAuto); Property SortStyle : TStringsSortStyle Read FSortStyle Write SetSortStyle; I assume the meaning is clear. - Sorted

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On Tue, 22 Mar 2016, David Jenkins wrote: On 3/22/16 10:48 AM, Michael Van Canneyt wrote: On Tue, 22 Mar 2016, David Jenkins wrote: No one here holds Delphi up on a pedestal - least of all me. My viewpoint is completely practical/funcitonal - I have to make our code base work

Re: [fpc-devel] Bug #29037 StrToCurr raises exception for MinCurrency value on Win64

On Thu, 24 Mar 2016, LacaK wrote: Hi *, can somebody please look at bug report #29037 and attached patch there ? I am on it. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On Tue, 22 Mar 2016, Denis Kozlov wrote: On 22/03/2016 17:56, Michael Van Canneyt wrote: or better something concise like ltAuto,ltUser,ltNone. It may make more sense to call it ListSortType (as opposed to ListType): TListSortType = (lstNone, lstAuto, lstManual); I went

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On Tue, 22 Mar 2016, Michael Van Canneyt wrote: On Tue, 22 Mar 2016, Jonas Maebe wrote: Michael Van Canneyt wrote: On Tue, 22 Mar 2016, David Jenkins wrote: or have a ListType property that is ltAutoSort, ltNaturalSort, ltNone I think this idea is probably the best alternative. I

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On Tue, 22 Mar 2016, Jonas Maebe wrote: Michael Van Canneyt wrote: On Tue, 22 Mar 2016, David Jenkins wrote: or have a ListType property that is ltAutoSort, ltNaturalSort, ltNone I think this idea is probably the best alternative. I don't think "natural sort" is a good nam

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On Tue, 22 Mar 2016, David Jenkins wrote: or have a ListType property that is ltAutoSort, ltNaturalSort, ltNone I think this idea is probably the best alternative. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On Tue, 22 Mar 2016, David Jenkins wrote: No one here holds Delphi up on a pedestal - least of all me. My viewpoint is completely practical/funcitonal - I have to make our code base work with FPC/LCL and VCL. Given the way we use find functionality (with a mixture of naturally sorted and

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On Tue, 22 Mar 2016, David Jenkins wrote: On 3/22/16 2:01 AM, Michael Van Canneyt wrote: But you agree that if Find is called on an unsorted list, bogus data will be returned ? Or, worse, an never-ending loop may occur ? In short, as you say, an "error condition" can ensue w

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On Mon, 21 Mar 2016, David Jenkins wrote: I understand the need for the list to be sorted and agree that calling find on an unsorted list is an error condition. I am not convinced that current change deals with that well. For one, the Sorted flag and actual state of the list are not

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On Mon, 21 Mar 2016, David Jenkins wrote: On 3/21/16 2:55 PM, Michael Van Canneyt wrote: We can introduce a property which disables the check, if you want. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On Mon, 21 Mar 2016, David Jenkins wrote: I just ran across the change that checks Sorted at beginning of find and exits if Sorted = False. This has caused some problems for us a) We have lists that are sorted manually and we'd like to continue keeping them sorted manually (and be able

Re: [fpc-devel] Feature announcement: Record management operators

On Mon, 21 Mar 2016, Maciej Izak wrote: 2016-03-21 14:28 GMT+01:00 Sven Barth : The RTL *must* be compileable with the latest release. You need to use ifdefs to ensure that. If a "make all" at the top level with a FPC 3.0.0 does not work then your branch won't

Re: [fpc-devel] Implementing SHA256 Unit.

On Sun, 20 Mar 2016, Jy V wrote: On Sun, Mar 20, 2016 at 1:10 PM, Garry Wood wrote: Yes, the intent is to support https with TLS 1.0/1.1/1.2 so AES_128_GCM_SHA256 will be included in the cipher suite. Pure FreePascal code only ? no dependency with OpenSSL (or third

Re: [fpc-devel] Implementing SHA256 Unit.

On Sun, 20 Mar 2016, Garry Wood wrote: I'm trying to write a sha256 implementation in pure pascal like sha1 and md5 units. With negative results. Someone can helpme with this? I recently ported the implementation from LibTimCrypt / wpa_supplicant (which are both from public domain

Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64

On Thu, 10 Mar 2016, Sven Barth wrote: Am 10.03.2016 18:02 schrieb "Yury Sidorov" : On 3/10/2016 1:06 PM, Jy V wrote: This happens only on Win64 with FPC 3.0 Can somebody please check and confirm ? compiled with official Lazarus 1.6 (SVN revision as displayed

Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64

On Thu, 10 Mar 2016, LacaK wrote: This happens only on Win64 with FPC 3.0 Can somebody please check and confirm ? compiled with official Lazarus 1.6 (SVN revision as displayed in the about box: 51630) console output of your program is: 1.234500E+02*

Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64

On Thu, 10 Mar 2016, LacaK wrote: Hi, investigating bug #29760 I reduced bug to: var c: currency; d: double; begin c := 123.45; d := 100; writeln(c, '*', d, '=', c*d); // result of multiply is wrong = 12345 end. This happens only on Win64 with FPC 3.0 Can somebody please check

Re: [fpc-devel] Are LazUtils - XML units still necessary ?

On Thu, 10 Mar 2016, Mattias Gaertner wrote: On Wed, 9 Mar 2016 20:35:52 -0300 Daniel Gaspary wrote: Since FPC 3.00 has a new Unicode support I was wondering about that. AFAIK, support to Unicode(Or only UTF8?) was the main reason to the existence of the units

Re: [fpc-devel] The (near) future of strings

On Mon, 7 Mar 2016, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: /usr/local/lib/fpc/4.0.0/x86_64-linux/dotted/XYZ But only one is referenced in fpc.cfg : #IFDEF NAMESPACED /usr/local/lib/fpc/4.0.0/x86_64-linux/dotted/XYZ #ELSE /usr/local/lib/fpc/4.0.0/x86_64

Re: [fpc-devel] The (near) future of strings

On Mon, 7 Mar 2016, Florian Klämpfl wrote: I hope somebody implements this in fpmake :) My "subarch" directory approach needed by several targets is already on hold for years as I do not owe to touch fpmake regarding this. I don't understand why ? Why would you not touch fpmake for this

Re: [fpc-devel] The (near) future of strings

On Mon, 7 Mar 2016, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: However in Michael's scheme with Sysutils using Ansi and System.Sysutils using unicodestring this will fail. Why would this fail ? All we need to do is introduce -NS ? If you have a mix

<    2   3   4   5   6   7   8   9   10   11   >