Re: [lazarus] Search engine for Lazarus and Free Pascal concerned stuff
Al Boldi wrote: Sam Liddicott wrote: Tom Gregorovic wrote: Hi, it crossed my mind that it would be convenient to have one search service for all the information about Lazarus and Free Pascal, which are in forums, mail list archives, documentation reference, wiki, Mantis, SVN repository, SVN log, blog ... One possibility is Google Custom Search Engine (http://www.google.com/coop/cse/): * it is free for noncommercial usage, but I think it parses not all resources The alternative is to use some web search engine running on own server (e.g. http://www.mnogosearch.org/ ). I recommend xapian; www.xapian.org I've worked on it, I've used it and I've followed it's progress and when I worked at Orange we hired one of the developers to enhance it. It is based on a once-commercial search engine. It's not bad, you've clearly not used it much but it's huge. I don't think xapian is huge, although it can deal with huge data sets. It's being used to index gmane. I'm currently using swish-e, which is small and fast. It is a probabilistic search engine that also uses boolean terms The btree index for xapian has been re-written from scratch 3 times for maximum speed. I don't know fully how swish-e and xapian compare but I can't have anyone maligning xapian :-) in 2005 (by the looks of this message: http://lists.tartarus.org/pipermail/xapian-devel/2005-September/000254.html ) the swish-e guys were willing to ditch their backend db for xapian. I don't know how mych better it has become since ethen. I'd also suggest reading from this thread to see how xapian works and could work for lazarus: http://lists.xapian.org/pipermail/xapian-discuss/2005-January/000681.html Sam
Re: [lazarus]
On Nov 24, 2007 8:47 AM, Vincent Snijders <[EMAIL PROTECTED]> wrote: > Vasily I. Volchenko schreef: > > And lazarus team is trying to force UTF8 introduction with a revolution > > without supporting neither old project nor saving files (and only saving) > > in compartible with other projects format. Besides, that revolutionary > > process begins when the other version of the same product doesn't support > > such utf8. OK, I'll try to do something... > > > > Fortunately Lazarus is still beta, breaking things can be expected. > Other versions of Lazarus (for linux-gtk2, windows-qt) already use UTF8. The logic behind Unicode is quite clear, there are countries which simply cannot use some ANSI charset, i tend to agree that in your special case, with the cyrilic charset it might be an increase to use UTF8 or UTF16 since you get twice the size of the same text, i presume you don't write international applications otherwise you would have realised why Unicode is important, ideally UTF32 should be used everywhere but the price for using UTF32 is too high with the current internet speed, RAM and hard disk sizes and almost nobody uses it (i think perl does) at first people used UCS2 for API implementation but now UCS2 needed an upgrade to UTF16 to support all languages and it proved that UTF16 also needs special processing for 4 Byte chars but compatibility with UCS2 was needed so UTF16 is for UCS2 what UTF8 is for ANSI ... an extension, both need special processing, UTF8 has 2 advantages over UTF16: size and speed, from what i understand WideStrings in Delphi have a problem, they are not reference counted, that is their length is not precalculated and this means WideString are much slower than AnsiString, probably one of the reasons CodeGear/Borland doesn't support Unicode everywhere, the fact that GTK uses UTF8 by default forced people into adopting UTF8 internally since there was no reason why not to do so as most latin based languages got a real advantage with this and one could truly write an international multilanguage application with little cost to it, of course Asian languages need more storage but they need a lot with UTF16 also so for them the impact is not so great, in your case with cyrilic you do need twice the size for the text but how much is that, did you notice Office applications also use Unicode for storage and nobody seems to complain about it, internationalization is a fact, it is here, it is needed and it's not so painful done the right way, in our case UTF8 is the best way to do it, instead of having 2 sets of components for each encoding, Ansi and UTF16 and options to use UTF8 instead of Ansi, it is simply easier to just use UTF8 and you can also use some converter such as the one included with synapse library if you need support for Ansi codepages, unless you will only write russian applications you will need more codepages and possibly some Unicode form and why not implement it by default as all sane minded people would, i'm not sure if .NET also adopted it but most languages did adopt some form of Unicode already, be it UTF8 or UTF16 or even UTF32 they all have it, i see no reason why to stick to Ansi when unicode is there with so little cost and you can still use Ansi for storage when needed. I hope this mail wasn't too long to read, if you will every write an app in another language than your native language or mixed languages, you will see why Unicode is important and probably why UTF16 is not better than UTF8 neither in size nor in speed and not even in implementation. Razvan _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus]
What's the problem with WideStrings in Delphi: http://tobias.feedian.com/2007/05/24/whats-wrong-with-delphis-widestring/ http://delphi.about.com/od/beginners/l/aa071800a.htm Razvan _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: Re[2]: [lazarus]
On Nov 24, 2007 7:33 AM, Vasily I. Volchenko <[EMAIL PROTECTED]> wrote: > UTF8 might be good in the case of international texts mostly English. You say > that pascal program > is such a text, and I would agree with you. But we are living in a real > world, with a tons of text > files. LCL internal encoding is not the same thing as source code encoding which is not the same things as arbitrary text data used by your application. The 3 things are loosely related only, and proper conversion can make all 3 interoperate while using different encodings. Just because you are using source code encoded at utf-8 this doesn't mean your application needs to read text data from users encoded on utf-8 too. Of course, if the data is not in utf-8 you need to convert it if you plan on passing it to LCL, but there are plenty of routines to do this task, such as Utf8Encode, Utf8Decode, Utf8ToAnsi, AnsiToUtf8, etc. There are also some winapi routines for windows only applications: MultiByteToWideChar and WideCharToMultiByte -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Ideas about Delphi's Roadmap
I just noticed the CodeGear roadmap and thought it would be nice to see what they are planning to do so we keep somewhat close to Delphi's improvements, they don't plan 64 bit support and CrossPlatform compilation until 2009 at least but they do plan to switch to Unicode, how will this be compatible with Lazarus applications that use UTF8, should Lazarus switch to WideStrings unicode style, provide a compilation switch or provide conversion for those projects, i guess converting code written specifically for WideString is tricky to port automatically ... http://dn.codegear.com/article/36620 Razvan _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Search engine for Lazarus and Free Pascal concerned stuff
Sam Liddicott wrote: > Al Boldi wrote: > > Sam Liddicott wrote: > >> I recommend xapian; www.xapian.org > >> > >> I've worked on it, I've used it and I've followed it's progress and > >> when I worked at Orange we hired one of the developers to enhance it. > >> > >> It is based on a once-commercial search engine. > > > > It's not bad, > > you've clearly not used it much > > > but it's huge. > > I don't think xapian is huge, although it can deal with huge data sets. > It's being used to index gmane. > > > I'm currently using swish-e, which is small and > > fast. > > It is a probabilistic search engine that also uses boolean terms > The btree index for xapian has been re-written from scratch 3 times for > maximum speed. > > I don't know fully how swish-e and xapian compare but I can't have > anyone maligning xapian :-) Actually, trying to compare xapian to swish-e, would be like comparing KDE with WindowMaker. They don't compare. That's why I use WindowMaker, and only use KDE as a back-end when I need the extra features. But, when you start comparing their size, that's when you understand what I mean with HUGE. Just the xapian engine distribution alone is about 10x larger than swish-e. So, if there is a mini-xapian engine distribution that would weigh in at around 250kb compressed, then I would definitely like to know about it. Until then, xapian is definitely overkill for simple indexing needs. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Ideas about Delphi's Roadmap
Hi Razvan,
> I just noticed the CodeGear roadmap and thought it would be nice to
> see what they are planning to do so we keep somewhat close to Delphi's
Funny you mention it. I was thinking in similar lines. FPC and
Lazarus main goals was and still is (as far as I know) to be Delphi
compatible. In the beginning it was fine, because FPC and Lazarus was
far behind. Now both products have caught up a lot of ground. At some
places even surpassed the features of Delphi. Now CodeGear is feeling
the pressure from the market as they have been pretty dormant with new
feature for the last few years.
So yes, you asked a good question? Where does FPC and Lazarus stand,
if CodeGear starts implementing things FPC and Lazarus already has,
but their design is very different. WideString compared to UTF-8 is
one such case, but I'm sure there are many other such issues.
Does FPC and Lazarus scrap their ideas and start following Delphi
again to stay compatible, or do they decide compatibility is not such
a high priority anymore and go their own route.
If compatibility is still a high priority, then FPC and Lazarus has to
keep holding back on implementing new features and wait ('till God
knows when) to see how CodeGear handles the problem, so that FPC and
Lazarus can do something similar to stay compatible. This, I think is
not a good idea!!
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Ideas about Delphi's Roadmap
On Sat, 24 Nov 2007 12:45:12 +0200 "Razvan Adrian Bogdan" <[EMAIL PROTECTED]> wrote: > I just noticed the CodeGear roadmap and thought it would be nice to > see what they are planning to do so we keep somewhat close to Delphi's > improvements, they don't plan 64 bit support and CrossPlatform > compilation until 2009 at least but they do plan to switch to Unicode, > how will this be compatible with Lazarus applications that use UTF8, > should Lazarus switch to WideStrings unicode style, provide a > compilation switch or provide conversion for those projects, i guess > converting code written specifically for WideString is tricky to port > automatically ... Does someone know, *how* Codegear will change the VCL to support unicode? > http://dn.codegear.com/article/36620 This just says: The standard string in the Delphi language will become a Unicode string. Does this mean 'string' switches from 'ansistring' to 'widestring' or a new string type? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Ideas about Delphi's Roadmap
Mattias Gaertner wrote: On Sat, 24 Nov 2007 12:45:12 +0200 "Razvan Adrian Bogdan" <[EMAIL PROTECTED]> wrote: I just noticed the CodeGear roadmap and thought it would be nice to see what they are planning to do so we keep somewhat close to Delphi's improvements, they don't plan 64 bit support and CrossPlatform compilation until 2009 at least but they do plan to switch to Unicode, how will this be compatible with Lazarus applications that use UTF8, should Lazarus switch to WideStrings unicode style, provide a compilation switch or provide conversion for those projects, i guess converting code written specifically for WideString is tricky to port automatically ... Does someone know, *how* Codegear will change the VCL to support unicode? http://dn.codegear.com/article/36620 This just says: The standard string in the Delphi language will become a Unicode string. Does this mean 'string' switches from 'ansistring' to 'widestring' or a new string type? The roadmap for Delphi's Tiburon will be first half of 2008 In the database there is only one report about utf8 : filed 7/31/2007 The files produced by the ETM tool are reportedly in utf8, but in fact they are stored as ansi. This appears to be causing data loss. Steps to Reproduce: 1. Create any small application. 2. Create a resource string that contains a true unicode character. ie not one of the standard ansi characters. 3. Run the translation wizard and specify english as the base language of the project. Then open the translation editor and rubbish characters can be seen in the "untranslated" column. It appears that the translation wizard is creating files in a format according to the locale settings of the PC rather than using UTF always as one would expect from a translation tool. The resulting .rcn file is in xml format and at the top it showns utf8 encoding is being used...but this is a lie. We have a multilingual development environment and require a tool that fully supports unicode throughout the translation process. We can live with TNT as a solution for the forms for now, but the basic string resources must work. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Program Execute
Anybody know of a way to use TProcess to call the default program in WinXP ? - eg call for test.pdf to be opened, and it opens it with Acrobat (or currently assigned program). I know that ShellExecute manages this, but trying to keep everything cross platform. If not TProcess, any other method ? Thanks - SteveG have a list of functions I need cross platform equivalents for, but will work up slowly :) _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Program Execute
SteveG wrote: Anybody know of a way to use TProcess to call the default program in WinXP ? - eg call for test.pdf to be opened, and it opens it with Acrobat (or currently assigned program). I know that ShellExecute manages this, but trying to keep everything cross platform. Under Windows, you can use TProcess to execute "start.exe test.pdf". Of course, this still isn't crossplatform at all, but the issue is reduced to a string constant. Regards, Sergei _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Program Execute
This does the job for now though - Thanks Sergei Sergei Gorelkin wrote: SteveG wrote: Anybody know of a way to use TProcess to call the default program in WinXP ? - eg call for test.pdf to be opened, and it opens it with Acrobat (or currently assigned program). I know that ShellExecute manages this, but trying to keep everything cross platform. Under Windows, you can use TProcess to execute "start.exe test.pdf". Of course, this still isn't crossplatform at all, but the issue is reduced to a string constant. Regards, Sergei _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Google's Android OS :)
On Fri, Nov 23, 2007 at 12:56:21AM +0100, willem wrote: > Marco van de Voort wrote: >> On Thu, Nov 22, 2007 at 07:52:59PM +0100, willem wrote: >> >>> I know that the lazarus grammar is based on yacc >>> > > I did some google search on the fpc > I do know that google searches results are not always correct. > I a a newby to the lazarus project. > but i did study compiler comnstruction 30 years ago. > Pascal has been founded by Prof niklaus Wirth as an an educational computer > language > and he has extended the backus -nauer form to EBNF. > Well I am going to extend ENBF with XML. Why? EBNF to readable? > Grammar is very important as a base to study a language. Certainly. Though not always for compiler construction. But more importantly, regardless if you use it for a compiler or not, it needs to be correct. And validating is an huge problem, since there is no complete description of the Delphi language anywhere. The only argument I heard that it is "you downloaded it from the net". > > > > > > > > > > >> >> The FPC is recursive descent and is not based on yacc. Syntax highlighter >> parsers don't have to be 100% correct. >> >> Before you start you might also learn your target better, and at least have an idea how you are going to tackle porting unmanaged constructs to a managed version. >>> Sorry you are wrong. >>> I have already the delphi grammar for antlr >>> >> >> There is even one in the Delphi's manual. But even that is not complete. >> How >> can you be so sure yours is? >> _ >> To unsubscribe: mail [EMAIL PROTECTED] with >> "unsubscribe" as the Subject >>archives at http://www.lazarus.freepascal.org/mailarchives >> >> > > _ > To unsubscribe: mail [EMAIL PROTECTED] with >"unsubscribe" as the Subject > archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re[4]: [lazarus]
> LCL internal encoding is not the same thing as source code encoding
> which is not the same things as arbitrary text data used by your
> application.
>
Of course. There are:
1. LCL internal encoding (encoding of LCL sources),
2. Lazarus IDE internal encoding,
3. encoding of .po files,
4. SynEdit internal encoding,
5. special project files encoding (.lpi, .lrs and, may be in some cases, lfm)
6. current source encoding,
7. importing project encoding.
8. other files encoding
While 2 and 4 can use any encoding which is convenient for Lazarus developers,
3 and 5 should be unified (utf8 is not a bad choice), 1 should be
encoding-invariant (ASCII7), but 6 and 7 are the choice of user-programmer, and
8 is a problem of user-programmer who tries to read it. Presently both 6 and 7
are forced either as a system encoding on Windows (or fake system in Win2k+) or
UTF-8 on gtk2. Is it so good? I think, forcing anyone to use anything is a bad
idea. Especially it is bad for 7, when it is known that utf8 is not used.
> Just because you are using source code encoded at utf-8 this doesn't
> mean your application needs to read text data from users encoded on
> utf-8 too.
It is obvious. But... Pascal files were considered as a text files, but now
they can't be considered such anymore. As for me, UTF-8 file is not a text
file, it is just an abrakadabra with many hard sings (who don't know - hard
sing is the most rare letter in Russian, and in now most popular Russian
encoding cp1251 - its popularity is other bad story, but it is a fact - it is
#255) and for many others it is right too.
>
> Of course, if the data is not in utf-8 you need to convert it if you
> plan on passing it to LCL, but there are plenty of routines to do this
> task, such as Utf8Encode, Utf8Decode, Utf8ToAnsi, AnsiToUtf8, etc.
Yes, but to use anything else including clean FPC you should return to original
encoding. Besides, try to use Writeln('.');
in current encoding, which is not UTF8. Windows had such problem from the
beginning (requires AnsiToOEM), but why should we introduce the same problem
(and double it for Windows) in Unix?
Yes, there are some means to live with UTF8, but why should anyone to live with
it when he can live without it? Or just live with it and doesn't notice any
changes? And it is only while he wants to live without it! This should be an
option to use either system encoding or to use utf8.
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus]: utf8 or not necessury?
> > Vasily I. Volchenko schreef: > > And lazarus team is trying to force UTF8 introduction with a revolution > > without supporting neither old project nor saving files (and only saving) > > in compartible with other projects format. Besides, that revolutionary > > process begins when the other version of the same product doesn't support > > such utf8. OK, I'll try to do something... > > > > Fortunately Lazarus is still beta, breaking things can be expected. > Other versions of Lazarus (for linux-gtk2, windows-qt) already use UTF8. And why using UTF8 internally must means using UTF8 in a saved project? _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Ideas about Delphi's Roadmap
On 24/11/2007, Giuliano Colla <[EMAIL PROTECTED]> wrote: > > My guess. Nobody knows, not even Codegear. > They've become more and more dependent on marketing rather than on sound > technical strategies. Yeah, I'm so glad our company decided to move over to Free Pascal. CodeGear looks like it is going nowhere slowly. Maybe Delphi will have the same fate as Kylix had. Borland silently moving it to the Historic Products section on their website. Did anybody actually check if they haven't done that already? :-) Borland should have pushed CLX and Kylix much harder than trying to play the catch-up game with Microsoft and trying to compete in the .NET world. Obviously Visual Studio will always support .NET better than any other product! > If we scratch our heads better than them, and it appears to me that the > process has already begun, we may end up with a better solution before > they've made up their mind. Now see, this is exactly where I foresee a problem! We find a solution before CodeGear does and then CodeGear does something totally different. Where does Lazarus then stand with Delphi compatibility??? I think we should bin the whole idea of trying to be compatible and let the LCL implement it's own features. Trying to be compatible is just holding Lazarus back! Take the Lazarus IDE for example. It's goal isn't to be Delphi IDE compatible and because of that we can be creative and inventive, and look at what a awesome IDE we have! LCL on the other hand has improved by leaps and bounds over the last few years, but will always stand in the shadow of the VCL. My 2c worth. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Ideas about Delphi's Roadmap
Mattias Gaertner ha scritto: On Sat, 24 Nov 2007 12:45:12 +0200 "Razvan Adrian Bogdan" <[EMAIL PROTECTED]> wrote: Does someone know, *how* Codegear will change the VCL to support unicode? My guess. Nobody knows, not even Codegear. They've become more and more dependent on marketing rather than on sound technical strategies. This made them lose a lot of money (because marketing vision never goes beyond next quarter) and be for sale since an year, without anybody buying. http://dn.codegear.com/article/36620 This just says: The standard string in the Delphi language will become a Unicode string. AFAIK there's not such a thing as a Unicode string. There's a Unicode standard, and a number of implementations such as UTF-8 UTF-16 UCS-2, UCS-4 etc. This proves my point. It originates from marketing, now it's to developers to scratch their head. If we scratch our heads better than them, and it appears to me that the process has already begun, we may end up with a better solution before they've made up their mind. (I say "we" just because I feel part of the game) Does this mean 'string' switches from 'ansistring' to 'widestring' or a new string type? IMHO opinion the good question is "what's the best way to approach the Unicode problem?" It may be much more important be compatible with the existant software base, for instance, than with a last minute solution offered by Codegear, under marketing pressure, which may be rejected by users. It's not a good thing to underestimate competitors, but overestimating them can be even worse. Just my two cents. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus]: utf8 or not necessury?
On Sat, 24 Nov 2007 17:58:12 +0300 "Vasily I. Volchenko" <[EMAIL PROTECTED]> wrote: > > > > > Vasily I. Volchenko schreef: > > > And lazarus team is trying to force UTF8 introduction with a > > > revolution without supporting neither old project nor saving > > > files (and only saving) in compartible with other projects > > > format. Besides, that revolutionary process begins when the other > > > version of the same product doesn't support such utf8. OK, I'll > > > try to do something... > > > > > > > Fortunately Lazarus is still beta, breaking things can be expected. > > Other versions of Lazarus (for linux-gtk2, windows-qt) already use > > UTF8. > And why using UTF8 internally must means using UTF8 in a saved > project? Theoretically it can be in any encoding iff the encoding is saved too. Without this information the code is useless to all others. Pascal has no convention about encoding so there are two possible defaults: Use the system charset or an 8-bit unicode. For Lazarus UTF-8 was chosen. If you want to extend the IDE to load/save text files in other encodings you are welcome. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus]: utf8 or not necessury?
> did you notice
> Office applications also use Unicode for storage and nobody seems to
> complain about it
OK, office applications do so. It was some (or it is better to say - a lot of)
problems
with them, so when MSOffice 97 was introduced, most people had it with an old
office.
And these problems were only with badly saved old files, or files with wrong
fonts.
But that situation was very good because of
1. Backward compatibility.
2. Changing encoding type was concerned only with internal office format.
Office (and other applications to) was able to use either plain text or
unicode, and
unicode is not used at all.
You are trying to break both things: no compatibility and autoconversion is
made for old (or delphi/kylix) projects
and you are forcing saving text (.pas) files in the new encoding. Is it so good?
> needed and it's not so painful done the right way, in our case UTF8 is
> the best way to do it, instead of having 2 sets of components for each
> encoding, Ansi and UTF16 and options to use UTF8 instead of Ansi, it
> is simply easier to just use UTF8 and you can also use some converter
> such as the one included with synapse library if you need support for
> Ansi codepages, unless you will only write russian applications you
> will need more codepages and possibly some Unicode form and why not
I don't speak that utf8 shouldn't be used at all. If I write an international
application, I'll
either write clean ansi7 .pas files with internationalization .po files or I'll
make such an
applications using some koi8 or cp1251 comments (that wouldn't harm) or I'll
make another mechanism
of internationalization. But sometimes I have to make a small Russian program,
may be for student testing
(yes, there is such an application, it is written on Lazarus and is used on our
department of the University), or
to data processing. Of course, the first stage is making Russian application
with russian text in messages and buttons
(you must be sure, both students and post-graduates will be strongly
disappointed if they will see English messages,
and they will be disappointed much more if they would see somewhat like
ЪЪЪЦЪЪ). Of course, I should use only Win95 and Win2k on work machines, and
either my licensed Windows Vista Home Basic or Linux (mandriva or SLAMD64) on
my home machine, dependend what have I previously loaded. And even at that time
I have some problems because the encoding of project is different. Why it is
not possible to load a project saved in another encoding? Especially if this is
a system encoding! Especially bad it is for Windows because linux has iconv
utility. So, if I do something on linux, and next time will use windows, I'll
need to reboot back or to write a recoder (which at last I did). And can you
imagine if one file would stay untranslated? OK, you will make UTF8 support on
Windows, but I am not sure that it won't conflict with system encoding. For
example, are you sure that
ShowMessage('Ваша оценка - '+IntToString(mark));
written in UTF8 will really shows correct message?
And the same will be with Application.MessageBox?
If you are, how will it be with those who have a tons of code (easily converted
to UTF8, as you say) full with
Windows.MessageBox(Handle,...)
which means MessageBoxA?
And you say that it is not reasonable to make them a choice, to use or not to
use UTF8 in their programs.
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: Re[4]: [lazarus]
On Nov 24, 2007 3:58 PM, Vasily I. Volchenko <[EMAIL PROTECTED]> wrote: > 6. current source encoding, The source code encoding will be (more or less) irrelevant when this feature is implemented: http://www.freepascal.org/mantis/view.php?id=9305 > Especially it is bad for 7, when it is known that utf8 is not used. Use a text editor with multiple encoding support like Notepad++ Open the file on a encoding and save it on another. Done. A trivial pascal app can be built to automate that if you have many files. > As for me, UTF-8 file is not a text file, it is just an abrakadabra with many > hard sings There are plenty of UTF-8 capable editors, including Lazarus if you recompile it with WindowsUnicodeSupport. A simple google search should return plenty more. For windows Notepad++ comes to my mind. > in current encoding, which is not UTF8. Windows had such problem from the > beginning (requires AnsiToOEM), but why should we introduce the same problem > (and double it for Windows) in Unix? Unix is migrating to UTF-8 > Yes, there are some means to live with UTF8, but why should anyone to live > with it when he can live without it? There is just no way to provide a high quality internationalization support without Unicode. Just to give you a very simple example, suppose you write a LCL application without the new unicode support and write it in russian. Now transfer that to my computer which has a portuguese windows. What will I see?? Non-sense. The same application can't work on the same windows version if only the Windows localization changed! With unicode the same application will work anywhere, including other operating systems. > This should be an option to use either system encoding or to use utf8. There is no reason to support something that would never work on all systems we support to start with. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus]: utf8 or not necessury?
On Sat, 24 Nov 2007 18:29:48 +0300
"Vasily I. Volchenko" <[EMAIL PROTECTED]> wrote:
> > did you notice
> > Office applications also use Unicode for storage and nobody seems to
> > complain about it
> OK, office applications do so. It was some (or it is better to say -
> a lot of) problems with them, so when MSOffice 97 was introduced,
> most people had it with an old office. And these problems were only
> with badly saved old files, or files with wrong fonts. But that
> situation was very good because of 1. Backward compatibility.
> 2. Changing encoding type was concerned only with internal office
> format. Office (and other applications to) was able to use either
> plain text or unicode, and unicode is not used at all.
> You are trying to break both things: no compatibility and
> autoconversion is made for old (or delphi/kylix) projects and you are
> forcing saving text (.pas) files in the new encoding. Is it so good?
About autoconversion:
Changing the encoding of text files is pretty easy. For example: use
the 'recode' tool. An alternative would be to extend the IDE to
load/save files of other encodings and extend the compiler to auto
convert the strings.
After that you must check all places, where fixed visual character
widths are used. In lazarus only synedit and parts of the widgetsets
were affected. So, although is not difficult, this part can not be
done automatically.
>> [...]instead of having 2 sets of components for each encoding,
> > Ansi and UTF16 and options to use UTF8 instead
> > of Ansi,
>[...]
> (you must be sure, both students and
> post-graduates will be strongly disappointed if they will see English
> messages, and they will be disappointed much more if they would see
> somewhat like ЪЪЪЦЪЪ).
This is the current situation (as soon as you switch to another OS).
That's exactly what the switch to one encoding should fix.
>[...] OK, you will make UTF8 support on Windows, but I am not
> sure that it won't conflict with system encoding. For example, are
> you sure that ShowMessage('Ваша оценка - '+IntToString(mark));
> written in UTF8 will really shows correct message?
It will reasonably work. For example you can not expect that the
current windows font supports all languages. But this can not be fixed
by the LCL anyway.
> And the same will
> be with Application.MessageBox? If you are, how will it be with those
> who have a tons of code (easily converted to UTF8, as you say) full
> with Windows.MessageBox(Handle,...) which means MessageBoxA?
AFAIK the call to Windows.MessageBox is not the problem, but the non
UTF-8 strings stored in databases.
> And you
> say that it is not reasonable to make them a choice, to use or not to
> use UTF8 in their programs.
Conclusion:
Switching to UTF-8 means writing i18n programs becomes much easier and
writing system specific programs becomes harder. It breaks
compatibility. Some people would like a simple switch and that the LCL
should support both, but lazarus has not the man power to support this.
Mattias
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Ideas about Delphi's Roadmap
On Nov 24, 2007 12:24 PM, Mattias Gaertner <[EMAIL PROTECTED]> wrote: > Does someone know, *how* Codegear will change the VCL to support > unicode? Yes, I'm one step ahead of you guys =) I already posted many questions about this on delphi.non-tech and studied the situation. They will do: Char = WideChar string = WideString It will be still possible to have the same project working with both vcl and lcl if some care is taken. Actually it will be even better then it's now because it will be possible to have a unicode-enabled app working with both =) The problem will be that any code written to depend on string = widestring won't work on fpc, and the same for char=widechar -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Ideas about Delphi's Roadmap
On Nov 24, 2007 12:18 PM, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: > So yes, you asked a good question? Where does FPC and Lazarus stand, > if CodeGear starts implementing things FPC and Lazarus already has, > but their design is very different. WideString compared to UTF-8 is > one such case, but I'm sure there are many other such issues. We will follow our own path. We started implementing unicode support before they mentioned it, and we won't change our implementation now. If they do like I think they will, they will cut support for non-NT Windows versions, and will offer a inferior solution to ours. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Google's Android OS :)
Marco van de Voort wrote: On Fri, Nov 23, 2007 at 12:56:21AM +0100, willem wrote: Marco van de Voort wrote: On Thu, Nov 22, 2007 at 07:52:59PM +0100, willem wrote: I know that the lazarus grammar is based on yacc I did some google search on the fpc I do know that google searches results are not always correct. I a a newby to the lazarus project. but i did study compiler comnstruction 30 years ago. Pascal has been founded by Prof niklaus Wirth as an an educational computer language and he has extended the backus -nauer form to EBNF. Well I am going to extend ENBF with XML. Why? EBNF to readable? Yes making it readable by addening comment to the grammar and the progress status of new grmmar. Grammar is very important as a base to study a language. Certainly. Though not always for compiler construction. But more importantly, regardless if you use it for a compiler or not, it needs to be correct. And validating is an huge problem, since there is no complete description of the Delphi language anywhere. Yes I agree validating is very important. The DGROK project is also working on the delphi grammar. http://www.excastle.com/dgrok/grammar.html DGROK is a tool for seeking through delphi code. The only argument I heard that it is "you downloaded it from the net". The FPC is recursive descent and is not based on yacc. Syntax highlighter parsers don't have to be 100% correct. Before you start you might also learn your target better, and at least have an idea how you are going to tackle porting unmanaged constructs to a managed version. Sorry you are wrong. I have already the delphi grammar for antlr There is even one in the Delphi's manual. But even that is not complete. How can you be so sure yours is? DGROK claims to have their grammar 100 % completed. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Google's Android OS :)
willem schreef: _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives How many links to th archive does one need? Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: Re: [lazarus]: utf8 or not necessury?
I said not just about text files in IDE (it is not really interesting), but about pascal project files. Where to store encoding? It is a good question. The easiest way is to add a string to the .lpi file which either contains the locale of all the project (but it is not so easy to completely convert from UTF8 to any encoding) or just a boolean means either the project uses the system encoding or UTF8. If it uses the system encoding, and we are not in Windows (or in Windows but using utf8), SynEditTextBuffer should use somewhat like AnsiToUTF8 when loading any project file. If it uses UTF8 and we are in Windows, the conversion from UTF8 should be used. It seems quite easy to make. Let UTF8 be standard international mode while system encoding is a compatibility mode. When the problem of project encoding will be solved, it is possible to go further. Most files loaded in projects will be loaded in project encoding. But some files may be in other encoding (it is a problem of user-programmer to make them to compiled correctly by fpc). In this case the first line of such a file should indicate this, may be //&encoding=koi8r So, reader should try to read a line (may be some lines), and if it won't find something like this, it will turn encoding to project default, and then reset the position. If it find it, it will set mechanism to loaded enc. conversion and reset the position too. The same thing will be done by writer. So, to change the encoding of a source file you will need just to add such a comment. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: Re: [lazarus]: utf8 or not necessury?
On Nov 24, 2007 5:24 PM, Vasily I. Volchenko <[EMAIL PROTECTED]> wrote: > I said not just about text files in IDE (it is not really interesting), but > about pascal project files. Where to store encoding? How to store the encoding is something well stablished by international standards: http://en.wikipedia.org/wiki/Byte_Order_Mark -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Ideas about Delphi's Roadmap
On 24/11/2007, Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: > > The problem will be that any code written to depend on string = > widestring won't work on fpc, and the same for char=widechar > So based on that statement, I gather Delphi project compatibly stops there. Unless I guess FPC implements yet another new compiler mode or something, but even so, it will be a sh*t load of work for the FPC developers to fix all internal code that will get broken (code that relies on a Char=1byte), just to try and maintain compatibility. Even for developers using multpile versions of Delphi, I can't see how they can maintain backward compatibility with such a change. All projects supporting multiple compilers will have issues. Or am I not understanding the effect such a change will have? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re[6]: [lazarus]
> Use a text editor with multiple encoding support like Notepad++ > > Open the file on a encoding and save it on another. Done. > Good. It is a "very convenient", especially if project contains many files. > A trivial pascal app can be built to automate that if you have many files. > Of course, I did it. See attachment. But don't you really think that this should be done by the means of Lazarus? If lazarus contains project convertor. > > As for me, UTF-8 file is not a text file, it is just an abrakadabra with > > many hard sings > There are plenty of UTF-8 capable editors, including Lazarus if you > recompile it with WindowsUnicodeSupport. A simple google search should > return plenty more. For windows Notepad++ comes to my mind. I know. But anyway, it is not so good. That files are still "foreign". > Unix is migrating to UTF-8 Yes, but how? How transparent was it done in first KDE (1,2,3), and how rough it is done now (in Lazarus, Firefox and OpenOffice)? Why do you choose such a rough way? > There is just no way to provide a high quality internationalization > support without Unicode. Internationalization is not for all... > > Just to give you a very simple example, suppose you write a LCL > application without the new unicode support and write it in russian. > Now transfer that to my computer which has a portuguese windows. What > will I see?? Non-sense. The same application can't work on the same > windows version if only the Windows localization changed! Yes, you will see nonsense. If you are expect that this application will be used by somebody else, you make the ways to make internationalization. If you want to make temporary application for small group, you can use somewhat they use. Besides, most portuguese-speaking users will see nonsense in Russian application anyway. > With unicode the same application will work anywhere, including other > operating systems. May be... But presently the result is opposite. > > This should be an option to use either system encoding or to use utf8. > > There is no reason to support something that would never work on all > systems we support to start with Why all? And why shouldn't you support things that were made? May be as a compatibility mode. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Ideas about Delphi's Roadmap
On Nov 24, 2007 5:34 PM, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: > So based on that statement, I gather Delphi project compatibly stops there. It's not that it stops. You can still make an application that works with both. However if you make an app that depends on those details it won't work. Actually, even then it should be possible to make it work with some ifdefs. Lazarus was never perfectly compatible with Delphi anyway, starting that we already support unicode on gtk2 since years and that obviously doesn't work on delphi. > Even for developers using multpile versions of Delphi, I can't see how > they can maintain backward compatibility with such a change. All > projects supporting multiple compilers will have issues. That's correct. There will be now a significant cost for components to maintain multiple versions of Delphi, but it's still possible with ifdefs. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: Re: Re: [lazarus]: utf8 or not necessury?
This is only about unicode text files. Can you imagine that BOM will be in a text file given to pascal compiler? _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: Re: Re: [lazarus]: utf8 or not necessury?
On Nov 24, 2007 5:49 PM, Vasily I. Volchenko <[EMAIL PROTECTED]> wrote: > This is only about unicode text files. Can you imagine that BOM will be in a > text file given to pascal compiler? A source code is a text file. Free Pascal is already prepared to handle source code including a BOM marker. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Buffer Overflow
- Original Message - From: "Jesus Reyes" <[EMAIL PROTECTED]> To: Sent: Friday, November 23, 2007 20:11 Subject: Re: [lazarus] Buffer Overflow --- Jeff Steinkamp <[EMAIL PROTECTED]> escribió: I just rebuilt Lazarus with SVN 12973 on my Linux box with GTK2 and upon restart I got a error dialog that said buffer overflow. Here is the output trace: TLazarusManager.Run starting /home/n7yg/.lazarus/bin/lazarus ... TApplication.IconChanged - TODO: convert this message...no implementation in gtk or win32 [TMainIDE.Destroy] A [TMainIDE.Destroy] B -> inherited Destroy... TMainIDE [TMainIDE.Destroy] END [FORMS.PP] ExceptionOccurred Sender=Ecompressionerror Exception=buffer error Stack trace: $081A26DE $0819BC0B $0819B9E4 $08196D9D $081949E1 $081367E1 TFPIMAGEBITMAP__READSTREAM, line 1926 of graphics.pp $0812BFD4 TBITMAP__LOADFROMSTREAM, line 459 of ./include/bitmap.inc $08127A10 LOADBITMAPFROMLAZARUSRESOURCE, line 1509 of graphics.pp $08090CE6 CREATEBUTTON, line 1431 of main.pp $0809084B TMAINIDE__SETUPSPEEDBUTTONS, line 1460 of main.pp $0808FAB7 TMAINIDE__CREATE, line 1117 of main.pp $0805C023 main, line 93 of lazarus.pp TApplication.HandleException buffer error Stack trace: $081A26DE $0819BC0B $0819B9E4 $08196D9D $081949E1 $081367E1 TFPIMAGEBITMAP__READSTREAM, line 1926 of graphics.pp $0812BFD4 TBITMAP__LOADFROMSTREAM, line 459 of ./include/bitmap.inc $08127A10 LOADBITMAPFROMLAZARUSRESOURCE, line 1509 of graphics.pp $08090CE6 CREATEBUTTON, line 1431 of main.pp $0809084B TMAINIDE__SETUPSPEEDBUTTONS, line 1460 of main.pp $0808FAB7 TMAINIDE__CREATE, line 1117 of main.pp $0805C023 main, line 93 of lazarus.pp It seems to run fine under GTK Jeff Steinkamp - N7YG Tucson, AZ SCUD Missile Coordinates N32-13-55.01 W110-50-51.91 http://n7yg.net http://home.earthlink.net/~jksteinkamp Linux User #420428 Skype : jeff_steinkamp Yahoo Messenger: n7yg The problem is a recent change in FPC, it's already reported in http://www.freepascal.org/mantis/view.php?id=10232 if you compile your own FPC from SVN, for a quick fix, enter directory fpc/packages/paszlib/src and update to r9290 (svn update -r9290) recompile everything and that should do it. Jesus Reyes A. Thanks, That has fixed the problem Jeff _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Google's Android OS :
haha none of course vincent. kind regards _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re[2]: [lazarus]: utf8 or not necessury?
> About autoconversion: > > Changing the encoding of text files is pretty easy. For example: use > the 'recode' tool. An alternative would be to extend the IDE to > load/save files of other encodings and extend the compiler to auto > convert the strings. > After that you must check all places, where fixed visual character > widths are used. In lazarus only synedit and parts of the widgetsets > were affected. So, although is not difficult, this part can not be > done automatically. Yes, this may be a problem. This is another argument to make a compatibility mode. > >> [...]instead of having 2 sets of components for each encoding, > > > Ansi and UTF16 and options to use UTF8 instead > > > of Ansi, > >[...] > > (you must be sure, both students and > > post-graduates will be strongly disappointed if they will see English > > messages, and they will be disappointed much more if they would see > > somewhat like ЪЪЪЦЪЪ). > > This is the current situation (as soon as you switch to another OS). > That's exactly what the switch to one encoding should fix. Should fix. Only if such text is not placed directly. > It will reasonably work. For example you can not expect that the > current windows font supports all languages. But this can not be fixed > by the LCL anyway. And this code SHOULD work good (this is a bad code for international projects, but a real code for small national projects). If you say that this code won't be supported anyway, I will prefer old good versions (or patched current). > > > And the same will > > be with Application.MessageBox? If you are, how will it be with those > > who have a tons of code (easily converted to UTF8, as you say) full > > with Windows.MessageBox(Handle,...) which means MessageBoxA? > > AFAIK the call to Windows.MessageBox is not the problem, but the non > UTF-8 strings stored in databases. If stored - yes. If not - no. Will you store any message in "quickly made" application? > Conclusion: > Switching to UTF-8 means writing i18n programs becomes much easier and > writing system specific programs becomes harder. It breaks > compatibility. Some people would like a simple switch and that the LCL > should support both, but lazarus has not the man power to support this. > This switch is quite simple... Besides, my recoding "work around" - encoding conversion application for the whole directory (from prev.post) cptr.tgz Description: Binary data
Re: Re[6]: [lazarus]
On Nov 24, 2007 5:39 PM, Vasily I. Volchenko <[EMAIL PROTECTED]> wrote: > Of course, I did it. See attachment. But don't you really think that this > should be done by the means of Lazarus? If lazarus contains project convertor. I also think it's a great idea. Please read: http://wiki.lazarus.freepascal.org/How_To_Help_Developing_Lazarus If you have more specific questions about implementing this, just ask. thanks, -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Serial Comm Support Windows
I know there is a serial unit for Linux/Unix, but is there similar support for serial communications for the Windows Platform? Jeff Steinkamp - N7YG Tucson, AZ SCUD Missile Coordinates N32-13-55.01 W110-50-51.91 http://n7yg.net http://home.earthlink.net/~jksteinkamp Linux User #420428 Skype : jeff_steinkamp Yahoo Messenger: n7yg ___ STUPIDITY IS NOT A HANDICAP. Park elsewhere! _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus]: utf8 or not necessury?
On Sat, 24 Nov 2007 19:58:54 +0300 "Vasily I. Volchenko" <[EMAIL PROTECTED]> wrote: > > About autoconversion: > > > > Changing the encoding of text files is pretty easy. For example: use > > the 'recode' tool. An alternative would be to extend the IDE to > > load/save files of other encodings and extend the compiler to auto > > convert the strings. > > After that you must check all places, where fixed visual character > > widths are used. In lazarus only synedit and parts of the widgetsets > > were affected. So, although is not difficult, this part can not be > > done automatically. > Yes, this may be a problem. This is another argument to make a > compatibility mode. Some notes about compatibility mode: - gtk1 supports system encodings and only if the environment is setup correctly. AFAIK all major distros are now using UTF-8. So, compatibility mode can be only: use gtk1 and setup the right language. - gtk2 only supported UTF-8. - qt, carbon, fpgui, wince: they are too new, so they don't need to. - win32/64: ATM you need to compile with -dWindowsUnicodeSupport to get UTF-8. As soon as the last bug is fixed the default will be UTF-8 and you have to compile with -dDisableWindowsUnicodeSupport (or something like that) to get the old situation. This means you can not switch at runtime, nor can you do both encodings at the same time. If you want both LCLs, then you probably need two copies of the LCL. > > >> [...]instead of having 2 sets of components for each encoding, > > > > Ansi and UTF16 and options to use UTF8 instead > > > > of Ansi, > > >[...] > > > (you must be sure, both students and > > > post-graduates will be strongly disappointed if they will see > > > English messages, and they will be disappointed much more if they > > > would see somewhat like ЪЪЪЦЪЪ). > > > > This is the current situation (as soon as you switch to another OS). > > That's exactly what the switch to one encoding should fix. > Should fix. Only if such text is not placed directly. I meant, new programs or updated old ones will not have the problem any more. > > It will reasonably work. For example you can not expect that the > > current windows font supports all languages. But this can not be > > fixed by the LCL anyway. > And this code SHOULD work good > (this is a bad code for international projects, but a real code for > small national projects). If you say that this code won't be > supported anyway, I will prefer old good versions (or patched > current). Yes, I think it should be said clearly: no one likes to break compatibility, but we lack the manpower to support several encodings. Lazarus already supports more platforms than it has developers. Nevertheless I will help writing tools for porting old code and extending the IDE to load/save text files in different encodings. But I'm not an expert in local encodings, so I need some help here. I will use your lconv.pas as a start and start a new thread. > > > > > And the same will > > > be with Application.MessageBox? If you are, how will it be with > > > those who have a tons of code (easily converted to UTF8, as you > > > say) full with Windows.MessageBox(Handle,...) which means > > > MessageBoxA? > > > > AFAIK the call to Windows.MessageBox is not the problem, but the non > > UTF-8 strings stored in databases. > If stored - yes. If not - no. Will you store any message in "quickly > made" application? > > Conclusion: > > Switching to UTF-8 means writing i18n programs becomes much easier > > and writing system specific programs becomes harder. It breaks > > compatibility. Some people would like a simple switch and that the > > LCL should support both, but lazarus has not the man power to > > support this. > > > This switch is quite simple... I think it is not that simple. The LCL must run in one encoding. All devels will only use the unicode 'mode'. The platform independent code is and will be written only for UTF-8. > Besides, my recoding "work around" - encoding conversion application > for the whole directory (from prev.post) Great. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [Lazarus] Error compiling lazarus
On Fri, 23 Nov 2007 17:14:30 +0100 Antonio Talamini <[EMAIL PROTECTED]> wrote: > Somebody has this error compiling Lazarus? > > Compiling /usr/lib/lazarus/components/tachart/taseries.pas > Compiling /usr/lib/lazarus/components/tachart/tagraph.pas > Compiling /usr/lib/lazarus/components/tachart/taengine.pas > taengine.pas(43,24) Error: Identifier not found "class" > taengine.pas(45,5) Error: Error in type definition > taengine.pas(45,5) Fatal: Syntax error, ";" expected but "identifier > PRIVATE" found > Fatal: Compilation aborted What fpc version? It compiles here under fpc 2.2.1. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Non UTF-8 Encodings
Goal: - IDE should load/save text files in non UTF-8 encodings. - The IDE is compiled with UTF-8 LCL, so all internal functions expects this. - It is not sufficient to change synedit, because text is often copied between synedit and other tools. And there many other IDE tools reading/editing text files. The central text loading/saving routines is the TCodeBuffer in the codetools. For performance and consistency almost all functions use these text file caches. There are a few exceptions. - When a TCodeBuffer loads a file it must find out the encoding, convert it to UTF-8 and on saving convert it back. Problems: * How to find out the encoding? - BOM - lpi file - heuristic - system char set * What about buggy text files? Vasily, your lconv.pas uses libc. AFAIK this unit only exists on a few platforms. For example not on amd64 nor sparc. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Enhanced TODO list patch
On Tue, 6 Nov 2007 18:30:33 +0100 "Gerard N/A" <[EMAIL PROTECTED]> wrote: > Ok, I have the .inc thing fixed, as long as it is in the project's > directory. Thanks. Applied. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Serial Comm Support Windows
Am Samstag, den 24.11.2007, 12:39 -0700 schrieb Jeff Steinkamp: > I know there is a serial unit for Linux/Unix, but is there similar > support for serial communications for the Windows Platform? Someone posted a unit for win32 lately. If it is not in the sources yet you may find it searching the archives of fpc and lazarus mailing lists. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Bugs in pnm, pbm and ppm loader
Hi, I saw that there were some bugs to load images ;) There are images to test in the directory GIMP-2.0\share\gimp\2.0\gimpressionist\Brushes Regards, -- Laurent. My Components: http://wiki.lazarus.freepascal.org/Wile64 French Forum : http://lazforum-fr.tuxfamily.org/index.php fpreadpnm.pp Description: Binary data
Re: [lazarus] Serial Comm Support Windows
Jeff Steinkamp wrote: I know there is a serial unit for Linux/Unix, but is there similar support for serial communications for the Windows Platform? http://www.luisdigital.com/programacion/fpc/serial.pp _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Serial Comm Support Windows
Jeff Steinkamp schrieb: I know there is a serial unit for Linux/Unix, but is there similar support for serial communications for the Windows Platform? I have a port of my original Unix serial unit (the one which has been included in FPC years ago) for Windows; it has even are more OOP-like interface (in addition to the old Linux-style one). It isn't committed yet, as I wanted to backport the OOP stuff to Linux/Unix as well; but when you are interested, I can send you the source via mail. It's working perfectly for over a year now. But be beware that it works strictly synchronous, i.e. when using it in Lazarus you would have to use a receive thread. Regars, Sebastian _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Serial Comm Support Windows
- Original Message - From: "Stephano" <[EMAIL PROTECTED]> To: Sent: Saturday, November 24, 2007 16:45 Subject: Re: [lazarus] Serial Comm Support Windows Jeff Steinkamp wrote: I know there is a serial unit for Linux/Unix, but is there similar support for serial communications for the Windows Platform? http://www.luisdigital.com/programacion/fpc/serial.pp I got the necessary units and now have this working quite well. Thanks Jeff _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Non UTF-8 Encodings
My lconv.pas can use libc because this unit was added by someone else (in LCL), I have fixed only working swich combination. It must work without it. Anyway, lconv.pas is a bad workaround, presently it fit my purposes, but not others. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
