Martin Schreiber schrieb:
>>> http://www.freepascal.org/mantis/view.php?id=6036
>> It doesn't look like that is going to be fixed any time soon. It was
>> reported in 2005-06-14 and still hasn't even been acknowledged!
I've no clue how it is supposed to work :)
>>
> :-)
> Reference counted widest
Since I assume the DLL use is the scenario that is wanted,
it de facto means that you must use widestrings.
What about old fashioned PChar ? Everybody using the Windows and Linux
APIs is used to that.
-Michael
___
fpc-devel maillist - fpc-deve
Michael Van Canneyt wrote:
Classes:
- No reference counting mess. - Easier to grasp conceptually.
In plugin dll?
Sure. Why not ?
Obviously, the DLL needs to use packages, but that is understood.
I mean what is easier to grasp conceptually when you use class in dll
instead of interface?
On Friday 30 November 2007 11.22, Florian Klaempfl wrote:
> > I forgot to mention that the Delphi 'implements' keyword
>
> FPC supports this? Thought some bugs are known iirc.
>
Is the following from Delphi 7 help possible with FPC?
"
If the delegate property is of a class type, that class and its
On Nov 30, 2007 10:12 AM, Michael Schnell <[EMAIL PROTECTED]> wrote:
> What is the advantage of interfaces anyway (seems that I have been
> missing something ... )
One advantage is that it can be easely used on many languages,
althougth the usefulness of that for ideintf is probably very small.
-
Op Fri, 30 Nov 2007, schreef Felipe Monteiro de Carvalho:
> What do other FPC developers think of this?
>
> Should it be the responsability of the fpc user to write it's own
> routines to override the output of the widestring manager or should
> FPC provide this mechanism?
The default widestri
What do other FPC developers think of this?
Should it be the responsability of the fpc user to write it's own
routines to override the output of the widestring manager or should
FPC provide this mechanism?
thanks,
--
Felipe Monteiro de Carvalho
___
fpc
> On 30 Nov 2007, at 15:27, Marco van de Voort wrote:
>
> > Well, those are not numbers I'm interested in anyway. Sparc doesn't
> > feature
> > binwriter
>
> Why would the presence/absence of an integrated assembler make a
> difference?
Performance is not just CPU, but also disk and startup
On 30 Nov 2007, at 15:27, Marco van de Voort wrote:
Well, those are not numbers I'm interested in anyway. Sparc doesn't
feature
binwriter
Why would the presence/absence of an integrated assembler make a
difference? At least make -j doesn't do any assembling in parallel
with the rest whe
Micha Nelissen schrieb:
> Florian Klaempfl wrote:
>> OTOH2, using no build unit but compiling with make -j is faster on multi
>> core systems.
>
if (Micha==0)
multi_threaded_fpc=0;
else
multi_threaded_fpc++;
___
fpc-devel maillist - fpc
Marco van de Voort schrieb:
>> Florian Klaempfl schrieb:
>> OTOH, this might be solved indeed in the future by splitting the rtl.
>> OTOH2, using no build unit but compiling with make -j is faster on multi
>> core systems.
>
> Is it? Do you have numbers?
I tested once on Paul Davidson's quad core
Florian Klaempfl wrote:
OTOH2, using no build unit but compiling with make -j is faster on multi
core systems.
multi_threaded_fpc++ :-)
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-d
Florian Klaempfl schrieb:
> Micha Nelissen schrieb:
>> Florian Klaempfl wrote:
>>> Micha Nelissen schrieb:
Well, the best optimization is not needing to do something at all ;-).
>>> So you see a way to do make cycle in one compiler call ;)?
>> Obviously not the three cycles, but maybe one cycl
Micha Nelissen schrieb:
> Florian Klaempfl wrote:
>>> 8 seconds instead of 1min20 is better, don't you think?
>>
>> Oh great, please tell me how you accelerated make and process start
>> times.
>
> Well, the best optimization is not needing to do something at all ;-).
>
So you see a way to do ma
Marc Weustink schreef:
Vincent Snijders wrote:
Michael Van Canneyt schreef:
I find classes more natural than interfaces. It 'just works'. Not so
with interfaces, because you must do a typecast every time.
Compare
Function GetPluginInterface : ISOmeThing;
begin
X:=MyPluginObjectXYZ.Creat
OK, Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Vincent Snijders wrote:
Michael Van Canneyt schreef:
I find classes more natural than interfaces. It 'just works'. Not so
with interfaces, because you must do a typecast every time.
Compare
Function GetPluginInterface : ISOmeThing;
begin
X:=MyPluginObjectXYZ.Create;
Result:=X as ISomet
Michael Van Canneyt schreef:
I find classes more natural than interfaces. It 'just works'.
Not so with interfaces, because you must do a typecast every time.
Compare
Function GetPluginInterface : ISOmeThing;
begin
X:=MyPluginObjectXYZ.Create;
Result:=X as ISomething;
end;
This is then
On 30/11/2007, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>
> > and the interface
> > method resolution clauses would be useful too.
>
> What this?
>
I think he means when a class implements a inferfaces and somewhere in
the class hierarchy, there already exists a method with the same name.
You
I even do have that book right behind me on the shelf.
Silly me should have looked there :(.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 30/11/2007, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>
> This works iirc too?
That's what I remember as well
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
On 30 Nov 2007, at 11:49, Martin Schreiber wrote:
Delphi 7 is 10 times faster than FPC 2.2.
8 seconds instead of 1min20 is better, don't you think?
That very much depends on the trade-offs. If there are none: fine.
However, if it requires to go back to a compiler design similar to
that of
On Friday 30 November 2007 09.59, Florian Klaempfl wrote:
> Martin Schreiber schrieb:
> >>> http://www.freepascal.org/mantis/view.php?id=6036
> >>
> >> It doesn't look like that is going to be fixed any time soon. It was
> >> reported in 2005-06-14 and still hasn't even been acknowledged!
>
> I've
On Fri, 30 Nov 2007, Paul Ishenin wrote:
>
>
> Michael Van Canneyt пишет:
> > On Thu, 29 Nov 2007, Mattias Gaertner wrote:
> >
> >
> > > Lazarus has the IDEIntf, the API for IDE plugins.
> > >
> > > What is better in this case: classes or interfaces?
> > >
> >
> > Classes:
> > - No ref
> > What is better in this case: classes or interfaces?
> >
> What is the advantage of interfaces anyway (seems that I have been
> missing something ... )
A limited form of multiple inheritance.
> I _thought_ it would be reference counting, but in the other thread
> someone wants to (and do
What is better in this case: classes or interfaces?
What is the advantage of interfaces anyway (seems that I have been
missing something ... )
I _thought_ it would be reference counting, but in the other thread
someone wants to (and does) use Interfaces without reference counting.
-Mich
Daniël Mantione schreef:
Op Mon, 26 Nov 2007, schreef Paul Ishenin:
Daniël Mantione wrote:
This patch is not correct because there might still be unread data in the
zlib data buffers; this patch makes no attempt to flush them.
Daniël
This patch only do repositioning of Source stream to apr
Martin Schreiber schrieb:
> On Friday 30 November 2007 11.23, Graeme Geldenhuys wrote:
>
>>> Delphi 7 is 10 times faster than FPC 2.2.
>>> 8 seconds instead of 1min20 is better, don't you think?
>> I'll bite. :-)
>> What can I compile to do a speed comparison? How do I compile MSEgui
>> under De
> Micha Nelissen schrieb:
> > Florian Klaempfl wrote:
> >> OTOH2, using no build unit but compiling with make -j is faster on multi
> >> core systems.
> >
>
> if (Micha==0)
> multi_threaded_fpc=0;
> else
> multi_threaded_fpc++;
Cough!
___
fp
Michael Van Canneyt wrote:
No-one. The DLL must be recompiled anyway if you use packages.
And this is also true if you use interfaces, so using interfaces
will not solve the problem you mention.
Only if compiler (who provides package system) changed. Ide changes will
not cause recompilation o
Daniël Mantione ha scritto:
Op Thu, 29 Nov 2007, schreef Alvise Nicoletti:
I added a /usr/lib32 link to the fpc.cfg, however I have no "crti.o" in the
/usr/lib32/ folder.
I got the same error trying to cross-compile to a i386 target.
/usr/lib/crti.o is a "ELF 64-bit LSB relocatable, AMD x86
[ Charset ISO-8859-1 unsupported, converting... ]
> On Friday 30 November 2007 11.22, Florian Klaempfl wrote:
> > > I forgot to mention that the Delphi 'implements' keyword
> >
> > FPC supports this? Thought some bugs are known iirc.
> >
> Is the following from Delphi 7 help possible with FPC?
int
Graeme Geldenhuys schrieb:
> On 30/11/2007, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>>> and the interface
>>> method resolution clauses would be useful too.
>> What this?
>>
>
>
> I think he means when a class implements a inferfaces and somewhere in
> the class hierarchy, there already exist
On 30/11/2007, Martin Schreiber <[EMAIL PROTECTED]> wrote:
> >
> I forgot to mention that the Delphi 'implements' keyword and the interface
> method resolution clauses would be useful too.
>
Aren't those already supported in FPC 2.2.0? I thought 'implements'
was around some some time now.
>
> D
Martin Schreiber schrieb:
> On Friday 30 November 2007 09.59, Florian Klaempfl wrote:
>> Martin Schreiber schrieb:
> http://www.freepascal.org/mantis/view.php?id=6036
It doesn't look like that is going to be fixed any time soon. It was
reported in 2005-06-14 and still hasn't even been
On 30/11/2007, Michael Schnell <[EMAIL PROTECTED]> wrote:
> >
> What is the advantage of interfaces anyway (seems that I have been
> missing something ... )
>
Many others have answered this already, so I'm not going to type out
the answer. Instead, I'll just quote some of them This should
gi
On Friday 30 November 2007 10.26, Michael Van Canneyt wrote:
>
> When you pass an interface that uses ansistrings to a DLL,
> the ansistrings in it (or referenced by it) may be disposed
> of by the wrong memory manager.
>
> Since I assume the DLL use is the scenario that is wanted,
> it de facto me
Op Fri, 30 Nov 2007, schreef Martin Schreiber:
> On Friday 30 November 2007 10.26, Michael Van Canneyt wrote:
> >
> > When you pass an interface that uses ansistrings to a DLL,
> > the ansistrings in it (or referenced by it) may be disposed
> > of by the wrong memory manager.
> >
> > Since I ass
Florian Klaempfl wrote:
8 seconds instead of 1min20 is better, don't you think?
Oh great, please tell me how you accelerated make and process start times.
Well, the best optimization is not needing to do something at all ;-).
Micha
___
fpc-devel ma
On Fri, 30 Nov 2007, Paul Ishenin wrote:
> Michael Van Canneyt wrote:
>
> > > > Classes:
> > > > - No reference counting mess. - Easier to grasp conceptually.
> > > >
> > > In plugin dll?
> >
> > Sure. Why not ? Obviously, the DLL needs to use packages, but that is
> > understood.
>
> I me
On Friday 30 November 2007 11.23, Graeme Geldenhuys wrote:
> > Delphi 7 is 10 times faster than FPC 2.2.
> > 8 seconds instead of 1min20 is better, don't you think?
>
> I'll bite. :-)
> What can I compile to do a speed comparison? How do I compile MSEgui
> under Delphi 7?
>
http://www.mail-archi
> That's probably the end of that computer lazarus installation, I can't
> risk to mess up the libs again.
Personally, I use a 32 bit chroot environment to avoid headaches. The only
drawback is that you need root privileges to run chroot.
I wrote some bash scripts (very ugly and without error c
Florian Klaempfl wrote:
Micha Nelissen schrieb:
Well, the best optimization is not needing to do something at all ;-).
So you see a way to do make cycle in one compiler call ;)?
Obviously not the three cycles, but maybe one cycle could be done by not
compiling the RTL, but by starting to co
Micha Nelissen schrieb:
> Florian Klaempfl wrote:
>> Micha Nelissen schrieb:
>>> Well, the best optimization is not needing to do something at all ;-).
>>
>> So you see a way to do make cycle in one compiler call ;)?
>
> Obviously not the three cycles, but maybe one cycle could be done by not
> co
Florian Klaempfl wrote:
Well, problem is that then not all units are build and you don't want to
pull in variants etc. into the compiler :)
rtl_extra++ :-)
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/ma
On Fri, 30 Nov 2007, Paul Ishenin wrote:
> Michael Van Canneyt wrote:
> > No-one. The DLL must be recompiled anyway if you use packages.
> > And this is also true if you use interfaces, so using interfaces
> > will not solve the problem you mention.
> >
> Only if compiler (who provides packag
> Florian Klaempfl schrieb:
> OTOH, this might be solved indeed in the future by splitting the rtl.
> OTOH2, using no build unit but compiling with make -j is faster on multi
> core systems.
Is it? Do you have numbers?
___
fpc-devel maillist - fpc-deve
On Fri, 30 Nov 2007 13:22:54 +0100 (CET)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 30 Nov 2007, Paul Ishenin wrote:
>
> > Michael Van Canneyt wrote:
> > > No-one. The DLL must be recompiled anyway if you use packages.
> > > And this is also true if you use interfaces, so usin
On Fri, 30 Nov 2007, Mattias Gaertner wrote:
> On Fri, 30 Nov 2007 13:22:54 +0100 (CET)
> Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Fri, 30 Nov 2007, Paul Ishenin wrote:
> >
> > > Michael Van Canneyt wrote:
> > > > No-one. The DLL must be recompiled anyway if you use pa
> Marco van de Voort schrieb:
> >> Florian Klaempfl schrieb:
> >> OTOH, this might be solved indeed in the future by splitting the rtl.
> >> OTOH2, using no build unit but compiling with make -j is faster on multi
> >> core systems.
> >
> > Is it? Do you have numbers?
>
> I tested once on Paul Da
50 matches
Mail list logo
