Re: [fpc-devel] Re: PDF on C/C++ code in Free Pascal

2009-09-16 Thread Sven Barth 

Jonas Maebe schrieb:


On 16 Sep 2009, at 20:09, Sven Barth wrote:


Jonas Maebe schrieb:
As far as I know, there is not a single test for this functionality, 
so I'm not sure that it actually works.


Well... then I think it's time to change this.

I'll try to test this functionality (and to fix it, if it fails),


Thanks!


But I can't say when I'll have the time for it. Some weeks/months more 
won't matter with this old feature ^^




Frankly, I don't really know. I only discovered this by chance while 
working on the Objective-C support. As far as I could tell, you simply 
have to use "cppclass" rather than "class", and that's it (the cppdecl 
name mangling style is automatically applied to all methods afterwards, 
if I remember correctly). I don't think that field accesses can work at 
all though, nor calling virtual methods (let alone defining multiple 
inheritance hierarchies). The only thing that really seemed to be 
implemented was C++ name mangling.




Virtual methods would have been cool... So we would be able to import e. 
g. the Irrlicht library in a very easy way ^^



(although I think this message will be posted between Jonas' and 
Florian's, I will quote Florian here, cause I'm using digest mode and 
don't know how to answer him more directly (in the list))


>
> The code is already very old. It worked for very simply classes and
> gcc 2.95 iirc. But nobody continued so far to improve it.
>

The little searching that I did in the compiler's source tells me that 
it already supports gcc 3.x (and with this 4.x) name mangling. So it 
*should* work with gcc 3+. But whether it works is indeed another story ^^


If someone would be willing to extend this feature (virtual methods, 
perhaps multiple inheritance) would this be welcomed? I don't know if 
I'll find the time to do that, but I think it would certainly increase 
my knowledge about the compiler ^^ (but first I'll steer the Native NT 
port into a save harbour :) )


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

Re: [fpc-devel] Re: PDF on C/C++ code in Free Pascal

2009-09-16 Thread Florian Klaempfl 
Jonas Maebe schrieb:
> 
> On 16 Sep 2009, at 20:09, Sven Barth wrote:
> 
>> Jonas Maebe schrieb:
>>> As far as I know, there is not a single test for this functionality,
>>> so I'm not sure that it actually works.
>>
>> Well... then I think it's time to change this.
>>
>> I'll try to test this functionality (and to fix it, if it fails),
> 
> Thanks!
> 
>> but you  (or another core developer) should at least tell me how that
>> feature is supposed to work and (equally important) be used.
> 
> Frankly, I don't really know. I only discovered this by chance while
> working on the Objective-C support. As far as I could tell, you simply
> have to use "cppclass" rather than "class", and that's it (the cppdecl
> name mangling style is automatically applied to all methods afterwards,
> if I remember correctly). I don't think that field accesses can work at
> all though, nor calling virtual methods (let alone defining multiple
> inheritance hierarchies). The only thing that really seemed to be
> implemented was C++ name mangling.

The code is already very old. It worked for very simply classes and gcc
2.95 iirc. But nobody continued so far to improve it.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: PDF on C/C++ code in Free Pascal

2009-09-16 Thread Jonas Maebe 


On 16 Sep 2009, at 20:09, Sven Barth wrote:


Jonas Maebe schrieb:
As far as I know, there is not a single test for this  
functionality, so I'm not sure that it actually works.


Well... then I think it's time to change this.

I'll try to test this functionality (and to fix it, if it fails),


Thanks!

but you  (or another core developer) should at least tell me how  
that feature is supposed to work and (equally important) be used.


Frankly, I don't really know. I only discovered this by chance while  
working on the Objective-C support. As far as I could tell, you simply  
have to use "cppclass" rather than "class", and that's it (the cppdecl  
name mangling style is automatically applied to all methods  
afterwards, if I remember correctly). I don't think that field  
accesses can work at all though, nor calling virtual methods (let  
alone defining multiple inheritance hierarchies). The only thing that  
really seemed to be implemented was C++ name mangling.



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

Re: [fpc-devel] Re: PDF on C/C++ code in Free Pascal

2009-09-16 Thread Sven Barth 

Jonas Maebe schrieb:


As far as I know, there is not a single test for this functionality, so 
I'm not sure that it actually works.




