[fpc-devel] Error to file doesn't work
I can't get FreePascal 2.0.0 to write the compiler's error report to a file. I ran ppc386 with the -Fe option set to the file I wanted to use for the error output, but it just wasn't working; why not? Thanks, Alex C. Barberi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cryptography class nedded ?
On Thu, 17 Nov 2005, Florian Klaempfl wrote: > Paul Davidson wrote: > > > Did some work getting SSL working for FPC. Attached is unit that > > exposes most of the functions required. Tested with Darwin and Linux. > > What about putting it in packages/extra? OpenSSL is quite common. I was thinking the same thing. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Unicode RTL
> Who knows the future? > Maybe in 10 years 16bit non multi 'byte' encoding is sufficient for all > remaining languages. > Or maybe 32bit encodings will become the default. the unix and web worlds are going utf-8 the ms and java worlds are going utf-16 both are variable width ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cryptography class nedded ?
Will alter the unit, and submit it tomorrow :) Thanks On Nov 17, 2005, at 16:06, Florian Klaempfl wrote: Paul Davidson wrote: Did some work getting SSL working for FPC. Attached is unit that exposes most of the functions required. Tested with Darwin and Linux. What about putting it in packages/extra? OpenSSL is quite common. Hope this helps On Nov 17, 2005, at 7:57, Christian Iversen wrote: On Thursday 17 November 2005 13:18, Alexander Todorov wrote: Hi folks, can you tell if there is a good crypto class for FPC / Lazarus ? What do you use for crypting your stuff ? Any opinions are welcome. I'd go for openssl. I know we have to implement crypto support at some point in Technetium, and I'd really look into that library. It seems well-developed. Writing a new, safe, crypto lib is _hard_. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel P Davidson Corax Networks Inc. http://CoraxNetworks.com -- -- ___ 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 P Davidson ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cryptography class nedded ?
Paul Davidson wrote: > Did some work getting SSL working for FPC. Attached is unit that > exposes most of the functions required. Tested with Darwin and Linux. What about putting it in packages/extra? OpenSSL is quite common. > > > > > Hope this helps > > On Nov 17, 2005, at 7:57, Christian Iversen wrote: > >> On Thursday 17 November 2005 13:18, Alexander Todorov wrote: >> >>> Hi folks, >>> can you tell if there is a good crypto class for FPC / Lazarus ? >>> What do you use for crypting your stuff ? >>> Any opinions are welcome. >> >> >> I'd go for openssl. I know we have to implement crypto support at some >> point >> in Technetium, and I'd really look into that library. It seems >> well-developed. >> >> Writing a new, safe, crypto lib is _hard_. >> >> -- >> Regards, >> Christian Iversen >> ___ >> fpc-devel maillist - fpc-devel@lists.freepascal.org >> http://lists.freepascal.org/mailman/listinfo/fpc-devel >> >> > P Davidson > Corax Networks Inc. > http://CoraxNetworks.com > > > > > ___ > 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] MySQL v4.0 v4.1 and v5.0
--- Vincent Snijders <[EMAIL PROTECTED]> escribió: > Joost van der Sluis wrote: > > Hi all, > > > > atm I have a nearly finished mysql.inc file that can be used with > MySQL > > v4.0 v4.1 and v5.0. Loaded dynamically and static. > > > > It uses several defines to set the right MySQL version and to > turn the > > dynamically linking on or off. > > > > Create 6 different units in packages/base/mysql - for each > combination > > one? (thus mysql40, mysql40dyn, mysql41, mysql41dyn, mysql50 and > > mysql51dyn?) > > > > But then, what to do with the MySQL-connection for sqldb? In > principle > > the only thing that has to be changes to use another > MySQL-version is to > > change the used unit. So, always use the TMysqlConn-component, > but > > changes the usage-clausule. > > > > But how can this be handled by Lazarus? With the SQLDB-package > only one > > unit can be used. (Or else multiple types with the same name are > > defined) Let the users manually change the usage-line if they > want to > > use a different MySQL-library-version? > > FOr the sqldb package, let them add a define to the compiler > options: > -dMYSQL40 > or > -dMYSQL41 > or > -dMYSQL50 > > That seems more user friendly than editing the uses clause. > > In the source, change the uses clause, depending on the defines. > > Vincent. For mysql connection I would prefer an component for each version so users have it clear from begining, and not need to change anything. Jesus Reyes A. ___ Do You Yahoo!? La mejor conexión a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MySQL v4.0 v4.1 and v5.0
On Thu, 17 Nov 2005, Vincent Snijders wrote: > Joost van der Sluis wrote: > > Hi all, > > > > atm I have a nearly finished mysql.inc file that can be used with MySQL > > v4.0 v4.1 and v5.0. Loaded dynamically and static. > > > > It uses several defines to set the right MySQL version and to turn the > > dynamically linking on or off. > > > > Create 6 different units in packages/base/mysql - for each combination > > one? (thus mysql40, mysql40dyn, mysql41, mysql41dyn, mysql50 and > > mysql51dyn?) > > > > But then, what to do with the MySQL-connection for sqldb? In principle > > the only thing that has to be changes to use another MySQL-version is to > > change the used unit. So, always use the TMysqlConn-component, but > > changes the usage-clausule. > > > > But how can this be handled by Lazarus? With the SQLDB-package only one > > unit can be used. (Or else multiple types with the same name are > > defined) Let the users manually change the usage-line if they want to > > use a different MySQL-library-version? > > FOr the sqldb package, let them add a define to the compiler options: > -dMYSQL40 > or > -dMYSQL41 > or > -dMYSQL50 > > That seems more user friendly than editing the uses clause. > > In the source, change the uses clause, depending on the defines. The problem with this approach is that you can never distribute compiled MySQL support in this way. The only way to do that is to do the mysql40, mysql40dyn, mysql41, mysql41dyn, mysql50, mysql51dyn stuff. So for FPC, I'm for that approach. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cryptography class nedded ?
Em Qui, 2005-11-17 às 14:18 +0200, Alexander Todorov escreveu: > Hi folks, > can you tell if there is a good crypto class for FPC / Lazarus ? > What do you use for crypting your stuff ? > Any opinions are welcome. Take a look at http://sourceforge.net/projects/tplockbox Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MySQL v4.0 v4.1 and v5.0
Joost van der Sluis wrote: Hi all, atm I have a nearly finished mysql.inc file that can be used with MySQL v4.0 v4.1 and v5.0. Loaded dynamically and static. It uses several defines to set the right MySQL version and to turn the dynamically linking on or off. Create 6 different units in packages/base/mysql - for each combination one? (thus mysql40, mysql40dyn, mysql41, mysql41dyn, mysql50 and mysql51dyn?) But then, what to do with the MySQL-connection for sqldb? In principle the only thing that has to be changes to use another MySQL-version is to change the used unit. So, always use the TMysqlConn-component, but changes the usage-clausule. But how can this be handled by Lazarus? With the SQLDB-package only one unit can be used. (Or else multiple types with the same name are defined) Let the users manually change the usage-line if they want to use a different MySQL-library-version? FOr the sqldb package, let them add a define to the compiler options: -dMYSQL40 or -dMYSQL41 or -dMYSQL50 That seems more user friendly than editing the uses clause. In the source, change the uses clause, depending on the defines. Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] MySQL v4.0 v4.1 and v5.0
Hi all, atm I have a nearly finished mysql.inc file that can be used with MySQL v4.0 v4.1 and v5.0. Loaded dynamically and static. It uses several defines to set the right MySQL version and to turn the dynamically linking on or off. Nog my question is: what is the best way to use this? Create 6 different units in packages/base/mysql - for each combination one? (thus mysql40, mysql40dyn, mysql41, mysql41dyn, mysql50 and mysql51dyn?) And then remove the existing mysql4 unit? This one is useless anyway because someone tried to update to MySQL 4.1, which wasn't done completely so now it's useless with 4.0 and 4.1. (At least with sqldb, too bad I didn't discovered that, so that mysql-support in 2.0.2 is very bad) But then, what to do with the MySQL-connection for sqldb? In principle the only thing that has to be changes to use another MySQL-version is to change the used unit. So, always use the TMysqlConn-component, but changes the usage-clausule. But how can this be handled by Lazarus? With the SQLDB-package only one unit can be used. (Or else multiple types with the same name are defined) Let the users manually change the usage-line if they want to use a different MySQL-library-version? Or create a TMysqlConn40, TMysqlconn41 and TMyslqconn50 wich are effectively the same, only with another usage-line? (Using the ifdef's again?) Is the problem clear and does someone have any ideas on this? -- Met vriendelijke groeten, Joost van der Sluis CNOC Informatiesystemen en Netwerken http://www.cnoc.nl ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
Op Thu, 17 Nov 2005, schreef Felipe Monteiro de Carvalho: > On 11/17/05, Daniël Mantione <[EMAIL PROTECTED]> wrote: > > IMHO the "hope" is that if there is a Tnativestring, people will > > start to design their libraries using Tnativestring, which will result in > > that those libraries can be compiled for 8 of 16 bit strings. > > This does not fix everything. Some RTL functions would still have to > be modified even with this Tnativestring. The RTL needs modifications in any solution. > I think this can lead to slower compiles and overhead on the RTL. There would be consequences, even big ones, but not these. You won't get slower compilations; it doesn't matter much if the compiler has to consider a type Tnativestring or ansistring. Overhead is zero for non-Unicode rtl. Overhead would be huge when interfacing with non UCS-2 stuff. The widestring is slower than ansistring, but handling utf-8 inside ansistring can turn O(N) into O(N^2), which has terrible effects on performance. No, I think implementation of this could put a big wall between Pascal and external libraries. That is going to hurt the most. Inside Pascal it could be a very comfortable solution. Libraries important, very important. It might result in more Pascal libraries, but also makes using foreign libraries more difficult. For the Unicode RTL only, then, but I don't get comfortable with the idea that libraries get hard to use. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
- Original Message - From: "Felipe Monteiro de Carvalho" <[EMAIL PROTECTED]> On 11/17/05, Mattias Gaertner <[EMAIL PROTECTED]> wrote: > Speaking for lazarus: we want to support the whole unicode and UTF8 is > the > easiest to achieve that. I particulary like this solution. * It doesn´t break existing code * It makes it easy to make a program unicode. Just change the encoding to utf-8! * It includes no overhead to existing apps Only a few RTL functions would have to be created to support utf-8, as has being said here. Many functions could remain the same. The programer should know what he is using and take the necessary precautions (use special utf-8 function for example, if needed) I think RTL functions can use UTF-8 stored in regular ansistrings. But string type name must be different from String or AnsiString. It must be named like Utf8String or StringUtf8 to specify that the function or procedure is UTF-8 aware. Also conversion between WideString and Utf8String need to be transparent (automatic UTF-16 (UCS-2) <-> UTF-8 conversion). This will allow to assing Utf8String to WideString and perform indexing or per character operations easily if needed. Also developer can work only with WideStrings in his application and pass them to functions that accept Utf8String and that will work good (in non time critical places of code of course). Yury Sidorov. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cryptography class nedded ?
On Thursday 17 November 2005 14:04, Paul Davidson wrote: > Did some work getting SSL working for FPC. Attached is unit that > exposes most of the functions required. Tested with Darwin and Linux. Thank you! That's a great starting point. I'll look at it when we are implementing crypto :) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
On 11/17/05, Daniël Mantione <[EMAIL PROTECTED]> wrote: > IMHO the "hope" is that if there is a Tnativestring, people will > start to design their libraries using Tnativestring, which will result in > that those libraries can be compiled for 8 of 16 bit strings. This does not fix everything. Some RTL functions would still have to be modified even with this Tnativestring. I think this can lead to slower compiles and overhead on the RTL. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
On 11/17/05, Mattias Gaertner <[EMAIL PROTECTED]> wrote: > Speaking for lazarus: we want to support the whole unicode and UTF8 is the > easiest to achieve that. I particulary like this solution. * It doesn´t break existing code * It makes it easy to make a program unicode. Just change the encoding to utf-8! * It includes no overhead to existing apps Only a few RTL functions would have to be created to support utf-8, as has being said here. Many functions could remain the same. The programer should know what he is using and take the necessary precautions (use special utf-8 function for example, if needed) -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cryptography class nedded ?
> > Hi folks, > > can you tell if there is a good crypto class for FPC / Lazarus ? > > What do you use for crypting your stuff ? > > Any opinions are welcome. > > I'd go for openssl. I know we have to implement crypto support at some point > in Technetium, and I'd really look into that library. It seems > well-developed. Note that Indy contains headers for it. Older version though with mods. But maybe easier to check than start over. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cryptography class nedded ?
On Thursday 17 November 2005 13:18, Alexander Todorov wrote: > Hi folks, > can you tell if there is a good crypto class for FPC / Lazarus ? > What do you use for crypting your stuff ? > Any opinions are welcome. I'd go for openssl. I know we have to implement crypto support at some point in Technetium, and I'd really look into that library. It seems well-developed. Writing a new, safe, crypto lib is _hard_. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
Op Thu, 17 Nov 2005, schreef Yury Sidorov: > I agree. There is no need to make existing RTL APIs unicode aware, because > there will be no compatibility with existing apps in any case. > So how about to add alternative unicode versions of RTL APIs via overloading > or via adding some suffix (eg. Assign and AssignW, TStringList and > TStringListW - like in WinAPI)? > > There are following benefits in such approach: > 1. It will be possible to develop unicode apps using these APIs. > 2. There will be only one RTL. > 3. There will be single source tree. > 4. It will not break existing RTL code. If you look at the discussion I tried to convince Juras that such an assignw solutions was best. However, he convinced me instead of that I convinced him. IMHO the "hope" is that if there is a Tnativestring, people will start to design their libraries using Tnativestring, which will result in that those libraries can be compiled for 8 of 16 bit strings. With assignW, TstringlistW etc., that won't happen, i.e. everyone who writes a library has to decide if he uses 8 bit, 16 bit or both code paths. Practice will be that people design libraries with 8 bit in mind, if you are lucky utf-8 aware. People who have an interrest in Unicode would have to add Unicode support to way more code than they can manage. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cryptography class nedded ?
Op Thu, 17 Nov 2005, schreef Alexander Todorov: > Hi folks, > can you tell if there is a good crypto class for FPC / Lazarus ? > What do you use for crypting your stuff ? > Any opinions are welcome. There exist many Pascal implementations of cryptographic algorithms, but I am not aware of a library that provides a bundle of them. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Cryptography class nedded ?
Hi folks, can you tell if there is a good crypto class for FPC / Lazarus ? What do you use for crypting your stuff ? Any opinions are welcome. TIA. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
From: "Marco van de Voort" <[EMAIL PROTECTED]> Unicode RTL is needed for people who want to develop unicode applications from the beginning. In such case the developer will be aware of unicode and will write correct code. All correct, BUT 1) it is not Unicode RTL but Unicode FPC/Lazarus. 2) it is not backwards compatible. We have to take care of more people's need than just the ones that urgently need Unicode to be as easy as possible. 3) thus creating an huge support problem 4) as mentioned before (and forgotten by me earlier) even UTF32 is not 100% fixed width There is no magic solution to make unicode RTL compatible with existing apps or libs. Correct. But what is then the use of stuffing it into the entire codebase? That extra work is then useless Unicode RTL will be an option for people who really need it. Unicode is. I'm not sure "Unicode RTL" is. IMHO RTL code base must be the same for ansi and unicode. To build unicode RTL some define must be used. As said, since legacy RTL code doesn't become magically unicode, maybe it is better to keep it separate, and overload a few funcs (like filesystem) if necessary at all (on *nix, use utf8). I agree. There is no need to make existing RTL APIs unicode aware, because there will be no compatibility with existing apps in any case. So how about to add alternative unicode versions of RTL APIs via overloading or via adding some suffix (eg. Assign and AssignW, TStringList and TStringListW - like in WinAPI)? There are following benefits in such approach: 1. It will be possible to develop unicode apps using these APIs. 2. There will be only one RTL. 3. There will be single source tree. 4. It will not break existing RTL code. Yury Sidorov. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
Op Thu, 17 Nov 2005, schreef Mattias Gaertner: > On Thu, 17 Nov 2005 11:31:45 +0100 > "Dr. Karl-Michael Schindler" <[EMAIL PROTECTED]> wrote: > > > Hi > > > > Following this discussion, I want to throw in my 2 cents as well: > > On a real long term (like 5 or 10 years from now), the solution > > should be as "clean" as possible with as little awkward parts because > > of backward compatibility. This favors of a more separate solution > > with a compatibility layer. Sure enough, this means more work to set > > it up and maintain it. Therefore, it will take longer to have it > > running, but in the end it will prevent the situation, I'd like to > > call the A20 gate situation. > > Who knows the future? > Maybe in 10 years 16bit non multi 'byte' encoding is sufficient for all > remaining languages. > Or maybe 32bit encodings will become the default. Deciding between UCS-2 and UTF-16 could be left up to the implementers of such a runtime library; all special UTF-16 positions are unallocated in UCS-2, so they do not bite each other. IMHO the advantage of UCS-2 is that you can use the [] array index safely. Or can indeed decide that you want a super wide string... Variable length strings have their problems tough, I've got some problems in my collection which would be quite hard to solve Unicode proof with UTF-8 strings. I checked the situation a bit. There is one alive language that has symbols allocated beyond plane 0 and that is not surprisingly Chinese. These are 4 words allocated in plane 2, archaic words though. Dead languages are allocated in plane 1. You can decide to support them, or you can not. This is also up to font designers, try if you can render #&173733; in your browser. Mine did not in several fonts. > Speaking for lazarus: we want to support the whole unicode and UTF8 is the > easiest to achieve that. Fair enough; there is nothing wrong with that. What you need to consider though is the following: * How many Delphi apps in the wild are Unicode proof? * How many apps would be Unicode proof if the libraries would use widestrings? That is what is IMHO going on in the minds of people that are asking for this. So, I can tell Juras B. to go whining somewhere else and not bother, but I cannot deny validity of his points. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
> From: "Marco van de Voort" <[EMAIL PROTECTED]> > > Nothing. You can't. It was meant to illustrate that there is more to it > > than > > simply declaring an "tbasicstring" or so alias and fixing some internal > > routines. It will "just" mean full checking and ifdeffing of/in every part > > of the entire fpc/lazarus repository, and maintaining that, the added > > support > > burden etc. > > When unicode RTL will be used with existing non-unicode applications or > libraries there will be a problems in any case. Correct. > But it does not mean that unicode RTL is not needed at all. Correct. > Unicode RTL is needed for people who want to develop unicode applications > from the beginning. In such case the developer will be aware of unicode and > will write correct code. All correct, BUT 1) it is not Unicode RTL but Unicode FPC/Lazarus. 2) it is not backwards compatible. We have to take care of more people's need than just the ones that urgently need Unicode to be as easy as possible. 3) thus creating an huge support problem 4) as mentioned before (and forgotten by me earlier) even UTF32 is not 100% fixed width > There is no magic solution to make unicode RTL compatible with existing apps > or libs. Correct. But what is then the use of stuffing it into the entire codebase? That extra work is then useless > Unicode RTL will be an option for people who really need it. Unicode is. I'm not sure "Unicode RTL" is. > IMHO RTL code base must be the same for ansi and unicode. To build unicode > RTL some define must be used. As said, since legacy RTL code doesn't become magically unicode, maybe it is better to keep it separate, and overload a few funcs (like filesystem) if necessary at all (on *nix, use utf8). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
On Thu, 17 Nov 2005 11:31:45 +0100 "Dr. Karl-Michael Schindler" <[EMAIL PROTECTED]> wrote: > Hi > > Following this discussion, I want to throw in my 2 cents as well: > On a real long term (like 5 or 10 years from now), the solution > should be as "clean" as possible with as little awkward parts because > of backward compatibility. This favors of a more separate solution > with a compatibility layer. Sure enough, this means more work to set > it up and maintain it. Therefore, it will take longer to have it > running, but in the end it will prevent the situation, I'd like to > call the A20 gate situation. Who knows the future? Maybe in 10 years 16bit non multi 'byte' encoding is sufficient for all remaining languages. Or maybe 32bit encodings will become the default. Speaking for lazarus: we want to support the whole unicode and UTF8 is the easiest to achieve that. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
From: "Marco van de Voort" <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Marco van de Voort) wrote: > > Dani?l Mantione <[EMAIL PROTECTED]> wrote: > > > > > > In other words, you still need to duplicate an awfull lot of > > > > > code. > > > > > > > > That is the same for 8bit and widestring. > > > > > > No, that is not true. There would be two rtls based on the same > > > code. > > > > Can you give some examples, what parts of the RTL should change for > > widestring? > > All typecasts to OS parts, libraries and functions. > E.g. accessing mysql is now done with pchar(ansistring) And they should be replaced by what? Nothing. You can't. It was meant to illustrate that there is more to it than simply declaring an "tbasicstring" or so alias and fixing some internal routines. It will "just" mean full checking and ifdeffing of/in every part of the entire fpc/lazarus repository, and maintaining that, the added support burden etc. When unicode RTL will be used with existing non-unicode applications or libraries there will be a problems in any case. But it does not mean that unicode RTL is not needed at all. Unicode RTL is needed for people who want to develop unicode applications from the beginning. In such case the developer will be aware of unicode and will write correct code. There is no magic solution to make unicode RTL compatible with existing apps or libs. Unicode RTL will be an option for people who really need it. IMHO RTL code base must be the same for ansi and unicode. To build unicode RTL some define must be used. Yury Sidorov. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
Hi Following this discussion, I want to throw in my 2 cents as well: On a real long term (like 5 or 10 years from now), the solution should be as "clean" as possible with as little awkward parts because of backward compatibility. This favors of a more separate solution with a compatibility layer. Sure enough, this means more work to set it up and maintain it. Therefore, it will take longer to have it running, but in the end it will prevent the situation, I'd like to call the A20 gate situation. Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
On Thu, 17 Nov 2005 11:04:01 +0100 (CET) [EMAIL PROTECTED] (Marco van de Voort) wrote: > > [EMAIL PROTECTED] (Marco van de Voort) wrote: > > > > > > Dani?l Mantione <[EMAIL PROTECTED]> wrote: > > > > > > > > > > In other words, you still need to duplicate an awfull lot of > > > > > > > code. > > > > > > > > > > > > That is the same for 8bit and widestring. > > > > > > > > > > No, that is not true. There would be two rtls based on the same > > > > > code. > > > > > > > > Can you give some examples, what parts of the RTL should change for > > > > widestring? > > > > > > All typecasts to OS parts, libraries and functions. > > > E.g. accessing mysql is now done with pchar(ansistring) > > > > And they should be replaced by what? > > Nothing. You can't. It was meant to illustrate that there is more to it > than simply declaring an "tbasicstring" or so alias and fixing some > internal routines. It will "just" mean full checking and ifdeffing of/in > every part of the entire fpc/lazarus repository, and maintaining that, the > added support burden etc. :) That's exactly why I asked the trick questions. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
Op Thu, 17 Nov 2005, schreef Florian Klaempfl: > This makes no sense. If such a thing is done, the encoding of the actually > used > mysql db must be taken into care. Nothing is fun with charsets... The above just demonstrates the idea. File system encoding would be another of those wild west scenarios. Just to repeat, be ignorant about charsets is by far the most convenient scenario. For us, that is. Providing an environment were people (i.e. programmers/end users) don't need to worry about charsets is a different philisophy. That is what is being asked (by some users). Lets stop confusing those. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
> [EMAIL PROTECTED] (Marco van de Voort) wrote: > > > > Dani?l Mantione <[EMAIL PROTECTED]> wrote: > > > > > > > > In other words, you still need to duplicate an awfull lot of code. > > > > > > > > > > That is the same for 8bit and widestring. > > > > > > > > No, that is not true. There would be two rtls based on the same code. > > > > > > Can you give some examples, what parts of the RTL should change for > > > widestring? > > > > All typecasts to OS parts, libraries and functions. > > E.g. accessing mysql is now done with pchar(ansistring) > > And they should be replaced by what? Nothing. You can't. It was meant to illustrate that there is more to it than simply declaring an "tbasicstring" or so alias and fixing some internal routines. It will "just" mean full checking and ifdeffing of/in every part of the entire fpc/lazarus repository, and maintaining that, the added support burden etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
Daniël Mantione wrote:
>
> Op Thu, 17 Nov 2005, schreef Daniël Mantione:
>
>
E.g. accessing mysql is now done with pchar(ansistring)
>>>
>>>And they should be replaced by what?
>>
>>Pchar(Tnativestring(widestring_variable));
>
>
> Apparently I got too little sleep or something tonight :) It would be
> this:
>
> Pchar(ansistring(wide_string_variable));
>
> If the RTL would then be compiled without a {$define unicode} the
> ansistring() would be a dummy.
This makes no sense. If such a thing is done, the encoding of the actually used
mysql db must be taken into care.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
Op Thu, 17 Nov 2005, schreef Daniël Mantione:
> > > E.g. accessing mysql is now done with pchar(ansistring)
> >
> > And they should be replaced by what?
>
> Pchar(Tnativestring(widestring_variable));
Apparently I got too little sleep or something tonight :) It would be
this:
Pchar(ansistring(wide_string_variable));
If the RTL would then be compiled without a {$define unicode} the
ansistring() would be a dummy.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
Op Thu, 17 Nov 2005, schreef Mattias Gaertner: > On Thu, 17 Nov 2005 10:27:08 +0100 (CET) > [EMAIL PROTECTED] (Marco van de Voort) wrote: > > > > Dani?l Mantione <[EMAIL PROTECTED]> wrote: > > > > > > > > In other words, you still need to duplicate an awfull lot of code. > > > > > > > > > > That is the same for 8bit and widestring. > > > > > > > > No, that is not true. There would be two rtls based on the same code. > > > > > > Can you give some examples, what parts of the RTL should change for > > > widestring? > > > > All typecasts to OS parts, libraries and functions. > > E.g. accessing mysql is now done with pchar(ansistring) > > And they should be replaced by what? Pchar(Tnativestring(widestring_variable)); Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
On Thu, 17 Nov 2005 10:27:08 +0100 (CET) [EMAIL PROTECTED] (Marco van de Voort) wrote: > > Dani?l Mantione <[EMAIL PROTECTED]> wrote: > > > > > > In other words, you still need to duplicate an awfull lot of code. > > > > > > > > That is the same for 8bit and widestring. > > > > > > No, that is not true. There would be two rtls based on the same code. > > > > Can you give some examples, what parts of the RTL should change for > > widestring? > > All typecasts to OS parts, libraries and functions. > E.g. accessing mysql is now done with pchar(ansistring) And they should be replaced by what? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
> Dani?l Mantione <[EMAIL PROTECTED]> wrote: > > > > In other words, you still need to duplicate an awfull lot of code. > > > > > > That is the same for 8bit and widestring. > > > > No, that is not true. There would be two rtls based on the same code. > > Can you give some examples, what parts of the RTL should change for > widestring? All typecasts to OS parts, libraries and functions. E.g. accessing mysql is now done with pchar(ansistring) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
On Thu, 17 Nov 2005 08:36:27 +0100 (CET) Daniël Mantione <[EMAIL PROTECTED]> wrote: > > > Op Wed, 16 Nov 2005, schreef Mattias Gaertner: > > > I don't understand, why you connect UTF8 with 'ignorant of MBCS'. > > UCS-2 can be used as ignorant as UTF8. > > Even UCS-4 and UTF32 will not solve all problems. Think about arabic > > RTL. > > Sure. I am not against UTF-8 or something (if you got that impression). > What I did note though is that adding UTF-8 (or widestring, it doesn't > matter) would mean doubling a lot of code, while with a separate RTL > would prevent, there would be single code that can be compiled for > multiple targets. > > > > In other words, you still need to duplicate an awfull lot of code. > > > > That is the same for 8bit and widestring. > > No, that is not true. There would be two rtls based on the same code. Can you give some examples, what parts of the RTL should change for widestring? > > > What convinced me two rtl's might be a better choice, is that many of > > > the source code remains intact and does not need to be duplicated. > > > New code could take advantage immedeately. The decision wether the > > > code is going to be used in an 8-bit environment (i.e. MS-DOS) and > > > will be 8-bit, or in a Unicode environment (i.e. Windows NT) and will > > > be 16-bit a character, is solved by a few ifdefs. There won't even be > > > any overhead on the MS-DOS executables (allthough the programmer can > > > use widestrings if he wishes so). > > > > Please: No two RTLs. > > A separate RTL is not my proposal, but the idea isn't that stupid. > > I am not going to push anything. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
