"$999 per seat for the enterprise edition ..."
objC and xcode are free. And at this price, I'll buy a macbook !!!
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org
[mailto:fpc-devel-boun...@lists.freepascal.org] De la part de dmitry boyarintsev
Envoyé : mercredi 16 septembre
> Reading the wiki it is not really a snap to set it up to be able to develop
> iphone apps.
There's no ready-to-use solution to start developing iPhone apps.
> http://arstechnica.com/open-source/news/2009/09/monotouch-drops-net-into-apples-walled-app-garden.ars
"As MonoTouch necessitates stati
On Tuesday 15 September 2009 18:04:33 Luiz Americo Pereira Camara wrote:
>
> In my view, to get the fpc unicode support in a good state would be
> necessary to implement the encoding field in the string type so
> converting strings can be done system independently (seems to be the
> case of cpstr
Paul Ishenin wrote:
> Can we hope that after all experince you've got during this new compiler
> feature development you will not stop and continue with development of
> other 'nice to have' fpc features? For example discussed in 'Request for
> student project ideas' topic in the lazarus mail list?
On Wed, Sep 16, 2009 at 09:09, Paul Ishenin wrote:
> Michael V. Denisenko wrote:
> Can we hope that after all experince you've got during this new compiler
> feature development you will not stop and continue with development of other
> 'nice to have' fpc features? For example discussed in 'Reques
How is freepascal's iphone development compares to this latest mono way
of creating native iphone apps?
http://arstechnica.com/open-source/news/2009/09/monotouch-drops-net-into-apples-walled-app-garden.ars
Reading the wiki it is not really a snap to set it up to be able to
develop iphone apps.
On Sunday 13 September 2009 23:38:08 Jonas Maebe wrote:
> If the behaviour is different in Delphi.
at least in kylix.
this works in kylix and not in fpc
$ cat hooks2.pas
program hooks;
Graeme Geldenhuys escreveu:
Martin Schreiber het geskryf:
I think there is a misunderstanding. FPC UnicodeString type is identical to
widestring on all platforms except Windows. On Windows widestring is actual a
not reference counted OLE-string.
The problem as, that it's very differen
Michael V. Denisenko wrote:
I've just finished development of case-of-string
(http://bugs.freepascal.org/view.php?id=13700) which slightly
modifies case-statement syntax: now it understands either ordinal type
expressions or constant string type
expressions.
Can we hope that after all experi
On 14/09/2009, Vincent Snijders wrote:
>
> Fixed.
Thanks! :)
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist - fpc-dev
On Tue, Sep 15, 2009 at 8:40 AM, Marco van de Voort wrote:
> So D2009 is revolution, not evolution, and NOT backwards compatible. The
> question if FPC should do the same. And if so, when.
IMHO Never in the default modes, only in a new delphi2009 or similar
mode, if/when someone needs it. I use D
On 15 Sep 2009, at 17:46, Michael Van Canneyt wrote:
On Wed, 16 Sep 2009, Michael V. Denisenko wrote:
I've just finished development of case-of-string (http://bugs.freepascal.org/view.php?id=13700
) which slightly
modifies case-statement syntax: now it understands either ordinal
type expres
I'll send the description during the day; there are some specific cases which
deserve to be documented =)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Wed, 16 Sep 2009, Michael V. Denisenko wrote:
I've just finished development of case-of-string
(http://bugs.freepascal.org/view.php?id=13700) which slightly
modifies case-statement syntax: now it understands either ordinal type
expressions or constant string type
expressions.
For me, thes
I've just finished development of case-of-string
(http://bugs.freepascal.org/view.php?id=13700) which slightly
modifies case-statement syntax: now it understands either ordinal type
expressions or constant string type
expressions.
For me, these modifications should be included into documentation.
Marco van de Voort wrote:
In our previous episode, Thaddy said:
afaik widestrings are reference counted in Delphi. PWideChars not.
Yes, but not by Delphi but by COM.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://l
On Wed, 16 Sep 2009, Michael V. Denisenko wrote:
Trying to update case-statement syntax documentation I didn't understand how to
do it. Please help.
What do you want to do exactly ?
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.o
Trying to update case-statement syntax documentation I didn't understand how to
do it. Please help.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 15 Sep 2009, at 15:26, Gilles MARCOU wrote:
I am sorry to bother all of you about this small problem. In 2006, I
have written a small text about binding C/C++ code into Free Pascal
projects. I have written an updated version of this text and I'd
like to
replace the current version on the
Jonas Maebe het geskryf:
>
> It affects how the compiler interprets characters > #127 inside
> constant strings appearing in your source code. This can affect both
Thanks Jonas. I'll make a mental note of that.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Fr
Florian Klaempfl het geskryf:
>
> Using the WideString type on Windows. On Non-Windows WideString =
> UnicodeString.
Thanks. That complicates the unit tests a bit... or at least will be
obfuscated by IFDEF's a lot (something I hate in code).
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-pl
I forgot to mention
Please note that tiOPF and our company code does not use WideString in
general. So cwstring unit is never in any uses clause.
The tiOPF unit tests have some helper RTTI functions that extract
various bits of information. Those unit tests test for all supported
types in Obj
Graeme Geldenhuys schrieb:
> Hi,
>
> Continuing with the RTTI return types for various property types. In FPC
> 2.2.5, WideString properties were returned as tkWString types. Now with
> FPC 2.3.1, those are returned as tkUString.
>
> Does that mean tkWString is now deprecated? In that case, why
In our previous episode, Thaddy said:
> >
> afaik widestrings are reference counted in Delphi. PWideChars not.
Yes, but not by Delphi but by COM.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fp
Hi,
Continuing with the RTTI return types for various property types. In FPC
2.2.5, WideString properties were returned as tkWString types. Now with
FPC 2.3.1, those are returned as tkUString.
Does that mean tkWString is now deprecated? In that case, why is it not
removed from the enum list?
If
Hello,
I am sorry to bother all of you about this small problem. In 2006, I
have written a small text about binding C/C++ code into Free Pascal
projects. I have written an updated version of this text and I'd like to
replace the current version on the Free Pascal server
(ftp://ftp.freepascal.org/p
Martin Schreiber wrote:
On Tuesday 15 September 2009 15:21:54 Martin Schreiber wrote:
On Tuesday 15 September 2009 15:07:48 Jonas Maebe wrote:
On 15 Sep 2009, at 14:54, Michael Schnell wrote:
Martin Schreiber wrote:
On Windows widestring is actual a
not reference count
On Tuesday 15 September 2009 15:21:54 Martin Schreiber wrote:
> On Tuesday 15 September 2009 15:07:48 Jonas Maebe wrote:
> > On 15 Sep 2009, at 14:54, Michael Schnell wrote:
> > > Martin Schreiber wrote:
> > >> On Windows widestring is actual a
> > >> not reference counted OLE-string.
> > >
> > > H
On Tuesday 15 September 2009 15:07:48 Jonas Maebe wrote:
> On 15 Sep 2009, at 14:54, Michael Schnell wrote:
> > Martin Schreiber wrote:
> >> On Windows widestring is actual a
> >> not reference counted OLE-string.
> >
> > How can decent (and System independent) coding be done with not
> > reference
Michael Schnell wrote:
Micha Nelissen wrote:
FPC does support macros but not parametrized ones.
Any chance to use another preprocessor ?
So many choices, eg. sed?
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepas
Micha Nelissen wrote:
>
> FPC does support macros but not parametrized ones.
Any chance to use another preprocessor ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 15 Sep 2009, at 15:09, Michael Schnell wrote:
As FPC (other than Delphi) features a Macro preprocessor, I suppose
you
can get away without modifying the code.
No, you can't. FPC and Delphi macro's do not support parameters.
Jonas
___
fpc-deve
Michael Schnell wrote:
As FPC (other than Delphi) features a Macro preprocessor, I suppose you
can get away without modifying the code.
FPC does support macros but not parametrized ones.
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
As FPC (other than Delphi) features a Macro preprocessor, I suppose you
can get away without modifying the code.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 15 Sep 2009, at 14:54, Michael Schnell wrote:
Martin Schreiber wrote:
On Windows widestring is actual a
not reference counted OLE-string.
How can decent (and System independent) coding be done with not
reference counting (variable length) strings ?
Ask Microsoft and Borland. Microsoft d
On 15 Sep 2009, at 14:58, Graeme Geldenhuys wrote:
Does the $codepage only affect the WideString Manager? It doesn't
affect AnsiString (String type) at all?
It affects how the compiler interprets characters > #127 inside
constant strings appearing in your source code. This can affect both
On 15 Sep 2009, at 14:47, Martin Schreiber wrote:
On Tuesday 15 September 2009 14:34:52 Jonas Maebe wrote:
I don't think that the default source code encoding has ever been
changed. And the way to specify it is also quite old already.
Wasn't a string constant containing a character > #127 tr
Florian Klaempfl het geskryf:
>
> Because the source might not be written by you and because we want
> consistent behaviour.
OK, thanks.
Does the $codepage only affect the WideString Manager? It doesn't
affect AnsiString (String type) at all?
Regards,
- Graeme -
--
fpGUI Toolkit - a cros
In our previous episode, Michael Schnell said:
> If we really want a "character", MyChar would need to be a 32-Bit thing,
> and (in case of UTF, the [n] notation would need to scan the Unicode
> byte stream to find it, but I don't know if it's implemented in that way.)
Afaik a character in the uni
Martin Schreiber wrote:
> On Windows widestring is actual a
> not reference counted OLE-string.
How can decent (and System independent) coding be done with not
reference counting (variable length) strings ?
-Michael
___
fpc-devel maillist - fpc-devel
Jonas Maebe wrote:
> Our current unicodestring is an utf16string or something like that.
>
I don't claim that this is bad, but it can't be "Delphi compatible" at all.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freep
On Tuesday 15 September 2009 14:34:52 Jonas Maebe wrote:
>
> I don't think that the default source code encoding has ever been
> changed. And the way to specify it is also quite old already.
>
Wasn't a string constant containing a character > #127 treated as widestring
earlier?
Martin
___
Micha Nelissen wrote:
> Graeme Geldenhuys wrote:
>> MyString := '世界您好';
>> MyChar := MyString[1];
>> writeln(MyChar);
>> end.
>
> Extracting a Char from a UnicodeString? What's that supposed to do?
If "Char" is an 8-bit coded thing, for me this does not make sense
(using the [n] notation to
On 15 Sep 2009, at 14:37, Bruce Bauman wrote:
I am porting a large body of code from the MetaWare Professional
Pascal compiler to Free Pascal.
The existing code makes extensive use of the MetaWare "retype"
construct, which allows you to convert between types. For example:
retype(X, Rec1Ptr
I am porting a large body of code from the MetaWare Professional Pascal
compiler to Free Pascal.
The existing code makes extensive use of the MetaWare "retype" construct, which
allows you to convert between types. For example:
retype(X, Rec1Ptr) will convert the obect X to the type "Rec1Ptr".
On 15 Sep 2009, at 14:23, Martin Schreiber wrote:
On Tuesday 15 September 2009 14:19:51 Graeme Geldenhuys wrote:
Florian Klaempfl het geskryf:
Graeme said he did tell the compiler that he uses utf-8.
My mistake, I assumed that because my Linux system defaults to
UTF-8 it
will use utf-8.
Graeme Geldenhuys schrieb:
> Jonas Maebe het geskryf:
>> That's because you did not specify the code page of the source code,
>> in which case it's parsed as CP 8859-1.
>
> Even though my Linux system defaults to UTF-8? Umm
>
>
>> Add {$codepage utf-8} or save
>
> Adding that with test3.pas
On Tuesday 15 September 2009 14:19:51 Graeme Geldenhuys wrote:
> Florian Klaempfl het geskryf:
> > Graeme said he did tell the compiler that he uses utf-8.
>
> My mistake, I assumed that because my Linux system defaults to UTF-8 it
> will use utf-8. I guess I was wrong.
>
There was a change because
On 15 Sep 2009, at 14:18, Graeme Geldenhuys wrote:
Why doesn't the widestring manager default to the system defaults of
my
platform: UTF-8?
It does default to the system code page. It's the compiler that
doesn't while parsing your source file.
Jonas
On 15 Sep 2009, at 14:15, Florian Klaempfl wrote:
Jonas Maebe schrieb:
ä is not 世 as the website described the result to be.
That's because you did not specify the code page of the source
code, in
which case it's parsed as CP 8859-1. Add {$codepage utf-8} or save
the
file with an UTF
Florian Klaempfl het geskryf:
>
> Graeme said he did tell the compiler that he uses utf-8.
My mistake, I assumed that because my Linux system defaults to UTF-8 it
will use utf-8. I guess I was wrong.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http:
Jonas Maebe het geskryf:
>
> That's because you did not specify the code page of the source code,
> in which case it's parsed as CP 8859-1.
Even though my Linux system defaults to UTF-8? Umm
> Add {$codepage utf-8} or save
Adding that with test3.pas and then it works.
Jonas Maebe schrieb:
>
> On 15 Sep 2009, at 13:53, Graeme Geldenhuys wrote:
>
>> ian Klaempfl het geskryf:
>>>
>>> Do you use the cwstrings unit? Did you tell the encoding (UTF-8?) to the
>>> compiler? Did you use the UnicodeChar instead of Char?
>>
>>
>> Yes to all, and the example still doesn't
Jonas Maebe schrieb:
>
> On 15 Sep 2009, at 13:44, Florian Klaempfl wrote:
>
>> Graeme Geldenhuys schrieb:
>>> Micha Nelissen het geskryf:
Extracting a Char from a UnicodeString? What's that supposed to do?
>>>
>>> Follow the URL I posted with that example.
>>>
>>> I don't claim to know ever
In our previous episode, Graeme Geldenhuys said:
> > I think there is a misunderstanding. FPC UnicodeString type is identical to
> > widestring on all platforms except Windows. On Windows widestring is actual
> > a
> > not reference counted OLE-string.
>
> The problem as, that it's very differe
On 15 Sep 2009, at 13:53, Graeme Geldenhuys wrote:
ian Klaempfl het geskryf:
Do you use the cwstrings unit? Did you tell the encoding (UTF-8?)
to the
compiler? Did you use the UnicodeChar instead of Char?
Yes to all, and the example still doesn't work.
$ ./test
Martin Schreiber het geskryf:
> I think there is a misunderstanding. FPC UnicodeString type is identical to
> widestring on all platforms except Windows. On Windows widestring is actual a
> not reference counted OLE-string.
The problem as, that it's very different to Delphi. Bottom line: not
Del
On Tuesday 15 September 2009 12:56:08 Graeme Geldenhuys wrote:
>
> > Who says that? What is not supported?
>
> This I found myself:
> * Unicode+Variants... varUString type.
>
> By Google'ing for some D2009 unicode examples and searching the FPC
> source. Here I list a few that I found in under 5 m
Jonas Maebe het geskryf:
>
> The problem is that Delphi 2009's "unicodestring" type is something
> completely different.
Correct. I don't know the 'cpstr' branch so I can't comment on that.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opens
In our previous episode, Micha Nelissen said:
> >>> MyChar := MyString[1];
> >>> writeln(MyChar);
> >>> end.
> >> Extracting a Char from a UnicodeString? What's that supposed to do?
> >
> > CHAR is a 16-bit wchar in D2009. Simularly, pchar is a pointer to a 16-bits
> > char. (pansichar being
On 15 Sep 2009, at 13:44, Florian Klaempfl wrote:
Graeme Geldenhuys schrieb:
Micha Nelissen het geskryf:
Extracting a Char from a UnicodeString? What's that supposed to do?
Follow the URL I posted with that example.
I don't claim to know everything regarding Unicode. Florian said FPC
suppo
Florian Klaempfl het geskryf:
>
> Do you use the cwstrings unit? Did you tell the encoding (UTF-8?) to the
> compiler? Did you use the UnicodeChar instead of Char?
Yes to all, and the example still doesn't work.
$ ./test3
ä
ä is not 世 as the w
Graeme Geldenhuys schrieb:
> Florian Klaempfl het geskryf:
>> Then you shouldn't cry if a release candidate breaks your stuff :)
>
> I'm not crying. I go through this process on every new FPC release. It's
> part of my job. :-)
>
>
>> We can only fix stuff we know about.
>
> And I only know abo
Micha Nelissen schrieb:
> Graeme Geldenhuys wrote:
>> MyString := '世界您好';
>> MyChar := MyString[1];
>> writeln(MyChar);
>> end.
>
> Extracting a Char from a UnicodeString? What's that supposed to do?
As I said, it's UCS coding style :)
___
fpc-dev
Graeme Geldenhuys schrieb:
> Micha Nelissen het geskryf:
>> Extracting a Char from a UnicodeString? What's that supposed to do?
>
> Follow the URL I posted with that example.
>
> I don't claim to know everything regarding Unicode. Florian said FPC
> supports Unicode,
I said it supports the Unic
Marco van de Voort wrote:
In our previous episode, Micha Nelissen said:
Graeme Geldenhuys wrote:
MyString := '';
MyChar := MyString[1];
writeln(MyChar);
end.
Extracting a Char from a UnicodeString? What's that supposed to do?
CHAR is a 16-bit wchar in D2009. Simularly, pchar is a
In our previous episode, Micha Nelissen said:
> Graeme Geldenhuys wrote:
> > MyString := '';
> > MyChar := MyString[1];
> > writeln(MyChar);
> > end.
>
> Extracting a Char from a UnicodeString? What's that supposed to do?
CHAR is a 16-bit wchar in D2009. Simularly, pchar is a pointer t
Micha Nelissen het geskryf:
>
> Extracting a Char from a UnicodeString? What's that supposed to do?
Follow the URL I posted with that example.
I don't claim to know everything regarding Unicode. Florian said FPC
supports Unicode, so I simple tested a few D2009 examples I could find.
Hardly any w
Graeme Geldenhuys wrote:
MyString := '世界您好';
MyChar := MyString[1];
writeln(MyChar);
end.
Extracting a Char from a UnicodeString? What's that supposed to do?
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepasca
Florian Klaempfl het geskryf:
>
> Then you shouldn't cry if a release candidate breaks your stuff :)
I'm not crying. I go through this process on every new FPC release. It's
part of my job. :-)
> We can only fix stuff we know about.
And I only know about things (issues) when I get our code rea
In our previous episode, Florian Klaempfl said:
> > Exactly.
>
> The "1-byte" stuff has nothing to do with unicode but with code page
> aware strings.
Doesn't it have certain consequences for unicodestring<-> ansistring
conversions? Most notably to avoid that if a procedure has "ansistring" in
i
Graeme Geldenhuys schrieb:
> Marco van de Voort het geskryf:
>> MSE has no D2009 tested code afaik.
>
> MSE has no unit tests, period!
>
>> As far as I know unicodestring support is not at D2009 level, since the
>> 1-byte stuff and the format of internals are still missing/different?
>
> Exactl
Graeme Geldenhuys schrieb:
> Graeme Geldenhuys het geskryf:
>>> Who says that? What is not supported?
>
> Let me know how far you get with this example as well.
>
> http://compaspascal.blogspot.com/2008/10/delphi-2009-strings-explained-by.html
Didn't we talk about *unicode* ?
___
Graeme Geldenhuys schrieb:
> Florian Klaempfl het geskryf:
>> You should have tested with the unicode string branch one year ago ;)
>
> I gave up a long time ago testing "unstable" FPC branches with
> production code. Things change to often. I only test with the new FPC
> when it is announced that
Graeme Geldenhuys het geskryf:
>
>> Who says that? What is not supported?
Let me know how far you get with this example as well.
http://compaspascal.blogspot.com/2008/10/delphi-2009-strings-explained-by.html
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pas
Hi
make distclean crosszipinstall CPU_TARGET=arm CROSSOPT='-CfSOFT -darm
-dFPC-ARMEL -gl' FPC=/usr/bin/fpc
works for me well and i am able to cross compile and run many of the
gtk2 examples on arm-linux.
regards
Nataraj
On Tue, Sep 15, 2009 at 2:46 PM, Mark Morgan Lloyd
wrote:
> Just in case
Florian Klaempfl het geskryf:
>
> You should have tested with the unicode string branch one year ago ;)
I gave up a long time ago testing "unstable" FPC branches with
production code. Things change to often. I only test with the new FPC
when it is announced that a new version ('fixes' branch is c
On Tuesday 15 September 2009 11:49:13 Florian Klaempfl wrote:
> Who says that? What is not supported? Which issue report? FPC 2.3.1
> claims to support the UnicodeString type fully and it can be that bad
> because e.g. MSE is using it afaik.
Correct, it is enabled for MSEide+MSEgui SVN trunk whic
Marco van de Voort het geskryf:
>
> MSE has no D2009 tested code afaik.
MSE has no unit tests, period!
> As far as I know unicodestring support is not at D2009 level, since the
> 1-byte stuff and the format of internals are still missing/different?
Exactly. Plus, from what I can see from the u
oc...@pocketmt.com wrote:
Just a question Florian,
C offers the "volatile" attribute to mention that a variable can change
value without source code intervention (for example a variable that maps
to a port register).
I had all sort of troubles with gcc aggressive optimizations. Two years
ago,
In our previous episode, Florian Klaempfl said:
> > As far as I know FPC doesn't have Unicode support like Delphi 2009+ has.
> > Yet, when I query a WideString property, the RTTI functions now return
> > tkUString. tkUString is the Delphi Unicode string - but FPC doesn't
> > support that yet?
>
>
Graeme Geldenhuys schrieb:
> Hi,
>
> I reviewing the various errors that I am experiencing with tiOPF and FPC
> 2.3.1. The last count was 130+ errors! Considering that there was under
> 10 errors with FPC 2.2.5 and tiOPF, it seems a lot in FPC has changed.
You should have tested with the unicode
Jonas Maebe schrieb:
> I guess that FPC should simply write tkWString also for this unicode
> string type, since that's effectively what it is. Florian?
No. An unicode string encoded by tkUString is an utf-16 string.
___
fpc-devel maillist - fpc-devel@
On 15 Sep 2009, at 11:32, Graeme Geldenhuys wrote:
As far as I know FPC doesn't have Unicode support like Delphi 2009+
has.
Yet, when I query a WideString property, the RTTI functions now return
tkUString. tkUString is the Delphi Unicode string - but FPC doesn't
support that yet? So why is it
Micha Nelissen wrote:
> You could pass a pointer to this stack variable to another
> thread which could write to it asynchronously to your thread.
Ah, I see. Thanks for the enlightenment !
This might cause problem with FPC/Delphi. All local variables that are
referenced with a pointer of course w
Hi,
I reviewing the various errors that I am experiencing with tiOPF and FPC
2.3.1. The last count was 130+ errors! Considering that there was under
10 errors with FPC 2.2.5 and tiOPF, it seems a lot in FPC has changed.
Anyway, there are a few places in tiOPF code that has been IFDEF'ed
UNICODE f
Hi,
I'm working through tiOPF unit tests to get them up to speed with FPC
2.3.1. The unit test, testing for varUString type failed.
Looking at the fixes and trunk branch I don't find varUString declared
anywhere. Is this an oversight or something done for a specific reason?
I would image varUSt
Just in case it's useful to anybody in the future, I note that on Debian
"Lenny" (armel) compiling with
make NOGDB=1 "OPT=-O- -gl" NOWPOCYCLE=1 all
works but a make install might not copy ppcarm over- that might have to
be done manually.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. u
Michael Schnell wrote:
C can do local (Stack?) volatile variables. This does not seem to make
much sense.
Why not? You could pass a pointer to this stack variable to another
thread which could write to it asynchronously to your thread.
Micha
___
fp
oc...@pocketmt.com wrote:
> C offers the "volatile" attribute ...
I never found an issue when using static public variables for
synchronizing threads (while avoiding "atomic" problems). So seemingly
FPC (and Delphi) handles all non-local variables as volatile. (While C
usually optimizes them using
90 matches
Mail list logo
