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 input.
>
> The 3.0.4 behavi
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, consistent, easy.
>
> The above is
On Wed, Mar 6, 2013 at 10:00 PM, Michael Schnell 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 "i
On Tue, Mar 5, 2013 at 11:13 PM, ListMember 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
> implementation of the gene
On Wed, Mar 6, 2013 at 12:27 AM, Sven Barth 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)
Is not "specialize" ke
On Wed, Mar 6, 2013 at 12:16 AM, Sven Barth wrote:
>
> SomeVar := SomeFunc - SomeType.SomeMethod *
> SomeOtherType.SomeMethod;
>
> === example end ===
>
> while this will be much easier to implement:
>
> === example begin ===
>
> SomeVar := specialize SomeFunc - specialize
> SomeType.SomeMethod *
On Tue, Mar 5, 2013 at 10:24 PM, Marco van de Voort 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 nightmare to pa
On Tue, Mar 5, 2013 at 9:10 PM, Paul Ishenin 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 cost/benefit analysis.
For
On Tue, Mar 5, 2013 at 3:34 AM, Martin 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 "while&q
On Tue, Mar 5, 2013 at 2:10 AM, Martin 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 some persons
do
On Tue, Mar 5, 2013 at 1:49 AM, Sven Barth 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
> (after all we
On Tue, Mar 5, 2013 at 1:28 AM, Michael Van Canneyt
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.
Pascal is also procedura
On Mon, Mar 4, 2013 at 10:34 PM, Martin 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, this would be
On Mon, Mar 4, 2013 at 10:35 PM, Martin 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 the anonymou
On Mon, Mar 4, 2013 at 2:38 PM, Martin 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.
Nevertheless, I ag
On Mon, Mar 4, 2013 at 4:06 PM, Boian Mitov wrote:
> Here is another even simpler example:
>
> AItem := GComponentEditorList.Find(
>function( AItem : IComponentEditorItem ) : Boolean
>begin
> Result := ( AComponent is AItem.GetInstance().ComponentCl
On Mon, Mar 4, 2013 at 11:15 AM, Graeme Geldenhuys
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 computer science is
On Sun, Mar 3, 2013 at 11:21 PM, Sven Barth 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 implement short lamb
On Sat, Feb 9, 2013 at 1:13 PM, Vittorio Giovara
wrote:
> I think we could make this work thanks to the Google Summer of Code! This
> program (*if* they announce it) basically introduces students to the world
> of FOSS development by having them work on projects for an open source
> organization d
On Wed, Feb 6, 2013 at 10:31 PM, Michael Schnell 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 you'll have
On Sat, Feb 2, 2013 at 7:42 PM, Nikolai Zhubr 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 - fpc-devel@lists.freepasca
On Mon, Jan 28, 2013 at 7:25 PM, Hans-Peter Diettrich
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))//
On Tue, Jan 29, 2013 at 12:39 AM, Paul Ishenin 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 horror t
On Mon, Jan 28, 2013 at 4:46 AM, Hans-Peter Diettrich
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 below.
>> Any ti
On Mon, Jan 28, 2013 at 4:19 AM, Michael Van Canneyt
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 status:
> 'GetEnumera
On Mon, Jan 28, 2013 at 2:59 AM, Michael Van Canneyt
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 bo
On Mon, Jan 28, 2013 at 2:01 AM, Martin 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
>> inconvenient
On Mon, Jan 28, 2013 at 1:38 AM, Jonas Maebe 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 understood me :)
Please see
On Mon, Jan 28, 2013 at 1:26 AM, Paul Ishenin 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 think it
On Sun, Jan 27, 2013 at 11:29 PM, Michael Van Canneyt
wrote:
>>
>> Let me restate:
>> 1) Tuple as a type does nothing new compared to a record, except for
>> possibility to omit field names.
> That's all we need.
I disagree. In fact, the ability to omit field names is, in my opinion,
the least val
On Sun, Jan 27, 2013 at 10:10 PM, Michael Van Canneyt
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.
>
> I think t
On Sun, Jan 27, 2013 at 12:35 PM, Hans-Peter Diettrich
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 allocated for it. I
On Sun, Jan 27, 2013 at 12:11 PM, Alexander Klenin 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
On Sun, Jan 27, 2013 at 8:40 AM, Mark Morgan Lloyd
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
>> plain comma as an operator c
On Sun, Jan 27, 2013 at 4:43 AM, 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".
>
> Please note the following points:
> * This is not the
On Sun, Jan 27, 2013 at 3:51 AM, Marco van de Voort wrote:
> In our previous episode, Alexander Klenin said:
>> >
>> > Please take a look at this:
>> > http://blog.barrkel.com/2010/01/using-anonymous-methods-in-method.html
>>
>> While this article
On Sun, Jan 27, 2013 at 3:10 AM, Sven Barth 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
>>
On Sun, Jan 27, 2013 at 1:05 AM, Mark Morgan Lloyd
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.
>
> (x, y, z) := (0, 0, 0);
On Sun, Jan 27, 2013 at 1:59 AM, kyan 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 look at thi
On Sat, Jan 26, 2013 at 8:31 PM, Sven Barth wrote:
> On 25.01.2013 23:57, Alexander Klenin wrote:
>> You have also proposed lambda-expressions:
>>>
>>> map.Iterate(lambda TFPGMapLongInt.TIteratorProc(aKey, aData) as
>>> Writeln(aKey, ' => ', aDat
On Sun, Jan 27, 2013 at 12:26 AM, Paul Ishenin 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
>
On Sat, Jan 26, 2013 at 3:14 PM, Hans-Peter Diettrich
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
On Sat, Jan 26, 2013 at 10:58 PM, Sven Barth
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: TObject;
> beg
On Sat, Jan 26, 2013 at 10:34 PM, Michael Van Canneyt
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 the origina
On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth
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
>> using generics.
On Sat, Jan 26, 2013 at 9:50 AM, Marco van de Voort 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. The .
On Sat, Jan 26, 2013 at 5:17 AM, Sven Barth 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 procedures/closures
is the "real" t
On Sat, Jan 26, 2013 at 9:31 AM, Sven Barth 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
> TFPGListLongInt = specialize T
On Sat, Jan 26, 2013 at 9:27 AM, Sven Barth wrote:
>
> Regarding tuples:
> http://wiki.oxygenelanguage.com/en/Tuples
I know, but I consider this particular implementation an unpleasant example of
"no need to change the language -- lets do it in the library" philosophy.
Just look:
>The Tuple type i
On Sat, Jan 26, 2013 at 8:54 AM, Florian Klämpfl 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 proposal could be b
On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl 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 wrote:
> No. I want to see a language which provides something like the explicit
> i
On Sat, Jan 26, 2013 at 7:10 AM, Mark Morgan Lloyd
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 , or a /regular expression/ (b
On Sat, Jan 26, 2013 at 6:59 AM, Sven Barth 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 languages) where
> this
On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl 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 Alexande
On Sat, Jan 26, 2013 at 6:11 AM, Sven Barth wrote:
> I think he also means things like (without critizing):
Yes, thank for a dose of sanity :)
Few more examples, taken from just one standard package:
while Node.NextBrother<>nil do begin
...
Node:=Node.NextBrother;
end;
while Node<>nil do b
On Sat, Jan 26, 2013 at 5:12 AM, Daniël Mantione
wrote:
>> Consider these arguments:
>> 1) Even for simple arrays, depending on array element type,
>> and optimizer implementation, for-in can be more efficient since it
>> can avoid multiplication for element access.
> True, but it shouldn't. Loop
On Sat, Jan 26, 2013 at 4:38 AM, Michael Van Canneyt
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 for.
If you me
On Sat, Jan 26, 2013 at 3:30 AM, Florian Klämpfl wrote:
>> "for-in-index" extension was actually planned by me as a prerequisite
>> for fcl-stl work.
>
> Using indicies is against all principles of iterators.
I am not sure what princilpes you are talking about,
but accessing the key of the current
On Fri, Jan 25, 2013 at 7:07 PM, Michael Van Canneyt
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 since was deafenin
On Fri, Jan 25, 2013 at 10:38 AM, Graeme Geldenhuys
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.
>>>
>
On Fri, Jan 25, 2013 at 10:13 AM, Graeme Geldenhuys
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
On Fri, Jan 25, 2013 at 9:36 AM, Michael Van Canneyt
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" :)
However, it is im
On Fri, Jan 25, 2013 at 8:44 AM, Florian Klämpfl 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 adju
On Fri, Jan 25, 2013 at 7:56 AM, Florian Klämpfl wrote:
>>> Just an example: what happens with i if I start to delete from s during
>>> the for loop?
>>
>> Exactly the same thing as in the current for-in loop: either a range check
>> error
>> of nothing, depending on what you delete.
>
> How do y
On Fri, Jan 25, 2013 at 7:34 AM, Marco van de Voort 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 guideline.
--
Alex
On Fri, Jan 25, 2013 at 7:30 AM, Florian Klämpfl 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 examp
On Fri, Jan 25, 2013 at 7:18 AM, Jeppe Græsdal Johansen
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 loop can only
On Fri, Jan 25, 2013 at 4:45 AM, Michael Van Canneyt
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 syntax is not meant for
On Thu, Dec 6, 2012 at 8:29 PM, Jonas Maebe 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++ (nobody uses pure C in
comp
On Thu, Dec 6, 2012 at 2:16 PM, Nikolay Nikolov
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, Henadzi
> Karatkevitch fr
On Sun, Dec 2, 2012 at 9:47 PM, Tomas Hajny 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
On Sun, Dec 2, 2012 at 6:21 PM, Sven Barth 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):
>
> TTest>
On Sun, Dec 2, 2012 at 4:52 PM, Tomas Hajny 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 options do
On Sun, Dec 2, 2012 at 2:42 PM, Michael Van Canneyt
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 homegrown, as a lot of o
On Sun, Dec 2, 2012 at 2:08 PM, Michael Van Canneyt
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 purposes, mostly. I speak a
On Sun, Dec 2, 2012 at 2:02 PM, Sven Barth 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 being
> crap because of
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
On Wed, Nov 28, 2012 at 2:29 PM, Jonas Maebe 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 this.
I have rather cu
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
On Tue, Sep 11, 2012 at 8:03 AM, Jonas Maebe 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? If
not, then maybe the
On Fri, Jun 15, 2012 at 9:39 AM, Mattias Gaertner
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
nested" modifier.
--
On Mon, Jun 11, 2012 at 9:03 AM, Skybuck Flying 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 suggest to leave Delph
On Fri, Jun 8, 2012 at 7:22 PM, Sven Barth 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
backwards compatibil
On Fri, Jun 8, 2012 at 6:08 PM, Marc Weustink 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
> the places where
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 anoth
On Fri, May 18, 2012 at 12:16 PM, Joost van der Sluis 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 Name
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 return
On Fri, Apr 27, 2012 at 20:28, Marco van de Voort 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 TBookmark an int
On Fri, Apr 20, 2012 at 23:23, Sven Barth wrote:
> Am 20.04.2012 05:41 schrieb "Alexander Klenin" :
>> 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&
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 cl
On Tue, Mar 27, 2012 at 19:30, Mark Morgan Lloyd
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 refused to build
>> (ht
On Fri, Mar 16, 2012 at 21:06, Mattias Gaertner
wrote:
> On Fri, 16 Mar 2012 20:47:15 +1100
> Alexander Klenin wrote:
>
>> On Fri, Mar 16, 2012 at 19:36, Mattias Gaertner
>> wrote:
>> >> Is it possible to iterate through all items in a TAvgLvlTree? I
>> &g
On Sun, Mar 11, 2012 at 04:29, Michael Van Canneyt
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 Lazarus.
--
Alexander S
On Tue, Oct 4, 2011 at 08:48, Michael Van Canneyt
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 venture to disa
On Tue, Oct 4, 2011 at 00:49, Paul Ishenin 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
On Tue, Oct 4, 2011 at 01:01, Felipe Monteiro de Carvalho
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 simplify management of TAChart's
fpve
On Tue, Oct 4, 2011 at 00:42, Florian Klämpfl 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 and that's wha
On Mon, Oct 3, 2011 at 22:40, Florian Klämpfl 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 importa
On Mon, Oct 3, 2011 at 21:13, Felipe Monteiro de Carvalho
wrote:
> On Mon, Oct 3, 2011 at 11:38 AM, Marco van de Voort wrote:
>> These things are related to Lazarus UTF8
>> decision and thus logically belong in Lazarus,
>
> Not really. One can write a non-visual library which uses utf8string
> as
2011/10/3 Jonas Maebe :
> 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 used register is ax
1 - 100 of 311 matches
Mail list logo
