ik schrieb:
Am I missing something, or should I report it as a bug ?
Which installer did you use?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Thu, Jun 19, 2008 at 10:28 AM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
ik schrieb:
Am I missing something, or should I report it as a bug ?
Which installer did you use?
RPM on Mandriva 2008.1
Ido
--
http://ik.homelinux.org/
___
fpc-devel
Well, it has been a while..
Currently i'm only able to compile linux console applications. For GUI
I'm able to compile them but i do get a lot of linking errors (i copied
a truckload of ubuntu linux libraries, but i'm unsure if i always got
the right versions of the libs). I think it
On the bttr forum, one of the people that helped on the dos release (Laaca)
posted his initial conclusions. Note that the IDE is without debug support
apparantly.
--
I downloaded and briefly tested FPC 2.2.2 rc1 and the impresions are
generaly positive.
+there are my fixes
-generated EXEs are much bigger than in 2.2.0a without obvious reason
(-) not a bugs but missing features:
color selecting dialog still not available
topic help in IDE by pressing CTRL-RMouse still opens only help index but
not the topic like Turbo pascal does.
Hi folks,
It appears that this bug has been fixed. Where I can get a patch for this? This
is a very high priority bug for us, and we are glad that it has already been
addressed :-) . I am very eager to test the fix.
With best regards,
Boian Mitov
On 19 Jun 2008, at 13:10, Boian Mitov wrote:
It appears that this bug has been fixed. Where I can get a patch for
this? This is a very high priority bug for us, and we are glad that
it has already been addressed :-) . I am very eager to test the fix.
Please read the comments to
Hi Jonas,
Thank you!
I don't understand. 0011503 is a major failure. Is it in the compiler or in
some library?
This code:
Atest := TTest.Create();
Atest := NIL;
will release properly the reference at assignment to NIL
this code does not:
Atest := TestFunc();
Atest := NIL;
This is
On 19 Jun 2008, at 13:21, Boian Mitov wrote:
Thank you!
I don't understand. 0011503 is a major failure. Is it in the
compiler or in some library?
Please read the comments to http://bugs.freepascal.org/view.php?
id=9472. The whole issue is discussed there in great detail.
This is a huge
Hi Jonas,
This functionality works in all versions of Delphi 5-2007. We support them
all, and we have done so for years. We have no problems to compile with such
optimizations turned off. We need proper reference counting. We have over
300 Delphi components in 5 released and 3 libraries
On Thu, 19 Jun 2008, Boian Mitov wrote:
Hi Jonas,
This functionality works in all versions of Delphi 5-2007. We support them
all, and we have done so for years. We have no problems to compile with such
optimizations turned off. We need proper reference counting. We have over 300
Hi Michael,
Thank you! I will be looking into the code, and see if I can add the
functionality with some switch. We may redo the code, however it will
probably take well over a year for fully rewriting it all, and it may not be
necessarily a smart thing. Delphi unlike C++ does not have any
Boian Mitov schrieb:
I have downloaded the source, and I will see if we can tweak it and add
some compiler option to support this somehow.
If it would be that easy, we would have done it. It's simply a matter of
the design of compiler/rtl how ref. counting is done. We must draw a
border
PS: It will help me a lot if you guys can at least pint me to what files I
should be looking for to change the behavior of the temp ;-) .
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
On 19 Jun 2008, at 13:53, Boian Mitov wrote:
This functionality works in all versions of Delphi 5-2007. We
support them all, and we have done so for years. We have no problems
to compile with such optimizations turned off.
One final time: please read the comments to
Boian Mitov schrieb:
PS: It will help me a lot if you guys can at least pint me to what files
I should be looking for to change the behavior of the temp ;-) .
See my other mail, this requires not only a simple change in a few files.
___
fpc-devel
Gee... Isn't it the reason we all love C++ ;-) . There all those things
are standardized by the ANSI, and return variable temp must be alive only
for the duration of the statement if you want to call your compiler ANSI
;-) . Then again, don't we all hate the lack of support for singletons in
Thank you Florian, if needed, I will get couple of people to help me on
this one. I appreciate your help!
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
On Thu, 19 Jun 2008, Boian Mitov wrote:
Hi Michael,
Thank you! I will be looking into the code, and see if I can add the
functionality with some switch. We may redo the code, however it will probably
take well over a year for fully rewriting it all, and it may not be
necessarily a
Jonas Maebe schrieb:
On 19 Jun 2008, at 13:53, Boian Mitov wrote:
This functionality works in all versions of Delphi 5-2007. We support
them all, and we have done so for years. We have no problems to
compile with such optimizations turned off.
One final time: please read the comments to
Here is a code sniped that sows just one example of the problem:
This is a very simple example of how important the order really is:
We have even more crucial problems related with this. This is just a simple
one:
destructor TALBasicAudioOut.Destroy();
var
WriteLock : IOWLockSection;
begin
Gee... Isn't it the reason we all love C++ ;-) . There all those things
are standardized by the ANSI, and return variable temp must be alive only
for the duration of the statement if you want to call your compiler ANSI
;-) . Then again, don't we all hate the lack of support for singletons
I will dig for it.
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
- Original Message -
From: Marco van de Voort [EMAIL
Michael Van Canneyt schreef:
On Thu, 19 Jun 2008, Boian Mitov wrote:
Here is a code sniped that sows just one example of the problem:
This is a very simple example of how important the order really is:
We have even more crucial problems related with this. This is just a simple
one:
I will see to ping somebody on the ANSI comity for this one. It takes
forever to dig it out ;-) . I will let you know.
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
I will see to ping somebody on the ANSI comity for this one. It takes
forever to dig it out ;-) . I will let you know.
Thanks.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Boian Mitov schrieb:
Here is a code sniped that sows just one example of the problem:
This is a very simple example of how important the order really is:
Unfortunatly, I can quote only from the german delphi help: Wenn Sie
die Referenzzählung nutzen wollen, dürfen Sie das Objekt nur als
On 19 Jun 2008, at 14:36, Michael Van Canneyt wrote:
On Thu, 19 Jun 2008, Boian Mitov wrote:
Here is a code sniped that sows just one example of the problem:
This is a very simple example of how important the order really is:
We have even more crucial problems related with this. This is
Hi Florian,
FLock is not interface. There is no error with the FLock.
WriteLock is interface, and I have to destroy it before I destroy the FLock.
The order of destruction is obviously crucial.
The error is the fact that WriteLock referenced object is not released when
WriteLock is
This is not very precise. You are referring to garbage collection in
general. Reference counting as it used to be defined in the original COM
specification for DLL and statically linked objects specifically states that
the object will be destroyed as soon as the last reference to it is lost.
On Thu, 19 Jun 2008, Boian Mitov wrote:
This is not very precise. You are referring to garbage collection in general.
Reference counting as it used to be defined in the original COM specification
for DLL and statically linked objects specifically states that the object will
be destroyed as
Boian Mitov schrieb:
Hi Florian,
FLock is not interface. There is no error with the FLock.
To which instance is WriteLock an interface? FLock?
WriteLock is interface, and I have to destroy it before I destroy the
FLock. The order of destruction is obviously crucial.
The error is the
Michael,
I never call Free() on interfaced object. I surely know that if I have used
interfaces for the last 10 years or so ;-) .
What I need is a way to make sure that all the references are gone. This is
the first non garbage collected compiler that has prevented me from
releasing all
Hi Marco,
I have found it :-)
This is one of the draft, but that part has hardly changed:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf
Page 244
Item 3 describes the lifespan of a temporary object in expression (rvalue
life span):
3 When an implementation introduces a
Boian Mitov schrieb:
Michael,
I never call Free() on interfaced object. I surely know that if I have
used interfaces for the last 10 years or so ;-) .
See my other mail. You do a WriteLock:=FLock.StopLock(); call. Every
interface is associated with a class instance. With which class
function TOWLock.StopLock() : IOWLockSection;
begin
Result := TOWSimpleStopLockSection.Create( Self );
end;
This is a completely different object.
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
No,
function TOWLock.StopLock() : IOWLockSection;
{$ENDIF}
begin
Result := TOWSimpleStopLockSection.Create( Self );
end;
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
Hi Marco,
You are wrong. They mean expression not block!
This is one block with 3 expressions:
{
a = 3 + 4;
b = 5 + 3;
c = 3 + 7;
}
If an temporary variable is created it must be destroyed before the ;
symbol, not at the end of the block!
This is vary good as it prevent any optimization
Boian Mitov schrieb:
Hi Marco,
You are wrong. They mean expression not block!
This path of the discussion is useless. As soon as you make WriteLock a
global/static var, delphi behaves the same as fpc: it creates a temp.
ref. which is only cleaned at procedure exit.
Hi Florian,
Thank you!
This is false! In Delphi the interface is released immediately. Before you
make such statement I advise you to verify the Delphi behavior. I can ensure
you that D5, 6, 7, 2005, 2006, 2007 as well as BCB 5, 6, 2006, and 2007 will
release the object before the end of
On 19 Jun 2008, at 15:20, Boian Mitov wrote:
never call Free() on interfaced object. I surely know that if I
have used interfaces for the last 10 years or so ;-) .
What I need is a way to make sure that all the references are gone.
This is the first non garbage collected compiler that has
Boian Mitov schrieb:
Hi Florian,
Thank you!
This is false! In Delphi the interface is released immediately.
No.
Before
you make such statement I advise you to verify the Delphi behavior.
I did so because I discussed this behaviour several times before. Just
compare the output of and
Florian Klaempfl schrieb:
Jonas Maebe schrieb:
The behaviour you are counting on is a side effect of an optimisation,
not a behaviour by design.
Oh, btw: fpc 2.2.2rc1 behaves with -O2 like delphi :) Without -O2 like
2.2.0 :)
Add: I just realized that Peter implemented this some time ago in
Hi Jonas,
Delphi seems to be a fairly good player in terms of this behavior. I have
been using interfaces for many years, and they have worked as expected. You
can verify this with the code snipped from the bug report. I am excited
however by the last Florian post. I will have to figure
On 19 Jun 2008, at 16:06, Florian Klaempfl wrote:
Florian Klaempfl schrieb:
Jonas Maebe schrieb:
The behaviour you are counting on is a side effect of an
optimisation, not a behaviour by design.
Oh, btw: fpc 2.2.2rc1 behaves with -O2 like delphi :) Without -O2
like 2.2.0 :)
Add: I just
Boian Mitov schrieb:
Thank you! I will see to get the 2.2.2rc1 and compile with the switch
:-) . I will validate if it behaves the same way and will let you know
:-) . I am very excited that there could be a ready solution :-) .
I still recommend that you think about changing your design,
I understand and appreciate your input. If needed I will tweak some places
of the library. This is not problem. We have done some other changes as
well. As long as in most cases it works well we are happy ;-) . Porting all
of our products will take months of work and effort, but we are
Hmm... Florian, I seem to be finding only downloads for 2.2.0 . Where I
can get 2.2.2rc1 ?
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
On Thu, 19 Jun 2008, Boian Mitov wrote:
Hmm... Florian, I seem to be finding only downloads for 2.2.0 . Where I can
get 2.2.2rc1 ?
See download link on www.freepascal.org main page, first (english) news
item.
Michael.
With best regards,
Boian Mitov
The FTP server seems really slow to respond. Do you want me to setup an FTP
account for you guys on one of my servers, so you can upload in the future
Beta stuff there for easier access for everybody?
With best regards,
Boian Mitov
On Thu, 19 Jun 2008, Boian Mitov wrote:
The FTP server seems really slow to respond. Do you want me to setup an FTP
account for you guys on one of my servers, so you can upload in the future
Beta stuff there for easier access for everybody?
There are many mirrors; The main site just points
Hi Michael,
Finally the server responded. This file is not on the mirrors :-( . It is
only on the FTP.
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
On Thu, 19 Jun 2008, Boian Mitov wrote:
Hi Michael,
Finally the server responded. This file is not on the mirrors :-( . It is only
on the FTP.
Strange, I would think that the FTP mirrors picked it up by now ?
Michael.
___
fpc-devel maillist
Hi Michael,
Maybe I was looking at the wrong place. I was looking at SourceForge
initially, and saw 2.2.0 files only. I am still learning where the
FreePascal files and resources are, so it could be my fault. Maybe they ware
picking it and that is why it took me 50 minutes just to open
54 matches
Mail list logo
