Re: [fpc-pascal] non visual timer win32

2010-10-19 Thread Graeme Geldenhuys
Op 2010-10-18 22:44, Justin Smyth het geskryf:
 Guys
  
 i have an app on win32 that runs a timer when a form is hidden , any
 ideas how i get a timer to work when the form is hidden ?


Timers (TTimer and FPTimer) are not related to forms, so they will run even
without a form instance.



Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net:8080/fpgui/

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Can variables be declared within a block?

2010-10-19 Thread Sven Barth

Am 18.10.2010 20:21, schrieb Vannus:


On 18 October 2010 15:33, Sven Barth pascaldra...@googlemail.com
mailto:pascaldra...@googlemail.com wrote:

Am 18.10.2010 16:20, schrieb Michael Van Canneyt:

Object Pascal is a simple, beautiful and easy to read language.
The FPC
team tries to keep it that way.


And that is why I like the FPC team so much. :D


agreed.

When I went from C++ to Pascal back in 98/99, I found it quite hard
initially. Not being able to put variables anywhere  everywhere was
really awkward, but it dawned on me that I shouold be coding better.
Since then, i would say If you need vars throughout your code, then
something is wrong with your code


Makes you wonder why the ReactOS devs always declare their variables at 
the beginning of the functions (they're using C). :P Take a look at the 
source files of ntoskrnl for example.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] FPC for High Performance Computing (HPC) Components with Application API

2010-10-19 Thread Mark Morgan Lloyd

Andrew Brunner wrote:


Ok. You mentioned NPTL.  What can you tell me about that?  Is that the
project that makes pthreads?

I'm looking to get the latest and greatest source of posix threads so
I draw upon that code and perhaps even come up with a native version
for FPC.  Any help would be greatly appreciated.


I wonder if I could possibly make a suggestion here. NPTL is fairly well 
established in the Linux kernel- it's been a bit of a long haul, with 
some architectures getting it much later than others. However a lot of 
unix programmers are still very unfamiliar with the concept of threads, 
and diluting the brand with a competing implementation isn't going to 
help matters.


If you want to do something which is implemented inside FPC then don't 
mess with threads. Instead get an efficient coroutine implementation 
working, and then build whatever else you want on top of that- but call 
it something like Preemptive Coroutines :-)


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] non visual timer win32

2010-10-19 Thread Felipe Monteiro de Carvalho
MyTimer := TTimer.Create(Application);
MyTimer.OnTimer := myHandler;

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] ReadStr/WriteStr vs Val/Str

2010-10-19 Thread Jonas Maebe

On 19 Oct 2010, at 01:56, Richard Ward wrote:

 As a user of the old Macintosh Pascal (later THINK Pascal),  both ReadStr and 
 WriteStr functions were included and I used them quite a bit.   The names 
 were different but the FPC implementation is basically the same as far as I 
 can tell.
 
 Besides backward compatibility, portability issues and personal preference, 
 is there any functionality Val and Str may have that ReadStr and WriteStr 
 don't?  I can't see any, but wanted to make sure there there were no subtle 
 technical issue(s) I might need to consider.

readstr gives a run time error when you try to read an invalid number, while 
val() returns an error in the last parameter. Other than that, they all use the 
same helper routines to perform the actual conversions.


Jonas___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] non visual timer win32

2010-10-19 Thread Graeme Geldenhuys
Op 2010-10-19 10:17, Felipe Monteiro de Carvalho het geskryf:
 MyTimer := TTimer.Create(Application);
 MyTimer.OnTimer := myHandler;
 

or even

MyTimer := TTimer.Create(nil);
MyTimer.OnTimer := myHandler;

...later when application terminates...

MyTimer.Free;



Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net:8080/fpgui/

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] IntList

2010-10-19 Thread Luiz Americo Pereira Camara

Juha Manninen (gmail) escreveu:

Hi

In Lazarus project jcf2 component has an IntList class which is poorly 
implemented. It depends on integer and pointer being the same size.

I will later suggest to replace it.

I have a better IntList. See:
  http://github.com/JuhaManninen/Pascal/blob/master/IntList/intlist.pas

It is similar to TStringList except that it works with integers.
It is well tested.

Question: can this class be added to FCL?
Clearly such class is needed sometimes and people must make their own versions 
of it. Generics can solve it in the future but it is not ready yet.
  


Yes it's ready in fpc 240:

uses
 Fgl;

type
 TIntegerList = specialize TFPGList Integer;

Luiz
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] IntList