Well... then I think it's time to change this.

I'll try to test this functionality (and to fix it, if it fails), but 
you  (or another core developer) should at least tell me how that 
feature is supposed to work and (equally important) be used.


I'd love to see Free Pascal as a compiler that supports linking to C++ 
libraries (even if they are only GCC ones).


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

Re: [fpc-devel] iphone development

2009-09-16 Thread ABorka 

Well, according to Apple the number is 50M :

http://www.theiphoneblog.com/2009/09/10/apple-music-event-numbers-30m-iphones-20m-ipod-touches-75k-apps-18b-downloads/


dmitry boyarintsev wrote:

But $1K is peanuts if the finished application will be presented to 30-40
million people for download.

I wonder what application can make 30-40 downloads? AFAIK there're
less iPhones/Touches sold all over the world.



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

Re: [fpc-devel] iphone development

2009-09-16 Thread Jonas Maebe 


On 16 Sep 2009, at 19:01, ABorka wrote:

What is interesting that they seem to be able to really use a  
different language within the apple rules of iphone development.


Of course they can, there are no rules against that. You just cannot  
distribute any adapted headers (so you have to rely on install-time  
automatic conversion, if you want to play by the rules).



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

Re: [fpc-devel] iphone development

2009-09-16 Thread dmitry boyarintsev 
> But $1K is peanuts if the finished application will be presented to 30-40
> million people for download.
I wonder what application can make 30-40 downloads? AFAIK there're
less iPhones/Touches sold all over the world.

If Jonas is right about Apple's license violation. Apple can simply
ban your C# application. And there's no other way to sell the
application, but Apple Store.

Btw, according to Mono Touch docs, you have to pay for iPhone license
anyway, so in the end, enterprise license costs $1.5K. Is it worthy to
risk?

> Considering what I read about obj C development... I think many
> people/companies would happily pay the price to have some nice language for
> development.
> What is interesting that they seem to be able to really use a different
> language within the apple rules of iphone development.
ObjC is a fine language. Of course, it would take some time to get
used to it (and its syntax), but still, it's possible to create fine
applications with it.
Some modern languages such as Ruby and Python are already provide
bridges for the ObjC interface.

thanks,
dmitry
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] iphone development

2009-09-16 Thread ABorka 

You guys are correct about the pricing, of course.

But $1K is peanuts if the finished application will be presented to 
30-40 million people for download.
Considering what I read about obj C development... I think many 
people/companies would happily pay the price to have some nice language 
for development.


What is interesting that they seem to be able to really use a different 
language within the apple rules of iphone development.


Octal, Pocket MicroTechnics wrote:

"$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 2009 08:03
À : FPC developers' list
Objet : Re: [fpc-devel] iphone development


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 static linking, users will need a
commercial license. This will cost $999 per seat for the enterprise
edition and $399 per seat for the personal edition and will include
one year of updates. For additional details, you can refer to the
MonoTouch website."

imho, it's cheaper to learn obj-c.

thanks,
dmitry
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel




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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Luiz Americo Pereira Camara 

Martin Schreiber escreveu:

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 branch) and add a RTLString type to minimize conversions
when creating a unicode RTL


But as an additional string type, the fast and small FPC UnicodeString type we 
have now should be preserved.


  


Yes. RTLString would be just an alias to UnicodeString in win32 and 
UTF8String in unixes


Luiz

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

Re: [fpc-devel] C++ source in fpc

2009-09-16 Thread Desmond Coertzen 
Please accept my apologies to the ENTIRE FPC TEAM.

I should have never asked this. I was weak! (Pipe dream).

I have realized that this is the freepascal project, and all effort should
be done to keep things in pascal. I am myself a big pascal fan, and I have
forsaken my values and fundamentals. Please feel free to slap me.

I have stopped my whining and ported the code from c++ to fpc.

Problem solved.

On Mon, Sep 14, 2009 at 8:34 PM, Marco van de Voort  wrote:

