produce an
working executable)?
Peter Popov
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On the other hand without this you already mentioned that you will need
to create a list containing all the buffers. What is the performance
impact on adding, removing from the list? What about the support code?
What buffers? I destroy objects explicitly. The objects that need work
create a
Boian,
since you keep on repeating the false argument that reference counting
will somehow speed up parallel performance, I will restate the obvious:
using reference counting will decrease parallel performance for the
following obvious reasons:
1. Each reference assignment involves an atomic opera
On Mon, 22 Sep 2014 21:34:34 +0300, Boian Mitov wrote:
Strongly disagree...
For multithreading and parallel processing ARC is lifesaver. I have been
using it trough interfaces for 10 years already, and once I rewrote the
old code to use ARC it was a huge performance boost, and it keeps
g
question is: is there a standard for the memory layout of
multidimensional variant arrays.
As a remark, the relevant Kylix code also had bugs.
Peter Popov
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin
From: jonas.ma...@elis.ugent.be
To: fpc-devel@lists.freepascal.org
Date: Mon, 22 Sep 2014 17:11:08 +0200
Subject: Re: [fpc-devel] weak referencing (was Suggestion:.)
I would strongly recommend against that. Referenced and unreferenced objects
are completely different beasts with different
How will referenced objects behave when referenced by a threadvar. This is an
exceptional situation for both dynamic arrays and ansi strings.
Another comment: If referenced objects all derive from a single base, then, the
user cannot possibly have another hierarchy, which uses ref. objects. As
> > Because you'll need to declare an interface for each class you want to
> > have reference counted so that you can access its methods, properties,
> > etc.
> >
> Con: more typing
> Pro: you know what you are doing.
I cannot agree more.
_
---
-Original Message- From: Peter Popov
Sent: Sunday, September 21, 2014 12:29 PM
To: fpc-devel@lists.freepascal.org ; Sven Barth
Subject: Re: [fpc-devel] Suggestion: reference counted objects
Sven,
based on your comments a bizarre thought
---
-Original Message- From: Peter Popov
Sent: Sunday, September 21, 2014 12:29 PM
To: fpc-devel@lists.freepascal.org ; Sven Barth
Subject: Re: [fpc-devel] Suggestion: reference counted objects
Sven,
based on your comments a bizarre thought came to me. Currently, class
Sven,
based on your comments a bizarre thought came to me. Currently, class
instances are pointers. What you propose will somehow create a special
pointer type (referenced class).
Should this be done, I have a request: create a 4 byte "compressed" class
reference which expands into an 8 byte poin
Interfaces, among other things, are a way to bring in some features from
multiple inheritance. I think the term is one-sided multiple inheritance.
If multiple inheritance is good or bad is a separate topic. With time, one
begins to doubt the utility of classes in the first place and starts to
citly reference counted (an all
descendants, presubably). However, not TObject.
Peter
With best regards,
Boian Mitov
---
Mitov Software
www.mitov.com
---
-Original Message- From: Peter
20.09.2014 13:11, Peter Popov wrote:
Please do not reference count TObject. This is a uniquely bad and
unnecessary idea. I will switch to ANSI C if you guys do it
Please enlighten me why you think it is bad. Give reasons and don't be
like "a farmer doesn't eat what he doesn
Please do not reference count TObject. This is a uniquely bad and
unnecessary idea. I will switch to ANSI C if you guys do it
Peter
On Sat, 20 Sep 2014 13:52:57 +0300, Sven Barth
wrote:
On 20.09.2014 12:36, Hans-Peter Diettrich wrote:
FabrÃcio Srdic schrieb:
Hello,
In platforms with
I am interested.
On Sat, 20 Sep 2014 00:38:26 +0300, Boian Mitov wrote:
Hi Jonas,
I am sorry if I have misinterpreted the meaning of the message.
I am just terribly frustrated with the overall state of the FPC :-( .
I even offered to donate our enhanced RTTI API to the FPC community with
ure
of the code it is to represent. The key is the RTTI generated for
automated methods (although we need a hack to get the auto table start
pointer).
Something like this would be extremely useful if we are to fully switch to
fpc.
Peter Popov
on Sat, 20 Sep 2014 00:14:42 +0300, silvioprog
wrote
An example would be
TItemCache = class
private
const DEFAULT_CACHE_SIZE = 1024;
...
end;
sure a global value would do, but there is no need for the value to be
global.
Martin
This is a good example. However, the same paradigm can be achived by a
function:
function TItemCache.DEFAU
On Mon, 19 Oct 2009 04:02:45 -0500, wrote:
> All features being equal, I would rather have class constants and
class
> types
> included in FPC.
Class constants are exceptionally bad idea: I've seen a guy define
PI=3.1415... inside a C++ class! The same functionality already exists
in
fpc:
All features being equal, I would rather have class constants and class
types
included in FPC.
Class constants are exceptionally bad idea: I've seen a guy define
PI=3.1415... inside a C++ class! The same functionality already exists in
fpc: define a (class, inline) function returning the
other OOP framework to be used but not
abused. Maybe use "imported" instead of "sealed".
As for abuse of concepts - the richer a language becomes, the more paths
to abuse it. no way around that.
Peter Popov
On Fri, 16 Oct 2009 16:51:41 -0500, Sergei Gorelkin
wro
within FPC code.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
|***|
|
ul 2009 15:27:46 -0500, Jonas Maebe
wrote:
On 29 Jul 2009, at 22:28, Peter Popov wrote:
I was able to trace it to the unwinding of the gcc exception handler
for the terminating thread. An obvious assertation fails (in
unwind-dw2.c), which means that some basic startup data of gcc is
Thanks for the earlier remarks.
Note that by looking at the Kylix implementation in detail, you make it
very hard for us to ever accept run time library patches from you for
those part os the RTL, because you are tainting yourself this way (in
the sense of copyright).
I work strictly
I was able to trace it to the unwinding of the gcc exception handler
for the terminating thread. An obvious assertation fails (in unwind-
dw2.c), which means that some basic startup data of gcc is either 1)
messed up 2) not initialized.
The problem is probably that FPC either does not genera
etc. That is, nothing, except orderly
initialization of libc.
I will welcome any suggestions
Thanks
Peter Popov
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I have been testing lately fpc 2.2.4 on a linux powerpc5+. I am seeing
some issues with threads. I use cthreads and a very simple test crashes
with segmentation fault. Is anyone aware of known issues with threads on
linux/powerpc? I am not posting this is a bug yet because the platform is
w
sion
for compilation with Visual Studio, along with pascal interface. It goes
standard on most linux distributions (libgmp.so)
Cheers,
Peter Popov
On Sat, 28 Feb 2009 09:03:33 -0600, Michael Van Canneyt
wrote:
On Sat, 28 Feb 2009, Alexander Klenin wrote:
Is there such a thing for FPC?
I n
eneous networks (clouds, as it is called these days):
mpC.
Peter Popov
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
discussion.
Peter Popov
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
It may not be relevant, but do you specify a timeout for the wait?
Peter
On Wed, 17 Sep 2008 05:54:03 -0500, Graeme Geldenhuys
<[EMAIL PROTECTED]> wrote:
Hi,
I posted the original message in the fpc-users mailing list, but after
a few replies, I seem to think it's a bug in FPC. Hence I dec
Thanks for the detailed answer. I think the picture now is clear enough to
start working
Peter
On Sat, 13 Sep 2008 17:41:39 -0500, Jonas Maebe
<[EMAIL PROTECTED]> wrote:
On 13 Sep 2008, at 21:49, Peter Popov wrote:
I read Felipe's wiki thouroughly and i think I can manage t
ting the actual compiler branch. Unless you advise
otherwise I will generate a linux-darwin cross and start experimenting
with option 1.
Peter
On Sat, 13 Sep 2008 03:24:42 -0500, Jonas Maebe
<[EMAIL PROTECTED]> wrote:
On 11 Sep 2008, at 20:36, Peter Popov wrote:
Peter
It sh
Could you give me some pointers how to begin?
Peter
It should not be that hard. There are two main ABI's for PowerPC: the
sysv and the aix ABI. Linux/*BSD use the sysv ABI, and Mac OS, Mac OS X
and AIX uses the aix ABI. Hence, the aix abi is already supported in the
compiler. A libc-based
generate
binaries that would run on AIX? Depending on the complexity of the issue I
am willing to give it a try.
Thanks
Peter Popov
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
You get a pointer to some place where you may store 0 bytes, so nothing
:-).
This can be useful because otherwise you may think the allocation failed
if you get nil back. (And you've disabled heap exception).
you have a point
In FPC it is done by design. If 0 bytes are asked we allocate at
4 Sep 2008 14:27:35 -0500, Micha Nelissen <[EMAIL PROTECTED]>
wrote:
Peter Popov wrote:
size is 0 (realloc does). On the other hand, assigning something is a
bad idea too, as it suggests at least Size(pointer) amount of storage,
unless that memory spot is somehow marked as "empty&q
e reported as a feature, or should the
definition of GetMem be changed to cover this case. Note that it is
desirable to specify explictly what GetMem(p, 0) should do, since one can
in principle provide a separate heap manager. Therefore, behavior of
use-supplied getmem should be unniform
(MyFunc(20), time_out) of
csSignaled: ...
csTimeout: ...
end;
Best regards to all.
Peter Popov
On Thu, 31 Jul 2008 04:02:28 -0500, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
Before we discuss endless about useless stuff, I'll make a proposal for
a first addition: sup
- Original Message ----- From: "Peter Popov" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Friday, June 20, 2008 6:10 PM
Subject: Re: [fpc-devel] semaphores and mutes
Where do you want me to post it?
Peter
On Fri, 20 Jun 2008 17:37:58 -0500, Boian
ov.com
- Original Message - From: "Peter Popov" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Friday, June 20, 2008 3:32 PM
Subject: Re: [fpc-devel] semaphores and mutes
Anyways, some time ago I debuged the issue
is a total mess. Anyways,
if one explicitly instructs the kylix linker which version of semaphore
functions to use (they have to be consistent) TEvent.WaitFor can be
implemnted for any timeout. If there is interest I can post the patch.
Peter Popov
On Fri, 20 Jun 2008 17:13:11 -0500, Boia
ustom hierarchy of
classes in a single-sourced library, then the search can be O(1) within
the library and O(Depth) outside. If the custom class is near the top of
the tree, say TPersistent, that the algorithm will be fast
Peter Popov
On Sat, 21 Jul 2007 15:14:56 -0500, Bram Kuijvenhoven
&l
good job to piss off people,
we can't do better.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
|***|
|
developpers. On the other hand, say any stable fpc release should be
able
to compile (on win32), without trouble the entire VCL of say, delphi
2-5.
I don't see why that is a focus point. It's a nice testsuite, but until
it
is free, there is no real benefit in it. Specially since the VCL-
You can find binding here:
http://andy.jgknet.de/oss/kylix/wiki/index.php/Qt3Clx
The binding on the pascal side are quite nice. You will have troubles
finding qtc (c binding for qt3). You most likely have to recompile
yourself.
Peter
On Sun, 13 May 2007 06:11:37 -0500, ik <[EMAIL PROTECT
On Sat, 12 May 2007 15:40:49 -0500, ik <[EMAIL PROTECTED]> wrote:
Hi,
Ok, you dragged me into responding this subject as well :)
While it might sound as such, this is not Windows vs Linux fight, only
a point of view for an ex Delphi developer, and a 5 years of Linux
users (as only OS).
Corre
ently. But it will be a big boost for FPC if delphi
compatibility stops being and issue.
Best regards
Peter Popov
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
does that with
automated methods (and later versions for backward compatibility).
I will appreciate a lot any information/help/hints!
Thanks
Peter Popov
--
Peter Popov
Postdoctorial Research Assistant,
Institute for Scientific Computation
Te
automation table information on the compiler side. It doesn't have
to go as far as variant support for TAutoObject, etc.
Thanks
Peter Popov
--
|***|
| |
| Peter
Op Mon, 22 Jan 2007, schreef Felipe Monteiro de Carvalho:
> Maybe the compiler could hide the
> procedurization/re-object-orientation, thus making interfacing easier.
Already looked at many times, but it is not realistic.
Can you point me to previous discussion of this? Or perhaps a short
expla
Yes, this is the original purpose of interfaces in Delphi 3 and later:
reuse object code from different languages/executables through COM/DCOM or
CORBA. Both define standards for RPC (Remote procedure calling) and
passing arguments (type and size). An interface only exports member
functions
About the name mangling: this thing is compiler specific. To have really
portable code, whoever compiled the DLL should include flattened
procedural API model without name mangling. See the Kylix QT libraries:
borland have compiled their own version of Qt2.3.0 and have exported
things in a
to start with, just disconsider it.
Disclaimer: I know very little on the subject, so feel free to correct
me =)
thanks,
--
|***|
| |
| Peter Popov, |
|
The simple answer is that you cannot reliably mix object oriented
langugages without severe portability issues and without loosing basic
functionality: polymorphism. You simply cannot extend the functionality of
a class written in one language from another language.
ON THE LINKING PART: all
/mantis/view.php?id=6940), which is exactly what
you would need to interface with a C++ library.
Peter
On Tue, 15 Aug 2006 11:12:08 +0200, Jonas Maebe
<[EMAIL PROTECTED]> wrote:
On 15 Aug 2006, at 09:13, Peter Popov wrote:
I have the following question: how are open array para
Double; const high: Integer); cdecl;
The reason is simple, it's equal to C's code...
Open arrays are voodoo magic, specially for C\++ compilers..
Ido
On 8/15/06, Peter Popov <[EMAIL PROTECTED]> wrote:
Hi
I have the following question: how are open array parameters currently
implemente
vice versa.
I know that fpc does not like open array functions declared with cdecl. So
I am wondering wath is the internal representation and are such functions
binary equivalent to the above C++ example?
For more information, see bug:
http://www.freepascal.org/mantis/view.php?id=6940
typecasting) and pass it as an open
array parameter. Even without typecasting, this will let me compile
existing delphi code.
Thanks
Peter
--
Peter Popov
Postdoctorial Research Assistant,
Institute for Scientific Computation
Texas A&M Univer
59 matches
Mail list logo
