On Sat, Aug 7, 2010 at 01:12, Martin wrote:
> On 06/08/2010 14:53, Alexander Klenin wrote:
>>
>> Logical ones are actually less important for me,
>> but mod= and especially div= are rather useful.
>> Last time I wished a had div= was just a week ago.
>
> I could
On Fri, Aug 6, 2010 at 22:17, Martin wrote:
> -
> Readability is not equal to the sortest form of expressing something, in
> fact, the shortest form often lacks readability => hence many people dislike
> reg expression (which infact can be wonderfully short.
> in perl:
> $a := 11;
> if
On Fri, Aug 6, 2010 at 21:31, Marco van de Voort wrote:
> In our previous episode, Alexander Klenin said:
>>>> As for multiplication, floating-point and overloaded cases,
>>>> they are simply required since Inc and Dec do not work at all.
>>> inc and dec w
On Sat, Aug 7, 2010 at 00:12, Marcos Douglas wrote:
> On Fri, Aug 6, 2010 at 7:12 AM, Alexander Klenin wrote:
>>
>> On Fri, Aug 6, 2010 at 18:18, Michael Schnell wrote:
>>
>> > a, b := myfunc(x);
>> >
>> > I felt that this makes some sense, bu
On Fri, Aug 6, 2010 at 19:06, Marco van de Voort wrote:
> In our previous episode, Alexander Klenin said:
>> C-like operators reduce the number of required punctuation --
>> I always think that the extra punctuation is bad for readability.
[..]
> punctuation is not eve
On Fri, Aug 6, 2010 at 17:56, Graeme Geldenhuys wrote:
> Op 2010-08-06 05:05, Alexander Klenin het geskryf:
>> I specifically replace all usage of Inc/Dec and Include/Exclude in my
>> Pascal programs
>> by += / -= *to increase readability*.
>> And I think it really help
On Fri, Aug 6, 2010 at 18:18, Michael Schnell wrote:
> a, b := myfunc(x);
>
> I felt that this makes some sense, but
Agree, especially combined with built-in "dummy" variable,
so you can do
(_, _, a, _, b) := FuncWithManyOutputs(x);
to get only some of outputs.
> a,b := 0 just as a short for
On Fri, Aug 6, 2010 at 16:08, "Vinzent Höfler"
wrote:
> Alexander Klenin :
>
>> C-like operators reduce the number of required punctuation --
>> I always think that the extra punctuation is bad for readability.
>
> Rght. Shrt sntncs r mch sr t rd.
(No) ((
On Fri, Aug 6, 2010 at 14:08, Marco van de Voort wrote:
> In our previous episode, Alexander Klenin said:
>> > as this diminish the readability.
>>
>> FWIW, while migrating to FPC/newer Delphi,
>> I specifically replace all usage of Inc/Dec and Include/Exclude
On Fri, Aug 6, 2010 at 08:29, Michael Van Canneyt
wrote:
> Pascal as it is, is a very readable language as opposed to C. Proposals such
> as this diminish the readability.
FWIW, while migrating to FPC/newer Delphi,
I specifically replace all usage of Inc/Dec and Include/Exclude in my
Pascal progr
On Fri, Aug 6, 2010 at 07:23, Florian Klämpfl wrote:
> Am 05.08.2010 22:19, schrieb _-jan...@web.de:
>> Hello everybody,
>>
>> I would like to propose an enhanced replacement for the special assignment
>> operators += -= *= and /= :
>> More pascal-like would be constructs of the form "operator :=
On Wed, Jul 28, 2010 at 00:24, Martin wrote:
> On 27/07/2010 13:53, Alexander Klenin wrote:
> Not sure about the "by far"
Sorry about that.
> to me one of the really important questions is: Should qualified unit
> references in the source (outside the "uses"
On Wed, Jul 28, 2010 at 00:02, Martin wrote:
> Ah ok, well relative pathes can be done, but question is => do they need the
> namespace (leaving out the qualified unitname in source)
>
> if you just look at the uses clause => you do not need a namespace then =>
> you need "in" to work in units (an
On Tue, Jul 27, 2010 at 23:21, Martin wrote:
> On 27/07/2010 12:42, Martin wrote:
>>
>> Reffering to
>> http://wiki.lazarus.freepascal.org/Namespaces#Mapping_Namespace_to_each_search_path
>
>
I think you have over-engineered it by far ;-)
I see two use cases:
1) Project uses libraries which
On Tue, Jul 27, 2010 at 21:48, Martin wrote:
>> I think that ability to use plain
>> "fpc myproject.pas" to build the whole project is an important
>> advantage which would be lost with your alias proposal.
>
> Not really
> "fpc myproject.pas"
>
> for a project that uses RxLib, only works if RxLib
On Tue, Jul 27, 2010 at 21:35, Martin wrote:
> especially for the namespace (see the wiki page too), it solves the
> difference between
>
> uses Foo in 'LCL'; // a folder called lcl, in the project
> uses Foo in LCL; // the namespace
I agree that resolving ambiguity is a good thing, but still
thi
On Tue, Jul 27, 2010 at 02:54, Martin wrote:
> On 26/07/2010 16:49, Martin wrote:
>>
>> -Fu=/path/to/lcl // already existent, unit search path
>> -Fa-LCL:/path/to/lcl // define the LCL alias
>
> should have been an = sign
> -Fa=LCL:/path/to/lcl // define the LCL alias
>
> alias ends at the ":"
On Tue, Jul 27, 2010 at 02:27, Martin wrote:
> uses Foo in 'lcl' alias 'FooLCL', Foo in 'RTL' alias 'FooRTL'
I think this is a reasonable idea, with the following caveats:
1) I think both aliases and namespaces should be identifiers, not strings
(i.e. quotes are unnecessary distraction).
2) I th
On Wed, Jul 21, 2010 at 03:04, theo wrote:
> José Mejuto wrote:
>> Had you tried SizeOf(TTestarray) ?
>
> Good idea. Now I can see that the theory is right.
> for: TTestarray = array [1..100] of ttest;
> It goes down from 400 to 25 (using bitpacked).
>
> Jonas Maebe wrote
>> Uses new(lMask) instea
On Sat, Jul 17, 2010 at 20:12, Florian Klämpfl wrote:
>>
>>> For first results see the dodi/parser_rewrite branch.
>>
>> Generally speaking, long-lived feature branches should be avoided in SVN,
>> since the merging is incredibly painful.
>
> Why? As long as the patches textually apply, it's no pr
On Sat, Jul 17, 2010 at 11:36, Hans-Peter Diettrich
wrote:
> In the first step I'll enclose all semantical code into begin-end,
> so that it can be easily hidden (folded) in the Lazarus IDE.
This is not needed -- you can use {$REGION} ... {$ENDREGION}
directives instead.
If/when somebody implemen
On Wed, Jul 7, 2010 at 01:09, Michael Van Canneyt
wrote:
>
> Glad to hear FPC is not at fault, for once.
>
> So we can expect a new FPC and lazarus hopefully soon :-)
I am sorry for hijacking this thread, but while I see someone is interested
in proper command-line spaces handling, I would like t
On Thu, May 20, 2010 at 23:03, Jonas Maebe wrote:
>
> On 20 May 2010, at 13:57, Alexander Klenin wrote:
>
>> the safe version would be
>>
>> var tmp: TFPCanvasHelper;
>> ...
>> InitHelper(tmp, TFont);
>> tmp := FFont as TFont;
>
> I guess you me
On Thu, May 20, 2010 at 19:31, Florian Klaempfl wrote:
> Alexander Klenin schrieb:
>> I think it is a typical sample of change required to production code
>> by the restriction we are discussing.
>> Looking at the diff, I'd argue that:
>> 1) Old version was cle
On Thu, May 20, 2010 at 20:35, Joost van der Sluis wrote:
> On Thu, 2010-05-20 at 16:57 +1100, Alexander Klenin wrote:
>> I would like to return the discussion to the original question,
>> now with the real code sample ;-)
>> Look at r21318 of Lazarus (tachart: fixed compi
I would like to return the discussion to the original question,
now with the real code sample ;-)
Look at r21318 of Lazarus (tachart: fixed compilation with fpc 2.5.1,
by Vincent).
[BTW, is there any web-interface for browsing Lazarus SVN?]
I think it is a typical sample of change required to pro
On Tue, Dec 22, 2009 at 14:42, Paul Ishenin wrote:
> 22.12.2009 11:30, Flávio Etrusco wrote:
>>
>> Hi all,
>> I want to propose a syntax extension for the compiler to check
>> parameters' name on function/procure calls. Would such a patch be
>> accepted? Does anybody have a suggestion for the syn
On Thu, Nov 19, 2009 at 21:02, Jonas Maebe wrote:
>> Ok, so how about introducing, say, FillMem procedure, which is
>> identical to FillChar
>> except that it has "out" parameter,
>
> See http://lists.freepascal.org/lists/fpc-devel/2009-November/018559.html
>
> FillMem would be a very bad name th
On Thu, Nov 19, 2009 at 20:46, Jonas Maebe wrote:
>
> On 19 Nov 2009, at 11:42, Alexander Klenin wrote:
>
>> No, I asked for an example of code that would be negatively affected by
>> changing "var" to "out" in FillChar parameter.
>
> I don't kn
On Thu, Nov 19, 2009 at 20:31, Jonas Maebe wrote:
>
> On 19 Nov 2009, at 11:21, Alexander Klenin wrote:
>
>> On Thu, Nov 19, 2009 at 19:20, Martin wrote:
>>
>>> Jonas Maebe wrote:
>>
>> [skipped example]
>>
>>> Well in this case, the co
I still do not fully understand.
On Thu, Nov 19, 2009 at 19:20, Martin wrote:
> Jonas Maebe wrote:
[skipped example]
> Well in this case, the code is actually positively affected by the "out"
> param (because it avoids the mem leak)
Jonas, can you confirm that your example is incorrect one,
a
On Thu, Nov 19, 2009 at 18:36, Jonas Maebe wrote:
> More importantly, another thing it would affect is that in case someone has
> written their own fillchar with an out parameter, and *expects* reference
> counted structures to be finalised at the caller side before they are
> overwritten with ze
2009/11/11 Dariusz Mazur :
>
> With this I have and question:
> For me function FindNextRaw should be in protected section
> But then we cant use them in enumerator, except when something like friend
> classes can be used in FPC.
> I only read about this concept, is it possible/plan in FPC.
I
On Sat, Nov 7, 2009 at 20:32, Dariusz Mazur wrote:
> Alexander Klenin pisze:
>> Obviously, the implementation should not call FindFirstBit,
>> but copy it's logic. To avoid code duplication,
>> I think you can to it the other way around -- let FindFirstBit
>>
On Fri, Nov 6, 2009 at 05:51, "Vinzent Höfler"
wrote:
> Von: Michael Van Canneyt :
>
>> Like I said, we should not have named it enums. They are not enums.
>> They're a hack to support some C construct in a type-safe way.
>> No more, no less.
>
> IBTD.
[skip Ada sample]
> They might be an ugly h
On Wed, Nov 4, 2009 at 22:36, Paul Ishenin wrote:
> Alexander Klenin wrote:
>>
>> Yet another bug:
>>
>> ---
>> type T = (a1, b1=5);
>> var
>> ch: T;
>> begin
>> for ch in T do Writeln(ch);
>> end.
>>
>
> This is c
On Wed, Nov 4, 2009 at 13:46, Paul Ishenin wrote:
> Alexander Klenin wrote:
>>
>> I have started testing the new for..in code.
>> The very first test I tried found a bug ;-)
>>
>
> I would be nice to have all your tests in .pas/.pp files. Can you attached
> th
Yet another bug:
---
type T = (a1, b1=5);
var
ch: T;
begin
for ch in T do Writeln(ch);
end.
---
This leads to runtime error.
Note that
---
type T = (a1, b1=5);
begin
Writeln(Succ(a1));
end.
---
leads to compile-time error
(although I think it should work, but that is a separate topic).
-
Another minor problem:
--
begin
for ch in S do Writeln(ch);
end.
--
Results in:
t.pp(2,10) Error: Identifier not found "ch"
t.pp(2,15) Error: Identifier not found "S"
t.pp(2,28) Error: Identifier not found "ch"
t.pp(2,29) Error: Can not find an enumerator for the type ""
IMHO the last two error
On Wed, Nov 4, 2009 at 01:04, Florian Klaempfl wrote:
> Alexander Klenin schrieb:
>> For both FPC and Lazarus at about 8 days ago.
>
> Should work again.
thanks
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.free
On Wed, Nov 4, 2009 at 08:03, Thaddy wrote:
> Alexander Klenin wrote:
>>
>> I have started testing the new for..in code.
>> The very first test I tried found a bug ;-)
>> ---
>> const S = 'abc';//<???
>> var ch: Char;
>> begin
>&
Another bug:
---
var
ch: Char;
begin
for ch in [] do Writeln(ch);
end.
---
=> AV in compiler
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I have started testing the new for..in code.
The very first test I tried found a bug ;-)
---
const S = 'abc';
var ch: Char;
begin
for ch in S do Writeln(ch);
end.
---
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
htt
For both FPC and Lazarus at about 8 days ago.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Sun, Nov 1, 2009 at 17:49, Paul Ishenin wrote:
> If nobody want to test/review and nobody argue then maybe we can merge the
> changes? The changes are made so that they almost does not affect the other
> compiler/rtl code. Therefore there is no risk for the trunk compiler/rtl to
> be broken by
On Sun, Oct 25, 2009 at 20:05, Graeme Geldenhuys
wrote:
> On 25/10/2009, Alexander Klenin wrote:
>>
>> IMHO, Reset/JumpToBack should not be used inside "for..in" loop -- they are
>> analogous to "goto" inside for loop.
>> If "for .. in .. ind
On Sun, Oct 25, 2009 at 16:49, Paul Ishenin wrote:
>> When I use
>> iterators, I would like to have the ability to use Current, HasNext,
>> HasPrevious, PeakNext, PeakPrevious, Reset, JumpToBack, pass a filter
>> to GetIterator... etc.
>
> I don't argue but how do you think to use HasPrevious, Pea
On Thu, Oct 22, 2009 at 04:08, David B Copeland
wrote:
> In what way is Generics not 100%?
>
> Dave Copeland.
For me at least, the gravest problem is a lack of function-level generics.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.
On Thu, Oct 22, 2009 at 02:07, Sergei Gorelkin wrote:
> As I tried to say earlier, having distinct StepNext() and Current()
> functions is somewhat redundant, except the purpose of Delphi compatibility.
> Rationale: the for..in loop manages the iterator object itself, and does not
> allow user cod
On Thu, Oct 22, 2009 at 01:44, Michael Van Canneyt
wrote:
> What about
>
> function StepNext: Boolean; iterator 'movenext';
> property TheCurrentValue: Integer; iterator 'current';
You beat me by two minutes ;-)
> function StepNext: Boolean; iterator nextvalue;
> property TheCurrentValue: In
On Thu, Oct 22, 2009 at 01:15, Michael Van Canneyt
wrote:
>> On Tue, Oct 20, 2009 at 20:25, Alexander Klenin wrote:
>>> This is because the while you provided is not equivalent to the for loop
>>> above.
>>> The correct translation would be:
>>> var
&g
.
> It's not more readable, either, IMHO.
I understand what this thread is very long and hard to follow.
However, could you please at least read direct the answers to your mails:
On Tue, Oct 20, 2009 at 20:25, Alexander Klenin wrote:
> On Tue, Oct 20, 2009 at 20:09, Michael Van Can
On Wed, Oct 21, 2009 at 23:15, Michael Van Canneyt
wrote:
> This is all just nitpicking. Iterators as a language construct are a very ugly
> hack to save some typing, no matter how you turn it. Nice maybe for
> languages with dynamic typing and so on, but really not on it's place in
> Pascal.
I
On Tue, Oct 20, 2009 at 20:29, Graeme Geldenhuys
wrote:
> On 20/10/2009, Alexander Klenin wrote:
>> Hm. I can not see where lookahead aka peeking
>> is required in using any of the enumerators you mention.
>> UTF8String enumerator is even among the samples on the wik
On Tue, Oct 20, 2009 at 20:23, Florian Klaempfl wrote:
> Michael Van Canneyt schrieb:
> My opinion about the for-in loop:
> - I won't implement it
> - if somebody else implements it in a delphi compatible manner: fine
> - if somebody else implements it in a delphi compatible manner solving
> the
On Tue, Oct 20, 2009 at 20:09, Michael Van Canneyt
wrote:
> But I really don't see the advantage of being able to type
>
> For F in Someclass.Iterator do
> F.Something
>
> over
>
> While SomeClass.HaveValue do
> SomeClasss.NextValue.Something;
>
> It's not clearer, at most it saves you a c
On Tue, Oct 20, 2009 at 19:34, Michael Van Canneyt
wrote:
> You don't know this with an iterator since you depend on the implementation
> of the iterator. The loop could loop forever then...
Just as it can when using iterators explicitly. No difference here.
> Secondly:
> You promote a certain c
On Tue, Oct 20, 2009 at 19:40, Graeme Geldenhuys
wrote:
> // for basic type we will call only the apropriate function
> procedure TraverseString(S: String);
> var
> C: Char;
> begin
> for C in S using GetReverseStringEnumerator(S) do
> DoSomething(C);
> end;
> Now your for-in syntax changes b
On Tue, Oct 20, 2009 at 19:22, Graeme Geldenhuys
wrote:
> 2009/10/20 Alexander Klenin :
>>
>> Well, I suggest you to read at least the link provided in the original post,
>> and maybe also some documention about Delphi/C# enumerators.
>
>
> I just read the docs in
On Tue, Oct 20, 2009 at 19:03, Graeme Geldenhuys
wrote:
> 2009/10/20 Alexander Klenin :
>>> As an alternative to the very limited "for-in", I have a better and
>>> more flexible design, using the Iterator design pattern.
>>
>> for-in is just a syntax
On Tue, Oct 20, 2009 at 18:57, Graeme Geldenhuys
wrote:
> As an alternative to the very limited "for-in", I have a better and
> more flexible design, using the Iterator design pattern.
for-in is just a syntax sugar plus standard interface for the cost common usage
of iterators. So they are not m
On Tue, Oct 20, 2009 at 17:59, dmitry boyarintsev
wrote:
> On Tue, Oct 20, 2009 at 4:59 AM, Paul Ishenin wrote:
> Maybe the syntax should be simplified, rather than following new
> delphi's .Nettist growing style? AFAIK, it's been discussed about
> using class attributes.
Excellent idea, and I e
On Tue, Oct 20, 2009 at 01:12, Jonas Maebe wrote:
> Except if you want to use the constant in another constant expression (which
> is not possible with a function, inlined or not).
Which, by the way, is another limitation that would be good to lift:
const PI = Arctan(1) * 4;
--
Alexander S. Kl
On Mon, Oct 19, 2009 at 20:30, dmitry boyarintsev
wrote:
> Please forgive me my ignorance, but what is advantage of using sealed classes?
> Personally, i see no advantage of forbidding inheritance of some class.
>
> What should be the **proper** use of sealed classes and class helpers?
>
> Please
On Mon, Oct 19, 2009 at 20:27, Paul Ishenin wrote:
> Alexander Klenin wrote:
>
>> This is not the question of terminology (though I think the proper
>> term in this case is "non-reserved keyword"), but of the fact that
>> some programs that compiled previou
On Mon, Oct 19, 2009 at 19:35, Jonas Maebe wrote:
>
> On 17 Oct 2009, at 08:22, Paul Ishenin wrote:
>
>> Alexander Klenin wrote:
>>>
>>> 3) This patch introduces new keyword -- what about backwards
>>> compatibility? The code like:
>>> type T =
On Mon, Oct 19, 2009 at 18:44, Florian Klaempfl wrote:
> Alexander Klenin schrieb:
>> BTW, I have already asked in the beginning of the thread,
>> but got no answer: why are those files under version control at all?
>
> Because it's easier to handle when doing compiler
On Mon, Oct 19, 2009 at 18:40, Florian Klaempfl wrote:
> Alexander Klenin schrieb:
>> Why sealing a singleton is any more (or less) useful then sealing any
>> other class?
>
> As I said, it's as usefull as private/protected/strict private/strict
> protected imo
Wel
On Mon, Oct 19, 2009 at 18:35, Florian Klaempfl wrote:
> And taking into account the size of the patch (see below and ignore the
> auto generated files msg*.inc), it's worth to add. private etc. cause
> much more trouble in the compiler and has no more real use imo.
>
>> By I guess this whole thre
On Mon, Oct 19, 2009 at 17:55, Florian Klaempfl wrote:
> Without discussing details, I think a singleton is a good example where
> sealed is useful.
Why sealing a singleton is any more (or less) useful then sealing any
other class?
I use hierarchies of singletons quite often, and having them seal
On Mon, Oct 19, 2009 at 15:43, Paul Ishenin wrote:
> Except the security role sealed and abstract classes have their important
> oop meaning.
Security is only possible in the context of languages like Java, which can
actually enforce visibility rules at run-time. Compiled languages nave
no such a
On Sun, Oct 18, 2009 at 07:28, Jonas Maebe wrote:
> FPC can already do this automatically for all classes in the entire program
> with whole-program optimization. You don't need sealed classes for this
> (they might slightly improve those optimizations, but I doubt it will be
> noticeable in real
On Sat, Oct 17, 2009 at 08:51, Sergei Gorelkin wrote:
> Guess its primary target are classes like Java/.NET String. These are value
> classes, they do not contain other pointers, garbage collection is therefore
> easier and the whole framework speeds up. If you inherit from it and add
> your own m
On Sat, Oct 17, 2009 at 08:06, Graeme Geldenhuys
wrote:
> 2009/10/16 Alexander Klenin :
>> "Class sealing allows extension of classes within a package, but
>> prevent clients from extending such classes outside of the package."
>> This might actually make some se
On Sat, Oct 17, 2009 at 03:25, Paul Ishenin wrote:
> I tried to implement support for delphi sealed and abstract classes. They
> are described a bit here: http://edn.embarcadero.com/article/34324
First, let me say that I am very glad that you entered FPC development --
with your energy I hope it
On Wed, Sep 16, 2009 at 09:09, Paul Ishenin wrote:
> Michael V. Denisenko wrote:
> Can we hope that after all experince you've got during this new compiler
> feature development you will not stop and continue with development of other
> 'nice to have' fpc features? For example discussed in 'Reques
On Sat, Jun 13, 2009 at 22:47, Jonas Maebe wrote:
>
> On 13 Jun 2009, at 13:31, Alexander Klenin wrote:
>
>> Currently, Round and Trunc functions ignore the state of $OVERFLOWCHECKS
>> compiler directive. The following code prints "-2 -2":
> In Borland-speak,
Currently, Round and Trunc functions ignore the state of $OVERFLOWCHECKS
compiler directive. The following code prints "-2 -2":
{$MODE OBJFPC}{$OVERFLOWCHECKS ON}
var
a: Integer;
b: Double;
begin
b := MaxInt;
a := Round(2.0 * b);
Writeln(a);
a := Trunc(2.0 * b);
Writeln(a);
end.
Thi
On Fri, May 22, 2009 at 23:21, Michael V. Denisenko wrote:
> Hello everyone, just one question: can anyone monitor my patches: "Case of
> string"?
He probably wanted to ask for a review.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lis
On Sun, May 10, 2009 at 07:56, wrote:
> Hi all,
> I just grabbed the latest SVN - 19889 and a build of bigide is not
> working.
> The error occuring is...
>
> Free Pascal Compiler version 2.3.1 [2009/05/09] for powerpc
> Copyright (c) 1993-2009 by Florian Klaempfl
> Target OS: Darwin for PowerPC
On Sun, May 3, 2009 at 23:55, Jonas Maebe wrote:
>
> On 03 May 2009, at 13:54, Marco van de Voort wrote:
>
>> (I thought btw, generics in 2.2.4 had improved to being more or less
>> usable?)
>
> A number of important bugs were indeed fixed. But as far as I know, several
> more are left.
BTW, is g
While fixing http://bugs.freepascal.org/view.php?id=13619,
Jonas did not apply neither code cleanup not comment fix parts of it.
Are such changes not wanted?
I did not made a separate patch for them -- should I?
I thought they are trivial and obvious.
On a more generic note -- will massive code r
On Sat, May 2, 2009 at 03:16, Mattias Gaertner
wrote:
>> Is there a Mercurial mirror of FPC docs?
>
> Don't know.
> Will you create the bug report?
http://bugs.freepascal.org/view.php?id=13632
Is the mirror would be available, I'd create a patch too.
>> >> Alternative solution would be to issue
On Sat, May 2, 2009 at 02:39, Mattias Gaertner
wrote:
> On Sat, 2 May 2009 02:17:48 +1100
> Alexander Klenin wrote:
>
>> Because this surprises developers and leads to bugs.
>> See the issue http://bugs.freepascal.org/view.php?id=13418
>> (linked from the discusse
On Sat, May 2, 2009 at 01:56, Mattias Gaertner
wrote:
>> 4) If it has setter named "SetP", do the equivalent of "inherited
>> SetP".
>
> Why?
Because this surprises developers and leads to bugs.
See the issue http://bugs.freepascal.org/view.php?id=13418
(linked from the discussed one) for a recen
This mail is to discuss issue http://bugs.freepascal.org/view.php?id=13630.
>From the issue description:
Given the definitions:
type
T1 = class
procedure SetP(AP: Integer); virtual;
property P: Integer read FP write SetP;
end;
T2 = class(T1)
procedure SetP(AP: Integer); overri
2009/4/18 Mike Denisenko :
> Hello everyone, I'm a student of FESU, Russia. I've started to develop a
> feature - string cases
Mike is my student, and he is doing this project as a course work at
our university
(http://imcs.dvgu.ru/works/work?wid=7539 , russian only).
So I will try to oversee and
On Sun, Mar 1, 2009 at 21:06, Florian Klaempfl wrote:
> If one has more patches, something like using mercurial queues is a good
> idea. Maybe Alexander Klenin could write a short tutorial how to use mq
> to maintain patches.
There are many tutorials already:
http://www.google.ru
On Mon, Mar 2, 2009 at 23:13, Michael Schnell wrote:
>
>> here it has nothing to do with what a Fourier Transform results in. But
>> like FFT it's speed is O(n), while the speed of plain old "school"
>> multiplication and DFT is O(n²).
>
> I suppose in fact it's o(n * ln(n) )
It is O(n^log 3) ~ O
On Mon, Mar 2, 2009 at 21:58, Michael Schnell wrote:
> In the "Deutsches Lazarus Forum" there was a project called "GNURZ"
> providing this. It was quite promising and I provided some ASM-optimization
> for it.
>
> Here the original Author implemented a "Karazuba" multiplication, that is a
> lot f
On Mon, Mar 2, 2009 at 21:27, Michael Schnell wrote:
> Do you need integer or floating point ?
Fixed-point, actually.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-dev
On Mon, Mar 2, 2009 at 07:34, Daniël Mantione
wrote:
> This is a debate that has been held quite a few times :) If you look at
> typed consts from the point of view what a mathematical constant is, yes,
> it's completely absurd that you can write to them.
>From _mathematical_ point of view assign
On Mon, Mar 2, 2009 at 03:16, Daniël Mantione
wrote:
> Making typed constants writeable has been a disputed feature of the Borland
> dialect, I agree with that, but fact of the matter is they are writeable and
> thus cannot form a constant expression. The fact that there exists a $J
> directive d
On Mon, Mar 2, 2009 at 00:47, Jonas Maebe wrote:
>> Is rejected by Delphi, but compiled by FPC, which is a compatibility
>> bug in itself.
>
> This depends on a mode switch. Use {$j-} to turn off the ability to write to
> typed constants. Maybe it's off by default in your version of Delphi.
I know
Since issue http://bugs.freepascal.org/view.php?id=13256 was marked resolved,
I can not add comments, so I'd like to discuss it here.
Original report claimed that code
const c: SomeType = ;
var y: t = c;
begin
end.
Works for primitive types, but not the complex ones.
This was an error on my part
On Sun, Mar 1, 2009 at 20:07, Florian Klaempfl wrote:
>> 3) Finally, and relevantly for this list,
>> should something like this be included into FPC?
> Imo in principle, yes, but:
> - simpler than NX library in the sense of less functionally, putting
> something like NX library in FPC is too m
On Sun, Mar 1, 2009 at 07:15, m2 wrote:
> Alexander Klenin a écrit :
>> So, should I write one or did I just not searched in the right place?
>
> There is my NX library (still alpha) at
>
> htpp://www.ellipsa.net/
Now, this code is much more pleasant to read ;-)
A few ques
On Sun, Mar 1, 2009 at 01:03, Michael Van Canneyt
wrote:
>> So, should I write one or did I just not searched in the right place?
>
> There is one in the contributed units:
> mpcalc from Franco Milano. It has been around for quite some time.
Oh, indeed, thanks. I missed it when I looked there.
Ho
Is there such a thing for FPC?
I need it for my project and I have found is this:
http://pauillac.inria.fr/~quercia/cdrom/bibs/numerix.tar.gz
Which seems unmaintained, in french, has horrible API,
and is actually a wrapper around C library.
Seeing as FPC contains at least three expression-pars
On Sat, Dec 20, 2008 at 21:48, Michael Van Canneyt
wrote:
> I specially chose local because I don't want it to be roaming data.
This is actually a (minor) problem sometimes -- e.g. students at unversity
where I work have roaming profiles so the could log in and work prom
any PC in the domain.
Wit
201 - 300 of 311 matches
Mail list logo
