Lazarus
Announcements => Lazarus => Topic started by: JuhaManninen on January 11, 2015, 03:06:47 pm
-
I move the discussion from "Lazarus 1.2.6 Release" to this new thread.
FYI: The next release Lazarus 1.4 will use FPC 2.6.4. I understand many people have questions about when the new FPC 3.x will be used.
The following major release Lazarus 2.0 will surely use FPC 3.x but also Lazarus 1.4.x minor release could in theory switch to it, although I don't see much use for it. Unicode related changes happen in Lazarus trunk and will not be backported, and Unicode is the biggest thing in FPC 3.x after all.
BTW, I have no idea when Lazarus 2.0 happens. Someday in future ...
2 questions of the top of my head
1) codetyphoon seems to be able to use the 3.1.1 along with lcl or so it seems from a quick glance aren't they willing to share they test cases and results with you or something along those lines to shorten the fpc 3.0 integration effort.
Usually CodeTyphon is not willing to share anything. On the other hand, they have nothing to share in this case because Lazarus already compiles with FPC 3.0 or 3.1.1 and works pretty well. CodeTyphon has not done anything to improve the Unicode support which will be our next challenge.
2) Are we going to see major changes in the lcl for the new unicode support? EE will the lcl support ucs16 or what ever is the default encoding for windows and utf8 for linux to minimize the translations between lcl and system encoding to minimum (I would go for 0 translation) or it will be kept as UTF8 and autotranslate to what ever the unicode windows api expects it to be?
Zero translation in encoding would be very difficult to implement.
If nothing unexpected comes up, Lazarus will continue to use UTF8 but using new cool features of FPC. See :
http://lists.lazarus.freepascal.org/pipermail/lazarus/2014-November/089394.html
If you want to know more, please ask questions in Lazarus mailing list because Mattias follows it and he know the topic best.
-
What is the plan for supporting Right-To-Left languages?
There is no plan because none of the core developers know the issue well enough.
We would need a person who understands both Right-To-Left issues and LCL well enough. In practice it must be a person who natively uses a Right-To-Left language.
If such a person (maybe you) steps forward, other developers will be happy to share their knowledge about LCL.
That is how open source development works.
-
There is no plan because none of the core developers know the issue well enough.
We would need a person who understands both Right-To-Left issues and LCL well enough. In practice it must be a person who natively uses a Right-To-Left language.
If such a person (maybe you) steps forward, other developers will be happy to share their knowledge about LCL.
That is how open source development works.
I am willing to assist. I am more than willing actually and really very happy to contribute to this community. But not sure if my knowledge of LCL is enough to start.
-
I am willing to assist. I am more than willing actually and really very happy to contribute to this community. But not sure if my knowledge of LCL is enough to start.
If you are serious about it, you must study the LCL architechture and code. Wiki may have some info but diving into the code will be needed very soon.
When you don't understand something although you tried, please ask questions in Lazarus mailing list. Developers follow it more than this forum. I am not an expert with LCL, better ask details from other people.
One challenge with LCL is the division between LCL code itself and the widgetset binding code. I believe that much of Right-To-Left code must go to bindings because all major widgetsets support it.
-
Is now any string-based RTL functions (such as StrReplace(), Format(), Trim(), UpperCase(), etc..) will correctly handle characters with variable bytes length?
And some functions, like Pos(), Length(), Copy() will be bytes-oriented, or character-oriented? Is lazutf8 unit not needed anymore?
-
Is now any string-based RTL functions (such as StrReplace(), Format(), Trim(), UpperCase(), etc..) will correctly handle characters with variable bytes length?
And some functions, like Pos(), Length(), Copy() will be bytes-oriented, or character-oriented? Is lazutf8 unit not needed anymore?
I don't have answers for your questions, maybe nobody has yet. In new FPC the codepage can be set for UTF8 by :
SetMultiByteConversionCodePage(CP_UTF8);
SetMultiByteRTLFileSystemCodePage(CP_UTF8);
added to the initialization section of an early unit. It means the characted encoding in FPC is not fixed to UTF16 after all.
Mattias has experimented with it, see the mailing list thread mentioned earlier.
-
I don't have answers for your questions, maybe nobody has yet.
...
After reading the whole thread:
http://lists.lazarus.freepascal.org/pipermail/lazarus/2014-November/089394.html
Using Lazarus 1.3 and FPC 3.0.1, both development versions, should I start making tests on Unicode, UTF16 and UTF8?
Should I report problems here or on the Bug Tracker (Mantis)?
Is Mattias' wiki page about FPC Unicode ready? If so, where?
http://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows
http://superuser.com/questions/221593/windows-7-utf-8-and-unicode
http://msdn.microsoft.com/en-us/library/windows/desktop/dd319072(v=vs.85).aspx
http://msdn.microsoft.com/pt-br/library/windows/desktop/dd317756(v=vs.85).aspx
-
see the mailing list thread mentioned earlier.
Yes, I read it. This one is same, as I want to say:
http://lists.lazarus.freepascal.org/pipermail/lazarus/2014-November/089555.html
And, some my suggestions:
Char is character, and String is array of characters. Long ago, characters was a bytes, so strings was a array of bytes.
But now, Char is not byte. It short array of bytes (ShortString, maybe?). String is array of bytes, like before, but must treated as array of characters, when used as characters container.
var
SomeByte: Byte;
SomeChar: Char;
SomeString: String;
begin
SomeString:='абракадабра'; // Russian 2-byte letters in utf8
SomeChar:=SomeString[2]; // 'б', second character
SomeByte:=SomeString[2]; // $E1, second byte
end;
SomeChar must be 'б', second letter, not second byte. And so for every function, that works with characters. That is what I mean as Unicode support.
For single-byte characters there is AnsiChar and AnsiString, same as in Delphi.
-
Using Lazarus 1.3 and FPC 3.0.1, both development versions,
Lazarus trunk is now 1.5 and FPC trunk is 3.1.1. FPC 3.0.1 is the release branch.
should I start making tests on Unicode, UTF16 and UTF8?
Yes, if you want.
Should I report problems here or on the Bug Tracker (Mantis)?
Not in bug tracker for sure. Only some experiments have been done, everybody knows it does not work yet.
If you make serious testing which can lead to code contribution, then Lazarus mailing list would be the best place as the right people follow it.
Is Mattias' wiki page about FPC Unicode ready? If so, where?
I don't think so. He has not worked on this issue either recently.
Now that 1.4 has been forked, trunk is open for experimental changes.
-
Yes, I read it. This one is same, as I want to say:
http://lists.lazarus.freepascal.org/pipermail/lazarus/2014-November/089555.html
That is DoDi partly hijacking yet another thread where the magic word "Unicode" was mentioned.
Remember, the thread was originally about Mattias asking help for testing the UTF8 RTL on Windows.
And, some my suggestions:
Char is character, and String is array of characters. Long ago, characters was a bytes, so strings was a array of bytes.
... and so on ...
Please let's not start discussion about differences of UTF8 and UTF16 here. Also let's not discuss here about how Embarcadero should have implemented Unicode or about if FPC should be 100% compatible with Delphi.
Those issues have been discussed again and again in FPC mailing lists during past 5 years. If a mail mentioned the word "Unicode", certain people joined and started repeating the same arguments again and again and again. A single mail thread typically lasted many months and had hundreds of mails.
Also the FPC devels wasted lots of energy explaining the same things repeatedly in those mail threads!
If Unicode in Lazarus must be discussed, let's keep it as concrete as possible. The requirements for participants should be:
1. Know how UTF8 and UTF16 work.
2. Know how Unicode and string types are implemented in new FPC.
3. Know how UTF8 support is implemented in current Lazarus.
4. Have read enough of FPC mail Unicode thread history to understand how bad it was.
The information is out there for those who have gaps in their knowledge.
Still, for serious discussion based on test results I recommend Lazarus mailing list, although the same rules should apply also there.
-
Please let's not start discussion about differences of UTF8 and UTF16 here.
No, I don't.
All, that I want from subject - that standard functions works as it described in help and manuals. For example:
Copy() - Copy returns a string which is a copy if the Count characters in S, starting at position Index.
s:=Copy('южный', 2, 2);
it obviously, that it take two characters, starting from second character. And if it return '躰', then that considered as a bug.
-
If you are serious about it, you must study the LCL architechture and code. Wiki may have some info but diving into the code will be needed very soon.
When you don't understand something although you tried, please ask questions in Lazarus mailing list. Developers follow it more than this forum. I am not an expert with LCL, better ask details from other people.
One challenge with LCL is the division between LCL code itself and the widgetset binding code. I believe that much of Right-To-Left code must go to bindings because all major widgetsets support it.
I will do my best. Let's see how it goes. Thank you Juha.
-
Right-To-Left language...
If such a person (maybe you) steps forward, other developers will be happy to share their knowledge about LCL.
I am willing to assist.
You may look as well for posts from Avishai (http://forum.lazarus.freepascal.org/index.php?action=profile;u=45211) or just contact him. He might be still very interested in the RTL topic.
-
You may look as well for posts from Avishai (http://forum.lazarus.freepascal.org/index.php?action=profile;u=45211) or just contact him. He might be still very interested in the RTL topic.
He is interested but his knowledge is not enough to implement it. He may become even more frustrated if you ask him questions about the implementation.
He has not written anything for a while. Earlier he mentioned about some health problems. I hope he is still OK.
-
First, I admit it was stupid to put up rules for not discussing Unicode. I am apparently allergic for the topic after reading FPC lists for 5 years.
Yes, I still recommend for anybody to study the topic because it is unbelievably complex. However talking about Lazarus and the new FPC brings some obvious new questions. Unicode is the main feature of FPC 3.0 after all.
All, that I want from subject - that standard functions works as it described in help and manuals. For example:
Copy() - Copy returns a string which is a copy if the Count characters in S, starting at position Index.
s:=Copy('южный', 2, 2);it obviously, that it take two characters, starting from second character. And if it return '躰', then that considered as a bug.
There will be such function for sure. Let's see if the name is Copy() also for UTF8.
However working with variable width Unicode strings is always more complex than fixed width AnsiStrings.
When you have to iterate characters, you must use a string to keep a single character.
UnicodeString in Delphi and FPC has the same problem. UTF16 is NOT fixed width although this impression is easy to get when looking at code samples. The old code from AnsiString Delphis will work most of the time but not always. There are almost 100k Unicode characters but 16 bits can address only 64k of them. It means ~30000 characters require 2 words (of type UnicodeChar). Those are maybe rare characters but will cause a bug eventually in code that does not take them into account.
Which encoding should Lazarus use? There seemed to be 2 alternatives, the Delphi compatible UnicodeString and AnsiString + the UTF8 specific functions in LCL.
Then it turned out that FPC + its libs can use UTF8 by simply setting some variables. FPC is well designed, 5 years of arguing in mailing list was not wasted after all.
Lazarus + LCL is already designed for UTF8 and this allows a conversion with least changes. (This assuming nothing unexpected comes up in tests).
It will still be possible to create a version of Lazarus + LCL with UTF16 UnicodeString if somebody wants to implement it.
UTF8 is a very clever encoding. It is backwards compatible with ascii, it produces compact data for western languages (ok, I don't know what Chinese people think of it), and its integrity can be analyzed from the data itself.
The benefit of UTF16 originally was its fixed width characters, but it is not true any more. So its main benefit went away.
Positive news is that user code only seldom needs to iterate single variable width Unicode characters because such things are encapsulated in libraries, and because often the characters of interest are in ascii area. For example many current parsers work with UTF8 data well because all <tag> chars are ascii. Data between tags can be UTF8 but typically the parser just copies it without analysis.
Now I discussed about differences of UTF8 and UTF16, here we go...
We can write about congrete Lazarus implementation details in mailing list when somebody has done tests.
-
Yes, I still recommend for anybody to study the topic because it is unbelievably complex.
However talking about Lazarus and the new FPC brings some obvious new questions.
Unicode is the main feature of FPC 3.0 after all.
Agree.
I do not want to discuss Unicode choices and implementation again.
I just want to test this new main feature of FPC 3.0, report the real problems I got (if any) and contribute to stabilize FPC 3.0 as soon as possible.
The perfect world would be to see stable Lazarus 1.4 and stable FPC 3.0 released together. :)
Now, some extra, basic information to understand UTF8, UTF16, UTF32, ISO, subsets and sub-flavors:
https://mobworld.wordpress.com/2010/05/06/utf-encoding-formats/
http://www.unicode.org/faq/utf_bom.html
http://stackoverflow.com/questions/496321/utf8-utf16-and-utf32
youtube - Characters, Symbols and the Unicode Miracle - Computerphile
https://www.youtube.com/watch?v=MijmeoH9LT4
http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings
http://unicodebook.readthedocs.org/en/latest/unicode_encodings.html
http://www.personal.psu.edu/ejp10/blogs/gotunicode/2007/10/which_utf_do_i_use.html
http://www.quora.com/What-is-the-difference-between-UTF-8-and-UTF-16
http://programmers.stackexchange.com/questions/40063/should-character-encodings-besides-utf-8-and-maybe-utf-16-utf-32-be-deprecated
http://programmers.stackexchange.com/questions/102205/should-utf-16-be-considered-harmful
http://www.editpadpro.com/unicode.html (just an example to see how complicated this subject may be, no need to buy anything)
-
The perfect world would be to see stable Lazarus 1.4 and stable FPC 3.0 released together. :)
No. It is better to release 1.4 now without the Unicode changes. If we wanted to include those changes in 1.4, the release cycle would become much too long and people would not have the nice features already implemented in trunk.
Also the version number would be wrong. 2.0 will indicate major changes where also user level code must be adjusted.
Although Lazarus 1.4 does not benefit from FPC Unicode features, you can still compile it using FPC 3.0 or trunk. It is backwards compatible when the old default AnsiString is used.
-
@JuhaManninen, I understand your view point and I agree with you.
I would like to include here some extra information I read in other topic that I think is relevant to this discussion.
Please, explain me, what about unicode support in Lazarus?
It is supported by AnsiString + UTF8 specific functions. See :
http://wiki.freepascal.org/LCL_Unicode_Support
Lazarus 2.0 will improve things.
The Windows unit won't really change in newer FPC versions, since that is the interface of Windows operating system, and windows won't suddenly start supporting utf8.
On Windows, Utf8 is for textfiles only, not for APIs.
The only change that still must happen is to switch the default names (e.g. GetCRC32OfFile) from the -A to the -W alias, similar like D2009 did
-
I would like to include here some extra information I read in other topic that I think is relevant to this discussion.
Why are those things relevant? Both myself and Marcov stated some well known facts for a new person who does not know them yet.
For example LCL has supported Unicode maybe 7 or 8 years. Nothing new there.
-
Basically for users not much changes, except that most file related routines in system and sysutils will work fine with unicode if you pass it the file or directory name in an utf8string or unicodestring.
-
Why are those things relevant? Both myself and Marcov stated some well known facts for a new person who does not know them yet.
For example LCL has supported Unicode maybe 7 or 8 years. Nothing new there.
This topic has been read 2494 times so far. It seems to me that it is interesting to many people, including new comers.
That little piece of information shows alternatives and states information related to Unicode treatment in FPC 2.x and 3.x and its consequences in Windows, Lazarus 1.4 and 2.0.
Sorry for not everybody here to be on the project as much time as you, or know it so deep inside as much as you.
-
This topic has been read 2494 times so far. It seems to me that it is interesting to many people, including new comers.
Quite many readers indeed!
There may be an impression that the Unicode support of Lazarus will improve dramatically when the new FPC features are utilized. Not really. Explicit conversion routines are not needed and some things become easier, but the current UTF8 support is also good.
Many people may find the new features of the coming 1.4 more interesting than the future Unicode improvements.
-
How far is FPC3.0 safe to use with Lazarus trunk version
-
How far is FPC3.0 safe to use with Lazarus trunk version
As safe as all trunk compiler version all this time.
-
Hello Guys,
I have an alternative question. Will this FPC support Android developing?
Regards,
Sty
-
Hello Guys,
I have an alternative question. Will this FPC support Android developing?
Regards,
Sty
It's based on trunk, so it of course will have Android support.
-
So, the most of the talk here has been that the main feature of FPC 3.0 would be Unicode changes which are irrelevant for Lazarus 1.2.x...
But, as I recall, FPC 2.7.x was declared necessary for Android target, and it has also been said that it produces better optimized binaries, up to 30% faster.
So it seems there actually may be real benefits of using FPC 3.0 and Lazarus 1.2.x together, if I got that correctly...
-
So it seems there actually may be real benefits of using FPC 3.0 and Lazarus 1.2.x together, if I got that correctly...
Depends on whether you need the features or not. Please don't forget the maturing generics feature, it's getting better and better. There are also more utilities included in trunk and more optimizations (yay).
-
So it seems there actually may be real benefits of using FPC 3.0 and Lazarus 1.2.x together, if I got that correctly...
You mean Lazarus 1.4.x, not Lazarus 1.2.x. The former is already forked and RC1 will come soon, 1.2.x will not be updated any more.
Otherwise you have a valid point. FPC 3.0 will have a huge number of improvements and new features. It would make sense to use it at some point for Lazarus 1.4 series. It has been done before, IIRC Lazarus 1.2.0 was released with FPC 2.6.2 but Lazarus 1.2.2 with FPC 2.6.4 (or something).
Lazarus 1.4.0 must use FPC 2.6.4 because 3.0 will not (likely) be released yet.
We try to get 1.4.0 out rather soon while FPC 3.0 testing and stabilization will take longer. When FPC 3.0 is out, Lazarus must be tested more with it.
After that maybe 1.4.2 could use the new FPC. Let's see. It has not been discussed anywhere.
Some visually apparent changes of Lazarus 1.4 are listed here :
http://wiki.freepascal.org/New_IDE_features_since#v1.4_.28to_be_announced.29
It also has tons of smaller improvements and bug fixes.
People who use trunk knew this already, yes.
-
Hello Everyone,
I have got an idea for Lazarus form design ;
All we are using some unvisual components (like as lazserial , timers, fontdialog etc) in the forms , over 10~20 unvisual components our form is complexing a lot.
Is it possible to layered to show or hide of form components?
I know I can create a datamodule form and put all I needed components and use in the main unit but unfortunately we are not start with this dicipline.
Have a nice coding.
-
Hi all.
Try to rebuild the trunk Lazarus (rev 47551)/fpc trunk (rev 29561) . When compiling I get an error
Compiling forms.pp
Compiling .\widgetset\wsforms.pp
wincontrol.inc(2623,5) Error: Asm: Duplicate label CONTROLS$_$TWINCONTROL_$_ALIGNCONTROLS$TCONTROL$RECT_DOPOSITION$TCONTROL$TALIGN$LONGINT_$$_CONSTRAINTHEIGHT$crc42AA5AF5
wincontrol.inc(2602,5) Error: Asm: Duplicate label CONTROLS$_$TWINCONTROL_$_ALIGNCONTROLS$TCONTROL$RECT_DOPOSITION$TCONTROL$TALIGN$LONGINT_$$_CONSTRAINTWIDTH$crc42AA5AF5
controls.pp(4175) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted
make[1]: Leaving directory `d:/Archive/development/lazarus_trunk/lcl'
What happened? :o
-
Hi all.
Try to rebuild the trunk Lazarus (rev 47551)/fpc trunk (rev 29561) . When compiling I get an error
Compiling forms.pp
Compiling .\widgetset\wsforms.pp
wincontrol.inc(2623,5) Error: Asm: Duplicate label CONTROLS$_$TWINCONTROL_$_ALIGNCONTROLS$TCONTROL$RECT_DOPOSITION$TCONTROL$TALIGN$LONGINT_$$_CONSTRAINTHEIGHT$crc42AA5AF5
wincontrol.inc(2602,5) Error: Asm: Duplicate label CONTROLS$_$TWINCONTROL_$_ALIGNCONTROLS$TCONTROL$RECT_DOPOSITION$TCONTROL$TALIGN$LONGINT_$$_CONSTRAINTWIDTH$crc42AA5AF5
controls.pp(4175) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted
make[1]: Leaving directory `d:/Archive/development/lazarus_trunk/lcl'
What happened? :o
http://bugs.freepascal.org/view.php?id=27348
-
Thx :)
-
Is now any string-based RTL functions (such as StrReplace(), Format(), Trim(), UpperCase(), etc..) will correctly handle characters with variable bytes length?
I have more answers now. For details see :
http://wiki.freepascal.org/Better_LCL_Unicode_Support
There is no StrReplace() in FPC libs. The other funcs work as expected. UpperCase() continues to work in ASCII area only, just like in Delphi.
The Ansi...() versions of string functions are also Delphi compatible.
And some functions, like Pos(), Length(), Copy() will be bytes-oriented, or character-oriented?
Bytes-oriented.
In Delphi they are not character-oriented either, they are UnicodeChar(*) (WideChar, Word, 2 Bytes)-oriented. One Unicode codepoint in UTF-16 encoding can consist of 2 UnicodeChars(*). There is lots of sloppy Delphi code forgetting this fact.
Please read carefully this:
http://wiki.lazarus.freepascal.org/UTF8_strings_and_characters
and you understand that Pos(), Length(), Copy() are very useful with UTF-8.
Is lazutf8 unit not needed anymore?
No. There will be CodePoint...() functions but they are not implemented yet. With UTF-8 they will be wrappers for the functions in LazUTF8, you can test now with them.
Things happen in a little wrong order. This new UTF-8 support is for Lazarus 2.0 and it works well, but Lazarus 1.4 has not been released and does not even have RC1 yet.
Anyway, please test with the new UTF-8 support and try to find problems. The only known problem is still the Char type with TFormatSettings.
(*) "UnicodeString" and "UnicodeChar" names for types was a very unfortunate choice from Borland.
A Unicode codepoint is a "real" character definition in Unicode which can be encoded differently and its length depends on the encoding.
A Unicode character is either one codepoint or a surrogate pair of multiple codepoints. Yes, this is complex ...
-
Sorry guys,
maybe this is a little bit off topic but reading this posts I am getting the impression that FPC 3.0 is already out? But there are no news about FPC 3.0 on the http://www.freepascal.org . So is it out or not?
-
Sorry guys,
maybe this is a little bit off topic but reading this posts I am getting the impression that FPC 3.0 is already out? But there are no news about FPC 3.0 on the http://www.freepascal.org . So is it out or not?
FPC 3.0 has been branched off and is in a stabilization phase. It is not an official release yet
-
FPC 3.0 has been branched off and is in a stabilization phase. It is not an official release yet
Do you know which branches have been / are being merged? I'm mostly interested in enhanced RTTI and custom attributes.
-
FPC 3.0 has been branched off and is in a stabilization phase. It is not an official release yet
Do you know which branches have been / are being merged? I'm mostly interested in enhanced RTTI and custom attributes.
I don't know the exact status of those. To my best knowledge nothing is moving there. There was some talk about the invoke related rtti, but that is about it.
Afaik the last updates on the branches that you name were public in fpc-devel because of several Mormot people asking.
-
I've been trying out Lazarus 1.4RC1 with FPC 2.6.4 and it looks good. The upcoming FPC 3.0 contains two new transaction options.
sqldb.pp line 265
TSQLTransactionOption = (stoUseImplicit, stoExplicitStart);
If I start using Lazarus 1.4RC1 with FPC 3.0 will these new options show up in the object inspector or will I have to set the option in code?
-
If I start using Lazarus 1.4RC1 with FPC 3.0 will these new options show up in the object inspector or will I have to set the option in code?
If you recompile the RC1 branch with FPC 3.0 such properties (and additional enum fields) will be visible yes. The Lazarus classes inherit from the FPC ones, so if the FPC ones change, that is automatic.
-
Hi friends
Try to compile the latest trunk fpc (r. 30510), get
Start compiling package utils for target i386-win32.
Compiling BuildUnit_utils.pp
Compiling usubst.pp
Compiling ptopu.pp
Compiling ptop.pp
The installer encountered the following error:
External command "d:/Archive/development/fpc_trunk/compiler/ppc386.exe -Twin32 -FEbin\i386-win32 -FUunits\i386-win32\ -Fud:\Archive\development\fpc_trunk\rtl\units\i386-win32\ -Fud:\Archive\development\fpc_trunk\units\i386-win32\fcl-base -Fud:\Archive\development\fpc_trunk\units\i386-win32\fcl-res -Fud:\Archive\development\fpc_trunk\units\i386-win32\rtl-objpas -Fud:\Archive\development\fpc_trunk\units\i386-win32\paszlib -Fud:\Archive\development\fpc_trunk\units\i386-win32\hash -Fud:\Archive\development\fpc_trunk\units\i386-win32\rtl-extra -Ur -Xs -O2 -n -Fud:/Archive/development/fpc_trunk/rtl/units/i386-win32 -Fud:/Archive/development/fpc_trunk/packages/paszlib/units/i386-win32 -Fud:/Archive/development/fpc_trunk/packages/fcl-process/units/i386-win32 -Fud:/Archive/development/fpc_trunk/packages/hash/units/i386-win32 -Fud:/Archive/development/fpc_trunk/packages/libtar/units/i386-win32 -Fud:/Archive/development/fpc_trunk/packages/fpmkunit/units/i386-win32 -Fud:/Archive/development/fpc_trunk/packages/fcl-json/units/i386-win32 -di386 -dRELEASE -viq ptop.pp" failed with exit code 1. Console output:
Target OS: Win32 for i386
Compiling ptop.pp
PPU Loading D:\Archive\development\fpc_trunk\units\i386-win32\fcl-base\custapp.ppu
PPU Invalid Version 172
ptop.pp(21,29) Fatal: Can't find unit CustApp used by PtoP
Fatal: Compilation aborted
make[2]: Leaving directory `d:/Archive/development/fpc_trunk/utils'
make[1]: Leaving directory `d:/Archive/development/fpc_trunk'
Does someone have a solution? :-[
-
Properly clean out old ppu's and .o's before building new ones.
-
Thank you, you was right :D
-
Hi,
I'm seeing the wiki "recent changes" and I see that they're planning the FPC 3.0.
I can't find anything about Lazarus on these articles, Lazarus will be shipped with FPC 3.0 when they release it? At the same time or not?
-
Usually Lazarus releases a point release one or two weeks later.
Note that the activity you see is not the (final) release but a release candidate.
-
Alright. Thanks.
-
For anyone that's interested, after installing CodeTyphon (Win32), i'm able to use its FPC (version 3.1.1) in Lazarus 1.4.2:
In IDE options, change:
Compiler executable (e.g. fpc.exe)
C:\codetyphon\fpc\fpc32\bin\i386-win32\fpc.exe
FPC source directory
C:\codetyphon\fpcsrc\
"Make" executable
C:\codetyphon\fpc\fpc32\bin\i386-win32\make.exe
Lazarus recompiled without problems. (So far)
-
About Unicode: is there also support for flat, 32-bit Unicode? I would really like that. That makes it easy again to implement all those missing functions. UTF-8 is nice and all, for files and sockets, but not for string manipulation. And who cares about the memory?
I'm using C++ Builder at my job, and the best things about that are real strings (no C-strings or std::string!) and TStringList. UTF8 strings is in many ways like going back to C-strings...
I mean, it's great that FPC + Lazarus support UTF-8, of course, but a large part of writing business apps is string manipulation. Half the functions I use regularly won't work or very slowly with UTF-8.
If I can help with it, tell me with what and I'll take a look.
-
Hello, I am new to Lazarus. I just recently installed it, and also installed FPC v3.0 because I wanted the cross compilation ability. However, when went into the options to redirect Lazarus to the new version of FPC, I found the executable names are different in FPC v3.0 than in v2.6.4. Can anyone tell me which executables do what in v3.0, and what settings to change in the options dialog to get Lazarus to work with v3.0? I've been hobby programming for 15 years in C/C++ and I am just now taking up the Pascal language because it seems like it might be easier. In another IDE I use for C++, I had to create screenshots for myself to remember how to setup the GNU GCC toolchains in that particular IDE because the naming convention used for the executables was not the least bit intuitive. Neither Fpc.exe nor make.exe are in v3.0, so I don't know what new executables do what, or to which property to assign them in the options dialog.
I have to warn you in advance, I am kind of slow on the uptake/slow in the head. It took me about 6 years just to get the basics of C++. So pictures or anything else that will make it as easy as possible for me to set up Lazarus w/FPC v3.0 will be appreciated.
Thanks in advance!
GypsyPrince
-
Hi, and welcome GypsyPrince.
Every version of the Free Pascal commandline compiler is named fpc.exe (well, for windows platforms that is). In case it doesn't for you, then for sure there must be something amiss.
Rather than trying to solve your current issues, would it be an option for you to install the latest release candidate of lazarus (which comes with FPC 3.0 installed) ?
You can find it here in this post (http://forum.lazarus.freepascal.org/index.php/topic,31095.0.html).
edit: corrected link
edit2: or not, i give up.
BTW: something completely unrelated for those that recognize: but is it only me that can't view posted links because of those silly session id's that are automatically attached when copy-pasting a link ? The only way to be able to view such a link is when logged in.
-
Molly,
Thank you very, very much for the info!!
I know that I will eventually have to learn the compiler setup down the road, but for now this is a very convenient fix so that I can get started learning Pascal!!!
Again, thanks!.!.! :)
-
[/quote]Right-To-Left language...
If such a person (maybe you) steps forward, other developers will be happy to share their knowledge about LCL.
I am willing to assist.
You may look as well for posts from Avishai (http://forum.lazarus.freepascal.org/index.php?action=profile;u=45211) or just contact him. He might be still very interested in the RTL topic.
Another user who has some expertise of R-T-L in FreePascal is motaz.
-
Hi Juha and the team. Can I buy the book, to support You, by buying the book from Google to show my appreciation, for the freepascal/lazarus? 8)
Can anyone tell me?
Best regards Robbanux