Re: [fpc-devel] Case of string

On Fri, Apr 27, 2018 at 4:29 AM, Bart wrote: > Hi, > > With 3.0.4 when the inout is 'qwerty' the output is 'In 'a'..'z'. > > In trunk (r37889) the output will be: > 'In Hello' for 'Hello' and 'Hello2' > 'In 'a'..'z' only when the inout is 'a' > 'In else' for every other

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

On Thu, Apr 5, 2018 at 10:24 AM, Michael Van Canneyt wrote: > > You explained exactly why I think the delphi docs are wrong. > > If delphi wanted to do things correctly and consistently they would simply > say 'everything is initialized to 0'. Period. > > Simple,

Re: [fpc-devel] Pass compiler options to generics [was Delphi anonymous methods]

On Wed, Mar 6, 2013 at 10:00 PM, Michael Schnell mschn...@lumino.de wrote: On 03/05/2013 05:17 PM, Alexander Klenin wrote: 1) Make sure is and as work with generic types -- maybe they already are? is the generic type and/or is a certain specialization ? Yes, and also generic parameters

Re: [fpc-devel] Delphi anonymous methods

On Tue, Mar 5, 2013 at 9:10 PM, Paul Ishenin paul.ishe...@gmail.com wrote: 05.03.13, 17:55, Sven Barth wrote: I see you, Graeme, Michael and probably some more 5-6 developers. The level of Delphi compatibility vs. syntax quality is, as always in engineering, a matter of compromise and

Re: [fpc-devel] Delphi anonymous methods

On Tue, Mar 5, 2013 at 10:24 PM, Marco van de Voort mar...@stack.nl wrote: Just to say one thing clear: I will NOT drop FPC's generic implementation and I'll revert every commit that tries to do so, because not only do we have to keep backwards compatibility, but the Delphi syntax is a

Re: [fpc-devel] Delphi anonymous methods

On Wed, Mar 6, 2013 at 12:16 AM, Sven Barth pascaldra...@googlemail.com wrote: SomeVar := SomeFuncSomething - SomeTypeSomething.SomeMethod * SomeOtherTypeSomething.SomeMethodSomething; === example end === while this will be much easier to implement: === example begin === SomeVar :=

Re: [fpc-devel] Delphi anonymous methods

On Wed, Mar 6, 2013 at 12:27 AM, Sven Barth pascaldra...@googlemail.com wrote: I don't know why the one who first implemented them chose them, but now the reason is backwards compatibility. Please note that I wouldn't have choosen round brackets either (potential conflicts with type casting)

Re: [fpc-devel] Pass compiler options to generics [was Delphi anonymous methods]

On Tue, Mar 5, 2013 at 11:13 PM, ListMember listmem...@letterboxes.org wrote: This brings me to wonder if it would be possible to pass some constant (or set of constants, or something similar) to generic routine such that this/these option(s) would be treated as compiles options within the

Re: [fpc-devel] Delphi anonymous methods

On Mon, Mar 4, 2013 at 10:35 PM, Martin laza...@mfriebe.de wrote: On 04/03/2013 06:06, Boian Mitov wrote: It may be a good idea to analyze the current Delphi implementation. In essence the anonymous method expands to a class and interface. The interface Execute method has the parameters of

Re: [fpc-devel] Delphi anonymous methods

On Mon, Mar 4, 2013 at 10:34 PM, Martin laza...@mfriebe.de wrote: Nevertheless, I agree what the implementation plan can be detailed even further: 1) Anonymous procedures *without* closures -- basically, just another syntax for nested procedures. That might be interested for mode Delphi No,

Re: [fpc-devel] Delphi anonymous methods

On Tue, Mar 5, 2013 at 1:28 AM, Michael Van Canneyt mich...@freepascal.org wrote: Pascal is declarative, Please... no, Pascal is not declarative, and we have establised that fact just about two weeks ago. not functional. Trying to import elements from the second into the first is misguided.

Re: [fpc-devel] Delphi anonymous methods

On Tue, Mar 5, 2013 at 1:49 AM, Sven Barth pascaldra...@googlemail.com wrote: The use of as is based on an idea of mine. C# for example has = and Oxygene has - which I didn't consider much Pascal like. Also the compiler needs to know the type of the lambda so it can correctly typecheck its code