> In our previous episode, Desmond Coertzen said:
> > I need some advice:
> >
> > I have a few c++ source files containing conversion functions. Is it at
> all
> > possible to compile them into my fpc project?
> >
> > Is this possible with fpc? Am I under
> > the influence of a pipe dream?
>
> Wrap it in plain C and stuff it in a library with libstdC++ linked to it.
> Then write a Pascal header for
> it, and use it like any C library.
>
> > I imagine I have seen this in kylix 3.
>
> Could be, but that is because Borland also has a BCB C++ compiler that is
> kept strictly in line with Delphi from a compatibility aspect.
>
> In BCB there is also specific syntax to declare stuff Delphi compatible.
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Graeme Geldenhuys 
Jonas Maebe het geskryf:
> 
> The way to implement stuff like that is to call the appropriate  
> library functions. It makes no sense to completely re-implement  
> everything in the RTL.
> 
> Such API-calls can of course be wrapped by the RTL, similar to the way  
> there are already function such as sysutils.ansicomparestr()/ 

Yes, I would imagine we have something similar to that. It would seem
the most logical and like you mentioned, keep backward compatibility and
speed for non-unicode RTL functions.

 eg: sysutils.unicomparetext()

Internally, this function could normalize the text first and then do
some comparison, etc...


Regards,
  - Graeme -

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

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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Jonas Maebe 


On 16 Sep 2009, at 16:34, Michael Schnell wrote:


Does the FPC rtl compare two unicode-strings a and b as equal with
"if a=b ..."
even when both print as "ä" and one is coded as a single character and
the other is coded as an a and a " double dot superscript" ?


No, it just compares the literal bytes (and it will probably keep  
doing so forever, both for Delphi and for backwards compatibility).



How should it do that ? it would need a table of the codings of all
possible multi-unicode-character encodings ?


The way to implement stuff like that is to call the appropriate  
library functions. It makes no sense to completely re-implement  
everything in the RTL.


Such API-calls can of course be wrapped by the RTL, similar to the way  
there are already function such as sysutils.ansicomparestr()/ 
sysutils.ansicomparetext()/... etc. These also simply call through to  
OS-supplied functionality.



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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Michael Schnell 
Jonas Maebe wrote:
> 
> On 16 Sep 2009, at 11:44, Michael Schnell wrote:
> 
> Don't analyse them character by character, but use standard functions to
> compare them. 

Does the FPC rtl compare two unicode-strings a and b as equal with
 "if a=b ..."
even when both print as "ä" and one is coded as a single character and
the other is coded as an a and a " double dot superscript" ?

How should it do that ? it would need a table of the codings of all
possible multi-unicode-character encodings ?

-Michael

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

Re: [fpc-devel] iphone development

2009-09-16 Thread Jonas Maebe 


On 16 Sep 2009, at 11:13, Jonas Maebe wrote:

We don't distribute an interface to most iPhone frameworks, in part  
because the iPhone SDK licensing agreement forbids distributing any  
derivative works. The Mono guys apparently ignore this and do  
distribute a bunch of XML files generated from the files included in  
the iPhone SDK. So keep in mind that you are violating Apple's  
licensing agreement if you use their stuff (although Apple doesn't  
seem to care much about that, given that a lot of applications based  
on an engine using the precursor of MonoTouch, namely Unity3D, are  
shipping already). At any point, an application you write using that  
stuff could probably be yanked from the Apple store though (unless  
the Mono people have a redistribution agreement with Apple, but I  
doubt that).


They also copied (pre-release) documentation from Apple onto their  
website: http://www.go-mono.com/docs/index.aspx?tlink...@ecma%3a143%23nsobject%2fm


I'm quite sure they have never asked permission to do so (nor would  
they get it). I would strongly recommend against trying to get Apple  
to take it down though, since would only have downsides (it won't help  
us get permission, it will hurt developers using MonoTouch, and it  
will hurt users who want the application being written using that  
framework).



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

Re: [fpc-devel] iphone development

2009-09-16 Thread dmitry boyarintsev 
Here you're. Free iPhone dev tools: http://code.google.com/p/iphone-dev/

thanks,
dmitry
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Marco van de Voort 
In our previous episode, Thaddy said:
> > It is. Widestring always worked more or less, on both FPC,Kylix and Delphi.
> > But the COM backed versions (FPC2.2+ (?) and Delphi) suffered from
> > performance problems
> As I wrote it should be opaque ( = transparent, btw).
> At least for windows I overcame most of the problems that widestring is 
> using COM by writing a simple COM Delphi memorymanager replacement years 
> ago in pre-userspace. Thus all reference counting (at least at block 
> level, but also for delphi strings) is managed by COM. It is still 
> available at my website. And yes, it is rather slow. But string 
> manipulation is slow anyway.