2010-10-19 Thread Juha Manninen (gmail)
On Tuesday 19 October 2010 19:10:39 Luiz Americo Pereira Camara wrote:
 Yes it's ready in fpc 240:
 
 uses
   Fgl;
 
 type
   TIntegerList = specialize TFPGList Integer;

Well, yes. It is almost as good as a dedicated class. It has a Sort method but 
you must feed the compare function for it.
It does not have a Find method for a binary search in a sorted list.
Indexof does a linear search.

Anyway, it could be used as a base class in Lazarus. I don't know what is the 
Lazarus team's policy for using generics in Lazarus code-base.

In FPC 2.4.0 I had problems with memory consumption of generics containers.
A Integer, Integer map hogged gigabytes of memory while my data took only 
kilobytes (less than 1 MB for sure), on a 64 bit Linux.
Now I have the latest FPC trunk 2.5.1 and the problems are gone. I added 
10 integers to both a List and to a Map and didn't even notice the memory 
increase in resource monitor.

  TIntegerList = specialize TFPGList Integer;
  TIntegerMap = specialize TFPGMap Integer, Integer;

TFPGMap's problem still is that it is not a hash map and is butt-slow with 
lots of data. A hash map is a superior container type, it really should be 
changed.
Besides, people expect to get a hash map when they see map in the class 
name. Now they get a list which is deceivingly named as map.


Juha
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] IntList

2010-10-19 Thread Sven Barth

Am 19.10.2010 19:54, schrieb Juha Manninen (gmail):

On Tuesday 19 October 2010 19:10:39 Luiz Americo Pereira Camara wrote:

Yes it's ready in fpc 240:

uses
   Fgl;

type
   TIntegerList = specialize TFPGListInteger;


Well, yes. It is almost as good as a dedicated class. It has a Sort method but
you must feed the compare function for it.
It does not have a Find method for a binary search in a sorted list.
Indexof does a linear search.

Anyway, it could be used as a base class in Lazarus. I don't know what is the
Lazarus team's policy for using generics in Lazarus code-base.

In FPC 2.4.0 I had problems with memory consumption of generics containers.
AInteger, Integer  map hogged gigabytes of memory while my data took only
kilobytes (less than 1 MB for sure), on a 64 bit Linux.
Now I have the latest FPC trunk 2.5.1 and the problems are gone. I added
10 integers to both a List and to a Map and didn't even notice the memory
increase in resource monitor.

   TIntegerList = specialize TFPGListInteger;
   TIntegerMap = specialize TFPGMapInteger, Integer;

TFPGMap's problem still is that it is not a hash map and is butt-slow with
lots of data. A hash map is a superior container type, it really should be
changed.
Besides, people expect to get a hash map when they see map in the class
name. Now they get a list which is deceivingly named as map.


As you seem to have experience with efficient data structures, what 
about creating such a generic hash map? :)


(but don't use 2.4.2rc1 and current/unpatched 2.4.3 as a test base as 
those don't have the fixes from trunk to make specialize working again)


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] IntList

2010-10-19 Thread Michael Van Canneyt



On Tue, 19 Oct 2010, Sven Barth wrote:


Am 19.10.2010 19:54, schrieb Juha Manninen (gmail):

On Tuesday 19 October 2010 19:10:39 Luiz Americo Pereira Camara wrote:

Yes it's ready in fpc 240:

uses
   Fgl;

type
   TIntegerList = specialize TFPGListInteger;


Well, yes. It is almost as good as a dedicated class. It has a Sort method 
but

you must feed the compare function for it.
It does not have a Find method for a binary search in a sorted list.
Indexof does a linear search.

Anyway, it could be used as a base class in Lazarus. I don't know what is 
the

Lazarus team's policy for using generics in Lazarus code-base.

In FPC 2.4.0 I had problems with memory consumption of generics containers.
AInteger, Integer  map hogged gigabytes of memory while my data took only
kilobytes (less than 1 MB for sure), on a 64 bit Linux.
Now I have the latest FPC trunk 2.5.1 and the problems are gone. I added
10 integers to both a List and to a Map and didn't even notice the 
memory

increase in resource monitor.

   TIntegerList = specialize TFPGListInteger;
   TIntegerMap = specialize TFPGMapInteger, Integer;

TFPGMap's problem still is that it is not a hash map and is butt-slow with
lots of data. A hash map is a superior container type, it really should be
changed.
Besides, people expect to get a hash map when they see map in the class
name. Now they get a list which is deceivingly named as map.


As you seem to have experience with efficient data structures, what about 
creating such a generic hash map? :)