Re: [fpc-devel] Delphi anonymous methods

On Tue, Mar 5, 2013 at 2:10 AM, Martin laza...@mfriebe.de wrote: First: Stressing out: I don't like it. But if we must have one, the lambda approach is the best one yet. Reason: At least the type is declared at a pascal-like location. I certainly agree that it is subjective in the sense that

Re: [fpc-devel] Delphi anonymous methods

On Tue, Mar 5, 2013 at 3:34 AM, Martin laza...@mfriebe.de wrote: On 04/03/2013 16:05, Alexander Klenin wrote: Anonymous functions (with good syntax, of course) fall in this category. The world recognized that fact -- rather slowly, to be sure, but remember that whiles and fors also took

Re: [fpc-devel] Delphi anonymous methods

On Sun, Mar 3, 2013 at 11:21 PM, Sven Barth pascaldra...@googlemail.com wrote: This will also help to split implementation. 1. Implement Sven's proposal. Anonymous functions which can capture local variables only by value. 2. Create Delphi-compatible capturing by reference. 3. Discuss and

Re: [fpc-devel] Delphi anonymous methods

On Mon, Mar 4, 2013 at 11:15 AM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: From what I can see, anonymous methods are just like the above code... allowing a declaration of a procedure/method in-line inside a code block where in shouldn't belong. It is very, very un-Pascal like. Because

Re: [fpc-devel] Delphi anonymous methods

On Mon, Mar 4, 2013 at 4:06 PM, Boian Mitov mi...@mitov.com wrote: Here is another even simpler example: AItem := GComponentEditorList.Find( function( AItem : IComponentEditorItem ) : Boolean begin Result := ( AComponent is

Re: [fpc-devel] Delphi anonymous methods

On Mon, Mar 4, 2013 at 2:38 PM, Martin laza...@mfriebe.de wrote: Closures, do not need to be written/declared in the middle of other code (in-line) Strictly speaking, they do not. However, if the closures are required to be named, their expressive power and readability will suffer greatly.

Re: [fpc-devel] Feature announcement: Type helpers

On Wed, Feb 6, 2013 at 10:31 PM, Michael Schnell mschn...@lumino.de wrote: point.x := x; point.y := y; s := point.ToString; or s := (x,y).ToString; Has there not recently been a discussion on Tupels ?!?!?! :-) At least according to my proposal, tuples will not be a type, so

Re: [fpc-devel] Testsuite database

On Sat, Feb 2, 2013 at 7:42 PM, Nikolai Zhubr n-a-zh...@yandex.ru wrote: Apparently the test suite database needs some love? Wow, I did not even know such a thing existed! How is it populated? -- Alexander S. Klenin ___ fpc-devel maillist -

Re: [fpc-devel] for-in-index loop

On Tue, Jan 29, 2013 at 12:39 AM, Paul Ishenin paul.ishe...@gmail.com wrote: I would use anonymouse methods in pascal - I use them in javascript when I need to perform something asynchronosly. Since you can do the same with simple named methods too, I see no need for creating the readibility

Re: [fpc-devel] RFC: Support for new type tuple v0.1

On Mon, Jan 28, 2013 at 7:25 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Consider these examples: var x, y, z: Integer; pt: TPoint; ... (x, y) // record a, b: Integer; end; (x, (y))// record a, b: Integer; end; (x, (y, z))

Re: [fpc-devel] RFC: Support for new type tuple v0.1

On Sun, Jan 27, 2013 at 12:35 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: (a, b) := (b, a); // the compiler needs to ensure the correct usage of temps here! What will happen here? At compile time a tuple type (integer; integer) has to be defined, and an instance must be

Re: [fpc-devel] RFC: Support for new type tuple v0.1

On Sun, Jan 27, 2013 at 10:10 PM, Michael Van Canneyt mich...@freepascal.org wrote: 2.1) Tuples are always temporary and anonymous. You can not store a tuple, define tuple type, of variable of tuple type. So tuples are 100% static, compile-time feature -- no change to RTTI, variants etc. No.

