Op 2010-06-21 17:11, Michael Van Canneyt het geskryf:
Only if you program it so. I program with UpdateMode=upWhereKeyOnly, and
then all updates go through, unless the record was deleted.
Because they don't get notified about their data (last saved) being lost. :-)
Well, I prefer that
On Mon, 21 Jun 2010 16:45:08 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
Op 2010-06-21 16:31, Mattias Gaertner het geskryf:
Now I understand.
Yes, TXMLConfig has the same design flaw as
TStringList.LoadFromFile/SaveToFile.
It is strange how you get used to such flaws and
On Tue, 22 Jun 2010, Graeme Geldenhuys wrote:
Op 2010-06-21 17:11, Michael Van Canneyt het geskryf:
Only if you program it so. I program with UpdateMode=upWhereKeyOnly, and
then all updates go through, unless the record was deleted.
Because they don't get notified about their data (last
Op 2010-06-22 09:51, Mattias Gaertner het geskryf:
Is there already some documentation?
None that I know of. I looked in the fpcdocs repository.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
In our previous episode, Graeme Geldenhuys said:
That is a rather dangerous approach to take. Imagine two accountants have a
Clients transaction screen open - both adding new transactions.
You should not be using as of yet unproven components and concepts in
accountant apps :)
On 21/06/10 15:42, Henry Vermaak wrote:
On 21 June 2010 15:35, Graeme Geldenhuysgraemeg.li...@gmail.com wrote:
Op 2010-06-21 16:29, Henry Vermaak het geskryf:
You can create a class that wraps all the json operations, and
therefore handle concurrency in one place.
Correct, that's one
Op 2010-06-22 11:17, Henry Vermaak het geskryf:
My point is that this is the wrong place to build such functionality
in. How do you propose this should work from different files or
processes?
s/files/threads
In tiOPF we have a Singleton for INI file processing. It uses the
On Tue, 22 Jun 2010, Graeme Geldenhuys wrote:
Op 2010-06-22 11:17, Henry Vermaak het geskryf:
My point is that this is the wrong place to build such functionality
in. How do you propose this should work from different files or
processes?
s/files/threads
In tiOPF we have a Singleton for
Op 2010-06-22 11:44, Michael Van Canneyt het geskryf:
Nono.
We'll put a big warning 'Not concurrency safe' in the files.
Yes, that is fine, and I understand that. I simply meant it as showing
Henry how tiOPF did it for INI files - not mean as FPC's implementation
must change as such.
can
Op 2010-06-22 12:01, Michael Van Canneyt het geskryf:
One of the drawbacks is that it will pull in thread support, and hence the C
library. But if you care to donate the code, I will be happy to include it
in FPC.
I can't remember when last I created an app that wasn't multi-threaded. :-)
On 22/06/10 10:29, Graeme Geldenhuys wrote:
Op 2010-06-22 11:17, Henry Vermaak het geskryf:
My point is that this is the wrong place to build such functionality
in. How do you propose this should work from different files or
processes?
s/files/threads
In tiOPF we have a Singleton for INI
OK, the subject sounded vaguely familiar, so when I Googled it, I found my
own posting back in 2009 asking the same questions. :-) I'll extend the
wiki multi-threading page with the answers that was given last time.
Just another question. Windows gets its threading support from the Win API.
Graeme Geldenhuys schrieb:
FPC finally has a working TMultiReadExclusiveWriteSynchronizer
implementation (tiOPF implemented it's own), but I don't know if that
implementation is available for FPC 2.4.x yet, or if it is still only in
Trunk. Either way, TXXXConfig classes could use the same
In our previous episode, Graeme Geldenhuys said:
If these questions are answered somewhere on the wiki, then just pointing
me in that direction please.
I know that to threading support is optional in Linux/Unix apps, and is
always available under Windows (not sure about Macs).
* What is
On 22/06/10 11:40, Graeme Geldenhuys wrote:
OK, the subject sounded vaguely familiar, so when I Googled it, I found my
own posting back in 2009 asking the same questions. :-) I'll extend the
wiki multi-threading page with the answers that was given last time.
Just another question. Windows
On 06/22/2010 12:40 PM, Graeme Geldenhuys wrote:
Just another question. Windows gets its threading support from the Win API.
Similar for OS/2. Doesn't the Linux kernel have a similar threading API, or
do they just rely on the C library?
The Linux Way is more like doing separate executable
In our previous episode, Henry Vermaak said:
If not, then I gather the C library (libc, glibc or whatever is used these
days) implemented threading in C code using the POSIX spec as the guide. So
couldn't one implement the POSIX spec (thinking of threading support only)
in pure Object
On 22 June 2010 13:24, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
Yes, but that would probably be a very daunting task.
The problem is not the programming (since a dedicated person could probably
start with a translated glibc in a good month), but
On 22 June 2010 13:13, Michael Schnell mschn...@lumino.de wrote:
Thus older Linux Kernels did not have special threading support.
Threading could be done using clone() (instead of fork() ) to create
processes that share some resources (e.g. memory). The kernel did not
Threading is still done
Op 2010-06-22 14:24, Marco van de Voort het geskryf:
No, not straight away. That is technically impossible without integrating a
full C compiler, since POSIX requires to be able to read and interpret
And what if one implements a non-posix based implementation (of Free
Pascal's own design)
On Tue, 22 Jun 2010, Graeme Geldenhuys wrote:
Op 2010-06-22 14:24, Marco van de Voort het geskryf:
No, not straight away. That is technically impossible without integrating a
full C compiler, since POSIX requires to be able to read and interpret
And what if one implements a non-posix
Op 2010-06-22 14:13, Michael Schnell het geskryf:
The Linux Way is more like doing separate executable than doing
threads, as Linux always provided high-performance inter process
communication (e.g. pipes, usable with select() etc.) and process
starting ( fork() ).
Form the previous links I
Op 2010-06-22 14:55, Michael Van Canneyt het geskryf:
It would be nice to have a kernel interface, though. That way you could have
threading support without pulling in libc.
Exactly. The less we rely on other libraries the better. :)
Regards,
- Graeme -
--
fpGUI Toolkit - a
On 22 June 2010 13:55, Michael Van Canneyt mich...@freepascal.org wrote:
The problem starts if you start linking to C libraries. In that case you're
pretty much forced to use pthreads;
Why is that? I thought you could use anything, as long as it's posix compliant?
Henry
On 22 June 2010 13:13, Michael Schnell mschn...@lumino.de wrote:
Of course you can avoid using the library, do the stuff in Pascal and
directly access the Kernel API, but this might be dangerous in case the
API might be modified some time in the future or if it's different with
different
On Tue, 22 Jun 2010, Henry Vermaak wrote:
On 22 June 2010 13:55, Michael Van Canneyt mich...@freepascal.org wrote:
The problem starts if you start linking to C libraries. In that case you're
pretty much forced to use pthreads;
Why is that? I thought you could use anything, as long as
On 22 June 2010 14:16, Michael Van Canneyt mich...@freepascal.org wrote:
On Tue, 22 Jun 2010, Henry Vermaak wrote:
On 22 June 2010 13:55, Michael Van Canneyt mich...@freepascal.org wrote:
The problem starts if you start linking to C libraries. In that case
you're
pretty much forced to use
On 22 Jun 2010, at 15:01, Henry Vermaak wrote:
On 22 June 2010 13:55, Michael Van Canneyt mich...@freepascal.org
wrote:
The problem starts if you start linking to C libraries. In that
case you're
pretty much forced to use pthreads;
Why is that? I thought you could use anything, as
In our previous episode, Henry Vermaak said:
The problem is not the programming (since a dedicated person could probably
start with a translated glibc in a good month), but the continuous
maintenance (for every distribution separately, since they could use
different kernels, options etc) ,
In our previous episode, Graeme Geldenhuys said:
Op 2010-06-22 14:24, Marco van de Voort het geskryf:
No, not straight away. That is technically impossible without integrating a
full C compiler, since POSIX requires to be able to read and interpret
And what if one implements a non-posix
In our previous episode, Henry Vermaak said:
[ Charset ISO-8859-1 unsupported, converting... ]
On 22 June 2010 13:55, Michael Van Canneyt mich...@freepascal.org wrote:
The problem starts if you start linking to C libraries. In that case you're
pretty much forced to use pthreads;
Why is
On 22 June 2010 14:29, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
The problem is not the programming (since a dedicated person could probably
start with a translated glibc in a good month), but the continuous
maintenance (for every distribution
On 22 June 2010 14:33, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
[ Charset ISO-8859-1 unsupported, converting... ]
On 22 June 2010 13:55, Michael Van Canneyt mich...@freepascal.org wrote:
The problem starts if you start linking to C libraries. In
In our previous episode, Henry Vermaak said:
The syscall interface is very stable, so you wouldn't have to touch
anything there. ?I haven't looked at the nptl source, yet, what do they
use that changes between distros?
The syscall interface now only uses a subset of relatively the oldest
In our previous episode, Henry Vermaak said:
Why is that? ?I thought you could use anything, as long as it's posix
compliant?
Good luck getting all the C libs to use your POSIX compatible threading
model.
The reason for creating a native threading implementations is that you
_don't_
On 22 June 2010 14:38, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
Why is that? ?I thought you could use anything, as long as it's posix
compliant?
Good luck getting all the C libs to use your POSIX compatible threading
model.
The reason for
In our previous episode, Henry Vermaak said:
Why would you need a native one in the first place?
I was under the impression that fpc uses libc to implement threads on
unix. Is this not the case?
Yes. And 99% of the thread using programs also use other C libs that use
libc anyway (*)
As
On 22 June 2010 14:46, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
Why would you need a native one in the first place?
I was under the impression that fpc uses libc to implement threads on
unix. Is this not the case?
Yes. And 99% of the thread
In our previous episode, Henry Vermaak said:
Yes. And 99% of the thread using programs also use other C libs that use
libc anyway (*)
So, to answer your question above about why we need a native one: so
we can do away with the libc dependency.
In 0.1% of the programs. The rest doesn't
On 22 June 2010 15:21, Marco van de Voort mar...@stack.nl wrote:
The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
Libc breaks often, but I'm sure that a native lib will break much more
I certainly haven't experienced this libc that breaks often.
In our previous episode, Henry Vermaak said:
The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
Libc breaks often, but I'm sure that a native lib will break much more
I certainly haven't experienced this libc that breaks often.
Keep in mind
Marco van de Voort schrieb:
In our previous episode, Henry Vermaak said:
The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
Libc breaks often, but I'm sure that a native lib will break much more
I certainly haven't experienced this libc that
In our previous episode, Florian Klaempfl said:
In our previous episode, Henry Vermaak said:
The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
Libc breaks often, but I'm sure that a native lib will break much more
I certainly haven't
In our previous episode, Marco van de Voort said:
At least according to Linus, the kernel api/syscall interface will never
break.
They will just not implement new calls on new archs ? :-)
Euh, old calls obviously.
___
fpc-devel maillist -
On 22 June 2010 16:15, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
Libc breaks often, but I'm sure that a native lib will break much more
I certainly
On 22 June 2010 16:18, Florian Klaempfl flor...@freepascal.org wrote:
Marco van de Voort schrieb:
In our previous episode, Henry Vermaak said:
The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
Libc breaks often, but I'm sure that a native lib
In uGenerics I have two lists. 1 for Data Structures and 1 for Objects.
If I place this statement in declarations for a system that handles an
Int64 List...
GInt64List=specialize GStructListInt64;
... then I get
C:\Developer\Source\Libraries\Core\uInt64Array.pas(54,17) Error:
Forward
In our previous episode, Henry Vermaak said:
At least according to Linus, the kernel api/syscall interface will never
break.
Never say never, things will be added, but not taken away. There are
some very old programs that still run fine on new kernels. I've read
that someone has
Marco van de Voort schrieb:
In our previous episode, Marco van de Voort said:
At least according to Linus, the kernel api/syscall interface will never
break.
They will just not implement new calls on new archs ? :-)
Euh, old calls obviously.
Well, adding a new arch is not breaking old
In our previous episode, Florian Kl?mpfl said:
In our previous episode, Marco van de Voort said:
At least according to Linus, the kernel api/syscall interface will never
break.
They will just not implement new calls on new archs ? :-)
Euh, old calls obviously.
Well, adding a new
Hi,
I noticed this change log on fpc svn:
florian 15472
* don't build a native compiler for embedded targets
I sometimes build a native fpc on N900,
(sometimes because it takes some time)
Will this affect me if I do a 'svn up fpc' on the N900 ?
When is a target considered embedded by the
On 22 Jun 2010, at 22:17, Den Jean wrote:
I noticed this change log on fpc svn:
florian 15472
* don't build a native compiler for embedded targets
I sometimes build a native fpc on N900,
(sometimes because it takes some time)
Will this affect me if I do a 'svn up fpc' on the
Den Jean schrieb:
Hi,
I noticed this change log on fpc svn:
florian 15472
* don't build a native compiler for embedded targets
I sometimes build a native fpc on N900,
(sometimes because it takes some time)
Will this affect me if I do a 'svn up fpc' on the N900 ?
When is a
Marco van de Voort wrote:
Huh? Do stock Linux kernels still support a.out? Since afaik ELF was only added
in
1.1.52 ?
It's a kernel option to support it. Most distro's choose module here I
think? (Autodetect when used)
Micha
___
fpc-devel
Andrew Brunner wrote:
... then I get
C:\Developer\Source\Libraries\Core\uInt64Array.pas(54,17) Error:
Forward declaration not solved GStructList$Int64.Empty(var Int64);
Please always provide a complete compilable example.
Micha
___
fpc-devel
On Tuesday 22 June 2010 22:27:59 Florian Klämpfl wrote:
Devices without any operating system, i.e. mainly microcontrollers.
thx Jonas and Florian, updating and compiling now.
fpc on arm related question,
when installing fpc, I need to install to /opt,
because /opt resides on a partition with
Den Jean schrieb:
On Tuesday 22 June 2010 22:27:59 Florian Klämpfl wrote:
Devices without any operating system, i.e. mainly microcontrollers.
thx Jonas and Florian, updating and compiling now.
fpc on arm related question,
when installing fpc, I need to install to /opt,
because /opt
On Tuesday 22 June 2010 23:24:28 Florian Klämpfl wrote:
(This is normal on N900, it is called optify, do not know
why /opt/bin is not in path.)
Just insert /opt/bin into the path?
this would mean editing a system file
like /etc/profile, I'd like to avoid that
in instructions, as apt-get
On 22 June 2010 21:31, Micha Nelissen mi...@neli.hopto.org wrote:
Marco van de Voort wrote:
Huh? Do stock Linux kernels still support a.out? Since afaik ELF was only
added in
1.1.52 ?
It's a kernel option to support it. Most distro's choose module here I
think? (Autodetect when used)
Yes,
I provided a working example. Just employ uGenerics in a project and declare
GInt64List=specialize GStructListInt64;
TInt64List=Class(GInt64List)
public
procedure Empty(Var Item:Int64); override;
procedure Done(Var Item:Int64);override;
procedure Init(Var Item:Int64);override;
end;
The result is get with a direct typecast Variant String. In this case
if Variant is Null an exception will occur.
Is this the desired behavior or should be changed to a call to VarToStr?
Luiz
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Luiz Americo Pereira Camara escreveu:
The result is get with a direct typecast Variant String. In this
case if Variant is Null an exception will occur.
Is this the desired behavior or should be changed to a call to VarToStr?
Sorry. Wrong list
Luiz
On Tuesday 22 June 2010 22:45:59 Den Jean wrote:
are needed to just compile fpc and lazarus. I know
when trying to compile lazarus using native arm on N900,
I get the errors below. There is no file lazarus.or (strange extension ??)
I manually tried some tests from
63 matches
Mail list logo
