Re: [fpc-pascal] Limit concurrent connections to Firebird DB
On Thu, 1 Jun 2006, Graeme Geldenhuys wrote: > Hi, > > Anybody know how I can limit concurrent connections to a Firebird DB > via a FPC/Lazarus application. I am currently using FBLib as my > database component, but info on any sql component will do. > > Interbase used to have a Licensing API build into the database. Did > Firebird inherit that? Obviously not, since it is open source. There is no way to limit this, unless you recode the Firebird Server. In your own program, you can simply keep a count of the number of connection components... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Daemon doesn't work right at boottime.
> /me considers recoding the whole thing as a cronjob... > (A joke, in reality I simply don't have the diskspace to put cron where > this is needed so it's not an option even if it COULD do the work). Interesting, I have since learned something else. In fact it DOES work - but there is an odd difference. When started from the commandline, the timer starts at 0, ergo my maths (using mod to determine interval matches) means that every plugin gets run at least once on startup. For some reason however, when started at boottime - the timer starts at 1 - so things don't run until the first match of their interval setting. I actually wanted things to be launched once at boot-up - and then only again at the next interval each time. I do think this is a very odd thing to find though - why would the counter start with different values depending on whether it is started by a script or by hand ? Any ideas ? -- "there's nothing as inspirational for a hacker as a cat obscuring a bug by sitting in front of the monitor" - Boudewijn Rempt A.J. Venter Chief Software Architect OpenLab International www.getopenlab.com www.silentcoder.co.za +27 82 726 5103 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparing version numbers
On 6/3/06, A.J. Venter <[EMAIL PROTECTED]> wrote: The debian version on the other hand is well over 200 lines of code by itself, and I am not entirely sure my version is going to be stable on all testdata yet. Learn to code with UnitTests (process is called Test Driven Development). I have to admin, it takes a while to get use to it, but you have a major confidence boost after writing some code, and having tests to prove that it works. This version number process is a perfect candidate to start with. Regards, Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparing version numbers
Learn to code with UnitTests (process is called Test Driven Development). Never used. How does this work? I found only a unit called "UnitTests.pp" and nothing else. Thank you. jk ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparing version numbers
Jilani Khaldi wrote: > >> Learn to code with UnitTests (process is called Test Driven >> Development). > > Never used. How does this work? I found only a unit called > "UnitTests.pp" and nothing else. > Thank you. The first article that started the practice, written by Kent Beck and Erich Gamma: http://junit.sourceforge.net/doc/testinfected/testing.htm See also the JUnit website http://www.junit.org/index.htm for more articles on the subject. To get you started with unit testing with FPC: http://www.freepascal.org/docs-html/fpcunit.pdf Regards, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparing version numbers
On 6/3/06, Jilani Khaldi <[EMAIL PROTECTED]> wrote: > Learn to code with UnitTests (process is called Test Driven > Development). Never used. How does this work? I found only a unit called "UnitTests.pp" and nothing else. Use an xUnit testing framework while coding. Free Pascal comes with fpcUnit. Under Delphi people normally use DUnit. Under Java they use JUnit, etc... Regarding TDD (Test Driven Development) look at the following websites: In short - You write a test, Write the code, Run the tests, Refactor. Then repeat the whole process... The first 3 steps should be completed in under a minute. As I said, it is very different to traditional programming style, but once mastered, you can't think of programming any other way. http://en.wikipedia.org/wiki/Test_driven_development http://www.testdriven.com http://www.agiledata.org/essays/tdd.html Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparing version numbers
> Regarding TDD (Test Driven Development) look at the following websites: > In short - You write a test, Write the code, Run the tests, Refactor. > Then repeat the whole process... The first 3 steps should be > completed in under a minute. As I said, it is very different to > traditional programming style, but once mastered, you can't think of > programming any other way. > Well my only real worry was whether I needed to do exception catching on the strToInt calls, but I cannot imagine a dataset where my other functions wouldn't ensure I have valid inputs for those. I'm checking your links though - it may well be worth running through it. I should just mention this function is actually part of a lazarus project, but since it's not visual in any way and doesn't use the LCL at all, I reckoned fpc-pascal would be a more appropriate place to ask questions. A.J. -- "there's nothing as inspirational for a hacker as a cat obscuring a bug by sitting in front of the monitor" - Boudewijn Rempt A.J. Venter Chief Software Architect OpenLab International www.getopenlab.com www.silentcoder.co.za +27 82 726 5103 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparing version numbers
> On 6/3/06, Jilani Khaldi <[EMAIL PROTECTED]> wrote: > > > Learn to code with UnitTests (process is called Test Driven > > > Development). > > > > Never used. How does this work? I found only a unit called > > "UnitTests.pp" and nothing else. > > Use an xUnit testing framework while coding. Free Pascal comes with > fpcUnit. Under Delphi people normally use DUnit. Under Java they use > JUnit, etc... > > Regarding TDD (Test Driven Development) look at the following websites: > In short - You write a test, Write the code, Run the tests, Refactor. > Then repeat the whole process... The first 3 steps should be > completed in under a minute. As I said, it is very different to > traditional programming style, but once mastered, you can't think of > programming any other way. I've said this before but most of the test-driven development stuff is kind of quack. That a program needs to be tested, is common sense. The programs which need to be tested more, are programs that are going to be used frequently. Write programs that test your library or program, but don't buy books or read web pages about that quack called test-driven development - because it's just books about common sense - flawed common sense, actually. You simply can't always write tests *before* you develop your program because this is too much design up front. If you know all the tests you should write before you even *have your program coded*, then you are designing too much up front, and knowing too much up front - this is not the way case in programming - the program changes as you start developing it. So you can't test for everything before you write any code. Sometimes you need a quick program that will only be used a few times in the entire year, and writing tests would be a waste of time. And as for the testing suite that FPC uses - this is not even "test driven development", according to the true definition of test driven development. The test suite that fpc has are composed of a bunch of tests written by users and developers who found bugs after the code for FPC was already written. In other words, most of us realistically write code before writing tests - and the most effecient way to write tests is have your users write the tests, if you can. A bug reporting system is a testing system. But since bugs come after code has written, this must be against the test driven development model. I bet the test driven development model requires that you write all your bugs before any code is written - so that you don't need a bug reporting system. Hogwash. Use common sense - test the hell out of your programs if they are going to be used 100 times per day, if you are having lots of problems with that program. If you aren't having any problems with that program - and it's doing its job - testing the program would be like beating a dead horse. All programs have bugs - but if the bugs affect no one, then there is no point in fixing those bugs. FPC for example has about a million undiscovered bugs - and no one in their right mind could know those bugs ahead of time by writing tests ahead of time - it's not humanly possible. Realistically, and reasonably (which test-driven development is not) most of the bugs are going to be tested for after some code is written for the job first. If you write tests first, you might be writing stupid tests that you already know work - because what you know works, is the tests you will write for! What you don't know works, isn't written yet - so you can't test it yet. Those are the tests that you need to spend time on - the stuff you don't know - not the stuff you know. Until you write complicated code that's broken, you can't write a good test. But this isn't what TDD pages or books seem to claim. Write your own tests by hand - don't use any "testing framework". It's simply easier to write mini programs that test your code, than it is to use some testing framework. Each program and each library you write will need to be tested uniquely - a framework is impossible since there is no "framework" around testing. Testing is unique - anything so unique as testing cannot possibly have a framework. A web program will need completely different tests, and completely different prioritization of what to test than a search utility program or a file back up program, or a you-name-it program. What people do need to learn about tests - is that they need to save their tests. Save them for later. This doesn't mean you need a testing framework. It simply means you need to dedicate a /tests/ folder in your project directory and save some tests there. But imagine you spend several days writing tests for a large project ahead of time - before writing actual code for the project - then you finally get around to writing the project and you find out that the project is a no-go. People don't want the project. Your software idea was good for a few folks - but the product isn't needed on the mark