Re: [fpc-devel] RFC: Support for new type tuple v0.1

On Mon, Jan 28, 2013 at 1:26 AM, Paul Ishenin paul.ishe...@gmail.com wrote: 27.01.13, 1:43, Sven Barth wrote: Based on the results of the for-in-index thread I've decided to come up with a draft for the Tuple type which is thought by many people to be a better alternative to for-in-index. I

Re: [fpc-devel] RFC: Support for new type tuple v0.1

On Mon, Jan 28, 2013 at 1:38 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: you no longer have a tuple type, but rather a deconstruct_into_component_types() type conversion operator along with anonymous records. Yes, this is quite close to what I wanted to propose. I am glad someone has

Re: [fpc-devel] RFC: Support for new type tuple v0.1

On Mon, Jan 28, 2013 at 2:01 AM, Martin laza...@mfriebe.de wrote: Of course. But note that in this thread, many more uses of tuples (which I do NOT want to make a type -- see my previous mail for lengthy explanation why). Some of the uses are: record and array constructors, adaptation of

Re: [fpc-devel] RFC: Support for new type tuple v0.1

On Mon, Jan 28, 2013 at 2:59 AM, Michael Van Canneyt mich...@freepascal.org wrote: On Mon, 28 Jan 2013, Alexander Klenin wrote: I have a compromise suggestion: Implement for-index extension with the syntax: for (k, v) in a do this syntax is forward-compatible with both tuples proposals

Re: [fpc-devel] RFC: Support for new type tuple v0.1

On Mon, Jan 28, 2013 at 4:19 AM, Michael Van Canneyt mich...@freepascal.org wrote: Define an iterator type/operator. - No interface - No 'specially named function' in the class. The iterator should be separate from the class. Now they promoted 1 function with a special name to a special

Re: [fpc-devel] RFC: Support for new type tuple v0.1

On Mon, Jan 28, 2013 at 4:46 AM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Preface: In the following I assume that tuples can be implemented by records. The proposed syntax extensions can be applied to records as well, they are not restricted to a new type. Ok, with a few caveats listed

Re: [fpc-devel] for-in-index loop

On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth pascaldra...@googlemail.com wrote: Generics was implemented without my knowledge. I only found out when suddenly the classes unit had been changed to use them. After a horrible discussion, this was reversed, because of the drop in speed you got when

Re: [fpc-devel] for-in-index loop

On Sat, Jan 26, 2013 at 10:34 PM, Michael Van Canneyt mich...@freepascal.org wrote: But if I must choose between for a,b in c do (with C a tuple enumerator/iterator) or for a in c index b do Then the former is ten times (well, a lot) better. So if someone were to introduce that to solve

Re: [fpc-devel] for-in-index loop

On Sat, Jan 26, 2013 at 10:58 PM, Sven Barth pascaldra...@googlemail.com wrote: I mean less the implementation specific details, but more the syntax they chose: === example begin === TTestTuple = tuple of (Integer, String, TObject); var t: TTestTuple; i: Integer; s: String; o:

Re: [fpc-devel] for-in-index loop

On Sat, Jan 26, 2013 at 3:14 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Alexander Klenin schrieb: 2) Indeed, introducing tuples to Pascal might be an alternative solution. Below is a proposal: 2.1) Tuple definition. Tuple is an anonymous list of values, possibly of different types

Re: Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)

On Sun, Jan 27, 2013 at 12:26 AM, Paul Ishenin paul.ishe...@gmail.com wrote: 26.01.13, 6:57, Alexander Klenin пишет: Why to invent a new solution if Delphi already have one: http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/anonymousmethods_xml.html

Re: Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)

On Sun, Jan 27, 2013 at 1:59 AM, kyan alfasud...@gmail.com wrote: I assume this is because anonymous functions are not plain methods. Thus they are not compatible with TMethod (the type behind procedure/function of object). They are instead based on a different (internal) type. Please take a

Re: [fpc-devel] for-in-index loop

On Sun, Jan 27, 2013 at 1:05 AM, Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk wrote: Sven Barth wrote: Some way of extending a single value to fill a tuple where all the elements are of the same type would be useful, note that I'm not suggesting any other relaxation of type checking.

