Re: [fpc-devel] Adding a unidirectional dataset to sqldb
Joost van der Sluis wrote: Why would it work faster ? The only thing a unidirectionalquery query gives you is less memory requirements, because it needs only 2 buffers. Less copying around of the buffers. But I did some tests, it's negligible. I don't see any advantage in this worker-class, or the unidirectional query anymore. Maybe that Martin still sees some advantages? Maybe for queries with large number of results, that the memory reduction is significant ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
On Wed, 2006-10-18 at 09:10 +0200, Michael Van Canneyt wrote: > > On Tue, 17 Oct 2006, Joost van der Sluis wrote: > > > On Fri, 2006-10-06 at 07:51 +0200, Martin Schreiber wrote: > > > On Thursday 05 October 2006 22.41, Joost van der Sluis wrote: > > > > > > Now I'm thinking about using an interface, to avoid double code. > > > > > > But I > > > > > > don't know what effect that has on run-time performance. I mean, the > > > > > > idea was to make if faster ... > > > > > > > > > > A very good idea! It can then be implemented by a common worker class. > > > > > TSQLConnection and TSQLTransaction should be independent of TSQLQuery > > > > > and > > > > > TSQLQuery should get its own unit. > > > > > > > > Can you explain to me how I should construct this worker-class? As > > > > Michael said, my solution won't work... > > > > > > > If TSQLConnection or TSQLTransaction need callbacks into TSQLQuery and > > > "TSQLQueryUni" do it by an corba interface (at the first glance I didn't > > > see > > > any). > > > To implement the common functions of TSQLQuery and TSQLQueryUni use a > > > "worker > > > class" which does callbacks by an corba interface. > > > > Ok, I tried to implement this. I still don't understand why I should > > need an interface for this, though. > > You don't need an interface ? What good would that do you ? No idea. It was Martin's suggestion. > > Attached is a patch that does this. It's work in progress, TSQLQuery > > doesn't work with this patch, but the TSQLUnidirectionalQuery does. At > > least, a basic select works... > > > > But I wanted to make things faster. I'm not feeling comfortable with > > creating more wrapper-class layers, more complexity, for nothing, if it > > doesn't result in any speedup. > > Why would it work faster ? The only thing a unidirectionalquery query gives > you is less memory requirements, because it needs only 2 buffers. Less copying around of the buffers. But I did some tests, it's negligible. I don't see any advantage in this worker-class, or the unidirectional query anymore. Maybe that Martin still sees some advantages? Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: AW: [fpc-devel] ZEOS Contribution Offer
On Thu, 19 Oct 2006, Helmut Hartl wrote: > > > The upshot of all this is that we don't need to include all packages > > in FPC by default, making the maintenance burden smaller for the core > > team. All you would need to do is create one small driver file, > > and the rest will be automated for you. > > The central repository access will also be automated. > > Michael. > > That sounds pretty cool. That is the idea :-) First get it to work. Then we'll see if it is cool :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
AW: [fpc-devel] ZEOS Contribution Offer
> The upshot of all this is that we don't need to include all packages > in FPC by default, making the maintenance burden smaller for the core > team. All you would need to do is create one small driver file, > and the rest will be automated for you. > The central repository access will also be automated. > Michael. That sounds pretty cool. Helmut. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CmdLine
From: "Daniël Mantione" <[EMAIL PROTECTED]> > Hi, > > Does the CmdLine variable in the System unit exist for Delphi/TP/... > compatibility ? Delphi compatibility. By the way, I have a patch ready which turns it into a property, which prevents some code being pulled in Hello World kind of apps. I already implemented optimization of CmdLine for smartlinking for WinCE some time ago. It is controlled by HAS_CMDLINE define. And CmdLine is declared as function in WinCE system unit. CmdLine as property will be great, but I found that property getter/setter need to be declared before property declaration in the interface part. This will garbage a global namespace with private getters/setters. Is it possible to make compiler to accept getters/setters not declared in the interface part, but implemented in the implementation? Yury Sidorov. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ZEOS Contribution Offer
On Thu, 19 Oct 2006, Helmut Hartl wrote: > I speak in the name of the ZEOS Developers. > > We want to contribute to the FPC Project, in the form that we > > deliver a FPC usable Version of the ZEOS DBO. > > > > If you don't know ZEOS by now, it is a set of mature database components > > usable visual or nonvisual, wich interface to SQLite, MySQL, > > PostgreSQL, Interbase, Firebird,Oracle and others. > > Normally the latest versions are supported. > > > > Currently we are preparing the 6.6 Version. (beta cycle). > > We will change our licensing terms to make it LGPL with the > > FPC / Lazarus static linking exception. > > The library works fine for Delphi's, FPC under Windows and Linux. Thank you very much for your offer. Since this would be a rather substantial addition to the FPC sources, I will discuss this with the core team, to see what we can do. However, I am in favour of including ZEOS. HOWEVER: We are currently working on a package managing system for FPC. This is something which is similar to rpm and smart/yum for linux. Or CPAN for Perl. It's 80% ready, currently. Basically it means that 1. Makefiles are history. 2. The package manager will download and compile all that is needed to compile your code. In this system we will be maintaining a repository of 'known' packages, which are not included in FPC by default, but which can be downloaded from a well-known location. The package manager will then download and install them as needed. The upshot of all this is that we don't need to include all packages in FPC by default, making the maintenance burden smaller for the core team. All you would need to do is create one small driver file, and the rest will be automated for you. The central repository access will also be automated. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] ZEOS Contribution Offer
I speak in the name of the ZEOS Developers. We want to contribute to the FPC Project, in the form that we deliver a FPC usable Version of the ZEOS DBO. If you don’t know ZEOS by now, it is a set of mature database components usable visual or nonvisual, wich interface to SQLite, MySQL, PostgreSQL, Interbase, Firebird,Oracle and others. Normally the latest versions are supported. Currently we are preparing the 6.6 Version. (beta cycle). We will change our licensing terms to make it LGPL with the FPC / Lazarus static linking exception. The library works fine for Delphi’s, FPC under Windows and Linux. Currently only SVN versions and snapshots are usable, But the Beta Cycle starts soon. If someone is willing to integrate/maintain the sources into next fpc version, maybe we get another set of databse components that work out of the box with FPC/Lazarus. As ZEOS is quite huge and we are all short of time (as everybody is :) we are searching for testers, developers and users if someone is interested … The forum is reachable under zeos.firmos.at Please tell me your thoughts. Thanks, helmut -- helmut dot hartl at firmos dot at ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CmdLine
Peter Vreman wrote: situations. Maybe you remember what the (currently disabled) VMT optimizer did for the LCL. It removed methods that the LCL expected to be there. After some thinking, the VMT optimizer can be enabled, but should not remove any published methods. Those may be referenced from streaming LFMs etc. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CmdLine
On Thursday 19 October 2006 09:39, Marc Weustink wrote: > The only thing guaranteed by the language is that if you follow its > definitions, it will compile. No. That's syntax. I'm talking about semantics. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CmdLine
Vinzent Hoefler wrote: On Thursday 19 October 2006 08:31, Marc Weustink wrote: The case shows that users can do this. There is no language construct that forbids it. So optimizing this with a smart linker may break such code. Yes, it may. So what? There's hell a lot of code that is generally possible within the language. Still it can be unportable, plain wrong, only work in certain situations etc. pp. Read: It still may break. I'm speaking about correct and portable code working in all situations. The only point is that the linker doesn't recognize the reference being used. So "no language construct that forbids it" is no excuse, especially when you're digging around in internal compiler constructs. I'm not digging in internal compiler constructs, I'm using a defined class layout and RTTI. No internal magic is used. (unless you define RTTI as internal) Otherwise I'd expect some of my old code to work with FreePascal - where I outsmarted TPs heap manager to be able to free parts of dynamically allocated arrays. IMO, ppl will always be smarter and find a valid case where things get broken. This highly depends on your definition of "valid". My opinion: If it ain't guaranteed by the language, it ain't valid. A valid case is a piece of code where you and I will agree on that is should work. The only thing guaranteed by the language is that if you follow its definitions, it will compile. Nothing more nothing less. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CmdLine
Op Thu, 19 Oct 2006, schreef Micha Nelissen: > Marc Weustink wrote: > > It isn't really doing much with the internals. I've to admit that > > It reads/searches the VMT pointers themselves, right ? Is that supposed to > work in the language ? I don't know, but there should be a way to request the VMT-index of a virtual method, and then such a method should count as used. For example, calling virtual methods from assembler is a low level thing I'd rather like to be possible. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CmdLine
On Thursday 19 October 2006 08:31, Marc Weustink wrote: > The case shows that users can do this. There is no language construct > that forbids it. So optimizing this with a smart linker may break > such code. Yes, it may. So what? There's hell a lot of code that is generally possible within the language. Still it can be unportable, plain wrong, only work in certain situations etc. pp. Read: It still may break. So "no language construct that forbids it" is no excuse, especially when you're digging around in internal compiler constructs. Otherwise I'd expect some of my old code to work with FreePascal - where I outsmarted TPs heap manager to be able to free parts of dynamically allocated arrays. >IMO, ppl will always be smarter and find a valid case where things get >broken. This highly depends on your definition of "valid". My opinion: If it ain't guaranteed by the language, it ain't valid. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CmdLine
Marc Weustink wrote: It isn't really doing much with the internals. I've to admit that It reads/searches the VMT pointers themselves, right ? Is that supposed to work in the language ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CmdLine
Micha Nelissen wrote: Peter Vreman wrote: That is impossible. The linker is 'stupid' in that sence. And it also should not be trying to be smart. Otherwise it will fail in other situations. Maybe you remember what the (currently disabled) VMT optimizer did for the LCL. It removed methods that the LCL expected to be there. That's a bug in the LCL IMHO. We shouldn't be messing around with internals. It isn't really doing much with the internals. I've to admit that nowadays better solutions are available, but thats something different. The case shows that users can do this. There is no language construct that forbids it. So optimizing this with a smart linker may break such code. Problem only is till what level should a smart linker detect this. IMO, ppl will always be smarter and find a valid case where things get broken. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CmdLine
Peter Vreman wrote: That is impossible. The linker is 'stupid' in that sence. And it also should not be trying to be smart. Otherwise it will fail in other situations. Maybe you remember what the (currently disabled) VMT optimizer did for the LCL. It removed methods that the LCL expected to be there. That's a bug in the LCL IMHO. We shouldn't be messing around with internals. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
