[fpc-devel] Optimization stops near inline asm
the following code:
{$mode objfpc}
var
a: Integer;
begin
a := a + 1;
asm nop end;
end.
generates (under -O2):
movlU_P$PROGRAM_A,%eax
incl%eax
movl%eax,U_P$PROGRAM_A
nop
instead of a single incl.
removing either asm statement OR $mode directive
reinstates the optimization (although in the latter case with incw,
of course).
This obviously never matters in practice, but may be a symptom of some more
serious problem. Should I file a bug report?
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Optimization stops near inline asm
Am 03.10.2011 08:27, schrieb Alexander Klenin:
the following code:
{$mode objfpc}
var
a: Integer;
begin
a := a + 1;
asm nop end;
end.
generates (under -O2):
movlU_P$PROGRAM_A,%eax
incl%eax
movl%eax,U_P$PROGRAM_A
nop
instead of a single incl.
removing either asm statement OR $mode directive
reinstates the optimization (although in the latter case with incw,
of course).
This obviously never matters in practice, but may be a symptom of some more
serious problem. Should I file a bug report?
FPC doesn't do any optimization in procedures containing inline assembler.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Optimization stops near inline asm
2011/10/3 Jonas Maebe jonas.ma...@elis.ugent.be: asm nop end []; then the statement will optimized. Otherwise the compiler assumes that the contents of eax may still be used inside the assembler block and hence cannot remove its use. The fact that the optimization is performed in case the used register is ax instead of eax suggests a small bug. I see, thanks. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] utf-8 package in Free Pascal
Hello, I would like to add a new package to Free Pascal into the directory packages/fputf8 which will provide classes and routines for UTF-8 applications. It might grow to include things like: * full unicode tables and conversion routines * Equivalents of RTL classes which are not adequate for UTF-8 applications and/or will still not be in the wide RTL like TFileStream and TStringList * Equivalents of RTL routines with UTF-8 parameters Just announcing to check if there is opposition to Free Pascal distributing such a package. thanks, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
In our previous episode, Felipe Monteiro de Carvalho said: I would like to add a new package to Free Pascal into the directory packages/fputf8 which will provide classes and routines for UTF-8 applications. It might grow to include things like: * full unicode tables and conversion routines * Equivalents of RTL classes which are not adequate for UTF-8 applications and/or will still not be in the wide RTL like TFileStream and TStringList * Equivalents of RTL routines with UTF-8 parameters Just announcing to check if there is opposition to Free Pascal distributing such a package. I don't see the point of this. These things are related to Lazarus UTF8 decision and thus logically belong in Lazarus, till they are superceded in 2.8 by proper unicode support. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Mon, 3 Oct 2011, Felipe Monteiro de Carvalho wrote: Hello, I would like to add a new package to Free Pascal into the directory packages/fputf8 which will provide classes and routines for UTF-8 applications. It might grow to include things like: * full unicode tables and conversion routines * Equivalents of RTL classes which are not adequate for UTF-8 applications and/or will still not be in the wide RTL like TFileStream and TStringList * Equivalents of RTL routines with UTF-8 parameters Just announcing to check if there is opposition to Free Pascal distributing such a package. Please do not include this package yet. Currently, hard work is being put in the unicode string and codepage string routines in the RTL. Chances are that you will duplicate a lot of functionality, and this should be avoided at all costs. So I suggest you wait till the dust settles around the new string type, and then check a) what is still needed. Maybe we will have solved it for you. b) whether it should not be put in the RTL instead of a separate package. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Mon, Oct 3, 2011 at 11:38 AM, Marco van de Voort mar...@stack.nl wrote: These things are related to Lazarus UTF8 decision and thus logically belong in Lazarus, Not really. One can write a non-visual library which uses utf8string as its main string type, why not? But the RTL is not adequate for utf8string projects and will still not be after the Unicode RTL is completed. This is the case of fpvectorial and fpspreadsheet for example. If there is no fpc package with UTF-8 routines then it becomes impossible to write utf-8 non-visual packages which do not depend on the LCL. FPSpreadsheet already contains code copied from the LCL utf-8 routines, I want to stop this multiplication of code copies and unify all routines in one base place, which logically should be in Free Pascal. till they are superceded in 2.8 by proper unicode support. The Unicode RTL is not satisfactory for utf-8 projects. One cannot seriously expect to be able to write a project which uses utf8string if you don't even have a utf-8 TStringList to share between various libraries. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Mon, Oct 3, 2011 at 11:41 AM, michael.vancann...@wisa.be wrote: Please do not include this package yet. I'd rather find a consensus on this now then to postpone yet again. I have patches to merge about this and I have some time now which is something which can disappear at any moment. So I suggest you wait till the dust settles around the new string type, and then check a) what is still needed. Maybe we will have solved it for you. I am 100% sure that it will not solve my problems. b) whether it should not be put in the RTL instead of a separate package. Wasn't this rejected a short while ago? -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] building fpc / fpmake and multicore cpu ?
On 01/10/2011 12:56, Mattias Gaertner wrote: Is that correct? Does the old Makefile driven compilation use both/all cores, while packages done via fpmake, are using one core only? AFAIK the makefile does not use parallel compilation. Yes it does, at least for compiling FPC itself (or rather parts thereof - but which parts I don't know, probably the FCL). eg: make -j 5 all Then when looking at the CPU monitor from Gnome, I see heavy CPU load on one core only. After some initial compilation on one core, it will switch to using all 4 cores in my system. This shaves about 30 seconds off the time for a clean compile of FPC on my system (if I remember correctly). I think it was Michael van Canneyt who told me about this switch a while back, and that it indeed works with FPC too. How you apply this to your own work / projects, I have no idea. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Optimization stops near inline asm
Jonas Maebe schrieb: It does. But also assumes that all registers are used in assembler blocks, unless the programmer specifies otherwise. But a:=a+1; does not imply any register usage, and the variable is a global one? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Optimization stops near inline asm
Am 03.10.2011 10:24, schrieb Jonas Maebe: On 03 Oct 2011, at 10:14, Florian Klämpfl wrote: FPC doesn't do any optimization in procedures containing inline assembler. It does. Oops, I thought you changed this a while ago :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
Am 03.10.2011 12:20, schrieb Felipe Monteiro de Carvalho: On Mon, Oct 3, 2011 at 11:41 AM,michael.vancann...@wisa.be wrote: Please do not include this package yet. I'd rather find a consensus on this now then to postpone yet again. I have patches to merge about this and I have some time now which is something which can disappear at any moment. You can always commit them to a branch so the changes can be discussed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
In our previous episode, Felipe Monteiro de Carvalho said: Not really. One can write a non-visual library which uses utf8string as its main string type, why not? But the RTL is not adequate for utf8string projects True, because we never planned to have support for such utf8 only libraries in the first place. and will still not be after the Unicode RTL is completed. I don't see why not. This is the case of fpvectorial and fpspreadsheet for example. If there is no fpc package with UTF-8 routines then it becomes impossible to write utf-8 non-visual packages which do not depend on the LCL. FPSpreadsheet already contains code copied from the LCL utf-8 routines, I want to stop this multiplication of code copies and unify all routines in one base place, which logically should be in Free Pascal. Then factor out the relevant LCL independent stuff to an external project. If it is non visual, it doesn't automatically mean it should go into FPC. till they are superceded in 2.8 by proper unicode support. The Unicode RTL is not satisfactory for utf-8 projects. One cannot seriously expect to be able to write a project which uses utf8string if you don't even have a utf-8 TStringList to share between various libraries. 1) There is an unit ansistrings in Delphi for just that. 2) And if you use the UTF8 spin of the unicode RTL, the default TStringlist is UTF8. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Mon, 3 Oct 2011, Felipe Monteiro de Carvalho wrote: On Mon, Oct 3, 2011 at 11:41 AM, michael.vancann...@wisa.be wrote: Please do not include this package yet. I'd rather find a consensus on this now then to postpone yet again. I have patches to merge about this and I have some time now which is something which can disappear at any moment. This is in fact a reason not to include it in fpc. You commit some quick-and-dirty stuff, and then it's forgotton, or abandoned. So: rather not. So I suggest you wait till the dust settles around the new string type, and then check a) what is still needed. Maybe we will have solved it for you. I am 100% sure that it will not solve my problems. b) whether it should not be put in the RTL instead of a separate package. Wasn't this rejected a short while ago? Not to my knowledge. First wait till the dust settles. You can always park your routines in lazarus CCR in the meantime. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Mon, Oct 3, 2011 at 21:13, Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote: On Mon, Oct 3, 2011 at 11:38 AM, Marco van de Voort mar...@stack.nl wrote: These things are related to Lazarus UTF8 decision and thus logically belong in Lazarus, Not really. One can write a non-visual library which uses utf8string as its main string type, why not? But the RTL is not adequate for utf8string projects and will still not be after the Unicode RTL is completed. Felipe, I agree with you in theory, but I'd still recommend you to move utf8string together with fpvectorial and fpspreadsheet into Lazarus. This way, you can develop much faster, without the need to fight for your changes, and without the need for a half-duplicate CCR repository. As for visual vs non-visual distinction, Lazarus can be used to produce console applications just as well, so moving to Lazarus does not automatically means depending on LCL. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Mon, Oct 3, 2011 at 12:40 PM, Marco van de Voort mar...@stack.nl wrote: True, because we never planned to have support for such utf8 only libraries in the first place. ... Then factor out the relevant LCL independent stuff to an external project. If it is non visual, it doesn't automatically mean it should go into FPC. You know very well that this is not a workable solution. It would be a huge work to set up such an intermediary project between FPC and Lazarus. I think that's a very radical posture. I can even understand that you may not want utf-8 support in the RTL which you develop, that you may not want to use fputf8 in your projects, but block packages which you don't develop??? You don't have to use it if you don't like it. 1) There is an unit ansistrings in Delphi for just that. Not nearly what I want. Just to start with, ansistring is not the same as utf8string. 2) And if you use the UTF8 spin of the unicode RTL, the default TStringlist is UTF8. Also not a solution, because then fpvectorial and fpspreadsheet would not be able to compile in other RTL modes. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On 3-10-2011 13:45, Felipe Monteiro de Carvalho wrote: Also not a solution, because then fpvectorial and fpspreadsheet would not be able to compile in other RTL modes. What? confused You mean you are seeking the solution upstream? Seems the design of those units is lacking. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Mon, Oct 3, 2011 at 22:40, Florian Klämpfl flor...@freepascal.org wrote: Am 03.10.2011 13:23, schrieb Alexander Klenin: This way, you can develop much faster, without the need to fight for your changes, Others call this fighting review and consider it as important part to improve software quality. I'd say there is a continuum between those extremes, and (unfortunately) from my point of vew, FPC review is sometimes rather close to the former. I have been burned by this myself. Anyway, what I suggest is IMO a good compromise and should satisfy both sides -- Felipe can continue development of his packages unobstucted, while the quality of FPC will not suffer. I do not really see any downsides -- perhaps there is a section of users who use FPSpreadsheet and NOT use Lazarus, but I suspect this section is very small. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
Am 03.10.2011 15:32, schrieb Alexander Klenin: On Mon, Oct 3, 2011 at 22:40, Florian Klämpflflor...@freepascal.org wrote: Am 03.10.2011 13:23, schrieb Alexander Klenin: This way, you can develop much faster, without the need to fight for your changes, Others call this fighting review and consider it as important part to improve software quality. I'd say there is a continuum between those extremes, and (unfortunately) from my point of vew, FPC review is sometimes rather close to the former. FPC has to fit the need of a lot of users so we must be very carefull what we add and what not. Everything we add and which goes into a release must be maintained. We cannot easily kill packages if a maintainer disappears or if the functionality is already in base units. Unicode support is currently under heavy reconstruction so it's not a good idea to add new packages for unicode. Anyway, what I suggest is IMO a good compromise and should satisfy both sides -- Felipe can continue development of his packages unobstucted, while the quality of FPC will not suffer. That's why I proposed a branch and that's what branches are for. For example a TString* class for UTF-8 might even go into classes. But this needs to be done carefully. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
03.10.2011 21:32, Alexander Klenin wrote: I'd say there is a continuum between those extremes, and (unfortunately) from my point of vew, FPC review is sometimes rather close to the former. I have been burned by this myself. When? Anyway, what I suggest is IMO a good compromise and should satisfy both sides -- Felipe can continue development of his packages unobstucted, while the quality of FPC will not suffer. As I remember there is a package lnet which can be somehow installed via internet. I don't remember the details but I believe I've seen this a half year ago or so. Why fpspreadsheet and fpverctorial together with new utf8 package can't be follow this way of distributing? Those users who need them can install then using some fp package install utility. I also don't see the big need for hosting the majority of FPC packages in the FPC svn repository. Why not to leave there only the basic things like windows, osx, gtk and other platform packages and to remove everything else outside? Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Mon, Oct 3, 2011 at 3:49 PM, Paul Ishenin webpi...@mail.ru wrote: As I remember there is a package lnet which can be somehow installed via internet. I don't remember the details but I believe I've seen this a half year ago or so. Why fpspreadsheet and fpverctorial together with new utf8 package can't be follow this way of distributing? Not a solution for the utf-8 package because then Lazarus would not be able to use it easily. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On 03 Oct 2011, at 15:49, Paul Ishenin wrote: As I remember there is a package lnet which can be somehow installed via internet. I don't remember the details but I believe I've seen this a half year ago or so. Why fpspreadsheet and fpverctorial together with new utf8 package can't be follow this way of distributing? lnet is only a test package for that functionality. It hasn't been opened yet in general. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Mon, Oct 3, 2011 at 3:42 PM, Florian Klämpfl flor...@freepascal.org wrote: That's why I proposed a branch and that's what branches are for. So far we had two against and one maybe a small part of it ... seriously I think it is unrealistic to expect that if there is virtually no support from fpc developers for the proposal now, if I would implement it in a branch, then support for this would magically build up. I think we should agree to disagree: Let's delete fpvectorial from FPC, I'll export it into lazarus/components/fpvectorial and we move our separate ways. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Tue, Oct 4, 2011 at 00:42, Florian Klämpfl flor...@freepascal.org wrote: Anyway, what I suggest is IMO a good compromise and should satisfy both sides -- Felipe can continue development of his packages unobstucted, while the quality of FPC will not suffer. That's why I proposed a branch and that's what branches are for. No, the branches (in svn, at least) are for code that is an alternative/in-progress imlpementation of some features, not for features rejected from the main branch. For example a TString* class for UTF-8 might even go into classes. But this needs to be done carefully. There is, again, a continuum between careful development and stangation. While acknowledging great work that FPC team has done on the former, I'd venture to say that is came uncomfortably close to the latter. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Tue, Oct 4, 2011 at 01:01, Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote: I think we should agree to disagree: Let's delete fpvectorial from FPC, I'll export it into lazarus/components/fpvectorial and we move our separate ways. +1 Among other things, this will simplify management of TAChart's fpvectorial back-end ;-) -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
Am 03.10.2011 16:06, schrieb Alexander Klenin: On Tue, Oct 4, 2011 at 00:42, Florian Klämpflflor...@freepascal.org wrote: Anyway, what I suggest is IMO a good compromise and should satisfy both sides -- Felipe can continue development of his packages unobstucted, while the quality of FPC will not suffer. That's why I proposed a branch and that's what branches are for. No, the branches (in svn, at least) are for code that is an alternative/in-progress imlpementation of some features, Well, I consider an utf-8 package as an alternative/in-progress implementation to the current wip on unicode support. not for features rejected from the main branch. If you like, we can also create svn.freepascal.org/svn/fpc/stagging ;) I don't see it as rejected, see e.g. also MvC's mail. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Tue, Oct 4, 2011 at 00:49, Paul Ishenin webpi...@mail.ru wrote: 03.10.2011 21:32, Alexander Klenin wrote: I'd say there is a continuum between those extremes, and (unfortunately) from my point of vew, FPC review is sometimes rather close to the former. I have been burned by this myself. When? To avoid re-starting old flame, I'll send you an example privately. I also don't see the big need for hosting the majority of FPC packages in the FPC svn repository. Why not to leave there only the basic things like windows, osx, gtk and other platform packages and to remove everything else outside? There is also a balance there -- while I agree that currently FPC has some obvoiusly unneeded packages (a52/dts for example), there are some benefits for both users and developers when using a common repository. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] building fpc / fpmake and multicore cpu ?
On Sat, 2011-10-01 at 09:24 +0100, Martin wrote: I noticed, when I build fpc, then I get cpu usage between 70% and 100%. So it appears that both cores of my pentium are used. But when a package is compiled using fpmake, then it drops to 50%, so apparently only one core is used? Is that correct? Does the old Makefile driven compilation use both/all cores, while packages done via fpmake, are using one core only? Not completely, when you use 'make -Jx' with x1 then the old makefiles can use multiple threads to actually compile. But it could be that some overhead is done in a second thread? As fpmake is now used in trunk the biggest disadvantage is that for each unit that is compiled a instance of the compiler is invoked. If you add '-bu' to the fpmake commandline, it outperforms the 'older' makefiles. There's also a multi-threaded version of fpmake, but that's not comitted yet. Joost -- My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On Sat, 2011-10-01 at 10:26 +0200, Florian Klämpfl wrote: Am 30.09.2011 15:02, schrieb Joost van der Sluis: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip Did you get also a libgdb.a which you could provide for the fpc ide? No. I don't know how to build a libgdb.a. I'll look into it later. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] New Windows gdb-binary
On Sat, 2011-10-01 at 11:00 +0200, Pierre Free Pascal wrote: Did you use the mingw 7.3 patch that handles the windows style path containing ':'? No. I recreated the patch below by doing a diff from official GDB 7.3 release and mingw7.3.2 sources. Without this, debug information containing drive letters are wrongly cut into parts at the ':' position... Thanks. That was one of the issues I still had, without a clue how to fix it. Can you also think about this problem: http://www.cygwin.com/ml/gdb/2011-10/msg3.html Because I've got this problem now at two places (two different warnings) already. The second warning is also in stock-fsf-gdb. I can't imagine that the official GDB 7.3 also has this problem with nul-parameters and fprintf. Joost -- My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On 03 Oct 2011, at 16:06, Alexander Klenin wrote: There is, again, a continuum between careful development and stangation. While acknowledging great work that FPC team has done on the former, I'd venture to say that is came uncomfortably close to the latter. I think http://wiki.freepascal.org/FPC_New_Features_Trunk looks quite good. Apart from that, I agree with the sentiment that it does not make sense trying to stuff everything and the kitchen sink under the FPC umbrella. Everything that's distributed that way automatically becomes the responsibility of the core developers of the day, and that collection of source code has grown much faster than the number of people maintaining it (and in a number of cases, maintainers have also disappeared). So distributing packages separately generally indeed makes much more sense for everyone (more flexibility for the maintainer, less responsibility and stagnation risk for the FPC project due to additional responsibilities). And in this particular case, there does remain the fact that the cpstrnew adaptations are far from finished and that part of the functionality in this utf-8 package may well become part of the RTL or FCL. If there is then also a separate utf-8 package used by fpvectorial, and possibly also by user programs, you can bet that people would (understandably) complain if functionality is then removed from this utf-8 package to prevent code and maintenance duplication. That's also why Florian mentioned the branch: does not cause wrong expectations (users won't start using that package), the code is available in svn and therefore it can be used for finishing the cpstrnew work where appropriate, and before/when merging to trunk we can first look at what should be removed or changed to prevent duplication of functionality. But again: as a non-FPC package you indeed avoid this overhead and the uncertainty that when the time merging arrives, you won't be able to merge everything you want. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] New Windows gdb-binary
On Mon, 2011-10-03 at 16:40 +0200, Pierre Free Pascal wrote: -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Joost van der Sluis Envoyé : lundi 3 octobre 2011 16:29 À : FPC developers' list Objet : RE: [fpc-devel] New Windows gdb-binary On Sat, 2011-10-01 at 11:00 +0200, Pierre Free Pascal wrote: Did you use the mingw 7.3 patch that handles the windows style path containing ':'? No. I recreated the patch below by doing a diff from official GDB 7.3 release and mingw7.3.2 sources. Without this, debug information containing drive letters are wrongly cut into parts at the ':' position... Thanks. That was one of the issues I still had, without a clue how to fix it. Can you also think about this problem: http://www.cygwin.com/ml/gdb/2011-10/msg3.html Because I've got this problem now at two places (two different warnings) already. The second warning is also in stock-fsf-gdb. I can't imagine that the official GDB 7.3 also has this problem with nul-parameters and fprintf. Use this new macro: $ cvs diff -u -p gdbtypes.h Index: gdbtypes.h === RCS file: /cvs/src/src/gdb/gdbtypes.h,v retrieving revision 1.153 diff -u -p -r1.153 gdbtypes.h --- gdbtypes.h 5 Jul 2011 13:36:41 - 1.153 +++ gdbtypes.h 3 Oct 2011 14:39:08 - @@ -1115,6 +1115,11 @@ extern void allocate_gnat_aux_type (stru || TYPE_NFN_FIELDS (thistype) == 0) \ (TYPE_STUB (thistype) || !TYPE_STUB_SUPPORTED (thistype))) +/* A helper macro that returns the name of a type or unnamed type if the type + has no name. */ +#define TYPE_SAFE_NAME(type) \ + (TYPE_NAME (type) ? TYPE_NAME (type) : _(unnamed type)) + /* A helper macro that returns the name of an error type. If the type has a name, it is used; otherwise, a default is used. */ #define TYPE_ERROR_NAME(type) \ roflol. Take a good look at this patch. Especially the last few lines... I'll use TYPE_ERROR_NAME. Thanks for the hint. ;) Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
Am 03.10.2011 16:23, schrieb Joost van der Sluis: On Sat, 2011-10-01 at 10:26 +0200, Florian Klämpfl wrote: Am 30.09.2011 15:02, schrieb Joost van der Sluis: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip Did you get also a libgdb.a which you could provide for the fpc ide? No. I don't know how to build a libgdb.a. I'll look into it later. Afaik it is generated by default. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Windows gdb-binary
On Mon, 2011-10-03 at 19:27 +0200, Florian Klämpfl wrote: Am 03.10.2011 16:23, schrieb Joost van der Sluis: On Sat, 2011-10-01 at 10:26 +0200, Florian Klämpfl wrote: Am 30.09.2011 15:02, schrieb Joost van der Sluis: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip Did you get also a libgdb.a which you could provide for the fpc ide? No. I don't know how to build a libgdb.a. I'll look into it later. Afaik it is generated by default. You are right. I included it in this new version: http://www.lazarussupport.com/gdb_lazarussupport_20111003b.zip The libgdb.a file is not tested whatsoever, so I can't tell if it works. The zipfile also contains some instructions how to build it, and all the changes compared to the Archer branch on which is it was based. This version includes some fixes for the several crashes that Martin encountered and the changes for the Windows-paths that Pierre mailed. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Tue, 4 Oct 2011, Alexander Klenin wrote: On Tue, Oct 4, 2011 at 00:42, Florian Klämpfl flor...@freepascal.org wrote: Anyway, what I suggest is IMO a good compromise and should satisfy both sides -- Felipe can continue development of his packages unobstucted, while the quality of FPC will not suffer. That's why I proposed a branch and that's what branches are for. No, the branches (in svn, at least) are for code that is an alternative/in-progress imlpementation of some features, not for features rejected from the main branch. For example a TString* class for UTF-8 might even go into classes. But this needs to be done carefully. There is, again, a continuum between careful development and stangation. While acknowledging great work that FPC team has done on the former, I'd venture to say that is came uncomfortably close to the latter. I'd venture to disagree. Attached is a small graph from the bugtracker activity. As you can see, the bugfix rate remains constant, which refutes 'stagnation'. We do work, even if it is not so 'visible'. Many things are not even in this graph, as Jonas pointed out with his WIKI link. The difficulty is: The more code there is, the more it must be maintained. The team does not grow at the same rate as the lines of code in the files we distribute, meaning that virtually the same amount of people must maintain more code. Now, to counter the perception of stagnation, you can help: I suspect faster release schedules could help to counter this perception. So: Please help us working on fppkg, which should allow a much more free release schedule for FPC, and especially for the packages. Using fppkg as a distribution mechanism would release the FPC team from the need to maintain everything in the FPC subversion. People could add packages to the repository, and release updates of their packages at will. Slowly, we (mainly Joost, in fact) are converting the FPC packages to this new mechanism, fixing bugs as we go along. You can help by testing this, and converting more packages to the new fppkg. Michael.attachment: activity.png___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On Tue, Oct 4, 2011 at 08:48, Michael Van Canneyt mich...@freepascal.org wrote: There is, again, a continuum between careful development and stangation. While acknowledging great work that FPC team has done on the former, I'd venture to say that is came uncomfortably close to the latter. I'd venture to disagree. Attached is a small graph from the bugtracker activity. As you can see, the bugfix rate remains constant, which refutes 'stagnation'. We do work, even if it is not so 'visible'. As I said, I did not ever deny you work, of course you do. Still, steady bugfixing and dymanic evolution are not quite the same, although related. Now, to counter the perception of stagnation, you can help: Please help us working on fppkg Looking at the bugtracker, I found a single non-assigned issue #18321, which talks about some webdesign package I know nothing about. So I where can I look at the todo-list? Slowly, we (mainly Joost, in fact) are converting the FPC packages to this new mechanism, fixing bugs as we go along. You can help by testing this, and converting more packages to the new fppkg. Perhaps I can take care of a single package -- for example, numlib improvement was discussed recently on the forum. However, I am afraid my work will be rejected again as was the case with fpdoc. So I'd consider working on numlib (+ math unit, which is obviously closely related), if I'd get either commit access or somebody who will timely commit my patches. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