Re: Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)

On Sun, Jan 27, 2013 at 3:10 AM, Sven Barth pascaldra...@googlemail.com wrote: On 26.01.2013 16:34, Alexander Klenin wrote: Ok, then let's take just one step back: SomeProc(lambda TProc1 as Writeln(aArg)); This way, but problems are solved -- procedure type is specified independently from

Re: [fpc-devel] RFC: Support for new type tuple v0.1

On Sun, Jan 27, 2013 at 8:40 AM, Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk wrote: If you can't define a tuple type then you can't check that it's assignment-compatible with e.g. an array. I do not see a link here. 2.2) Tuples construction: after some thinking, I propose to define a

Re: [fpc-devel] RFC: Support for new type tuple v0.1

On Sun, Jan 27, 2013 at 12:11 PM, Alexander Klenin kle...@gmail.com wrote: Nothin useful is gained by abbing extra pair of brackets. Sorry, I mean Nothing useful is gained by adding ... -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel

Re: [fpc-devel] for-in-index loop

On Fri, Jan 25, 2013 at 7:07 PM, Michael Van Canneyt mich...@freepascal.org wrote: WITH EACH ADDITIONAL FEATURE WE ARE BUTCHERING PASCAL MORE AND MORE. Hm... Do not you think this is a bit of an overstatement? There are plenty to choose from. He said maybe he'd look after fcl-stl. The silence

Re: [fpc-devel] for-in-index loop

On Sat, Jan 26, 2013 at 4:38 AM, Michael Van Canneyt mich...@freepascal.org wrote: WITH EACH ADDITIONAL FEATURE WE ARE BUTCHERING PASCAL MORE AND MORE. Hm... Do not you think this is a bit of an overstatement? No, not really. I really feel that we are deviating a lot from what pascal stands

Re: [fpc-devel] for-in-index loop

On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl flor...@freepascal.org wrote: Am 25.01.2013 18:17, schrieb Alexander Klenin: Using indicies is against all principles of iterators. I am not sure what princilpes you are talking about, The theory of iterators. You mean Alexander Stepanov's

Re: [fpc-devel] for-in-index loop