(but don't use 2.4.2rc1 and current/unpatched 2.4.3 as a test base as those 
don't have the fixes from trunk to make specialize working again)


Currently, the FPC team is looking at an implementation of Vlado Boza 
us...@ksp.sk for a standard template library for inclusion in FPC.


The code is on

http://code.google.com/p/stlpascal

Please have a look and comment on it.

I'm not a generics expert and am not in the position to judge whether this 
library is good or not.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] IntList

2010-10-19 Thread Brian Winfrey
Take a look at http://code.google.com/p/fprb/.  I have just perused
it, but it looks pretty good.

Brian.


 Currently, the FPC team is looking at an implementation of Vlado Boza
 us...@ksp.sk for a standard template library for inclusion in FPC.

 The code is on

 http://code.google.com/p/stlpascal

 Please have a look and comment on it.

 I'm not a generics expert and am not in the position to judge whether this
 library is good or not.

 Michael.
 ___
 fpc-pascal maillist  -  fpc-pas...@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Re: Can variables be declared within a block?

2010-10-19 Thread Vinzent Höfler

On Tue, 19 Oct 2010 02:07:25 +0200, Dimitri Smits smi...@telenet.be
wrote:

on the other hand, what stops the OP from using 'with'? (multiple  
levels/variables?)


with contaminates the name space. Locally scoped variables don't.

and you won't die from using another stack variable scoped at the  
beginning of the method.


True. If the subroutine is long enough that an additional declaration
block seems necessary, it's probably too long already.

just to say that I'm not too fond of that c-ism in a pascal language  
(although I've used it plenty in c++, java, C#, php, ... over the years).


Just because C has it doesn't mean it is a C-ism. Local declaration blocks
are definitely not an invention of C. IIRC, C89/90 didn't even had it yet.


Vinzent.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] What are the issues involved in threads sharing variables?

2010-10-19 Thread Brian Winfrey
 Polling where the list size is highly dynamic you will need protect
 it.  I think FPC has thread safe list objects too.

Yes it does, Classes.TThreadList I think.  I thought it was a
conatiner for threads, but it is a safe list.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Can variables be declared within a block?

2010-10-19 Thread Vannus
On 19 October 2010 15:06, Rob Kennedy
kennedyri+fpc-pas...@gmail.comkennedyri%2bfpc-pas...@gmail.com
 wrote:

 On Tue, Oct 19, 2010 at 12:23 AM, Jürgen Hestermann 
 juergen.hesterm...@gmx.de wrote:

 Reimar Grabowski schrieb:

  for (int i = 0;...)
 Can't see anything wrong. I use declaration of variables inside blocks
 quite often in Java and C++ but have never missed it in pascal. Please
 enlighten me. What is so bad about creating temporary variables inside
 blocks instead of the beginning of a function in a language that supports
 it?


your example is at the start of a for loop block, which is much the same
as having it at the start of a procedure block

pascal prevents people from putting declarations strewn throughout the
block, which i found reduces mistakes  bugs from 20-30 people coding, and
their code is more readable. Coding standards are do similar thing.

which of the three languages do you find fastest to code in, including any
debugging time?



 I never thought about doing such declarations in Pascal.
 Although I would not be against it in general (provided
 that all identifiers have to be different)


 That seems like an arbitrary restriction, given that Object Pascal
 *already* allows multiple variables to have the same name *and* be declared
 somewhere other than the top of the function. Think of exception handlers. I
 don't know about everyone else, but my exception variables are all always
 named e.


are you sure? i've tried making var's in WITh and Try Except blocks using
Delphi7 with no luck. Or is this a difference between object pascal 
delphi?



 I could understand disallowing variables from *shadowing* other local
 variables of the same name (it's legal in C, but better compilers warn about
 it), but I see no reason for the language to require variables from
 different local scopes to have unique names. Write that into your local
 coding guidelines and enforce it in code reviews, not the language spec.


i'd agree with that, local vars are local after all. perhaps make it a
compiler option.

- V
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Locate method in TBuFDataset

2010-10-19 Thread John


  
  
Hi all,
  
  Does anyone know if TBuFDataset.Locate honours the TLocateOptions
  parameter passed to it ? It certainly doesn't *seem* to work. 

  I am actually using a TSQLQuery against an SQLite3 database, Laz
  0.9.28.2, fpc 2.2.4, Win32. 
  
  I should say that I am probably well out of my depth looking at
  this stuff, but as far as I can see, TSQLQuery does not override
  locate, and looking at the code in TBufDataset I can't see
  anywhere that the options are passed to anything. 
  
  TDBCompareRec has a field for the options, but I can't see that it
  is set. If they were set in that structure, DBCompareText seems
  to honour loCaseInsensitive, but takes no notice of loPartialKey.
  
  cheers,
  John Sunderland 

  

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal