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 t
On Mon, 21 Jun 2010 16:45:08 +0200
Graeme Geldenhuys 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 think it is n
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 sa
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 Geldenhuys 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 possible solution like I ment
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
TMulti
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.
> ca
On Tue, 22 Jun 2010, Graeme Geldenhuys wrote:
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 F
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 f
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.
If these questions are answered somewhere on the wiki, then just pointing
me
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.
Simi
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 synch
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).
>
> * Wha
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 get
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 executa
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 Obje
On 22 June 2010 13:24, Marco van de Voort 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 the conti
On 22 June 2010 13:13, Michael Schnell 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 with clone.
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 base
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
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 cross-pla
On 22 June 2010 13:55, Michael Van Canneyt 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 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 archs (e.g. some a
On Tue, 22 Jun 2010, Henry Vermaak wrote:
On 22 June 2010 13:55, Michael Van Canneyt 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?
Be
On 22 June 2010 14:16, Michael Van Canneyt wrote:
>
>
> On Tue, 22 Jun 2010, Henry Vermaak wrote:
>
>> On 22 June 2010 13:55, Michael Van Canneyt wrote:
>>>
>>> The problem starts if you start linking to C libraries. In that case
>>> you're
>>> pretty much forced to use pthreads;
>>
>> Why is tha
On 22 Jun 2010, at 15:01, Henry Vermaak wrote:
On 22 June 2010 13:55, Michael Van Canneyt
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 compl
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
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 n
In our previous episode, Henry Vermaak said:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 22 June 2010 13:55, Michael Van Canneyt 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 though
On 22 June 2010 14:29, Marco van de Voort 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 separate
On 22 June 2010 14:33, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
> [ Charset ISO-8859-1 unsupported, converting... ]
>> On 22 June 2010 13:55, Michael Van Canneyt wrote:
>> >
>> > The problem starts if you start linking to C libraries. In that case you're
>> > prett
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 relativel
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
On 22 June 2010 14:38, Marco van de Voort 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 reas
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 (*
On 22 June 2010 14:46, Marco van de Voort 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 u
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 does
On 22 June 2010 15:21, Marco van de Voort 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. Does
that m
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
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 lib
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 certai
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 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 certainl
On 22 June 2010 16:18, Florian Klaempfl 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 will brea
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 GStructList;
... then I get
C:\Developer\Source\Libraries\Core\uInt64Array.pas(54,17) Error:
Forward declarati
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 brea
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.
>
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 mak
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 th
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
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 mailli
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 maill
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 wit
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,
> becaus
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 ap
On 22 June 2010 21:31, Micha Nelissen 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, it's B
I provided a working example. Just employ uGenerics in a project and declare
GInt64List=specialize GStructList;
TInt64List=Class(GInt64List)
public
procedure Empty(Var Item:Int64); override;
procedure Done(Var Item:Int64);override;
procedure Init(Var Item:Int64);override;
end;
and
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 svn/fpc/tests/test/units/s
On Tue, 22 Jun 2010, Luiz Americo Pereira Camara wrote:
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?
This is the correct (and delphi compatible) b
66 matches
Mail list logo
