Re: [fpc-devel] Re: FPC related fairy tale
On Fri, Oct 19, 2012 at 11:25 AM, Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk wrote: Yes, a IIIe I scrounged. I believe there's a Pascal compiler for it but I've never tried running it. I believe that the Palms were at one time popular as a brain for mobile robot experiments, programmed using a larger system and orchestrating commands to microcontrollers. You're probably talking about PocketStudio ( http://en.wikipedia.org/wiki/PocketStudio). When they appear I semi-automatically ported my ReadThemAll reader for PalmOS from C to their flavor of Pascal. Worked well. Interestingly they still offer the product as I see (http://www.winsoft.sk/pstudio.htm). Pity PalmOS is dead, otherwise it would be reasonable to suggest some kind of compatibility between fpc and PocketStudio. Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
On Thu, Sep 1, 2011 at 1:13 AM, Sven Barth pascaldra...@googlemail.com wrote: I'll try to improve the unit names of the android unit and its dependencies a bit and then it might become the first package for FPC-JVM ;) Sven, thanks for your tests. Adding hwfpo (Hello World From Pascal Only) and simple step-by-step instructions how to compile it also would be nice :) Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On Sat, Aug 20, 2011 at 12:49 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: There is a new branch in svn (branches/jvmbackend) that contains support for compiling Pascal code into Java virtual machine bytecode. While it does not support all language constructs and while there are some differences in some features that are supported, in general the result is fairly close to normal Pascal you'd write. Great new indeed! Just curious, is there an example program in pascal for jvm that can be compiled and seen in action? I checked out tests, but looking at random ones, they looks like console mode ones testing different rtl aspects. I'm talking about maybe a simplest one for example drawing a rectangle at the center of the window. Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On Thu, Aug 18, 2011 at 1:57 AM, Graeme Geldenhuys graemeg.li...@gmail.comwrote: On 15 August 2011 10:48, Michael Schnell wrote: I never tried this, but I feel that IDEs (integrating code editor, GUI designer, make process, and debugger) have been invented for a purpose. I agree with all except the gui designer part. Layout Managers are by far the better choice compared to something like Delphi or Lazarus or MSEgui and even fpGUI's UI Designer gives. Java hit the nail on the head. Why define a UI with co-ordinates, then sit with problems like overlapping components, components that don't scale, locked to a specific DPI etc. For my projects in Delphi I did this with a control that was inspired by table layouts of HTML (I called it TControlAligner, it is a TGraphicControl descendant without own drawing, its bounds are used as a container). It has Controls property (TCollection descendant) and direction (vertical/horizontal). Every collection item has a reference to a control on the form (that can be simple control or another TControlAligner) and different properties. The main property of the item that affects the position is Cells which is either weight (equivalent of % of html tables) or pixels, and when all requirements is set and this TControlAligner is placed (or its bounds changed) it does the best it can do with all the requirements of the collections items (as with html tables where cells can require % of the width or exact pixels). Adding new aligners and using it for items of another aligner can build very complex layouts not using direct coordinates at all. Seems like the port of this component works in Lazarus. If the concept is worth considering I can provide the source for further review by the developers. Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On Thu, Aug 18, 2011 at 9:56 PM, Graeme Geldenhuys graemeg.li...@gmail.comwrote: On Thursday, 18 August 2011, Max Vlasov wrote: Adding new aligners and using it for items of another aligner can build very complex layouts not using direct coordinates at all. Seems like the port of this component works in Lazarus. If the concept is worth considering I can provide the source for further review by the developers. MiGLayout went a step further. It is powerful enough to never need nested layout managers. Yet it's still possible to code complex forms with it. I once found a website where somebody took a popular app (I think firefox), and recreated all the forms using MiGLayout, just to show that it is possible and very simple to do, just with MiGLayout and no nesting. :-) I glanced at the quick guide. Actually MiGLayout looks promising, but personally I'd use it if it's implemented with intuitiveness and visual sense in mind. Without doubt they should work and show rendered layout in design-time and all these dock west, gaps etc should be available as a context menu items or maybe some tool buttons. Otherwise if one have to learn the string constraint language, he can fall into the same trap as with regular expressions, I mean if you don't use them on a regular (ironic coincidence) basic, you learn them every time from the start :) Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On Mon, Aug 8, 2011 at 12:49 AM, Florian Klämpfl flor...@freepascal.orgwrote: Am 07.08.2011 18:27, schrieb Jonas Maebe: And I don't understand all this hostility towards Embarcadero. Indeed. People should be happy that there is a pretty large commercial vendor which provides an professional object pascal development environment. Even if one doesn't use it, one should be aware that it really helps to keep pascal (well, they call it Delphi ;)) a living language. Florian, as I suppose, when you started the compiler , it could not be possible to develop a compiler written in pascal without the turbo pascal? So not only the product inspired, it was also a tool to build all other things upon. By the way, is it possible that when Delphi and fpc are now officially friends :) the some official inter-discussion possible before introducing some important things or before changing some things? Or you don't think that it will be useful? Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Sun, Jul 10, 2011 at 12:01 PM, Alexander Klenin kle...@gmail.com wrote: On Sun, Jul 10, 2011 at 18:53, Hans-Peter Diettrich drdiettri...@aol.com wrote: When the meaning of const/constref is documented as kind of a *calling convention*, that allows the compiler to optimize the code, no more discussion is required. constref is a calling convention, but const is not, since it is optimization hint. As you said above, this is the reason why constref was invented in the first place. Although I liked constref at first, I'd rather think that the current behavior is more of a side effect of the current implementation. I see that it was introduce to support well-known c/c++ concept of give me a pointer to the thing and I promise I won't change the thing used in many apis. But since ansistring is not used in any universal api, the compiler currently is free to change the meaning and for example pass not the address of the entry that hold the pointer, but pointer itself. In other words the compiler if free to choose because lazarus/fpc is the only place on earth where the pair constref-ansistring exists (currently). So the constref immunity is just a side effect And returning to the original discussion currently I'd like to look from another point (or maybe just summation of previous thoughts of others). I think that anything passed by reference (pure reference) pose the problem OP described, even if you use current immune constref. For example, when you want to investigate every char of the string you will probably use for i:=1 to Length(Str). As I recall taking length in advance and using it for every step is even the part Wirth's pascal as the requirement. If so, during the loop a callback or just some call shorten the string, the loop will fail almost for sure. Not because unexpectedly the string is invalid, but because the loop expects the string to be longer that it is now. And the problem like this also can be hard to detect. So personally I'd not separate the reference-based problems like this from the problems posed by const. We can blame the compiler for some optimization results (rarely), but we can not blame the programmer who cached the length of the string in a local variable thinking that the string will be same till the end of the function. And imho understanding that referencing can be dangerous in this regard should be a part of knowledge for every programmer. Some good news )... If we look at this, we will see that the problem exists for every data passed by reference in any language. But in contrary to some languages we have a luxury of passing by value not only register-sized data, but also arge data. And to make things even better we have a luxury of having a tricky ansistring with its copy-on-write concept. So for those who appreciate this luxury and afraid of reference-based problems, using passing ansistrings by value is the answer. Remember, it's a luxury ;) Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Mon, Jul 11, 2011 at 4:45 AM, Chad Berchek ad...@vobarian.com wrote: 1. It seems that if a string is a (non-const) local variable it should be safe. I base this on the following reasoning: looks like it's not: procedure TForm1.Button1Click(Sender: TObject); var S: string; procedure SideEffectCall; begin SetLength(S, 0); end; function CalcSomething(const T: string): integer; begin Result:=0; SideEffectCall; MessageDlg(T, mtInformation, [mbOk], 0); // crash here end; begin S:='12345678901234567890'; S:=S + S; CalcSomething(S); end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Sat, Jul 9, 2011 at 4:13 AM, Martin f...@mfriebe.de wrote: On 09/07/2011 00:59, Max Vlasov wrote: On Sat, Jul 9, 2011 at 3:14 AM, Martinf...@mfriebe.de wrote: function CRCConstString(constref Str: string): integer; does what you describ Hmm, it's interesting.. Some observations: - constref is implemented in 2.5.1, right? Unfortunately I can not test it right now in 2.4.2, it refuses to recognize it, but I I want to test it. - In LCL it used only with interfaces and TGuid's, no strings or other structures - there are not much information about constrefs in Lazarus, several posts, the largest part of them is yours, Martin :) so you're probably one of the few who really understand it :) Well the LCL can't use it, if it's trunk only (except if IFDEFed). The LCL should compile with release fpc... See: http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#Constref_parameter_modifier - See difference to normal const is that it must be passed by reference. - Note (same as const) it is described as: This modifier means that the compiler can assume that the parameter is constant The assume means that the requirement for constant-ness goes above that what the compiler can enforce (that is: the compiler can enforce only the local var; but constant implies the value by any means of access) With what the compiler does today (afaik) none-constantness would not cause any harm (yet). Unless you count it as harm (and you should) that future FPC may (= is allowed to) compile your code (without any warning or hint) into an exe that behaves different. Thanks for your notes, Martin. I compiled the trunk fpc (2.5.1) and compile the example with constref function TForm33.CRCConstRef(constref Str: string): integer; var i: integer; begin Result:=0; for i:=1 to Length(Str) do Result:=Result + Ord(Str[i]); end; it worked, also the timing is exactly the same as for PString, so your information (PString = constref Str) is indirectly confirmed. Btw, Chad's example also worked I understand that currently it works also because as you mentioned the compiler doesn't apply special optimization, sure it could. But also it's possible to forbid it for this special case. Since ansistring is a special entity, not present in COM at all, so with regard to standards it can be fully internal decision. Also since there are no consref in Delphi as I suppose, they can't be the authority in this regard :) If everything it taken care of, apart from possibly global switch to do const = constref aliasing, lcl also can gradually (when fpc 2.5.1 becomes requirement) replace const with constref in critical places (for example when probable events can be fired). Sure this can break inheritance, so just a thought to think about. Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Sat, Jul 9, 2011 at 3:14 AM, Martin f...@mfriebe.de wrote: On 09/07/2011 00:09, Max Vlasov wrote: The answer is indirect referencing. it's a workaround that probably will solve the problem, but I must admit that I don't know what is the exact performance price. The compiler when it detects const s: ansistring could switch to passing not the actual address of the string, but the address of the variable that holds it. In other words passing PString instead of string. In this case no reference counting or exception frame is probably created and at the same time, if the used string is reallocated occasionally because of a side change, the code will not fail because it will just automatically use the new modified address. function CRCConstString(constref Str: string): integer; does what you describe Hmm, it's interesting.. Some observations: - constref is implemented in 2.5.1, right? Unfortunately I can not test it right now in 2.4.2, it refuses to recognize it, but I I want to test it. - In LCL it used only with interfaces and TGuid's, no strings or other structures - there are not much information about constrefs in Lazarus, several posts, the largest part of them is yours, Martin :) so you're probably one of the few who really understand it :) If constref is what you said , some quick fix for those who's scary of the current const behavior could be iintroducing a setting in fpc that forces all const to be constrefs. Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Tue, Jul 5, 2011 at 12:39 AM, Chad Berchek ad...@vobarian.com wrote: I've been reading over some of the recent discussion about reference counting problems with const string parameters. I've done some experiments and I believe that the so-called const optimization is a serious flaw, not just a corner case of questionable legitimacy. I have some sample code I will show which should be quite scary. Additionally, this is a security vulnerability. It is also a quiet bug, because it may go undetected for a long time but randomly result in unreproducible crashes. Chad, I see your point, but you're exaggerating a little imho. I tried this with Delphi 5, although the program lived, the string became unusable, contained gardage after, so probably Borland already had this issue many years ago. Don't get me wrong, but if you want to fool the compiler, you will always be able to do this since you're a human and it is just a program :) It's subjective on my side, but If it existed so many years in borland/inprise/embarcadero products and I can not remember my own bug fixes related to something like this, I consider your example more artificial than one might think. But I'm not representative here, and maybe others have other examples. Also, can someone else test this on later delphis? Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Nested register error for procedure passing address
On Tue, Jan 11, 2011 at 1:46 AM, Andrew Brunner andrew.t.brun...@gmail.comwrote: I did read this however, I don't have the option of rewriting all the other implements to my api to declare as nested... http://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_nested_procedure_variables Andrew, don't know whether it will help or not, but I did a nested procs test with fpc 2.5.1, you can read the post here: http://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg22568.html. It seems like adding is nested is required in this case so there is no way to do this only with a define. But I may be wrong Max Vlasov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)
On Wed, Dec 1, 2010 at 6:44 PM, Hans-Peter Diettrich drdiettri...@aol.comwrote: I thing there might be some logical contradictions I'm not aware at the moment, but I think they can be resolved with general oop inheritance logic. My experience with const methods in C++ often resulted in a bunch of cloned methods, with only calls to other non-const methods removed - a maintenance nightmare :-( Just curious, was it a fight with yourself or with someone else's code? Sure I had no experience with const methods, but I just can't imagine how function or procedures intended to caclulate/find/collect some information from the fields and properties of an object can be a problem in this field. One example comes to mind, sometimes developer wants to know how often a method is used, sure in this case there's no easy way to increase a feild of the object. Can you name some other examples? Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] New language feature suggestion (probably not existing in Delphi)
Hi, I thought about OOP recently, as many sometimes wonder that it's not as good as it can be in some areas. For example, the OOP encapsulation is good, but sometimes the developer doesn't track the context completely or makes other bad things related to the hidden nature of encapsulation context. The notion of name the variables with f at the start also speaks itself about these problems. An idea here is to introduce a directive (maybe something else, but directive looks more straightforward), let's call it readonly that forces the method to be able only to read the fields and properties of the object it belongs to and forbid any writing. Sure in this case it only can call only the methods also containing such directive. One of example of possible usage: TBitmap contains PixelFormat, when user changes it, there should be a conversion, but to be more sure that it will be accurate and there are no side effects I'd mark the method for conversion with this directive so it will only read existing properties and create some new one to return in variable passed by reference. With this directive on, any attempt of this method to change the fields related to bits or handle will be stopped by the compiler, also if it tries to call a read/write method, the compiler will also stops. There are others examples that come to mind, all allowing oop programming to be more controlled. I thing there might be some logical contradictions I'm not aware at the moment, but I think they can be resolved with general oop inheritance logic. What do you think? Is anyone aware of similar concept in any other OOP language? Apart from the idea (worth it or not), there's also a question about introducing brand-new features in fpc. Are developers (read Florian :) is open to introducing new features that later possible other parties (read Embarcadero :) will be willing to adapt? Thanks, Max Vlasov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)
On Fri, Nov 26, 2010 at 6:57 PM, Sergei Gorelkin sergei_gorel...@mail.ruwrote: Max Vlasov пишет: Speaking of new features, I remember the bunch of them were introduced with Delphi 1.0 and many of them were inspired by other languages and dialects. I admit that frequent implementing of features like the one I suggested will make fpc more experimental and less solid. So consider it an idea just thrown in the wild to see whether it will survive or not :) This particular idea probably won't survive. In 'unsafe' language with pointers, there's no way to enforce the restriction you suggest. It will only cause annoyance and make people implement 'workarounds'. Sergei, around what code? if implemented, by default all methods read/write. If a developer restricts readonly directive to its own method, it is his own decision. For example, you're writing method Find, you understand that it hasn't change anything in the object state, you apply this directive to help yourself in the future :) if you talk about virtual readonly method someone introduced, it's similar to private section of object, you can love it or hate it, but this features exists (sure sometimes bringing real pain :) restricting usage of this method in other units. Another example, you successfully wrote first version of a method with reaonly directive, you try to change something several months later and one of your changes is try to change a field inside method implementaion, the compiler points out to the restriction and stops. You have two options: beat yourself for this silly change or understand that the state changing is really needed. If the latter, ok, press ctrl-shift-up, and delete reaonly directive, no problem :) Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: New language feature suggestion (probably not existing in Delphi)
On Fri, Nov 26, 2010 at 11:42 AM, Max Vlasov max.vla...@gmail.com wrote: An idea here is to introduce a directive (maybe something else, but directive looks more straightforward), let's call it readonly that forces the method to be able only to read the fields and properties of the object it belongs to and forbid any writing. Sure in this case it only can call only the methods also containing such directive. Also, one note to consider It is know that some of OOP concepts can be implemented with procedural language. For example, pseudo-encapsulation with the records. Ironically, this idea can be implemented using the emulation. Compare procedure MyObjFind(var Rec: TMyObjData) with procedure MyObjFind(const Rec: TMyObjData) the latter is actual readonly emulation, you won't be able to change anything and you won't be able to pass this record by reference to any other procedure Max Vlasov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)
On Fri, Nov 26, 2010 at 9:45 PM, Nikolay Nikolov nick...@users.sourceforge.net wrote: On 11/26/2010 10:42 AM, Max Vlasov wrote: Is anyone aware of similar concept in any other OOP language? Yes, C++ has it: http://duramecho.com/ComputerInformation/WhyHowCppConst.html It's true that it's a little bit messy, but that's pretty much the norm with everything in C++ ;-) Thanks, Nikolay, it's interesting information, when I tried to search before I posted, I didn't use const, only read only so did not find anything. I already see that it never would be implemented the similar way since in contrary to C++ const objects in pascal already can do whatever they want. Also searching now, found a post http://community.freepascal.org:1/bboards/message?message_id=256912forum_id=24082 Where was question about const, but it seems that primary discussion was about optimization, not preventing from occasional modification. Max Vlasov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Tue, Nov 23, 2010 at 10:28 PM, Andrew Brunner andrew.t.brun...@gmail.com wrote: On Tue, Nov 23, 2010 at 1:20 PM, Michael Van Canneyt mich...@freepascal.org wrote: They do the same as we: They introduced something like PtrInt (using of course a different name) and made tag equal to this type. Instead of biting the bullet and telling people to code properly. But like most companies, they are a bit of a prostitute in this regard. This is precisely why I asked to create a Data pointer so components can assign extraneous data and associate it with said component. Andrew, Creating TList as a field for storing extra structures and objects and supporting extra data reference using Tag as an index never was a problem for me. Can you tell a single reason not to implement this approach by yourself? Moreover managing the destruction of objects in this case is much easier and straightforward. Other consideration, if something starts to depend on future decisions of other developers, isn't it easy to create a simple (very simple) workaround :) Max Vlasov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Tue, Nov 23, 2010 at 11:32 PM, Andrew Brunner andrew.t.brun...@gmail.com wrote: On Tue, Nov 23, 2010 at 1:59 PM, Max Vlasov max.vla...@gmail.com wrote: Andrew, Creating TList as a field for storing extra structures and objects and supporting extra data reference using Tag as an index never was a problem for me. Can you tell a single reason not to implement this approach by yourself? Moreover managing the destruction of objects in this case is much easier and straightforward. Other consideration, if something starts to depend on future decisions of other developers, isn't it easy to create a simple (very simple) workaround :) Max Vlasov In the specific problem I have, it is corellating TMenuItem with a particular data pointer object of TForm. Forms can close out of order and re-Index the List I have (as you stated). But there is no clean way for me to reference what was clicked on Sender... Tag or Data is the only clean solution here. Out of order, happening on application thread... Oh, and TMenuItems being created at runtime. This is about productivity. What must I create an additional list when I have Tag or Data. Things become a little more complex in this case, but just a little, [id:pointer] where id is autoincrement. You can have two synchronized lists (TList), one stored ids, another one - corresponding object. Or create a list with a record containing both. I'm from Turbo Pascal era so dynamic array of was a kind of novelty some time ago for me and I created an analogue. But this time [array of record id: integrer; ptr: pointer end;] is no longer a problem and you have privilege to use a language already containing such a great dynamic structure :) I also must say (probably others will confirm) that programming starting turbo pascal gave me once and for good the sense that the design-time objects and data are a great help, but just secondary help, everything solid comes from elsewhere. Max Vlasov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Mon, Nov 22, 2010 at 5:13 PM, michael.vancann...@wisa.be wrote: We'll fix the issue as the upcoming Delphi 64-bit - unfortunately - forces us to follow suit. Will it also create an additional confusion in design time? I mean, non-RAD compilers possibly only have compile-time context, while Lazarus has also design-time. One example, if the Tag is 64-bit and one set up the environment to cross-compile from 32-bit IDE to 64-bit, he or she even won't be able to change a 64-bit integer property in the designer. And also speaking of following/not following Delphi, I think Lazarus has two things to have courage not to follow the trend: - dfm and lfm is not easily interchangeable, so if Lazarus is not going with Delphi with the tag size, there's always could be a warning (highlighting) pointing out to an exceeded Tag value. - the compiler for a long time had pointer conversion not portable hint/warning so no matter how big Tag is, writing SomeMyAddr:=pointer(Obj.Tag) already warns the developer. Hmm, also a little off-topic analogy, AMD was the second until they were first with 64-bit processors. Intel just had to follow. Project this to Pascal ;-) Max Vlasov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Suggestion regarding dynamic packages
Hi, I recently read the info about current implementation of packages and a post that dynamic packages support is at the early stage or not started yet. Knowing that fpc developers is very skilled and they probably the know things better than me I just wanted to suggest to implement something toward the needed direction without even deciding on major details (sorry if it's already considered) A little history. When the dynamic packages were introduced in Delphi, I did a little inquiry about the magic behind it and the major change I noticed was actually changing everything addressable in interface sections of units from direct addressing to indirect addressing. So, if there's a variable in the interface section of a unit, the corresponding dcu would not have a direct entry to be linked, but actually an entry that contained the address to the actuall variable. Interesting was the fact that it was true even for everything statically linked (as I suppose, in order not to do the things too complex). This would allow for the compiler to make a long table of entries from one package that it needs from other packages, and the long list of entries of the entries it offers to other packages. After that depending on the build type, this tables were directly linked (single exe) or splitted to import and export sections of dlls (bpl). So, I just wanted to suggest that regardless of the magic different platform has about such dynamic linking, there's something similar to this indirect addressing possibly should be done with interfaces sections of the unit. So even without actual dynamic packages implementation details, the fpc compiler could start support intdirect addressing for ppu files. It may be a conditional mode and in this case every ppu just can introduce a flag indicating the mode it was compiled with or just be gradually implemented unconditionally. The latter is not good for performance reasons and as I recall after the discovery about indirect addressing we did some tests and some artificial projects (for example a loop variable placed in the interface section of a unit) showed very little performance degradation, but for general approach it was almost unnoticeable. What you think? Thanks, Max Vlasov, maxerist.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion regarding dynamic packages
On Mon, Nov 22, 2010 at 1:40 AM, Willibald Krenn willibald.kr...@gmx.atwrote: Hi, Am 21.11.2010 12:49, schrieb Max Vlasov: I recently read the info about current implementation of packages and a post that dynamic packages support is at the early stage or not started yet. Knowing that fpc developers is very skilled and they probably the I've been very busy lately, so the implementation did not really start yet. All I've done so far is contributing some fixes for the win64 target so that I can actually debug the fpc compiler on my machine... ;-) ...snip... So, I just wanted to suggest that regardless of the magic different platform has about such dynamic linking, there's something similar to this indirect addressing possibly should be done with interfaces sections of the unit. So even without actual dynamic packages implementation details, the fpc compiler could start support intdirect addressing for ppu files. It may be a conditional mode and in this case every ppu just can introduce a flag indicating the mode it was compiled with or just be gradually implemented unconditionally. The latter is not good for performance reasons and as I recall after the discovery about indirect addressing we did some tests and some artificial projects (for example a loop variable placed in the interface section of a unit) showed very little performance degradation, but for general approach it was almost unnoticeable. What you think? This is interesting information and it sounds very reasonable. However, I haven't made much progress on the package front yet and I still need to read up (better: read again) on what fpc stores in it's .ppu files -- hence I cannot really say what is the best way to implement this feature.. ;) (Obviously I want to change as few things as possible in the fpc internals..) BTW: My main goal for this year still is to do a proof of concept and to compile the system unit into a fpcrtl.ppl with a simple application that uses this package. Willi, great to know that there's a activity about it. And wanting to change as few things as possible sounds also reasonable. This is also related to the long-time question of the usability of packages in general. On one side they remind Wirth's ideas in Oberon (modules) and would probably allow not only make things better for Lazarus IDE, but also creating lite/full versions of programs easily. On the other side, at least in Delphi the linkage was always strictly bound to detect smallest version changes that is probably good for compiler and not always for the developer. Good luck! :) Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