The slow was already relative to the non-COM kylix widestring handling.

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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Thaddy 

Marco van de Voort wrote:

This should be transparent for the non-library user code



It is. Widestring always worked more or less, on both FPC,Kylix and Delphi.
But the COM backed versions (FPC2.2+ (?) and Delphi) suffered from
performance problems

As I wrote it should be opaque ( = transparent, btw).
At least for windows I overcame most of the problems that widestring is 
using COM by writing a simple COM Delphi memorymanager replacement years 
ago in pre-userspace. Thus all reference counting (at least at block 
level, but also for delphi strings) is managed by COM. It is still 
available at my website. And yes, it is rather slow. But string 
manipulation is slow anyway.
I had to do this for COM production code written in Delphi to work more 
reliable. The solution had good reviews from then Borland techies.


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

Re: [fpc-devel] Re: PDF on C/C++ code in Free Pascal

2009-09-16 Thread Jonas Maebe 


On 16 Sep 2009, at 09:29, Sven Barth wrote:

What about documenting the 'cppclass' feature of Free Pascal? I  
found this a few weeks ago and digged in the compilers code. From  
what I saw it should still work with gcc 3.x/4.x compiled cpp code.  
But I didn't test how. The only documentation is that you can't mix  
normal class hierarchy with a cppclass one...


As far as I know, there is not a single test for this functionality,  
so I'm not sure that it actually works.



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

Re: [fpc-devel] Local boolean variables not always initalized with false by default?

2009-09-16 Thread theo 
You can fairly expose most such bugs in FPC by compiling with -gt, 

OK, thanks. I was not aware of this "feature".


PS: your system clock seems to be off by an hour,
Sorry. Better now? 


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

Re: [fpc-devel] Local boolean variables not always initalized with false by default?

2009-09-16 Thread Jonas Maebe 


On 16 Sep 2009, at 10:49, theo wrote:

Uninitialised means exactly that: not initialised, neither with  
false,

nor with true


OK, that's what I thought. So Delphi is "hiding" a coding bug here.


Well, it's not Delphi's fault either. It could just as well have been  
the other way round (with the value being non-0 in Delphi, and 0 in  
FPC).



Hard to find such little things ;-)


You can fairly expose most such bugs in FPC by compiling with -gt, - 
gtt or -gttt. All of these will initialise all local variables (and  
out parameters) with specific (non-0) values when the function starts.  
-g initialises everything with 0, but that is generally more  
likely to hide bugs than expose them. It doesn't hurt to try that one  
too though.


Note: I would strongly recommend against using -g in shipping  
software to have automatic zero-initialisation of local variables,  
since the initialisation is performed in a very inefficient way.



Jonas

PS: your system clock seems to be off by an hour, could you correct  
it? (it messes up thread ordering of messages)

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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Jonas Maebe 


On 16 Sep 2009, at 11:44, Michael Schnell wrote:


Jonas Maebe wrote:


Analysing strings by hand not a very smart thing to do with unicode
strings.


How should it be avoided if I want to react on a user input or on a
string read from a file ?


Don't analyse them character by character, but use standard functions  
to compare them. Any unicode support library worth its salt will offer  
you many different ways to compare strings, because depending on the  
context you may need different ways:


a) the locale may matter (e.g., depending on whether "." means  
"decimal point" or "thousands separator", a comparison result may be  
different)
b) you have many different ways to order (unicode) strings. E.g.,  
these are the options that Apple's CFString comparison offers:  (note that not all of those flags are about regular comparisons,  
and some of them are just for performance reasons). See in particular  
flags such as kCFCompareNonliteral, kCFCompareWidthInsensitive and  
kCFCompareLocalized.


This indeed causes problems with Pascal's generic comparison  
operators. I guess we will either have to define a particular  
behaviour for them (presumably whatever CodeGear chose), add some  
global variable that you can set to influence the behaviour, or tell  
people to use CompareText() and friends (and probably add variants  
with various options).


The upside of these complications (which have always existed, but most  
people just ignored them and their programs only worked with one or  
two locales and/or encodings), is that if you deal with it properly in  
the context of unicode, then your code will probably automatically  
behave "correctly" with many locales/scripts.



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

