Re: [fpc-devel] Apache headers
On Mon, 17 Jul 2006, Felipe Monteiro de Carvalho wrote: Hello, The headers are now available for download. The are explanations about how to make a simple module, example code, internal details and a download link of the bindings here: http://www.freepascal.org/wiki/index.php?title=FPC_and_Apache_Modules I translated mod_example from apache source code, and latter I should translate other modules too. Most of my tests were on Windows, so it would be nice if people test on Unix. Felipe, there is an easier way to export the variable on Linux. I've added a small entry to the Wiki page. I haven't been able to test it yet, but it should work as indicated Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Apache headers
Felipe Monteiro de Carvalho wrote: > The headers are now available for download. The are explanations about > how to make a simple module, example code, internal details and a > download link of the bindings here: > > http://www.freepascal.org/wiki/index.php?title=FPC_and_Apache_Modules I think using 'httpd' as unit name is a bit too generic. There are many more things httpd could mean besides Apache module headers. Maybe 'apache' or 'apache_mod' or so, instead. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Apache headers
On Tue, 18 Jul 2006, Micha Nelissen wrote: Felipe Monteiro de Carvalho wrote: The headers are now available for download. The are explanations about how to make a simple module, example code, internal details and a download link of the bindings here: http://www.freepascal.org/wiki/index.php?title=FPC_and_Apache_Modules I think using 'httpd' as unit name is a bit too generic. There are many more things httpd could mean besides Apache module headers. Maybe 'apache' or 'apache_mod' or so, instead. Under Delphi, it's called httpd too; so from a compatibility point of view, this is not such a bad idea. (although it might be httpd2, for version 2) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Apache modules?
Hi, I am new to web applications. How does Apache Modules differ from CGI apps? CGI Apps: * The application executes, creates output and exits. * Nothing stays in memory between user input Apache Modules: * no idea? * Can things be kept in memory between user input? example: When retrieving data from a database, can the connection be kept open? * can I load user data (example: login data) and keep in available while the user is working inside the web app? Is there a good resource on the web explaining the differences? Any help would be great. Regards, Graeme. -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Apache modules?
On 7/18/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: Hi, I am new to web applications. How does Apache Modules differ from CGI apps? CGI Apps: * The application executes, creates output and exits. * Nothing stays in memory between user input Apache Modules: * no idea? * You can create a pure cgi program that will stay resident in memory (mod_per/python as examples), but you can create extensions and additional things for Apache itself, such as header manipulation (that's what mod_security does) or handling of gzip parameters and much more. * Can things be kept in memory between user input? example: When retrieving data from a database, can the connection be kept open? * Yes you can. But the hard question is how would you do it ? how can I know what I should give to specific connection ? if I have 2 communication from the same user, how can I find the difference ? but basically you can. The thing is that you are getting a sub process that keep execute itself, rather then open a new child, execute things, close the child and any other connection. Here things keep on running until you will stop apache. * can I load user data (example: login data) and keep in available while the user is working inside the web app? * a bad security idea (memory leaks, shard memory, virtual host issues etc... )sometimes jails are not that helpful. Is there a good resource on the web explaining the differences? Any help would be great. Think about plugins vs content ... plugins are not just for web application development, but sometimes for the server itself (most of the time that is), while content, like cgi, just generate data on demand. Regards, Graeme. Ido ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Apache modules?
On Tue, 18 Jul 2006, Graeme Geldenhuys wrote: Hi, I am new to web applications. How does Apache Modules differ from CGI apps? CGI Apps: * The application executes, creates output and exits. * Nothing stays in memory between user input Apache Modules: * no idea? Apache loads your module, initializes it, and then, per page request, calls a couple of event handlers. The module is only unloaded when apache is unloaded. * Can things be kept in memory between user input? example: When retrieving data from a database, can the connection be kept open? Yes, this can be done in the initialization. * can I load user data (example: login data) and keep in available while the user is working inside the web app? Yes. It's kept as long as the module is not unloaded. (i.e. till apache is restarted) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
> Tue, Jul 18, 2006 at 01:22:40AM +0200, Jonas Maebe wrote:
> >libnames when determining how to link, with the default being 1:1.
>
> I know, but I was trying to point out that e.g. on Mac OS X sometimes
> you may need
>
> -lgtk-1.2.0 -lgdk-1.2.0 -lgdk_pixbuf
>
> and sometimes
>
> -framework Gtk+-Cocoa
>
> and sometimes
>
> -framework Gtk-Carbon
> (and there's a fourth "native" Mac OS X gtk port underway, because
> the two previous ones were never really finished)
>
> You need something more than merely the remapping of library names.
I know. We already need more to change libs from static to shared. And I
knew there was more, which I wanted this as formally undocumented
functionality. IIRC I referenced that in the mail to core about the
linkordering.
I'm not entirely happy having put this in parameter form. A keyword based
configuration file is a better way.
> >discovery process must be done up front).
> >
> >I want more out of source.
>
> I don't really care where exactly the information is stored (although
> the unit somehow seems logical to me, if you want to keep the
> interface and libs specification together),
Yes and no. The unit should only reference some abstract keyword, and the
mapping to exact actions should happen outside the source. Otherwise
overriding becomes nearly impossible.
Maybe this can be easily introduced by having a second parameter to linklib.
something like
{$linklib packagename,libraryname} // the comma makes it possible to
keep the old syntax also for migrational purposes.
We can then e.g. easily transform either on libraries or on groups of
libraries ( the packagename above, in the linklib), e.g. to -framework.
This would work for your system too, for the same reasons. If something
fails (e.g. wrong script called, since the new version names it differently,
or some distribution renames it to something-x.y because of a newer version
occupies the "something" name), you'd be able to override simply by
installing a new config file (no new binaries or precompiled sourcetree
needed)
This is also the main reason to make this config a separate file, or a
fpc.cfg #include. Default not for user editing.
So the hoisting out of the source (and too much hardcoding in t_*) should be
separate from if we go -config or manual. The abstract, transformable
representation is needed in either case, also to allow overrides on the
-config usage.
> but if we change things from the way they are now, then the information
> should be dynamic (i.e., not merely determined at install time, because
> that only shifts the problem) and preferably come from available automatic
> sources (as opposed to the developer having to specify it).
You could simply exit with a hint to run the configuration tool if you
detect that ldconfig has been run. ldconfig is the key here, because to my
limited knowledge it should be run after library changes.
But IMHO this automatic behaviour is a disaster waiting to happen.
Untransparant, unsupportable, to easily broken, hard to override (it is
easier to let the user make FPC specific config changes, than to have him
edit global pkgconfig and risk breaking his KDE)
But as long as the automated is not the default (which then can be
automatically turned on by IDEs), I don't care, as long as I don't have to
support it.
(Most of the rest of the discussion skipped, only replying to concrete
parts. Viewpoints won't change with more discussion anyway)
> The problem is that it needs to be "refed" every time you compile
> something using particular units (those depending on libraries
> requiring this mumbo-jumbo).
(I didn't get this? Surely reading an own config file is quicker than
calling a bunch of external _scripts_ ?)
> >This because I want to be able to say "mail me your compiler state", and
> >send back a new one. Too much automatism will make things less
> >transparant. To the user, but also to the one who has to support it.
>
> That's what "-al -s" is for.
Too crude. Only the output, not the input. Maybe combined with -va it could
work if enough msgs were emitted with relevant info, but way overkill for
99% of the cases that revolve recognizing variations of a few common
scenario's.
(Unix philosophy)
> >_eighties_ Unix philosophy. Have you seen the sheer size of an avg Linux
> >distribution?
>
> Many small things (and some larger, like OpenOffice.org) together
> make for large sizes.
I haven't seen small things made in recent years, and previously small
things have grown big.
gcc isn't exactly small, neither is glibc or KDE or Gnome or Eclipse or
Mozilla or Evolution or Samba, or X or anything that the user sees. And
nearly any of them are not run by volunteers anymore either. Nearly all have
fulltimers.
The only stuff that is small are the remnants of the said eighties unix
culture. Tail,wc and friends. The newer branches of that family (perl,
python etc) are all again huge.
> >and parse it and try to merge it
> >with our own
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
Alright everyone, just stop this ok? I was angry like hell when I first read the ORIGINAL poster's message about FreeBSD (hint, topic no longer valid in your discussion) I got even more angry and my response was very immature. I would like to apologise to everyone and especialy the original poster for my tone. This whole discussion is useless. I hate to be the one who brakes the party, but it all started because I said a few completly untrue things about C with relation to binary compatibility. Honestly I didn't expect you guys to catch up (when I cooled down that is). So there it goes, return to whatever you were doing before and we'll all be better of I think. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Apache headers
On 7/18/06, Micha Nelissen <[EMAIL PROTECTED]> wrote: I think using 'httpd' as unit name is a bit too generic. There are many more things httpd could mean besides Apache module headers. Maybe 'apache' or 'apache_mod' or so, instead. I just used the same name the c headers use. I also used just httpd instead of httpd2 because I plan to put each version of the headers (1.3, 2.0.x, 2.2.x) into one directory. So you can write a module, add unit httpd, and add the appropriate directory to the compiler search path and compile your module for one of this 3 possible versions. thanks, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On 18 Jul 2006, at 12:05, Aleš Katona wrote: This whole discussion is useless. Better library linking support is not useless. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Small Apps thing of the Past?
In response to the text below - I thought it useful to say that I have the need for a small APP to make a super thin CGI app to compromise between the "process startup" of CGI apps without locking myself into a HTTP API or FastCGI - Still not sure what the benchmarks will reveal but concerning FPC, By not using any units that appear to use classes internally (because of the CLASSES bloat code which is fine usually and desired) I have managed 30k exe's (upx even smaller) using only the DOS unit, and my own. I use ONLY FPC native objfpc mode - AND I made a skeleton of a little database format - using the file block stuff - and it SCREAMS So - small apps - I personally need to ability to count bytes sometimes depending on the application - and FPC has been handling BIG and SMALL - FAST never SLOW - for me in years! I personally use only my own homemade classes - unless absolutely necessary to use others.. only so I know intimately what each part of my system is doing down to the frame bolts so all in all... I think the statement below is not wrong but not entirely correct either. Jason P Sage >> Many small things (and some larger, like OpenOffice.org) together >> make for large sizes. >I haven't seen small things made in recent years, and previously small >things have grown big. >gcc isn't exactly small, neither is glibc or KDE or Gnome or Eclipse or >Mozilla or Evolution or Samba, or X or anything that the user sees. And >nearly any of them are not run by volunteers anymore either. Nearly all have >fulltimers. >The only stuff that is small are the remnants of the said eighties unix >culture. Tail,wc and friends. The newer branches of that family (perl, >python etc) are all again huge. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Small Apps thing of the Past?
> In response to the text below - I thought it useful to say that I have the > need for a small APP to make a super thin CGI app to compromise between the > "process startup" of CGI apps without locking myself into a HTTP API or > FastCGI - Still not sure what the benchmarks will reveal but concerning FPC, > By not using any units that appear to use classes internally (because of the > CLASSES bloat code which is fine usually and desired) I have managed 30k > exe's (upx even smaller) using only the DOS unit, and my own. I use ONLY FPC > native objfpc mode - AND I made a skeleton of a little database format - > using the file block stuff - and it SCREAMS Very nice. What is the % startup difference between using classes and not? And how do you measure ? I can't imagine it to be larger than the performance penalty on UPX. See also: http://www.freepascal.org/wiki/index.php/Size_Matters most notably the parts about UPX. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Apache modules?
On 7/18/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: Is there a good resource on the web explaining the differences? Any help would be great. There is a table that compares various web technologies here: http://162.105.203.19/apache-doc/8.htm#BIN21 Apache modules fit into the "Server API" category. Acctually you may want to read the full chapter. It´s the first chapter here: http://162.105.203.19/apache-doc/1.htm * Can things be kept in memory between user input? example: When retrieving data from a database, can the connection be kept open? Yes, sure. The module never unloads. You can even open the connect on the initialization of the library, and close on the finalization. Just make sure to handle errors, and possible server crashes. * can I load user data (example: login data) and keep in available while the user is working inside the web app? Yes, sure. You do can use modules to develop web page, but you can also do a lot more with them. One module I am planning to convert can detect spelling errors of a user trying to access a webpage, and then do it´s best to correct them. With modules you have access to all internals of the web server. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpc 2.1.1, x86_64, gtk crashes
Hi all, I'm hunting a strange bug. The Lazarus IDE works with gtk1 under fpc 2.0.2 on x86_64 without problems. But with fpc 2.1.1 it crashes when opening any modal form. For example open file. Compiling with -gv and starting with valgrind runs without access violation. With heaptrc: bug appears at the same position. With cmem: bug appears with a backtrace without any lineinfo. With cthreads: bug appears with a backtrace without any lineinfo. With -gv, but not in valgrind: bug appears with a backtrace without any lineinfo. I was not yet able to reproduce the error in a small test application. Maybe someone of the fpc devels has an idea, where I can start searching? What x86_64 bugs could be related to this problem? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Apache modules?
Thanks everybody you taking the time to reply... It seems Apache Modules can do a lot more that I thought. Well worth reading a bit more about it! Regards, Graeme. On 7/18/06, Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: On 7/18/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: > Is there a good resource on the web explaining the differences? Any > help would be great. There is a table that compares various web technologies here: http://162.105.203.19/apache-doc/8.htm#BIN21 Apache modules fit into the "Server API" category. Acctually you may want to read the full chapter. It´s the first chapter here: http://162.105.203.19/apache-doc/1.htm > * Can things be kept in memory between user input? example: When > retrieving data from a database, can the connection be kept open? Yes, sure. The module never unloads. You can even open the connect on the initialization of the library, and close on the finalization. Just make sure to handle errors, and possible server crashes. > * can I load user data (example: login data) and keep in available > while the user is working inside the web app? Yes, sure. You do can use modules to develop web page, but you can also do a lot more with them. One module I am planning to convert can detect spelling errors of a user trying to access a webpage, and then do it´s best to correct them. With modules you have access to all internals of the web server. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 2.0.4 rc2 and mse
> MSE created some patches for fpc 2.0.4 rc1 > to fix some widestring and db issues. > http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_4/ > > I seems they are not applied to rc2. > > Can someone with widestring and db knowledge > of fpc dev take a look at this? The db-files in fpc-2.0.4-rc2 are better up-to-date then the mse-one's. What's left is irrelevent, or in the fopen case, an ugly hack that shoudn't be there, imho. So for the db-part, nothing has to change. Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 2.0.4 rc2 and mse
> > The db-files in fpc-2.0.4-rc2 are better up-to-date then the mse-one's. > What's left is irrelevent, or in the fopen case, an ugly hack that > shoudn't be there, imho. > > So for the db-part, nothing has to change. thx for checking, is someone :-) looking to implement/fix blob/text in the mysql binding ? (see mse talk) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 2.0.4 rc2 and mse
On Tuesday 18 July 2006 19.11, Joost van der Sluis wrote: > > MSE created some patches for fpc 2.0.4 rc1 > > to fix some widestring and db issues. > > http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_ > >4/ > > > > I seems they are not applied to rc2. > > > > Can someone with widestring and db knowledge > > of fpc dev take a look at this? > > The db-files in fpc-2.0.4-rc2 are better up-to-date then the mse-one's. > What's left is irrelevent, or in the fopen case, an ugly hack that > shoudn't be there, imho. > > So for the db-part, nothing has to change. > > Joost Did you fix Mantis 6898 in the meantime? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 2.0.4 rc2 and mse
On Tue, 2006-07-18 at 22:13 +0200, Martin Schreiber wrote: > On Tuesday 18 July 2006 19.11, Joost van der Sluis wrote: > > > MSE created some patches for fpc 2.0.4 rc1 > > > to fix some widestring and db issues. > > > http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_2_0_ > > >4/ > > > > > > I seems they are not applied to rc2. > > > > > > Can someone with widestring and db knowledge > > > of fpc dev take a look at this? > > > > The db-files in fpc-2.0.4-rc2 are better up-to-date then the mse-one's. > > What's left is irrelevent, or in the fopen case, an ugly hack that > > shoudn't be there, imho. > > > > So for the db-part, nothing has to change. > > > > Joost > > Did you fix Mantis 6898 in the meantime? I didn't but Michael did in the mean time, so it seems. Well, I can live with that, until I come up with a real solution. I hope that the fix doesn't brake any of the db-tests. Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Testing of FPC 2.0.4 release candidates - next round
On 14 Jul 06, at 9:52, Tomas Hajny wrote: Hi again, > We're about to start preparation for the next round of testing of release > candidates for 2.0.4 after this weekend. More platforms and builds should > be included this time - in addition to those available in RC1, we expect > to have at least i386-freebsd, .rpm and .deb packages for i386-linux, > powerpc-morphos and x86_64-linux plus possibly arm-linux (cross-build) > too. > > Although the builds will be available to wide public, we'd still like to > have 1-2 people assigned to each of these builds, who will not only have a > look at the prepared packages, but will make sure to go through a defined > minimum list of test actions and provide us with explicit feedback > afterwards. As before, I'd like to ask those who are interested in helping > us to have FPC 2.0.4 working well on their preferred platforms and having > time to participate on this testing during next few weeks to provide us > with contact information on > http://www.freepascal.org/wiki/index.php/Testers_2.0.4. These people will > be then contacted with more information once the RC2 build for their > platform is available. We'd still need somebody for testing FreeBSD, the different i386-linux packages (tar, rpm, deb), powerpc-linux, x86_64-linux and Morphos. Anybody? Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Mac OS X Quickstart section in README file
On 18 Jul 06, at 8:55, Dr. Karl-Michael Schindler wrote: > There is no Mac OS X Quickstart section in the install/doc/readme.txt file, > although needed, in particular for the ReadMe.txt File of Mac OS X .dmg > package. . . Many thanks, it's being added to SVN now and should appear in 2.0.4. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Re[3]: [fpc-devel] FPC 2.0.4 release candidate 1 testing
On Mon, 2006-07-17 at 06:42 +0400, øòð Ãîñà ðåâñêèé ñ mail.ru wrote: > *. oracle: examples do not compile, makefile.fpc causes some problems. At least this last issue is fixed. I coudn't find however what's wrong with the makefile.fpc? Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Fwd: Re[5]: [fpc-devel] FPC 2.0.4 release candidate 1 testing
ÐÑо "forwarded" пиÑÑмо. From: ÐÑÑÑ ÐоÑаÑевÑкий Ñ mail.ru <[EMAIL PROTECTED]> To: Joost van der Sluis <[EMAIL PROTECTED]> Date: Wednesday, July 19, 2006, 3:47:59 AM Subject: [fpc-devel] FPC 2.0.4 release candidate 1 testing ===8<== ÐÑÑ Ð¾Ð´Ð½Ñй ÑекÑÑ === >> *. oracle: examples do not compile, makefile.fpc causes some problems. JvdS> At least this last issue is fixed. I coudn't find however what's wrong JvdS> with the makefile.fpc? JvdS> Joost The problems are incorrect paths in makefile.fpc-s. For oracle examples, fpcdir=../../../.. --- it's root dir, not FPC dir on my system (changing it to ../.. helps). ATTENTION: I didn't try to fpcmake all makefile.fpc, for example: examples\opengl has the same problem. (Probably, they were in a more nested place before building the release candidate, and were copied to the current place after creating working makefiles.) ===8<===ÐÐ¾Ð½ÐµÑ Ð¸ÑÑ Ð¾Ð´Ð½Ð¾Ð³Ð¾ ÑекÑÑа === -- ÐоÑÑаÑалÑÑ Ð¸ пеÑеÑлал Ð²Ð»Ð°Ð´ÐµÐ»ÐµÑ Ð°Ð´ÑеÑа [EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 2.0.4 rc2 and mse
On Tuesday 18 July 2006 23.27, Joost van der Sluis wrote: > On Tue, 2006-07-18 at 22:13 +0200, Martin Schreiber wrote: > > On Tuesday 18 July 2006 19.11, Joost van der Sluis wrote: > > > > MSE created some patches for fpc 2.0.4 rc1 > > > > to fix some widestring and db issues. > > > > http://svn.sourceforge.net/viewcvs.cgi/mseide-msegui/trunk/patch_fpc_ > > > >2_0_ 4/ > > > > > > > > I seems they are not applied to rc2. > > > > > > > > Can someone with widestring and db knowledge > > > > of fpc dev take a look at this? > > > > > > The db-files in fpc-2.0.4-rc2 are better up-to-date then the mse-one's. > > > What's left is irrelevent, or in the fopen case, an ugly hack that > > > shoudn't be there, imho. > > > > > > So for the db-part, nothing has to change. > > > > > > Joost > > > > Did you fix Mantis 6898 in the meantime? > > I didn't but Michael did in the mean time, so it seems. > > Well, I can live with that, until I come up with a real solution. I hope > that the fix doesn't brake any of the db-tests. > It seems that Michael used my file for rc1 to build the patch against fixes_2_0, so your changes in 4152 (Fix for datasets with a Recordsize which will not fit in a word) are lost. The patch to fix Mantis 6898 against 4023 is: " Index: bufdataset.inc === --- bufdataset.inc(revision 4023) +++ bufdataset.inc(working copy) @@ -77,6 +77,7 @@ var pc : pchar; begin + if fopen then begin FOpen:=False; FCurrentRecBuf := FFirstRecBuf; SetLength(FUpdateBuffer,0); @@ -87,6 +88,7 @@ FreeRecordBuffer(pc); end; SetLength(FFieldBufPositions,0); + end; end; procedure TBufDataset.InternalFirst; " Without this patch tbufdataset writes in coincidental memory areas if it is opened/closed several times with and without dbexceptions. It is the case if in MSEide one presses the test button in SQL editor while debugging the query. You can imagine what happens later... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
