Re: [fpc-pascal] Assign() vs AssignTo()
Martin Schreiber wrote: On Friday 12 February 2016 03:17:57 Dennis wrote: Is there any sample codes to copy published properties (via RTTI) ? e.g. psuedo code below for i := 0 to properties.count -1 do begin case properties[i].type of vtInteger : properties[i].AsInteger := Source.PropertiesByName(Properties[i].Name).AsInteger; vtdouble : vtString : ... end; end; MSEgui has such code for "trttistat" component, please see https://gitlab.com/mseide-msegui/mseide-msegui/raw/master/lib/common/kernel/mserttistat.pas although it is specialised for saving and editing options. Martin ___ Thank you. Dennis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assign() vs AssignTo()
On Friday 12 February 2016 03:17:57 Dennis wrote: > > Is there any sample codes to copy published properties (via RTTI) ? > e.g. psuedo code below > >for i := 0 to properties.count -1 do begin > case properties[i].type of > vtInteger : properties[i].AsInteger := > Source.PropertiesByName(Properties[i].Name).AsInteger; > vtdouble : > vtString : ... > end; >end; > MSEgui has such code for "trttistat" component, please see https://gitlab.com/mseide-msegui/mseide-msegui/raw/master/lib/common/kernel/mserttistat.pas although it is specialised for saving and editing options. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assign() vs AssignTo()
Martin Schreiber wrote: On Thursday 11 February 2016 17:17:32 Graeme Geldenhuys wrote: Now the other thing that surprised be, I thought TPersistent.Assign() automatically handles protected properties (via RTTI) - thinking that descendants automatically get such functionality for free. But reviewing the RTL code, I see Assign() and AssignTo() really has no functionality implemented by default. Correct, it depends much on the actual classes what should happen by calling "assign()". So "tpersistent" does nothing by default. Martin Is there any sample codes to copy published properties (via RTTI) ? e.g. psuedo code below for i := 0 to properties.count -1 do begin case properties[i].type of vtInteger : properties[i].AsInteger := Source.PropertiesByName(Properties[i].Name).AsInteger; vtdouble : vtString : ... end; end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Wed, 10 Feb 2016 05:10:55 -0500 Anthony Walter wrote: >[...] > Additionally, and in a different scenario, when the identifier IS defined > and several units are in the uses clause the goto declaration can jump to > an include file without any information pertaining to which of the units is > including the file. To the best of my knowledge there isn't a straight > forward way to figure this out, If Lazarus has found the declaration there are a few features that might help: Search / Goto include directive. This will take you one step up. Code Explorer / Surrounding Source / Unit Information Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On 02/11/2016 06:51 AM, Michael Van Canneyt wrote: On Thu, 11 Feb 2016, Mattias Gaertner wrote: Michael Van Canneyt hat am 11. Februar 2016 um 04:27 geschrieben: [...] Lazarus IDE shows a tooltip when you hover over an identifier with the mouse. I suspect it will take one on the team less than 10-minutes to add the unit name to the tooltip, in addition to the package and source file name. Done. It's a coder... It's a hacker... it's SuperMattias ! LOL! :thumbsup: -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assign() vs AssignTo()
On Thursday 11 February 2016 17:17:32 Graeme Geldenhuys wrote: > > Now the other thing that surprised be, I thought TPersistent.Assign() > automatically handles protected properties (via RTTI) - thinking that > descendants automatically get such functionality for free. But reviewing > the RTL code, I see Assign() and AssignTo() really has no functionality > implemented by default. > Correct, it depends much on the actual classes what should happen by calling "assign()". So "tpersistent" does nothing by default. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assign() vs AssignTo()
On 2016-02-11 15:55, Martin Schreiber wrote: > It depends on what knows to handle what. Sometimes both have to be overridden. Thanks Martin and Andreas. So it's more about which direction you want to go. Now the other thing that surprised be, I thought TPersistent.Assign() automatically handles protected properties (via RTTI) - thinking that descendants automatically get such functionality for free. But reviewing the RTL code, I see Assign() and AssignTo() really has no functionality implemented by default. I can only assume that the reason I thought published properties are handled for you (in the RTL), was because 99.9% of my projects are tiOPF based, and it always just worked. Looking now at this in more detail, I see it was indeed tiOPF that always gave me that functionality. Wow, 17+ years later and I only realise that now. :) Never too old to learn. ;-) Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assign() vs AssignTo()
On Thursday 11 February 2016 16:13:22 Graeme Geldenhuys wrote: > Hi, > > In TPersistent, we have two virtual methods. Assign() which calls > AssignTo(). > > 1) Why are they both virtual? It seems like Assign() is what I call a > template method, farming its work out to other helper methods - in this > case, AssignTo(). Normally template methods are not virtual, but their > helper methods (the ones doing the actual work) are. So again, why is > Assign() virtual? > If one wants to transfer property values from "source" to "dest" one calls "dest.assign(source)". If "dest" does not know how to handle "source" it calls "source.assignto(self)". > 2) Now seeing that both are virtual, and that is probably not going to > change in the RTL, which method is the preferred method to override so > you have the ability to do MyObject.Assign(MySource)? I've been > overriding Assign(), but thinking that maybe I should have overridden > AssignTo() instead. > It depends on what knows to handle what. Sometimes both have to be overridden. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assign() vs AssignTo()
Am 2016-02-11 16:13, schrieb Graeme Geldenhuys: Hi, In TPersistent, we have two virtual methods. Assign() which calls AssignTo(). 1) Why are they both virtual? It seems like Assign() is what I call a template method, farming its work out to other helper methods - in this case, AssignTo(). Normally template methods are not virtual, but their helper methods (the ones doing the actual work) are. So again, why is Assign() virtual? They are two different directions. AssignTo assigns *from* your current instance onto another, while Assign assigns *from* the other instance into yours. Sure, by default that should be the same, that's why it's sane to have Assign simply call the other object's AssignTo with Self as target. But IMHO it can't hurt to have the ability to override that behavior for only one direction. 2) Now seeing that both are virtual, and that is probably not going to change in the RTL, which method is the preferred method to override so you have the ability to do MyObject.Assign(MySource)? I've been overriding Assign(), but thinking that maybe I should have overridden AssignTo() instead. I think that really depends on what direction you want to usually handle. As far as I understand the code, the call in TPersistent is only a fallback, intended like that: if it is not possible to assign some instance onto another instance (because no class along the hierarchy down to TPersistent implemented an override for Assign that handles the specific case) it tries, if the other side maybe can handle it by calling their AssignTo method. That way you can allow your class to have some standard/thirdparty/whatever class assigned, while you certainly can't modify the standard/thirdparty/whatever class to allow assigning *to* your class (since it doesn't even know your class). The same goes for the other way around. If you know a foreign class will try to assign your class, which it doesn't know anything about, it will ultimately come back calling your AssignTo method which will allow your class to handle the assignment onto the foreign class. Best regards, Andreas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Assign() vs AssignTo()
Hi, In TPersistent, we have two virtual methods. Assign() which calls AssignTo(). 1) Why are they both virtual? It seems like Assign() is what I call a template method, farming its work out to other helper methods - in this case, AssignTo(). Normally template methods are not virtual, but their helper methods (the ones doing the actual work) are. So again, why is Assign() virtual? 2) Now seeing that both are virtual, and that is probably not going to change in the RTL, which method is the preferred method to override so you have the ability to do MyObject.Assign(MySource)? I've been overriding Assign(), but thinking that maybe I should have overridden AssignTo() instead. ps: The FPC (pdf) documentation for TPersistent.Assign() has a "See Also" reference to TPersistent.AssignTo(). But that link doesn't work, because AssignTo is Protected, and the RTL documentation doesn't include Protected methods. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Recovering info from a backtrace with an external debug file
El 11/02/16 a les 04:12, Martin ha escrit: info symbol 0x54320 and it prints what is at that address. Do that for each address in the trace. That should be "info line *0x54320". Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
Am 11.02.2016 11:41 schrieb "Anthony Walter" : > > > This won't be changed. Period. > > Sven, not to be argumentative, but you do get that for a long time programmers have learned how to write code and use libraries by examining them? My goal is simply to make it easier for the people who would want to pick up and start using Lazarus. Organizing things better for the general developer population, and I'm not just referring to only source code organization, is something I honestly hope this community considers important. I believe that point should be a consideration not just for beginners, but also for the mass of professionals. If they are just learning the language then they shouldn't poke around in the core units anyway. That's what the documentation and help is for. Back when I started learning TP I didn't have the internet and I didn't have the sources of the units. I only had the help and it was definitely enough, so no I'm not even remotely convinced by your argument. Also you aren't someone who's working on that code. New users aren't either. I am. The other maintainers are. *We* need to work in these units, not you. And thus the code is structured in a way that it is suitable for *us* not you. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Recovering info from a backtrace with an external debug file
2016-02-11 0:12 GMT-03:00 Martin : > > Lazarus has "Leaks and Traces" in the view menu. Paste the trace, and then > use the Button "Resolve" to load the exe with symbols. That should do. > > It uses a copy of the code found in infodwrf and "whatever the name of the > unit reading stabs". Both of them (afaik) dont do dbg files. If someone has > info how to add that, well > > > as for gdb, you can open your exe (and if gdb finds the dbg file, then > that should be fine.) > if gdb loaded your dbg info, then you can do something (not tested/from > memory) > > info symbol 0x54320 > > and it prints what is at that address. Do that for each address in the trace. > > Thanks. Much helpful Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Recovering info from a backtrace with an external debug file
2016-02-11 0:06 GMT-03:00 Luiz Americo Pereira Camara < luizameri...@gmail.com>: > > > 2016-02-10 23:59 GMT-03:00 : > >> On 02/10/2016 09:47 PM, Luiz Americo Pereira Camara wrote: >> >>> >>> How to get the line number, method names of the backtrace using the >>> external >>> debug file? >>> >> >> my first eWAG gut response is to distribute the DBG file with the >> executable... >> >> > Thanks > > But that will not help, the backtrace will still be generated without > info, just address > > My apologies. After some testing, i found that when the dbg file is in the same dir as the executable, the calltrace is show with lineinfo. Seems that fpc generates code to find the debug info. Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On 2016-02-11 11:51, Michael Van Canneyt wrote: > It's a coder... It's a hacker... it's SuperMattias ! :-D LOL G. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Thu, 11 Feb 2016, Mattias Gaertner wrote: Michael Van Canneyt hat am 11. Februar 2016 um 04:27 geschrieben: [...] Lazarus IDE shows a tooltip when you hover over an identifier with the mouse. I suspect it will take one on the team less than 10-minutes to add the unit name to the tooltip, in addition to the package and source file name. Done. It's a coder... It's a hacker... it's SuperMattias ! Michael. PS. For those not familiar with the reference: https://en.wikipedia.org/wiki/It's_a_Bird...It's_a_Plane...It's_Superman ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
> Michael Van Canneyt hat am 11. Februar 2016 um 04:27 > geschrieben: >[...] > Lazarus IDE shows a tooltip when you hover over an identifier with the mouse. > I suspect it will take one on the team less than 10-minutes to add the unit > name to the tooltip, in addition to the package and source file name. Done. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Thu, 11 Feb 2016, Anthony Walter wrote: This won't be changed. Period. Sven, not to be argumentative, Funny. You _are_ argumentative, considering the answers you got and number of posts :-) (no offense intended) but you do get that for a long time programmers have learned how to write code and use libraries by examining them? That may be true for ordinary libraries. But the RTL is equivalent to Libc. I suggest you hold a poll for the number of people that learned C (or C++) by studying libc or libstd (or whatever it is called in C++). I expect you will be disappointed. Secondly, I don't think the sysutils or system units are a particularly good example. They are a historical image of the attempts (and possible mistakes) of Borland, Inprise, CodeGear, Embarcadero and now Idera, dating back to Turbo Pascal. Hardly good study material for learning. My goal is simply to make it easier for the people who would want to pick up and start using Lazarus. A most noble goal, which I wholeheartedly support ! Therefor I humbly suggest you continue your much-appreciated efforts in writing much more documentation examples and tutorials, improve the documentation engine, help out in getting fppkg and its upcoming web front end deployed. I think that will help a lot more than us reorganizing the RTL unit files. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
On Thu, 11 Feb 2016, Anthony Walter wrote: Michael, a question: How much of the interface section of units differ per platform? Is it 1% of the code? Is it 5% of the code? With the xml2 unit it's 0%, yet all of the declarations are nested in several layers of include files: Numbers are irrelevant. A particular system is adhered to. It's clearly not your system, but then, one could point out that it's not your code either. Obviously, I cannot speak for Lazarus' LCL units. I can only speak for the RTL units. The files are like this for maintainability: - Platform dependent parts will always be in separate include files. Forget IFDEF. The few parts where it is used are ugly enough as it is. - Some interface parts are shared between units: see the unix-specific units as explained by Marco. Sysutils shares e.g. a part with the Strings unit. the DOS unit shares a part with the System unit, if memory serves correctly. - Smaller files reduce the risk of conflicts when committing changes. While it is common for 2 people to work on sysutils or system, it's already less common that they work on the same functionality. As said before, these files are organized for the sake of their maintainers. Not the users. What the maintainers deem best, will be used. Allow me to express some surprise at the vehemence with which you attack this perceived problem. First, it's not like the identifiers are distributed randomly over arbitrary include files. They are neatly grouped in logical units. Second, if you want a nice overview of what is implemented in a unit: the documentation is guaranteed to be complete at the time of release, and contains an index per unit and even of all identifiers in the RTL. The sysutils unit documentation contains some topics with 'groups' of functionality. (suggestions always welcome) In Delphi, that's what I also do if I need an overview; I open the help, and that's it. Only in the very last instance - if I am interested in the actual particulars of an implementation - then I open the source. And honestly, I cannot even remember when I had to look up something in sysutils or system. I expect experienced people to know these units better than the back of their hand. For beginners I think documentation is better suited. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
> This won't be changed. Period. Sven, not to be argumentative, but you do get that for a long time programmers have learned how to write code and use libraries by examining them? My goal is simply to make it easier for the people who would want to pick up and start using Lazarus. Organizing things better for the general developer population, and I'm not just referring to only source code organization, is something I honestly hope this community considers important. I believe that point should be a consideration not just for beginners, but also for the mass of professionals. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
Michael Van Canneyt wrote: he fact that you're the first to complain in 20 years (at least I cannot remember any others, and I've been around for a while) gives you an indication of the relative importance of your problem. I do share Anthony's (strong) dislike of include files (but I am not complaining about it). The RTL is organized for the benefit of its maintainers, not the users. It's a proven design since 20 years as explained by Marco and Sven. The maintainers can choose whatever they like best. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Please someone explain this to me
Am 11.02.2016 00:23 schrieb "Anthony Walter" :
>
> For those who didn't understand what I meant by using regions in the
interface section rather than include files, here is an image of what is
essentially in SysUtils currently:
>
> http://cache.getlazarus.org/images/sysutils-include.gif
>
> Notice the unit file is opened the almost none of what it declares is
visible. Instead the declarations are hidden in layers of header include
files. This makes it difficult to open a file and see what functions,
variables, classes, or types are available and can be used. And I might add
that this is problem isn't exclusive to the SysUtils unit.
>
> Now here is an example where the interface section includes are moved to
regions:
>
> http://cache.getlazarus.org/images/sysutils-region.gif
>
> Notice you can actually browse through the types and other declarations
by simply scrolling down. I understand there might be situations where the
interface of a unit might differ per platform, but surely those situations
are in the minority, and they could either be placed in {$IFDEF} directives
or just those parts could be put in include files. As it is right now
nearly everything is is include files and nested include files making
browsing source code declarations more difficult than it should be.
>
> It seems like this {$I sysinth.inc} for a header and {$I sysint.inc} for
an implementation harkens to C headers and C implementations, something
which Pascal is supposed to have done away with.
This won't be changed. Period.
These units are not this way for the sake of browsing, but for the sake of
maintainability.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