Re: [fpc-devel] Local boolean variables not always initalized with false by default?

2009-09-16 Thread theo 
> Uninitialised means exactly that: not initialised, neither with false,  
> nor with true

OK, that's what I thought. So Delphi is "hiding" a coding bug here.
Hard to find such little things ;-)

Thank you Jonas

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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Michael Schnell 
Jonas Maebe wrote:
> 
> Analysing strings by hand not a very smart thing to do with unicode
> strings. 

How should it be avoided if I want to react on a user input or on a
string read from a file ?

That is what a great lot of user programs do

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

Re: [fpc-devel] Local boolean variables not always initalized with false by default?

2009-09-16 Thread Jonas Maebe 


On 16 Sep 2009, at 10:34, theo wrote:


While uninitialized variables are certainly a bad thing, it's still a
bit strange why it defaults to 'true' in this case.
It was 'false' with Delphi.


Uninitialised means exactly that: not initialised, neither with false,  
nor with true (both in Delphi and FPC). What you get is whatever  
random value happens to be in stack memory at that location, based on  
what previously executed code stored there.



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

[fpc-devel] Local boolean variables not always initalized with false by default?

2009-09-16 Thread theo 
Hello,

I don't know if this is a bug.

If fixed an old bug in the janSQL port.
http://forum.lazarus.freepascal.org/index.php/topic,6694.msg35412/
The problem was, that there was an uninitialized local boolean in

TjanSQL.selectFromJoin
...
var bAggregate:boolean;   

if you insert a
  writeln(bAggregate);  in Line 758 (start of procedure!) then you get a
'true'.

It's fixed now using bAggregate:=False; there.
See http://www.theo.ch/lazarus/janSQLLaz.zip

While uninitialized variables are certainly a bad thing, it's still a
bit strange why it defaults to 'true' in this case.
It was 'false' with Delphi.

Thanks.

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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Jonas Maebe 


On 16 Sep 2009, at 11:30, Michael Schnell wrote:


Jonas Maebe wrote:


There are definitions of "canonical forms" (both "composed" and
"decomposed") of utf strings ...


So unless the rtl automatically offers this, the user is required to
take care of this by hand any time he tries to analyze a string in  
any way.


Analysing strings by hand not a very smart thing to do with unicode  
strings. And if you want to do that, you most certainly should convert  
them to a canonical form first.



Code from hell 



That's what assembler programmers said when compilers were introduced  
("why can't I control anymore exactly how my data is laid out so I can  
save 2 instructions in my function, because I know that variable A  
comes right after variable B in memory").



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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Michael Schnell 
Jonas Maebe wrote:
> 
> There are definitions of "canonical forms" (both "composed" and
> "decomposed") of utf strings ...

So unless the rtl automatically offers this, the user is required to
take care of this by hand any time he tries to analyze a string in any way.

Code from hell 

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

Re: [fpc-devel] iphone development

2009-09-16 Thread Jonas Maebe 


On 16 Sep 2009, at 01:06, ABorka wrote:

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


We don't distribute an interface to most iPhone frameworks, in part  
because the iPhone SDK licensing agreement forbids distributing any  
derivative works. The Mono guys apparently ignore this and do  
distribute a bunch of XML files generated from the files included in  
the iPhone SDK. So keep in mind that you are violating Apple's  
licensing agreement if you use their stuff (although Apple doesn't  
seem to care much about that, given that a lot of applications based  
on an engine using the precursor of MonoTouch, namely Unity3D, are  
shipping already). At any point, an application you write using that  
stuff could probably be yanked from the Apple store though (unless the  
Mono people have a redistribution agreement with Apple, but I doubt  
that).


Reading the wiki it is not really a snap to set it up to be able to  
develop iphone apps.


a) install the package
b) create a new Xcode project using the provided template
c) compile it/run it
d) see a nice spinning 3D FPC logo on your iPod/iPhone

(with an extra step between a) and b) if you're using the iPhone SDK  
3.0/3.1, because of a bug in the iPhone SDK linker). This does not  
include solving any troubles you may have with getting the certificate  
mess sorted out, because that's identical for regular Objective-C  
projects.


