Re: [fpc-devel] Improving Ref Counting
Jamie McCracken wrote: > A GC needs to trace an object's references to see if anything still > points to it. How else can it decide whether an object is no longer in use? GC starts from known alive object references, in static or local variables, and follows the references in these objects to further objects. Unused objects never occur in this search, so they need no special marking or other treatment. Imagine objects represented as tiles, tied together by reference ropes. Lift one living tile, and all other living tiles will follow. The tiles without references from living tiles will be left on the floor. GC does nothing but lift the known alive tiles, and then sweeps the garbage from the floor. The references in static and local variables are known to live, their location is the only thing that a garbage collector has to know. >> > It's very expensive. getmem is quite expensive, and you need it for every > reference this way. Okay then use Tlist with preallocation of say half a dozen references - that should be efficient for 99% of cases for an individual object's references. << Do you realize how much memory consume your suggestions? Talking abojects, each one increased by a list of references? I agree that there exist only few references to most objects, perhaps less thanX-Mozilla-Status: 0009 management of the according lists will cost either time (getmem/freemem) or space (preallocation). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Improving Ref Counting
Jamie McCracken wrote: > A GC needs to trace an object's references to see if anything still > points to it. How else can it decide whether an object is no longer in use? GC starts from known alive object references, in static or local variables, and follows the references in these objects to further objects. Unused objects never occur in this search, so they need no special marking or other treatment. Imagine objects represented as tiles, tied together by reference ropes. Lift one living tile, and all other living tiles will follow. The tiles without references from living tiles will be left on the floor. GC does nothing but lift the known alive tiles, and then sweeps the garbage from the floor. The references in static and local variables are known to live, their location is the only thing that a garbage collector has to know. >> > It's very expensive. getmem is quite expensive, and you need it for every > reference this way. Okay then use Tlist with preallocation of say half a dozen references - that should be efficient for 99% of cases for an individual object's references. << Do you realize how much memory consume your suggestions? Talking aboX-MozillaX-Mozilla-Status: 0009jects, each one increased by a list of references? I agree that there exist only few references to most objects, perhaps less than 2 on average, but the management of the according lists will cost either time (getmem/freemem) or space (preallocation). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changes to gtk 2 bindings
Hi
So here they are. Initially I was making my changes versus gtk2forpascal
from sourceforge, but now I made them versus FPC sources, since I can't
connect to gtk2forpascal cvs on sourceforge. I also noticed that version
from FPC tree already contains some of the fixes I was going to send...
excellent.
I'm attaching patch to packages/extra/gtk2/, it fixes various small
things: compiling gtk_demo, {$linklib c} and {$linklib pthread} needed
under FreeBSD, using HasGTK2_2 symbol in gtk2.pas, correct name for
identifier TGtkAccelGroupFindFunc, and four missing functions for
GtkWindow (gtk_window_fullscreen/unfullscreen,
gtk_window_set_keep_above/below).
Note that I added {$define GTK2_2} at the beginning of gtk2.pas -- I
think that GTK >= 2.2 is installed pretty everywhere where any GTK 2.x
is installed. But this may be a matter of personal experience, so feel
free to remove this bit if you think that's better.
And here you can find my gtkglext translation (12 KB):
http://www.camelot.homedns.org/~michalis/unofficial/gtkglext.tar.gz
I tested it (gtk 2 bindings with my patches and gtkglext) on Linux,
FreeBSD (5.3) and Win32. In the gtkglext archive you will find
subdirectory examples/, there is one simple test program using gtkglext,
gears.pas. This is rewritten in Pascal version of gears.c from gtkglext
examples. You can also look at the units and programs on my www page,
they use gtk2 and gtkglext, though they are not very good example
programs for teaching how to use gtkglext (since gtk code is there
embedded in rather large unit).
Michalis.
Index: examples/gtk_demo/stock_browser.inc
===
RCS file: /FPC/CVS/fpc/packages/extra/gtk2/examples/gtk_demo/stock_browser.inc,v
retrieving revision 1.1
diff -u -u -r1.1 stock_browser.inc
--- examples/gtk_demo/stock_browser.inc 24 Jan 2005 21:58:04 - 1.1
+++ examples/gtk_demo/stock_browser.inc 1 Mar 2005 01:16:18 -
@@ -68,7 +68,7 @@
stock_item_info_get_type := StockItemInfoType;
end;
-function STOCK_ITEM_INFO_TYPE: GType; inline;
+function STOCK_ITEM_INFO_TYPE: GType;
begin
STOCK_ITEM_INFO_TYPE := stock_item_info_get_type;
end;
Index: glib/glib2.pas
===
RCS file: /FPC/CVS/fpc/packages/extra/gtk2/glib/glib2.pas,v
retrieving revision 1.3
diff -u -u -r1.3 glib2.pas
--- glib/glib2.pas 3 Feb 2005 21:59:45 - 1.3
+++ glib/glib2.pas 1 Mar 2005 01:16:27 -
@@ -61,6 +61,11 @@
{$endif}
{$endif}
+{$ifdef FREEBSD}
+ {$linklib c}
+ {$linklib pthread}
+{$endif}
+
{$IFNDEF KYLIX}
{$PACKRECORDS C}
{$ELSE}
Index: gtk+/gtk/gtk2.pas
===
RCS file: /FPC/CVS/fpc/packages/extra/gtk2/gtk+/gtk/gtk2.pas,v
retrieving revision 1.2
diff -u -u -r1.2 gtk2.pas
--- gtk+/gtk/gtk2.pas 31 Jan 2005 14:08:25 - 1.2
+++ gtk+/gtk/gtk2.pas 1 Mar 2005 01:16:28 -
@@ -18,6 +18,8 @@
}
unit gtk2; // keep unit name lowercase for kylix
+{$define GTK2_2}
+
{$H+}
{$IFDEF FPC}
{$mode objfpc}
@@ -28,15 +30,18 @@
{$IFDEF GTK2_2}
{$DEFINE HasGTK2_0}
+{$DEFINE HasGTK2_2}
{$ENDIF}
{$IFDEF GTK2_4}
{$DEFINE HasGTK2_0}
+{$DEFINE HasGTK2_2}
{$DEFINE HasGTK2_4}
{$ENDIF}
{$IFDEF GTK2_6}
{$DEFINE HasGTK2_0}
+{$DEFINE HasGTK2_2}
{$DEFINE HasGTK2_4}
{$DEFINE HasGTK2_6}
{$ENDIF}
Index: gtk+/gtk/gtkaccelgroup.inc
===
RCS file: /FPC/CVS/fpc/packages/extra/gtk2/gtk+/gtk/gtkaccelgroup.inc,v
retrieving revision 1.1
diff -u -u -r1.1 gtkaccelgroup.inc
--- gtk+/gtk/gtkaccelgroup.inc 24 Jan 2005 21:58:04 - 1.1
+++ gtk+/gtk/gtkaccelgroup.inc 1 Mar 2005 01:16:29 -
@@ -50,7 +50,8 @@
accel_path_quark : TGQuark;
end;
- Tgtk_accel_group_find_func = function (key:PGtkAccelKey; closure:PGClosure;
data:gpointer):gboolean;
+ Tgtk_accel_group_find_func = function (key:PGtkAccelKey; closure:PGClosure;
data:gpointer):gboolean; cdecl;
+ TGtkAccelGroupFindFunc = Tgtk_accel_group_find_func;
{$ENDIF read_interface_types}
//--
Index: gtk+/gtk/gtkwindow.inc
===
RCS file: /FPC/CVS/fpc/packages/extra/gtk2/gtk+/gtk/gtkwindow.inc,v
retrieving revision 1.1
diff -u -u -r1.1 gtkwindow.inc
--- gtk+/gtk/gtkwindow.inc 24 Jan 2005 21:58:04 - 1.1
+++ gtk+/gtk/gtkwindow.inc 1 Mar 2005 01:16:35 -
@@ -233,6 +233,14 @@
procedure gtk_window_unstick(window:PGtkWindow); cdecl; external gtklib;
procedure gtk_window_maximize(window:PGtkWindow); cdecl; external gtklib;
procedure gtk_window_unmaximize(window:PGtkWindow); cdecl; external gtklib;
+
+{$ifdef HasGTK2_2}
+procedure gtk_window_fullscreen(window: PGtkWindow); cdecl; external gtklib;
+procedure gtk_window_unfullscreen(window: PGtkWindow); cdecl; ext
Re: [fpc-devel] Changes to gtk 2 bindings
On Mon, 28 Feb 2005 20:55:54 +0100 Michalis Kamburelis <[EMAIL PROTECTED]> wrote: > Hi > > I have a couple of corrections to gtk 2 bindings, gtk2forpascal. I also > made gtkglext bindings that could be incorporated into gtk 2 bindings, > if it feels appropriate (since, as far as I know, initial goal of > gtk2forpascal was to include gtkglext bindings, but they were not > implemented because interface of gtkglext library was changing rapidly). > > Since gtk2forpascal bindings are now incorporated into FPC source tree, > my question is: should I submit my patches/additions to gtk 2 bindings > here, as patches versus fpc packages/extra/gtk2/ sources, or should I > submit them to gtk2forpascal on sourceforge ? In other words, where does > development of gtk2forpascal continue -- as part of FPC, or on > gtk2forpascal sourceforge place ? Both. You can send me the patches/extra files. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Changes to gtk 2 bindings
Hi I have a couple of corrections to gtk 2 bindings, gtk2forpascal. I also made gtkglext bindings that could be incorporated into gtk 2 bindings, if it feels appropriate (since, as far as I know, initial goal of gtk2forpascal was to include gtkglext bindings, but they were not implemented because interface of gtkglext library was changing rapidly). Since gtk2forpascal bindings are now incorporated into FPC source tree, my question is: should I submit my patches/additions to gtk 2 bindings here, as patches versus fpc packages/extra/gtk2/ sources, or should I submit them to gtk2forpascal on sourceforge ? In other words, where does development of gtk2forpascal continue -- as part of FPC, or on gtk2forpascal sourceforge place ? Regards, Michalis. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Improving Ref Counting
>>> But it could be used on platforms that have a "fairly" stable and >>> standardised C++ ABI (windows and Linux mainly). Other platforms can >>> use the current FPC generic method as a fallback. >> >> >> FPC could use that trick on (pretty much?) any platform. It doesn't have >> to be compatible with the official C++ abi of that platform (just like >> the current technique isn't either). It just isn't implemented yet. > > Yes thats right which is why I think its best to optimise its > implementation in the various RTLs (the Linux RTL could use the C++ ABI > or something else depending on which is faster etc). Sorry, but it isn't so simple to just update the RTL. Also the compiler needs to be adapted to write exception frames (.eh_frame) sections. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Improving Ref Counting
On 28 feb 2005, at 13:14, Jamie McCracken wrote: FPC could use that trick on (pretty much?) any platform. It doesn't have to be compatible with the official C++ abi of that platform (just like the current technique isn't either). It just isn't implemented yet. Yes thats right which is why I think its best to optimise its implementation in the various RTLs (the Linux RTL could use the C++ ABI or something else depending on which is faster etc). It's not the RTL that contains these tables, it's the compiler that generates them. Using a specific ABI (table layout) is only required to be compatible with such tables generated by other compilers, I doubt there are many (if any) speed differences among them. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Improving Ref Counting
Jonas Maebe wrote: On 28 feb 2005, at 12:26, Jamie McCracken wrote: FPC uses an platform independent method. The C++ ABI isn't used. But it could be used on platforms that have a "fairly" stable and standardised C++ ABI (windows and Linux mainly). Other platforms can use the current FPC generic method as a fallback. FPC could use that trick on (pretty much?) any platform. It doesn't have to be compatible with the official C++ abi of that platform (just like the current technique isn't either). It just isn't implemented yet. Yes thats right which is why I think its best to optimise its implementation in the various RTLs (the Linux RTL could use the C++ ABI or something else depending on which is faster etc). jamie. Jonas ___ 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] Improving Ref Counting
On 28 feb 2005, at 12:26, Jamie McCracken wrote: FPC uses an platform independent method. The C++ ABI isn't used. But it could be used on platforms that have a "fairly" stable and standardised C++ ABI (windows and Linux mainly). Other platforms can use the current FPC generic method as a fallback. FPC could use that trick on (pretty much?) any platform. It doesn't have to be compatible with the official C++ abi of that platform (just like the current technique isn't either). It just isn't implemented yet. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Improving Ref Counting
Peter Vreman wrote: Why are you looking at GC/Refcounting when the problem is the try..finally? It is better to rewrite the try..finally code using the C++ ABI for exception handling. Where do you see improvements in the C++ ABI? Or even differences? Windows implements this ABI, and every language should use it in the intended way. Perhaps FPC implements a different method on other systems? FPC uses an platform independent method. The C++ ABI isn't used. But it could be used on platforms that have a "fairly" stable and standardised C++ ABI (windows and Linux mainly). Other platforms can use the current FPC generic method as a fallback. jamie. ___ 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
[fpc-devel] make cycle fails
For your information: Make cycle using fpc 1.0.10 as starting compiler fails: d:/fpc/bin/ppc386-release.exe -Ur -Xs -OG2p3 -n -Fi../inc -Fi../i386 -FE. -FUD:/lazarus/source/fpc-1.9/rtl/units/i386-win32 -gl -di386 -dRELEASE -Us -Sg syswin32.pp system.pp(924,18) Error: call by var parameters have to match exactly: Got WIDESTRING expected ANSISTRING system.pp(925,14) Error: Can't determine which overloaded function to call system.pp(926,42) Error: Can't determine which overloaded function to call system.pp(933,18) Error: call by var parameters have to match exactly: Got WIDESTRING expected ANSISTRING system.pp(934,14) Error: Can't determine which overloaded function to call system.pp(935,42) Error: Can't determine which overloaded function to call system.pp(943,5) Error: Identifier not found WIDESTRINGMANAGER system.pp(943,23) Error: Illegal qualifier system.pp(944,5) Error: Identifier not found WIDESTRINGMANAGER system.pp(944,23) Error: Illegal qualifier syswin32.pp(2) Fatal: There were 10 errors compiling module, stopping Regards, Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
