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, 4 Oct 2011, Alexander Klenin wrote:
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 wh
On Mon, 2011-10-03 at 19:27 +0200, Florian Klämpfl wrote:
> Am 03.10.2011 16:23, schrieb Joost van der Sluis:
> > On Sat, 2011-10-01 at 10:26 +0200, Florian Klämpfl wrote:
> >> Am 30.09.2011 15:02, schrieb Joost van der Sluis:
> >>> Please test this gdb-version, and tell me about your experiences.
Am 03.10.2011 16:23, schrieb Joost van der Sluis:
On Sat, 2011-10-01 at 10:26 +0200, Florian Klämpfl wrote:
Am 30.09.2011 15:02, schrieb Joost van der Sluis:
Please test this gdb-version, and tell me about your experiences.
Especially Martin. ;)
Oh, you can download it here:
http://www.lazarus
On Mon, 2011-10-03 at 16:40 +0200, Pierre Free Pascal wrote:
>
> > -Message d'origine-
> > De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
> > boun...@lists.freepascal.org] De la part de Joost van der Sluis
> > Envoyé : lundi 3 octobre 2011 16:29
> > À : FPC developers' list
> -Message d'origine-
> De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
> boun...@lists.freepascal.org] De la part de Joost van der Sluis
> Envoyé : lundi 3 octobre 2011 16:29
> À : FPC developers' list
> Objet : RE: [fpc-devel] New Windows gdb-binary
>
> On Sat, 2011-10-0
On 03 Oct 2011, at 16:06, Alexander Klenin 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 think http://wiki.freepascal.o
On Sat, 2011-10-01 at 11:00 +0200, Pierre Free Pascal wrote:
> Did you use the mingw 7.3 patch that handles
> the windows style path containing ':'?
No.
> I recreated the patch below by doing a diff
> from official GDB 7.3 release
> and mingw7.3.2 sources.
>
> Without this, debug informati
On Sat, 2011-10-01 at 10:26 +0200, Florian Klämpfl wrote:
> Am 30.09.2011 15:02, schrieb Joost van der Sluis:
> > Please test this gdb-version, and tell me about your experiences.
> > Especially Martin. ;)
> >
> > Oh, you can download it here:
> > http://www.lazarussupport.com/gdb_lazarssupport_201
On Sat, 2011-10-01 at 09:24 +0100, Martin wrote:
> I noticed, when I build fpc, then I get cpu usage between 70% and 100%.
> So it appears that both cores of my pentium are used.
>
> But when a package is compiled using fpmake, then it drops to 50%, so
> apparently only one core is used?
>
> Is
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 burned by this myself.
>
> When?
Am 03.10.2011 16:06, schrieb Alexander Klenin:
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 wh
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 3:42 PM, Florian Klämpfl wrote:
> That's why I proposed a branch and that's what branches are for.
So far we had two against and one maybe a small part of it ...
seriously I think it is unrealistic to expect that if there is
virtually no support from fpc developers for the
On 03 Oct 2011, at 15:49, Paul Ishenin wrote:
As I remember there is a package "lnet" which can be somehow
installed via internet. I don't remember the details but I believe
I've seen this a half year ago or so. Why fpspreadsheet and
fpverctorial together with new utf8 package can't be fol
On Mon, Oct 3, 2011 at 3:49 PM, Paul Ishenin wrote:
> As I remember there is a package "lnet" which can be somehow installed via
> internet. I don't remember the details but I believe I've seen this a half
> year ago or so. Why fpspreadsheet and fpverctorial together with new utf8
> package can't
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.
When?
Anyway, what I suggest is IMO a good compromise and should satisf
Am 03.10.2011 15:32, schrieb Alexander Klenin:
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 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 important part to
> improve software quality.
On 3-10-2011 13:45, Felipe Monteiro de Carvalho wrote:
Also not a solution, because then fpvectorial and fpspreadsheet would
not be able to compile in other RTL modes.
What? You mean you are seeking the solution upstream? Seems
the design of those units is lacking.
_
On Mon, Oct 3, 2011 at 12:40 PM, Marco van de Voort wrote:
> True, because we never planned to have support for such utf8 only libraries
> in the first place.
...
> Then factor out the relevant LCL independent stuff to an external project.
>
> If it is non visual, it doesn't automatically mean it
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 software quality.
___
fpc-devel mailli
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
On Mon, 3 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Mon, Oct 3, 2011 at 11:41 AM, wrote:
Please do not include this package yet.
I'd rather find a consensus on this now then to postpone yet again. I
have patches to merge about this and I have some time now which is
something which c
In our previous episode, Felipe Monteiro de Carvalho said:
>
> Not really. One can write a non-visual library which uses utf8string
> as its main string type, why not? But the RTL is not adequate for
> utf8string projects
True, because we never planned to have support for such utf8 only libraries
Am 03.10.2011 12:20, schrieb Felipe Monteiro de Carvalho:
On Mon, Oct 3, 2011 at 11:41 AM, wrote:
Please do not include this package yet.
I'd rather find a consensus on this now then to postpone yet again. I
have patches to merge about this and I have some time now which is
something which ca
Am 03.10.2011 10:24, schrieb Jonas Maebe:
On 03 Oct 2011, at 10:14, Florian Klämpfl wrote:
FPC doesn't do any optimization in procedures containing inline
assembler.
It does.
Oops, I thought you changed this a while ago :)
___
fpc-devel maillist
Jonas Maebe schrieb:
It does. But also assumes that all registers are used in assembler
blocks, unless the programmer specifies otherwise.
But a:=a+1; does not imply any register usage, and the variable is a
global one?
DoDi
___
fpc-devel maillis
On 01/10/2011 12:56, Mattias Gaertner wrote:
>>
>> Is that correct? Does the old Makefile driven compilation use both/all
>> cores, while packages done via fpmake, are using one core only?
>
> AFAIK the makefile does not use parallel compilation.
Yes it does, at least for compiling FPC itself (o
On Mon, Oct 3, 2011 at 11:41 AM, wrote:
> Please do not include this package yet.
I'd rather find a consensus on this now then to postpone yet again. I
have patches to merge about this and I have some time now which is
something which can disappear at any moment.
> So I suggest you wait till th
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 its main string type, why not? But the RTL is not adequate for
utf8string
On Mon, 3 Oct 2011, Felipe Monteiro de Carvalho wrote:
Hello,
I would like to add a new package to Free Pascal into the directory
packages/fputf8 which will provide classes and routines for UTF-8
applications. It might grow to include things like:
* full unicode tables and conversion routine
In our previous episode, Felipe Monteiro de Carvalho said:
> I would like to add a new package to Free Pascal into the directory
> packages/fputf8 which will provide classes and routines for UTF-8
> applications. It might grow to include things like:
>
> * full unicode tables and conversion routin
Hello,
I would like to add a new package to Free Pascal into the directory
packages/fputf8 which will provide classes and routines for UTF-8
applications. It might grow to include things like:
* full unicode tables and conversion routines
* Equivalents of RTL classes which are not adequate for UT
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
On 03 Oct 2011, at 10:14, Florian Klämpfl wrote:
FPC doesn't do any optimization in procedures containing inline
assembler.
It does. But also assumes that all registers are used in assembler
blocks, unless the programmer specifies otherwise. If you change the
assembler block into
asm
Am 03.10.2011 08:27, schrieb Alexander Klenin:
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
38 matches
Mail list logo