All the other information on the wiki is background information (a lot  
of it just repeating stuff from Apple's website to avoid having to  
answer questions from answer people who didn't read that information).



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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Martin Schreiber 
On Tuesday 15 September 2009 15:31:36 Thaddy wrote:

>
> afaik widestrings are reference counted in Delphi. PWideChars not.

According my experience, the Delphi7/Kylix3 documentation and this article:
http://edn.embarcadero.com/article/21301
"
WideStrings are now reference counted. In Windows, the Delphi WideString is 
implemented as an Ole BSTR to maximize data compatibility with OLE and 
ActiveX APIs. Ole BSTRs / WideStrings are not reference counted like Delphi 
AnsiStrings, so WideStrings tend to be a bit promiscuous in copying 
themselves all over the place. 
In Linux, there is no WideString compatibility requirement or issue, so we've 
reimplemented WideStrings to use the same copy-on-write reference count 
semantics as AnsiStrings. In fact, Kylix WideStrings use many of the same 
internal RTL support functions as AnsiStrings! How's that for code reuse!
"
you are wrong.

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

[fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread theo 

> I suppose converting a combined character into a single character is not
> possible as it would need a huge table.

Michael Schnell, I thought you'd know about character.pas 
http://wiki.lazarus.freepascal.org/Theodp
It does normalization:

class function Normalize_NFD(AString: UTF8String): UTF8String;
class function Normalize_NFC(AString: UTF8String): UTF8String;
class function Normalize_NFKD(AString: UTF8String): UTF8String;
class function Normalize_NFKC(AString: UTF8String): UTF8String;

See the charandscan example at:
Combined Chars: ÅÅ'


Cheers 
Theo

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

[fpc-devel] Re: PDF on C/C++ code in Free Pascal

2009-09-16 Thread Sven Barth 
(I hope this gets attached to the right thread, cause I just registered to 
fpc-devel)

Hi!

Gilles MARCOU wrote:
> By the way, I am open to all suggestions to improve this text.

What about documenting the 'cppclass' feature of Free Pascal? I found this a 
few weeks ago and digged in the compilers code. From what I saw it should still 
work with gcc 3.x/4.x compiled cpp code. But I didn't test how. The only 
documentation is that you can't mix normal class hierarchy with a cppclass 
one...

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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Marco van de Voort 
In our previous episode, Michael Schnell said:
> Marco van de Voort wrote:
> > 
> > Yes, but not by Delphi but by COM.
> 
> This should be transparent for the non-library user code

It is. Widestring always worked more or less, on both FPC,Kylix and Delphi.
But the COM backed versions (FPC2.2+ (?) and Delphi) suffered from
performance problems.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Jonas Maebe 


On 16 Sep 2009, at 09:24, Jonas Maebe wrote:


so you cannot have to files that have the name "ä"


*two files


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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Jonas Maebe 


On 16 Sep 2009, at 09:00, Michael Schnell wrote:


But if this conversion is possible (even if not in all cases)
theoretically but not practically, this means that there is _no_ way  
to

determine if Unicode strings are identical.


There are definitions of "canonical forms" (both "composed" and  
"decomposed") of utf strings that do enable this sort of stuff. E.g.,  
Apple uses this for their HFS+ file system so you cannot have to files  
that have the name "ä" in the same directory (since there are multiple  
ways in unicode to represent this character).



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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Michael Schnell 
Marco van de Voort wrote:
> 
> Yes, but not by Delphi but by COM.

This should be transparent for the non-library user code

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

Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support

2009-09-16 Thread Michael Schnell 
Marco van de Voort wrote:
> 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 unicode sense can consist out of multiple
> codepoints. (e.g. for languages that have many possibilities of combining
> "accents" where there doesn't exist a glyph for every combination)
> 
> So a character (as something that prints a whole) can consist out of
> multiple 32-bit values (codepoints)

Even Worse !!!

So  "Unicode Character" does not make sense at all.

I suppose converting a combined character into a single character is not
possible as it would need a huge table.

But if this conversion is possible (even if not in all cases)
theoretically but not practically, this means that there is _no_ way to
determine if Unicode strings are identical.

This makes programming a profoundly obscene adventure and we better
should start breeding cattle instead.

Obviously combined Unicode characters are code from hell and should be
banned completely :( .

-Michael

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