Re: [fpc-devel] Macro Processing
Op Sat, 14 May 2011, schreef Joerg Schuelke: 2) This is the solution? Making the compiler to store somewhere a string representation in my object file and then give it back to me if I request it by str(enumerate)??? All types (not just enums) have runtime type information that is stored in the object file. Runtime type information is very powerfull and has many applications, for example memory management for automatic types, or the population of a TForm with data entered in the GUI in Lazarus. Converting an enum to a string is another application of runtime type information. Thats so completely ... overhead, with a cannon to shoot a sparrow. There is no overhead because any unused RTTI is removed when smartlinking. Since when has an enumeration such kind of name, which lives outside compile time? RTTI is quite old already, but the compiler can convert between enums and strings since version 2.3. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
On Sat, 14 May 2011, Joerg Schuelke wrote: Am Sat, 14 May 2011 00:36:17 +0200 schrieb Jonas Maebe : 1) the compiler automatically makes you keep them in sync, because adding/removing an element form the enumeration will cause a compilation error for the array if it's not updated 2) the array can actually be removed at some time in the future, because FPC can nowadays convert enumerations to their their name in string representation (via str(), write() and writestr()). There are still some bugs in this functionality in 2.4.x on some platforms though, so it can't be used yet in the compiler 2) This is the solution? Making the compiler to store somewhere a string representation in my object file and then give it back to me if I request it by str(enumerate)??? Thats so completely ... overhead, with a cannon to shoot a sparrow. Since when has an enumeration such kind of name, which lives outside compile time? Since always as soon as you use str() on it, or if it is in RTTI somewhere. How do you think streaming works ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Latest SVN - make clean gives error in /packages/fppkg
Latest FPC SVN "make clean" results in: . . . make -C fppkg distclean make[2]: Entering directory `/fpc_svn/packages/fppkg' make[2]: *** No rule to make target `distclean'. Stop. make[2]: Leaving directory `/fpc_svn/packages/fppkg' make[1]: *** [fppkg_distclean] Error 2 make[1]: Leaving directory `/fpc_svn/packages' make: *** [packages_distclean] Error 2 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Latest SVN - make clean gives error in /packages/fppkg
Fixed. Michael. On Fri, 13 May 2011, ABorka wrote: Latest FPC SVN "make clean" results in: . . . make -C fppkg distclean make[2]: Entering directory `/fpc_svn/packages/fppkg' make[2]: *** No rule to make target `distclean'. Stop. make[2]: Leaving directory `/fpc_svn/packages/fppkg' make[1]: *** [fppkg_distclean] Error 2 make[1]: Leaving directory `/fpc_svn/packages' make: *** [packages_distclean] Error 2 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 01:23:08 +0200 schrieb Joerg Schuelke : > A third one. > > It is a further single and isolated solution to prevent the use of a > macro. How many of them are there around? A hundert, a thousand in 5 > years? > I will explain what is the problem with this. If I have a similar problem, a list of function names and somewhere else in my code a list of their names, would then be the answer to change the compiler, to make him give me the name of a procedure if I do str(proc)? And on and on.. I think nobody would say that, but it sounds a little like this. Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
In our previous episode, Joerg Schuelke said: > > some bugs in this functionality in 2.4.x on some platforms though, so > > it can't be used yet in the compiler > > 2) This is the solution? Making the compiler to store somewhere a > string representation in my object file and then give it back to me if > I request it by str(enumerate)??? Thats so completely ... overhead, Not really, if the RTTI is too slow for you, simply generate the array once on startup. (disclaimer I actually never have tested RTTI speed) > Since when has an enumeration such > kind of name, which lives outside compile time? Delphi: afaik always. It is a result of its form loading concept. The object inspector must be able to enumerate the various options for the combobox. FPC: pretty soon after Delphi compat was started; 1998ish. 0.99.10 or 0.99.12 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am 14.05.2011 01:23, schrieb Joerg Schuelke: > A third one. > > It is a further single and isolated solution to prevent the use of a > macro. How many of them are there around? A hundert, a thousand in 5 > years? It simply shows that in a modern programming language macros has few real use cases because there are a lot of other constructs which serve a similiar purpose. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Op Sat, 14 May 2011, schreef Marco van de Voort: 2) This is the solution? Making the compiler to store somewhere a string representation in my object file and then give it back to me if I request it by str(enumerate)??? Thats so completely ... overhead, Not really, if the RTTI is too slow for you, simply generate the array once on startup. (disclaimer I actually never have tested RTTI speed) It ain't slow at all. I think it beats many quick and dirty manual conversion solutions in speed and/or memory consumption. Maybe if you use it in an inner loop you may want your own code. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am 14.05.2011 00:06, schrieb Joerg Schuelke: > > A macro processor is the simplest way to generate such pieces of source > code. If it is that simple doing it another way you say, why can I > find in the compiler sources more then one example of this. Because a lot of code in the compiler is very old (remember, it was started in 1993 using TP) and writestr for enums is new compare with this time span. Nobody rewrote the code yet. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fppkg question
On Fri, 2011-05-13 at 13:18 +0200, Michael Van Canneyt wrote: > > On Fri, 13 May 2011, Darius Blaszyk wrote: > > > > > On May 13, 2011, at 1:01 PM, Michael Van Canneyt wrote: > > > >> > >> > >> On Fri, 13 May 2011, Darius Blaszyk wrote: > >> > > All this info is supposed to be output in XML format from fpmake > > --manifest. fppkg picks it up and stores it in the repository. > > > > If you want to extend it to include a category and keywords, be my > > guest. > > Thanks, that was the class indeed I was looking for to extend. > >>> > >>> I created a patch here: http://bugs.freepascal.org/view.php?id=19348 > >>> > >>> Please review and commit if approved. > >> > >> Please rework the patch. I don't want the Error->ErrorFmt, Log->logFmt > >> changes. > >> The overloaded versions exist on purpose. > > What is the alternative then? Any suggestion? > > Never mind. I fixed it myself. Rev 17440. I don't like the 'laz_list' exception in pkghandler.pp. I don't want any third-party-dependent code in fppkg. And binding on a specific name isn't fine either. fppkg should be for general use, if you need something special, use an add-in. In this case it is probably also possible to come up with another solution. (why is it for, anyway?) Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Florian Klämpfl schrieb: It simply shows that in a modern programming language macros has few real use cases because there are a lot of other constructs which serve a similiar purpose. ACK Nonetheless I wonder which efforts had to be made, to mimic only some of the many macro usages. While named constants deserve not much compiler code, what about: - overloaded procedures - inline procedures - templates - generics All that could already be implemented by macros, since the invention of C and its preprocessor. How long will we have to wait for further replacements in Pascal? IMO macros with arguments are not so hard to implement like beforementioned features, require no changes to the language syntax, and they will not slow down the compiler (if not used). Now give me any reasonable argument, why it should not be *allowed* to extend the compiler accordingly. The implementation can be provided by the community, as usual. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am 14.05.2011 14:43, schrieb Hans-Peter Diettrich: > Florian Klämpfl schrieb: > >> It simply shows that in a modern programming language macros has few >> real use cases because there are a lot of other constructs which serve a >> similiar purpose. > > ACK > > Nonetheless I wonder which efforts had to be made, to mimic only some of > the many macro usages. It's only a side effect that it reduces macro use cases. > Now give me any > reasonable argument, why it should not be *allowed* to extend the > compiler accordingly. Look at the bug count graph (important part attached, one gray line is 100 open bugs) and you will see that we're currently even not able due to lacking resources to maintain the current features so any new feature makes this worse without more people doing the dirty work of bug fixing. That's why I'am currently very carefull with new featuers. <>___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 12:14:52 +0200 schrieb Florian Klämpfl : > Because a lot of code in the compiler is very old (remember, it was > started in 1993 using TP) and writestr for enums is new compare with > this time span. Nobody rewrote the code yet. And it should not been rewritten this way, because this would force the use of RTTI information inside the compiler , which is needless. Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am 14.05.2011 15:07, schrieb Joerg Schuelke: Am Sat, 14 May 2011 12:14:52 +0200 schrieb Florian Klämpfl: Because a lot of code in the compiler is very old (remember, it was started in 1993 using TP) and writestr for enums is new compare with this time span. Nobody rewrote the code yet. And it should not been rewritten this way, because this would force the use of RTTI information inside the compiler , which is needless. Since the compiler uses classes, it uses rtti already heavily so I miss the point. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 15:12:46 +0200 schrieb Florian Klaempfl : > Since the compiler uses classes, it uses rtti already heavily so I > miss the point. OK, you need the RTTI for simple storing and recovering the informations to ppu files or whatever, thats a point to use it. Under normal circumstances I would say, you should not use classes too. Use objects. Or only one of them, classes or objects. And now you have properties inside the compiler, maybe someday interfaces too. Do not misunderstand this! I mean only that the incorporation of features in the compiler is part of the problem and not of the solution. First of all in respect of the bug fixing problem you mention in your answer to Hans-Peter. Thats kind of an unsolvable problem, a discussion may help from time to time. I will not bore you with this I think you will think about that a hundert times, while I do it one times. with regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 14:36:33 +0200 schrieb Florian Klämpfl : > so any new feature > makes this worse without more people doing the dirty work of bug > fixing. > > That's why I'am currently very carefull with new featuers. I see this point and it is one reason for me to think very careful about: "Is it possible to do it without touching the scanner?" Is the rest interesting enough to make it worth a further thinking. If not, trash it. with regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Op Sat, 14 May 2011, schreef Joerg Schuelke: Am Sat, 14 May 2011 12:14:52 +0200 schrieb Florian Klämpfl : Because a lot of code in the compiler is very old (remember, it was started in 1993 using TP) and writestr for enums is new compare with this time span. Nobody rewrote the code yet. And it should not been rewritten this way, because this would force the use of RTTI information inside the compiler , which is needless. It's not needless, it's usefull :) This code: type colour=(red,green,blue); begin writeln(red); writeln(green); writeln(blue); end; ... will cause 52 bytes of RTTI data to be inserted in your executable. Any do-it-yourself solution will consume more space. Therefore the RTTI not only helps to keep the source code compact and therefore readable, it would also help to keep the compiler exe compact. So use of RTTI information inside the compiler is most welcome :) Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 16:29:15 +0200 (CEST) schrieb Daniël Mantione : > ... will cause 52 bytes of RTTI data to be inserted in your > executable. Any do-it-yourself solution will consume more space. > Therefore the RTTI not only helps to keep the source code compact and > therefore readable, it would also help to keep the compiler exe > compact. > > So use of RTTI information inside the compiler is most welcome :) I think of this a little different. Maybe more from an other perspective. For me RTTI is a level of language extension. Like OOP, or generics, or inheritance. Macros are very low level (if you have them). It is not that I think that I would use a macro instead under all circumstances. But it should be possible to do it without RTTI which is of higher level in the language. The principle is do not use it if you do not like it. That should not influence the rest of the language. This way I think that it is not that bad to have a small, but powerful macro expander incorporated. 52 bytes of data. And the RTTI code? What if you do not smartlink? I repeat, I have really nothing against RTTI, but I state that it comes from a high level language extension. Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 17:04:45 +0200 schrieb Joerg Schuelke : > > I repeat, I have really nothing against RTTI, but I state that it > comes from a high level language extension. > By the way this RTTI thing comes from the argument: Do not use a macro, instead do it this way. But this forces me to use RTTI, which is possibly not what I want. Most of the arguments against macros where of this kind. You can do it an other way, using ... But this way I can show you even OOP is useless :) what I do not believe. Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am 14.05.2011 17:30, schrieb Joerg Schuelke: > Am Sat, 14 May 2011 17:04:45 +0200 > schrieb Joerg Schuelke : > >> >> I repeat, I have really nothing against RTTI, but I state that it >> comes from a high level language extension. >> > By the way this RTTI thing comes from the argument: Do not use a > macro, instead do it this way. But this forces me to use RTTI, which is > possibly not what I want. Then you should use C ;) RTTI is something which makes life easier and prevents mistakes. > > Most of the arguments against macros where of this kind. > > You can do it an other way, using ... > > But this way I can show you even OOP is useless :) what I do not > believe. True. But the point is: macros are something rendering code easily unreadable if used wrong and this is not true for OOP. And remember: pascal should always prevent you from shooting yourself into the foot (e.g. from http://www.fullduplex.org/humor/2006/10/how-to-shoot-yourself-in-the-foot-in-any-programming-language/). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Sat, 14 May 2011 17:38:27 +0200
schrieb Florian Klämpfl :
> Am 14.05.2011 17:30, schrieb Joerg Schuelke:
> > Am Sat, 14 May 2011 17:04:45 +0200
> > schrieb Joerg Schuelke :
> >
> >>
> >> I repeat, I have really nothing against RTTI, but I state that it
> >> comes from a high level language extension.
> >>
> > By the way this RTTI thing comes from the argument: Do not use a
> > macro, instead do it this way. But this forces me to use RTTI,
> > which is possibly not what I want.
>
> Then you should use C ;) RTTI is something which makes life easier and
> prevents mistakes.
I do not understand this C argument, I swear I am an pascal man! ;(
Again, nothing against RTTI, but I do not like to be forced to use it.
>
> >
> > Most of the arguments against macros where of this kind.
> >
> > You can do it an other way, using ...
> >
> > But this way I can show you even OOP is useless :) what I do not
> > believe.
>
> True. But the point is: macros are something rendering code easily
> unreadable if used wrong ...
Yea, thats why the explicit expansion of the macros, even the dumbest
can see it is a macro expansion {$expand macro(1,2,3)} the words you
suggests.
By the way the RTTI approach do not solve the problem, if there is one,
we did not see that:
enum(en1,en2,en3,...);
...
strarr:array[...] of shortstring={
str(en1),
str(en2),
...
}
does only half of the work. You have to keep them in sync furthermore,
see the order.
Sometimes we shoot a little to quick, so do I, sorry for that.
Regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am 14.05.2011 19:02, schrieb Joerg Schuelke:
> I do not understand this C argument, I swear I am an pascal man! ;(
> Again, nothing against RTTI, but I do not like to be forced to use it.
What's wrong with it?
> By the way the RTTI approach do not solve the problem, if there is one,
> we did not see that:
>
> enum(en1,en2,en3,...);
>
> ...
>
> strarr:array[...] of shortstring={
> str(en1),
> str(en2),
>...
> }
>
> does only half of the work. You have to keep them in sync furthermore,
> see the order.
The idea is to get completly rid of strarr because the typical use case
is like s:=strarr[en]; which can be replaced e.g. by writestr(s,en);
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Op Sat, 14 May 2011, schreef Joerg Schuelke: I think of this a little different. Maybe more from an other perspective. For me RTTI is a level of language extension. Like OOP, or generics, or inheritance. Macros are very low level (if you have them). RTTI *allows* for language extensions, like str/val for enums. RTTI by itself are just data structures describing Pascal types, emitted automatically by the compiler. Language extensions can use those data structures to provide their functionality. It is not that I think that I would use a macro instead under all circumstances. But it should be possible to do it without RTTI which is of higher level in the language. I still don't see why it should be possible to do it without RTTI. But the question is, is the unknown reason that you don't want to use str a justification for adding the can of worms that is called macro's? The principle is do not use it if you do not like it. That should not influence the rest of the language. This way I think that it is not that bad to have a small, but powerful macro expander incorporated. It's not that bad, but it should make something possible. Until now I haven't seen many bright examples of things that cannot be elegantly without macro's. 52 bytes of data. And the RTTI code? Not much. Converting an enum to a string is a single procedure. It's quickly won back if you use the feature a few times. Actually this is a nice story about the hidden costs of language features. The procedure would be extremely simple (lookup a pointer to the string in an array, return the string), but FPC supports non sequential enums: type colour=(red:=1,green:=10,blue:=100); The majority of the code in the procedure that converts an enum to a string deals with handling this special situation (don't worry: normal enums are still a simple lookup). Often when you add features, it has unforseen consequences and it can be a complicated effort to make everything together well enough. This is why you want to be carefull adding new features. What if you do not smartlink? Then you get so much extra code in your exe that the RTTI is still a small and irrelevant portion. Actually in the past you could disable RTTI generation, but it was too sensitive for bugs. Removing unused code & data is the task of the linker, we decided to make the linker do what it is designed for. I repeat, I have really nothing against RTTI, but I state that it comes from a high level language extension. Good. By the way this RTTI thing comes from the argument: Do not use a macro, instead do it this way. But this forces me to use RTTI, which is possibly not what I want. H... For the same reasoning you could say inline functions are ugly and you want not to be forced to use inlining. The point is that every time you can avoid a macro you win on code clarity, compiler speed (no time spent on evaluation & expansion), debugability, parsability by IDE's, and so on. Inlining is better that doing the same with macro's, so is the use of str/val better than macro tricks. We don't want to force you to use RTTI, but our point is that there is proper solution to achieve the same benefit that the macro approach gives. But this way I can show you even OOP is useless :) what I do not believe. While I do believe in the merit of OOP, there are many dubious OOP features that you can criticize in a valid way, escpially because few of those features open new possibilities. But unfortunately it's a waste of time; we need this for compatibility. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Latest FPC SVN , package fpmkunit crosscompiling failure
Latest FPC SVN 17459: Doing a "make all OS_TARGET=win64 CPU_TARGET=x86_64" crosscompiling with 32bit FPC gives the following error: = make -C fpmkunit bootstrap make[3]: Entering directory `c:/fpc_svn/packages/fpmkunit' C:/pp/bin/i386-win32/gmkdir.exe -p units_bs/i386-win32 C:\pp\bin\i386-win32\ppcrossx64.exe src/fpmkunit.pp -n -Fuc:/fpc_svn/rtl/units/i386-win32 -Fuc:/fpc_svn/packages/hash -Fuc:/fpc_svn/packages/paszlib -Fuc:/fpc_svn/packages/fcl-process -dNO_UNIT_PROCESS -dNO_UNIT_ZIPPER -FUunits_bs/i386-win32 PPU Loading C:\fpc_svn\rtl\units\i386-win32\system.ppu PPU is compiled for another processor Fatal: Can't find unit system used by fpmkunit Fatal: Compilation aborted make[3]: Leaving directory `c:/fpc_svn/packages/fpmkunit' make[2]: Leaving directory `c:/fpc_svn/packages' make[1]: Leaving directory `c:/fpc_svn' = units_bs ?? In any case, cant crosscompile FPC at the moment. AB ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fppkg question
On May 14, 2011, at 12:26 PM, Joost van der Sluis wrote: > On Fri, 2011-05-13 at 13:18 +0200, Michael Van Canneyt wrote: >> >> On Fri, 13 May 2011, Darius Blaszyk wrote: >> >>> >>> On May 13, 2011, at 1:01 PM, Michael Van Canneyt wrote: >>> On Fri, 13 May 2011, Darius Blaszyk wrote: >>> All this info is supposed to be output in XML format from fpmake >>> --manifest. fppkg picks it up and stores it in the repository. >>> >>> If you want to extend it to include a category and keywords, be my >>> guest. >> >> Thanks, that was the class indeed I was looking for to extend. > > I created a patch here: http://bugs.freepascal.org/view.php?id=19348 > > Please review and commit if approved. Please rework the patch. I don't want the Error->ErrorFmt, Log->logFmt changes. The overloaded versions exist on purpose. >>> What is the alternative then? Any suggestion? >> >> Never mind. I fixed it myself. Rev 17440. > > I don't like the 'laz_list' exception in pkghandler.pp. I don't want any > third-party-dependent code in fppkg. And binding on a specific name > isn't fine either. fppkg should be for general use, if you need > something special, use an add-in. > In this case it is probably also possible to come up with another > solution. (why is it for, anyway?) As far as I found, the "list" action get's cached in the ExecuteActions and if found the action is not executed, but rather the action is ignored. While perfectly suitable for fppkg which is only run once though and then exits, the GUI version stays active and can run the same actions multiple times. This makes me think that I should probably create a Laz_ExecuteAction procedure and keep the original procedure in tact. I will create a patch for it. Regards, Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Latest FPC SVN , package fpmkunit crosscompiling failure
On Sat, 2011-05-14 at 11:47 -0700, ABorka wrote: > Latest FPC SVN 17459: > Doing a "make all OS_TARGET=win64 CPU_TARGET=x86_64" crosscompiling with > 32bit FPC gives the following error: > > = > make -C fpmkunit bootstrap > make[3]: Entering directory `c:/fpc_svn/packages/fpmkunit' > C:/pp/bin/i386-win32/gmkdir.exe -p units_bs/i386-win32 > C:\pp\bin\i386-win32\ppcrossx64.exe src/fpmkunit.pp -n > -Fuc:/fpc_svn/rtl/units/i386-win32 -Fuc:/fpc_svn/packages/hash > -Fuc:/fpc_svn/packages/paszlib -Fuc:/fpc_svn/packages/fcl-process > -dNO_UNIT_PROCESS -dNO_UNIT_ZIPPER -FUunits_bs/i386-win32 > PPU Loading C:\fpc_svn\rtl\units\i386-win32\system.ppu > PPU is compiled for another processor > Fatal: Can't find unit system used by fpmkunit > Fatal: Compilation aborted > make[3]: Leaving directory `c:/fpc_svn/packages/fpmkunit' > make[2]: Leaving directory `c:/fpc_svn/packages' > make[1]: Leaving directory `c:/fpc_svn' > = > > units_bs ?? > > In any case, cant crosscompile FPC at the moment. Compile again, without make clean. That will help. See bug 19263. Or add PP=compiler_name Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Joerg Schuelke schrieb: I see this point and it is one reason for me to think very careful about: "Is it possible to do it without touching the scanner?" Is the rest interesting enough to make it worth a further thinking. If not, trash it. The macro definition and expansion has to be changed. Macro definition has to handle the formal parameter list, and this added code will execute only when a parameter list is present. Macro expansion will have to deal with the actual parameter list, also only when such a macro is used. With proper separation of old and new macro handling (with/out parameters), the new code again only executes when new macros are used in the code. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Florian Klämpfl schrieb: Look at the bug count graph (important part attached, one gray line is 100 open bugs) and you will see that we're currently even not able due to lacking resources to maintain the current features so any new feature makes this worse without more people doing the dirty work of bug fixing. Any thoughts about extending resources? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
On 13.05.2011 15:55, Hans-Peter Diettrich wrote: Traditional Pascal added compiler directives, hidden inside comments. It's only a matter of performance, whether these directives should be handled immediately at detection of a comment, or after a comment has been fully recognized (skipped) by the scanner. Conditional compilation also can be implemented outside the scanner, with optional feedback instructing the scanner to *not* apply special processing to tokens which are skipped by conditional directives. Include directives require more support in the scanner, which then must be capable of switching between multiple input streams. Macros can be implemented in the same way, but it will be more efficient to Record and Replay token streams instead of character streams. This recorder also can be implemented outside the scanner, an according filter will either return a previously recorded token, or else it asks the scanner for the next token. There is already a token recorder/replayer: the one that is used for generics. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
