Re: [fpc-devel] Local procedures as procedural parameter
Jonas Maebe wrote: Couldn't the framepointer be last parameter in all modes ? That would still require some ugly hacks inside the parameter passing code, because of the fact that on x86 the callee removes the parameters from the stack and not the caller (so you'd still need a check comparing that framepointer wil nil and not pushing it if it is nil). From the many contributions I got the following picture: 1) Local subroutines expect an framepointer, regardless of whether being called from their enclosing subroutine, or from outside (as a callback). This parameter must be passed, and possibly be removed from the stack, in every call to, and return from, a local subroutine. All the technical details are already specified, by the current handling of local calls to local subroutines. 2) The compiler must check every call for local/global subroutines, in order to supply or omit the framepointer. The only remarkable difference are static/dynamic checks, where direct calls can be handled at compile time, as is, whereas indirect calls would require a distinction at runtime, based on the local/global kind of the actual callback procedure. So I wonder why there should be any problem, besides for the generation of the code for the runtime checks? 3) Procedural parameters already come in two flavours, for global subroutines and methods. The of object type has an additional Self pointer field. It should not be hard to extend the base type with an according Frame pointer field. This extension only is necessary for parameters, not for variables of procedural type, because the compiler should (already!) reject attempts to store references to local subroutines in variables. Of course this change will break compatibility with older binary code, such code must be recompiled with the new compiler version. Such a change may allow for really smart callbacks, where global or local subroutines can be used for the same parameter, as well as methods can be used without an explicit of object clause. In the latter case distinct values must be used for the object (Self) pointer of methods, to distinguish between methods with Self=nil, and ordinary subroutines with no Self pointer at all. The extension of the calling conventions may be a nasty task, but the compiler already has implemented a bunch of calling conventions (cdecl, pascal...) and modifications (method vs. ordinary subroutines, direct vs. indirect calls). Only the very last case needs an update, so that indirect calls have to be checked for local/global subroutines at runtime. As mentioned above (3), additional dynamic support can distinguish and handle global/local and subroutine/method variations appropriately, as 4 distinct cases. Since such smart callbacks require some amount of code, increasing the size and runtime of the compiled code, it's up to the compiler writers to add an compiler mode, option, or a flag, to enable/disable smart callbacks and the according code production. Did I miss anything? What's your opinion on smart callbacks? I mentioned this new construct based on my current observations with comparison functions in sorting procedures. Wouldn't it be nice if one could supply any kind of comparison function (local/global, subroutine/method) to a single sorting procedure? Then the comparison function could check flags and other values in their own runtime environment, e.g. to distinguish between ascending/descending sort order, in a thread-safe environment. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] xf86vmode unit
xf86vmode unit attached xf86vmode.tar.gz Description: application/gzip ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] fink (debian) fpc package for darwin
note: a config file is NOT needed to compile freepascal itself the makefiles pass an option that tells the compiler to ignore it anyway. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dr. Karl-Michael Schindler Sent: 19 March 2005 23:11 To: FPC developers' list Subject: [fpc-devel] fink (debian) fpc package for darwin Hi all, In order to get fpc into fink, the darwin/macosx debian package manager it would be necessary to make available a bootstrap tar ball (640 KB) with the ppcppc binary and a default fpc.cfg file. My suggestion would be the same dir as the fpc source tar ball, i.e. ftp://ftp.freepascal.org/mirrors/fpc/beta/source-1.9.8/ Comments? Questions? Best wishes - Michael Schindler ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing transaction properties specific to IB when using IBConnection
I wrote:
Michael Van Canneyt wrote:
...
I would propose to introduce a enumerated
TSQLTransactionStyle =(tsConcurrent,tsReadCommit, etc.);
Then add a TransactionStyle to TSQLTransaction;
This must be mapped by the TSQLConnection when creating the handle.
...
Indeed, this would be more elegant than my solution, but this would
require finding some common functionality between various databases
(Firebird, PostgreSQL, MySQL, and thinking about others in the future).
I.e. something that would be both flexible and yet (at least relatively)
portable to all TSQLConnection descendants. I'll look into this
tomorrow. Although I may need some help about what transaction modes can
be expressed in PostgreSQL and MySQL. I'll see tomorrow what I can do
(and where I will need some help :).
1. After reading docs of PostgreSQL and MySQL (I know possibilities of
Firebird by heart :), I must admit that I don't see a way to define
TSQLTransactionStyle in a way that would be both really flexible and
portable to all 3 databases (Firebird, PostgreSQL, MySQL). Every
database has an idea of at least two transaction modes like
a) Concurrent (aka Snapshot)
b) Read committed
... but that's all. Many details seem to be different, especially read
committed mode has many diffeent variants and possibilities (whether
one multirow select can be only partially affected by committing some
other transaction ? In Firebird yes, it's always possible, in PostgreSQL
you can avoid this. What should happen when uncommitted data is pending
? In Firebird -- many choices: read committed record version, wait for
committing or rollback, return immediately with error... PostgreSQL
seems to always return committed record version. Anyway -- these are
just examples).
I'm waiting for your opinion on this point. How exactly would you
propose TSQLTransactionStyle to be defined, and how it should behave
when some modes cannot be implemented in some database ?
2. To clear field for our discussion, I'm attaching all my simple
corrections to fcl/db/ as a patch to this email. This patch does *not*
mess with anything related to changing transaction modes (neither your
way of TSQLTransactionStyle nor my initial way of exposing
TSQLTransaction.SQLHandle). In other words, this is the patch that you
want to apply now, no matter what is your answer to point 1 above :)
Summary of changes in this patch:
-- Default TIBTransaction.IsolationLevel is changed to ilConcurrent.
This makes TIBTransaction more consistent with TIBConnection behaviour,
and Delphi's IBX, and Firebird C API (as I explained in one of previous
letters).
-- In units Interbase and IBConnection, SQLVar[...].AliasName is used
everywhere, instead of SQLVar[...].SQLName. As I explained in previous
letter [fpc-devel] Fix to IBConnection field names, using AliasName is
just better than SQLName. Consider e.g. `select count(*) from ...', that
has one field with SQLName = '' but AliasName = 'COUNT'. Also, developer
writing SQL statememt has full control over what alias name will be
assigned for the field.
-- Fix for Sqldb unit that used in one place FieldByName while FindField
+ manual check was required. This is described in detail in comments
inside patch.
-- TIBDatabase should allow setting Transaction from non-nil to nil
(TIBDatabase must anyway be prepared everywhere to handle the case when
Transaction = nil), and also TIBDatabase should automatically set it's
Transaction property to nil when Transaction instance is destroyed
(using FreeNotification). I rearranged TIBDatabase.SetTransaction to
make it (in my opinion) cleaner.
Michalis.
cvs diff: Diffing .
cvs diff: Diffing dbase
cvs diff: Diffing interbase
Index: interbase/interbase.pp
===
RCS file: /FPC/CVS/fpc/fcl/db/interbase/interbase.pp,v
retrieving revision 1.16
diff -u -r1.16 interbase.pp
--- interbase/interbase.pp 17 Mar 2005 09:02:17 - 1.16
+++ interbase/interbase.pp 20 Mar 2005 03:13:15 -
@@ -52,6 +52,8 @@
procedure SetDBDialect;
procedure SetTransaction(Value : TIBTransaction);
protected
+procedure Notification(AComponent: TComponent;
+ Operation: TOperation); override;
function GetHandle : pointer; virtual;
{ This procedure makes connection to Interbase server internally.
Is visible only by descendants, in application programming
@@ -180,7 +182,7 @@
property AccessMode: TAccessMode
read FAccessMode write FAccessMode default amReadWrite;
property IsolationLevel: TIsolationLevel
- read FIsolationLevel write FIsolationLevel default ilReadCommitted;
+ read FIsolationLevel write FIsolationLevel default ilConcurrent;
property LockResolution: TLockResolution
read FLockResolution write FLockResolution default lrWait;
property TableReservation: TTableReservation
@@ -383,22 +385,24 @@
procedure TIBDatabase.SetTransaction(Value : TIBTransaction);