On Sat, Jan 26, 2013 at 6:59 AM, Sven Barth pascaldra...@googlemail.com wrote: What is concrete code? The code I provided only missed loop bodies. I can provide that too, but I do not think it will add anything to the discussion. I believe he wants to have real world examples (of other

Re: [fpc-devel] for-in-index loop

On Sat, Jan 26, 2013 at 7:10 AM, Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk wrote: However, I'd suggest that there are two possible category of extension: those that implement a clearly-delimited first-class object with interesting properties, and those that don't. Something like a

Re: [fpc-devel] for-in-index loop

On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl flor...@freepascal.org wrote: Where? Concrete code of a serious language! Not some oh, yes, this language has it and that as well On Sat, Jan 26, 2013 at 7:34 AM, Florian Klämpfl flor...@freepascal.org wrote: No. I want to see a language which

Re: [fpc-devel] for-in-index loop

On Sat, Jan 26, 2013 at 8:54 AM, Florian Klämpfl flor...@freepascal.org wrote: Maybe I wouldn't have to ask if there would be a clear proposal what shall be implemented, what are alternatives, what do other languages, why is a so strange approach chosen etc. I agree that the quality of initial

Re: [fpc-devel] for-in-index loop

On Sat, Jan 26, 2013 at 9:31 AM, Sven Barth pascaldra...@googlemail.com wrote: After implementing support for Delphi style generics I came to the conclusion that I would have preferred the following syntax: type TFPGListLongInt = specialize TFPGList as (Integer); or type

Anonymous procedures (Was: Re: [fpc-devel] for-in-index loop)

On Sat, Jan 26, 2013 at 5:17 AM, Sven Barth pascaldra...@googlemail.com wrote: One could also do an alternative (though currently not with arrays, but with type helper support even that would be possible...): Yes, this is certainly the most interesting alternative. Actually, anonymous

Re: [fpc-devel] for-in-index loop

On Sat, Jan 26, 2013 at 9:50 AM, Marco van de Voort mar...@stack.nl wrote: Whatever the particular syntax, I do agree that the decision to use angular brackets was unnecessarily copied from C++ -- round ones (or, at least, square ones) would be much better. Delphi got its generics from .NET.

Re: [fpc-devel] for-in-index loop

On Fri, Jan 25, 2013 at 4:45 AM, Michael Van Canneyt mich...@freepascal.org wrote: Enumerators are not iterators. Eh... actually, they are? Why do you think otherwise? If you want a full-fledged iterator, you should use classes. Enumerators *are* classes, except for built-in ones. The for

Re: [fpc-devel] for-in-index loop

On Fri, Jan 25, 2013 at 7:18 AM, Jeppe Græsdal Johansen jjoha...@student.aau.dk wrote: I think the idea is good if the feature is implemented as optional. That way: - If the enumerator class implements a CurrentIndex method then the for loop can have an index variable. - If not then the for

Re: [fpc-devel] for-in-index loop

On Fri, Jan 25, 2013 at 7:30 AM, Florian Klämpfl flor...@freepascal.org wrote: Am 24.01.2013 20:36, schrieb Alexander Klenin: That's debatable. As long as there is only some few line idea, there cannot debated much. It is more: an idea with implementation and tests ;) Just an example: what

Re: [fpc-devel] for-in-index loop

On Fri, Jan 25, 2013 at 7:34 AM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Florian Kl?mpfl said: As long as there is only some few line idea, there cannot debated much. http://www.freepascal.org/faq.var#extensionselect Yes, current discussion is based on that

Re: [fpc-devel] for-in-index loop

On Fri, Jan 25, 2013 at 8:44 AM, Florian Klämpfl flor...@freepascal.org wrote: Am 24.01.2013 22:26, schrieb Alexander Klenin: in all three cases, the effect will be more-or-less the same. In the first two cases the programmer knows that he does something strange, actually he can even adjust i

Re: [fpc-devel] for-in-index loop

On Fri, Jan 25, 2013 at 9:36 AM, Michael Van Canneyt mich...@freepascal.org wrote: If you want full fledged iterators, use classes. Please provide example of your suggestion for the case in the wiki. I don't need to provide *anything*. Of course you do not, this is why I said please :)

Re: [fpc-devel] for-in-index loop

On Fri, Jan 25, 2013 at 10:13 AM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: On 01/24/13 19:36, Alexander Klenin wrote: Enumerators are not iterators. Eh... actually, they are? Why do you think otherwise? Enumerators are limited in functionality. Iterators are the full-blown thing

Re: [fpc-devel] for-in-index loop

On Fri, Jan 25, 2013 at 10:38 AM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: On 01/24/13 23:26, Alexander Klenin wrote: If you want full fledged iterators, use classes. Please provide example of your suggestion for the case in the wiki. I don't need to provide *anything*. Of course

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

On Thu, Dec 6, 2012 at 8:29 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: If a major problem is really the lack of standard support for arbitrary-precision arithmetic, does that not mean that C and C++ are no longer serious options either? Actually, this is considered a drawback of C++

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

On Thu, Dec 6, 2012 at 2:16 PM, Nikolay Nikolov nick...@users.sourceforge.net wrote: Just to make it clear how these people usually think, I was part of the IOI2009 technical committee and I was responsible for setting up the pascal environment (fpc lazarus under ubuntu) to work. In that year,

[fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

In my ongoing efforts to prevent elimination of Pascal/FPC from a set of languages used to teach programming, I have recently encountered another problem: although FPC does include gmp unit for arbitrary-precision calculations, programs compiled with it require gmp dynamic library. This library

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

On Sun, Dec 2, 2012 at 2:02 PM, Sven Barth pascaldra...@googlemail.com wrote: We can not bundle such libaries as different (Linux) distributions will have different dependencies like different versions of the libc and then this library would not load anyway (and Free Pascal would be accused for

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

On Sun, Dec 2, 2012 at 2:08 PM, Michael Van Canneyt mich...@freepascal.org wrote: That is a bit of a difficult one. gmp just provides just the interface of an external library. If we do it fo this one, we should do it for all the libraries for which we provide headers. For marketing

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

On Sun, Dec 2, 2012 at 2:42 PM, Michael Van Canneyt mich...@freepascal.org wrote: Writing high-quality arbitrary precision arithmetics is hard. The fact that Free Pascal uses GMP instead of homegrown solution has actually earned some praise. Define homegown ? GMP most likely also is

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

On Sun, Dec 2, 2012 at 4:52 PM, Tomas Hajny xhaj...@hajny.biz wrote: As for fairness, the usual argument is just solve problems in Java/Python, which is exactly what I am trying to prevent :) Who defines what is the right file to choose if there are multiple options? I am not sure which

Re: [fpc-devel] Unhelpful error message

On Sun, Dec 2, 2012 at 6:21 PM, Sven Barth pascaldra...@googlemail.com wrote: On 02.12.2012 13:11, Henry Vermaak wrote: Yes, and are converted in scanner stage to shl and shr which will give me headaches once I want to support nested specializations (basically the same problem that C++ had):

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

On Sun, Dec 2, 2012 at 9:47 PM, Tomas Hajny xhaj...@hajny.biz wrote: On 2 Dec 12, at 16:45, Alexander Klenin wrote: I am not sure which options do you mean, I refer to the dll mentioned here: http://wiki.freepascal.org/gmp I meant multiple 2.6.2 installers (in particular, if we

Re: [fpc-devel] Are global variables guaranteed to be zero?

On Wed, Nov 28, 2012 at 2:29 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: Will global variables and static global arrays be always initialized to zero? Yes. Then I suggest to amend the first paragraph of http://www.freepascal.org/docs-html/ref/refse22.html which directly contradicts

[fpc-devel] Are global variables guaranteed to be zero?

Will global variables and static global arrays be always initialized to zero? It seems that they in fact are, and there is quite a lot of code relying on it. On the other hand, the documentation denies that. What is the official position? -- Alexander S. Klenin

Re: [fpc-devel] enums and integer auto conversion

On Tue, Sep 11, 2012 at 8:03 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: If you want to do that, you need to add a layer in between that converts the sets into integer bitmasks in a reliable, portable and future-proof way. How about packed sets? Do they have well-defined memory layout?

Re: [fpc-devel] Parallel procedures

On Fri, Jun 15, 2012 at 9:39 AM, Mattias Gaertner nc-gaert...@netcologne.de wrote: What do you think? Why not -- although IMO it would be much better to have some lagnuage-level support for things like single-owner semantics. Independenty, it seems that the unit should be updated to support is

Re: [fpc-devel] Scalar value is accepted as an argument for anopenarray parameter

On Mon, Jun 11, 2012 at 9:03 AM, Skybuck Flying skybuck2...@hotmail.com wrote: Unfortunately Delphi (6) accepts this too. It took me some time at work Delphi XE2 does not ;) Delphi XE does not accept constants either, but scalar variables. So the following compiles: Given the above, I

[fpc-devel] Scalar value is accepted as an argument for an open array parameter

The following code compiles both with : procedure F(const A: array of ShortInt); begin end; begin F(1); end. I think this is a bug in FPC, but if not -- it should be documented here: http://freepascal.org/docs-html/ref/refsu59.html#x157-16700014.4.5 I am willing to file an issue one way or

Re: [fpc-devel] Scalar value is accepted as an argument for an open array parameter

On Fri, Jun 8, 2012 at 6:08 PM, Marc Weustink m...@dommelstein.net wrote: Unfortunately Delphi (6) accepts this too. It took me some time at work to figure out why some code suddenly behaved weird. (I changed a integer argument to array of integer and assumed the compiler would help me to find

Re: [fpc-devel] Scalar value is accepted as an argument for an open array parameter

On Fri, Jun 8, 2012 at 7:22 PM, Sven Barth pascaldra...@googlemail.com wrote: I suggest this feature to be disabled in objfpc mode then. This would not be backwards compatible, thus the answer to this request is most likely: No. On the other hand, FPC has an established history of breaking

Re: [fpc-devel] Differences between 'tsym' and 'tdef'

On Fri, May 18, 2012 at 12:16 PM, Joost van der Sluis jo...@cnoc.nl wrote: I think I can. But in Delphi you can also give a non-exsisting attribute, ie:  TMyClass=class  private    FName: string;  published    [TThisTypeIsNowhereDefined('You','Can','Enter','Anything','here'1)]    property

[fpc-devel] Internal compiler error while compiling Lazarus

One user reported that latest FPC fails to compile a recent Lazarus: http://bugs.freepascal.org/view.php?id=22029 The bug was assigned to me, but I can't do much about it except to commit some workaround. And I am now away (at ACM ICPC World Finals), so it will take more than a week till my

Re: [fpc-devel] Breaking change in FPC 2.6.1

On Fri, Apr 27, 2012 at 20:28, Marco van de Voort mar...@stack.nl wrote: Calling a virtual(!) method when a bookmark is no longer needed allows to do other things too, like releasing something with db handles, and allows descendents of TDataset to do such things. Did you consider declaring

Re: [fpc-devel] On experience of using class helpers

On Fri, Apr 20, 2012 at 23:23, Sven Barth pascaldra...@googlemail.com wrote: Am 20.04.2012 05:41 schrieb Alexander Klenin kle...@gmail.com: The bad news is that I have encountered 4 bugs and 1 missing feature in about 10 lines of code :) Why do you need to test so much? Just kidding... I'm

[fpc-devel] On experience of using class helpers

I have used class helpers feature for the first time. (See components/tachart/tachartteechart.pas, r36916). The good news is that I was able to get it working. The bad news is that I have encountered 4 bugs and 1 missing feature in about 10 lines of code :) (Also, Lazaus does not seem to support

Re: [fpc-devel] Are C style operators default or not?

On Tue, Mar 27, 2012 at 19:30, Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk wrote: Gennadiy Poryev wrote: Hi all, I’ve recently ran into weird problem with “C style operators”. Though the story is about Lazarus, I thought I better ask it here. All of a sudden, my Lazarus trunk had

[fpc-devel] Re: [Lazarus] How to iterate through a TAvgLvlTree

On Fri, Mar 16, 2012 at 21:06, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Fri, 16 Mar 2012 20:47:15 +1100 Alexander Klenin kle...@gmail.com wrote: On Fri, Mar 16, 2012 at 19:36, Mattias Gaertner nc-gaert...@netcologne.de wrote: Is it possible to iterate through all items

[fpc-devel] Re: [Lazarus] FPC index/searcher classes committed.

On Sun, Mar 11, 2012 at 04:29, Michael Van Canneyt mich...@freepascal.org wrote: We'd like people to try it and comment on the design and speed of the engine, and if you have suggestions for improvements, they're more than welcome. A good use/test would be to speed up Find in Files in

[fpc-devel] Optimization stops near inline asm

the following code: {$mode objfpc} var a: Integer; begin a := a + 1; asm nop end; end. generates (under -O2): movlU_P$PROGRAM_A,%eax incl%eax movl%eax,U_P$PROGRAM_A nop instead of a single incl. removing either asm statement OR $mode directive

Re: [fpc-devel] Optimization stops near inline asm

2011/10/3 Jonas Maebe jonas.ma...@elis.ugent.be:  asm nop end []; then the statement will optimized. Otherwise the compiler assumes that the contents of eax may still be used inside the assembler block and hence cannot remove its use. The fact that the optimization is performed in case the

Re: [fpc-devel] utf-8 package in Free Pascal

On Mon, Oct 3, 2011 at 21:13, Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote: On Mon, Oct 3, 2011 at 11:38 AM, Marco van de Voort mar...@stack.nl wrote: These things are related to Lazarus UTF8 decision and thus logically belong in Lazarus, Not really. One can write a

Re: [fpc-devel] utf-8 package in Free Pascal

On Mon, Oct 3, 2011 at 22:40, Florian Klämpfl flor...@freepascal.org wrote: Am 03.10.2011 13:23, schrieb Alexander Klenin: This way, you can develop much faster, without the need to fight for your changes, Others call this fighting review and consider it as important part to improve

Re: [fpc-devel] utf-8 package in Free Pascal

On Tue, Oct 4, 2011 at 00:42, Florian Klämpfl flor...@freepascal.org wrote: Anyway, what I suggest is IMO a good compromise and should satisfy both sides -- Felipe can continue development of his packages unobstucted, while the quality of FPC will not suffer. That's why I proposed a branch

Re: [fpc-devel] utf-8 package in Free Pascal

On Tue, Oct 4, 2011 at 01:01, Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote: I think we should agree to disagree: Let's delete fpvectorial from FPC, I'll export it into lazarus/components/fpvectorial and we move our separate ways. +1 Among other things, this will

Re: [fpc-devel] utf-8 package in Free Pascal

On Tue, Oct 4, 2011 at 00:49, Paul Ishenin webpi...@mail.ru wrote: 03.10.2011 21:32, Alexander Klenin wrote: I'd say there is a continuum between those extremes, and (unfortunately) from my point of vew, FPC review is sometimes rather close to the former. I have been burned by this myself

Re: [fpc-devel] utf-8 package in Free Pascal

On Tue, Oct 4, 2011 at 08:48, Michael Van Canneyt mich...@freepascal.org wrote: There is, again, a continuum between careful development and stangation. While acknowledging great work that FPC team has done on the former, I'd venture to say that is came uncomfortably close to the latter. I'd

Re: [fpc-devel] who can explain why array of const can't be passed to another array of const

On Wed, Sep 14, 2011 at 19:03, Jonas Maebe jonas.ma...@elis.ugent.be wrote: It's more that even though both are called array of const, they are completely different things. They also don't support the same types. Perhaps varargs-compatible parameter type should be called something else then?

[fpc-devel] Local types and protected visibility

As reported in the Russian forum: http://freepascal.ru/forum/viewtopic.php?f=1t=7362 the following code: {$mode objfpc} uses Classes; type TMyClass=class private type TMyMemoryStream=class(TCustomMemoryStream) end; public procedure MyProc; end; procedure TMyClass.MyProc;

Re: [fpc-devel] Local types and protected visibility

On Tue, Sep 6, 2011 at 19:28, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 06 Sep 2011, at 10:13, Alexander Klenin wrote: As reported in the Russian forum: As reported on mantis: http://bugs.freepascal.org/view.php?id=18767 I see, thanks. -- Alexander S. Klenin

Re: [fpc-devel] Local types and protected visibility

On Tue, Sep 6, 2011 at 20:37, Paul Ishenin i...@kmiac.ru wrote: 06.09.2011 16:28, Jonas Maebe wrote: They are different bugs. The bug reported by Alexander here is related to with symbol table. I've already fixed it locally and will publish after the testsuite run. Can something be done to

[fpc-devel] Server availability

On Tue, Sep 6, 2011 at 20:57, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 06 Sep 2011, at 11:46, Alexander Klenin wrote: Can something be done to speed up the bugtracker? I have just given up waiting for the bug page to load, and just parroted the URL back to the freepascal.ru. Right

Re: [fpc-devel] Server availability

On Tue, Sep 6, 2011 at 22:17, Jonas Maebe jonas.ma...@elis.ugent.be wrote: For at least last few months, I write down bugs I encounter in the local file, since by the time the Report Issue page loads, I forget what I wanted to report. I suspect the server is severely overloaded. In general,

Re: [fpc-devel] Server availability

On Tue, Sep 6, 2011 at 22:43, Jonas Maebe jonas.ma...@elis.ugent.be wrote: There is one known problem: the server is behind a brain dead firewall, which drops most icmp packets (except for ping). This includes the fragmentation needed packets used for path mtu discovery

[fpc-devel] Issue 20124: Error with static direct field properties

[Is there any method to either comment on or re-open resolved isses? It is very frustrating to be forced to switch comminication channel] I think this issue is resolved prematurely. First, I do not see a reason why normal property can not be implemented by static field. Second, even is such a

Re: [fpc-devel] Issue 20124: Error with static direct field properties

On Fri, Sep 2, 2011 at 03:01, Florian Klaempfl flor...@freepascal.org wrote: Am 01.09.2011 17:48, schrieb Alexander Klenin: First, I do not see a reason why normal property can not be implemented by static field. Second, even is such a reason is provided, compiler should error out instead

  1   2   3   >