Re: [fpc-pascal] Generating code form xmi files
It seem there is nothing available. If it is confirmed, I'll try to write something. I'll have a lot of time because I'm stoping World of Wordcraft :) Philippe ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
Graeme Geldenhuys schrieb: > I currently use "Dia Diagram editor" to design UML diagrams, but as > far as I know it does generate any code. :-( Try http://www.uni-ulm.de/~s_mgerla/dia2pas.html mfg Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memory Size
On 04 Apr 2009, at 20:47, Markus Glugla wrote: But, if I allocate 2GB memory the program crashs with an access violation. I have read that fpc can handle arrays up to a size of 2GB, isn't? How great can be an array? First of all, you set the global system unit variable 'ReturnNilIfGrowHeapFails' to true, so that instead of a run time error (or exception) you will simply get nil if a memory allocation fails. Secondly, not being able to allocate an array of 2GB is unrelated to FPC, but due to the fact that you are (most likely) working on a 32 bit OS. While the theoretical maximum limit for 32 bit systems is 4GB, it is impossible to ever allocate that much memory in a s single block. The reason is that while your program runs in its own virtual memory space, it is not the only thing in that space. The kernel usually takes part of the memory (512MB to 1GB), your program code, data and stack take part of it (and not contiguously; e.g., the code and data usually start somewhere around address 0x804000, while the stack starts at 0xC000 and grows downwards from there), and then there are shared libraries which can be mapped all over the place. As a result, the virtual memory space is fragmented already right after your program starts, and on most 32 bit systems you seldom can allocate more than 1.5GB of contiguous memory (simply because other things are in the way otherwise), and sometimes even less. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler raise an EAbort exception
On 04 Apr 2009, at 21:47, ik wrote: I can't reproduce it with a stand alone test (made many attempts). I can however place my original unit, because it is a LGPL unit I'm creating in the bug report, and see what is wrong there. Will it be ok to do that in the bug report ? As long as you attach all necessary sources to the bug report (i.e., also other non-FPC units that it may require): sure! Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Remove unused functions in a class
On 05 Apr 2009, at 00:40, JoshyFun wrote: If a virtual method of a class is not used at all in the programm will the compiler remove it from the executable ? If you use FPC 2.3.1 with whole-program optimization and the compiler can prove that it is never callable: yes. See http://wiki.freepascal.org/Whole_Program_Optimization for more information. In case this is in relation to the thread on the Lazarus list about the big executables: note that it has only a limited effect on Lazarus programs, because almost all linked LCL code can potentially be executed (due to the way the LCL is constructed). In fact, I think most savings there come from making a number of virtual method calls non-virtual, rather than from throwing away unreachable code. The internal linker can also do it (only throwing away virtual method calls, not turning virtual method calls into static ones), but only on Windows platforms. It is however not currently enabled in the compiler, because the changes break the external linker. It should therefore be turned into a command line option (along with a check that produces an error if you try to link a unit compiled with the option using the external linker), but that hasn't been done yet. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constructors & Destructors 101
Jonas Maebe wrote: If you had two different create constructors (for whatever reason), might you not also need two different destroy destructors? No, the default destructor should always free all resources, regardless of how the class instance was created. Otherwise, it would also make your code more complex, because throughout the code you would have to track how the instance was created, so that in the end you could call the correct destructor. I think there's something even more subtle than that. If a constructor blows up and raises an exception, the destructor Destroy is called automatically to clean up the partially created class, before the exception is handled. So, it's not just .free that is hardcoded to call destroy. IOW it is an extremely bad idea to have a destructor other than Destroy for classes and IMO shouldn't be allowed by the language. However, having multiple constructors is perfectly fine, as long as the destructor is only one. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] Remove unused functions in a class
Hello Jonas, Sunday, April 5, 2009, 11:20:59 AM, you wrote: JM> If you use FPC 2.3.1 with whole-program optimization and the compiler JM> can prove that it is never callable: yes. See JM> http://wiki.freepascal.org/Whole_Program_Optimization JM> for more information. In case this is in relation to the thread on JM> the Lazarus list about the big executables: note that it has only a Yes and no :) The thread raises the question in my brain :) but not to reduce the LCL final size, it was only a conceptual question, how can the compiler determine that a virtual method is unused at all, and even if it is removed the VMT entry should be present do not ? JM> limited effect on Lazarus programs, because almost all linked LCL code JM> can potentially be executed (due to the way the LCL is constructed). JM> In fact, I think most savings there come from making a number of JM> virtual method calls non-virtual, rather than from throwing away JM> unreachable code. I think that LCL should be reestructured to get the compiler and linker performing a good dead code clean, but that task is a big task. JM> The internal linker can also do it (only throwing away virtual method [...] JM> that produces an error if you try to link a unit compiled with the JM> option using the external linker), but that hasn't been done yet. Just for curiosity which is the parameter set ? Thank you for the answer. -- Best regards, JoshyFun ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] Remove unused functions in a class
On 05 Apr 2009, at 13:28, JoshyFun wrote: JM> If you use FPC 2.3.1 with whole-program optimization and the compiler JM> can prove that it is never callable: yes. See JM> http://wiki.freepascal.org/Whole_Program_Optimization JM> for more information. In case this is in relation to the thread on JM> the Lazarus list about the big executables: note that it has only a Yes and no :) The thread raises the question in my brain :) but not to reduce the LCL final size, it was only a conceptual question, how can the compiler determine that a virtual method is unused at all, If you have a class hierarchy tbase->tderived1->tderived2 with a virtual method called "vmethod", and nowhere in the program there is a call to vmethod, then it is unused. Or if it is only called using tderived2 instances, then if the linker does not find any direct references to tderived1.vmethod or tbase.vmethod (e.g., via "inherited" calls from tderived2 methods), it knows that the VMT entries for vmethod in tderived1 and tbase can be set to nil. and even if it is removed the VMT entry should be present do not ? The easiest is to keep it, but simply set it to nil or to FPC_ABSTRACTERROR. Then you don't have to start juggling with changing offsets everywhere. JM> The internal linker can also do it (only throwing away virtual method [...] JM> that produces an error if you try to link a unit compiled with the JM> option using the external linker), but that hasn't been done yet. Just for curiosity which is the parameter set ? Compile the compiler with -dvtentry. It's not been tested for a while though, as far as I know. I also made a mistake in my previous explanation: currently, the WPO does not yet perform the optimization the -dvtentry does. -dvtentry looks at which VMT entries of a class hierarchy are never accessed, and replaces those by nil. As a result, if those methods are not referred directly, then they can be removed by the linker. The WPO looks at which class types can be instantiated in the program and at the inheritance tree, and based on this determines which virtual method calls can be replaced by non-virtual method calls (and for those methods, it replaces the VMT entry with FPC_ABSTRACTERROR). It also replaces the VMT entries for (non-class) virtual methods in all classes that cannot be instantiated in the program with FPC_ABSTRACTERROR. As a result, again if such methods are not referenced directly, then they can be removed by the linker (and the ones that are referenced can be turned into normal function calls). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax problem with first unit
Mehmet Erol Sanliturk writes: Unit and function names DebugPrint are the same . Pascal is case insensitive . Making their cases different does NOT make them different . Please make them different and retry . Thanks. That worked. It may help newcomers like myself if this was mentioned on the ref document. Just double checked and it does not mention this. Likely an error that people will only commit once, but still would be nice to have int he ref doc. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memory Size
Hi Jonas, > First of all, you set the global system unit variable > 'ReturnNilIfGrowHeapFails' to true, so that instead of a run time > error (or exception) you will simply get nil if a memory allocation > fails. This is a very good tip! I have read about 'ReturnNilIfGrowHeapFails' but I forget it. I think, it is a good solution for my problem. > Secondly, not being able to allocate an array of 2GB is unrelated to > FPC, but due to the fact that you are (most likely) working on a 32 > bit OS. While the theoretical maximum limit for 32 bit systems is 4GB, > it is impossible to ever allocate that much memory in a s single block. Yes, it finally sunk in. I see clearlier the context of memomry management. Thanks. > The reason is that while your program runs in its own virtual memory > space, it is not the only thing in that space. The kernel usually > takes part of the memory (512MB to 1GB), your program code, data and > stack take part of it (and not contiguously; e.g., the code and data > usually start somewhere around address 0x804000, while the stack > starts at 0xC000 and grows downwards from there), and then there > are shared libraries which can be mapped all over the place. Ok, thats new for me. It is very interesting. > As a result, the virtual memory space is fragmented already right > after your program starts, and on most 32 bit systems you seldom can > allocate more than 1.5GB of contiguous memory (simply because other > things are in the way otherwise), and sometimes even less. My experience with the topic coincides with your sentences. Finally, I think i understand some thinks better. Including with your first very good tip, I can fix the problem. Thank you, Jonas, for your help. Also Thank's to Marco. Bye, Markus ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
http://www.opensubscriber.com/message/dia-l...@gnome.org/11515637.html Em Dom, 2009-04-05 às 11:05 +0200, Michael Fuchs escreveu: > Graeme Geldenhuys schrieb: > > I currently use "Dia Diagram editor" to design UML diagrams, but as > > far as I know it does generate any code. :-( > > Try > http://www.uni-ulm.de/~s_mgerla/dia2pas.html > > > mfg > Michael > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax problem with first unit
On Sun, April 5, 2009 16:03, Francisco Reyes wrote: > Mehmet Erol Sanliturk writes: > >> Unit and function names DebugPrint are the same . >> Pascal is case insensitive . Making their cases different does NOT >> make them different . >> >> Please make them different and retry . > > Thanks. That worked. > > It may help newcomers like myself if this was mentioned on the ref > document. > Just double checked and it does not mention this. > > Likely an error that people will only commit once, but still would be nice > to have int he ref doc. Note that although having the unit named equally to a function, procedure or a variable defined within the unit (or elsewhere) is not really advisable, it is possible, but you need to take scoping rules into account when trying to access the function, procedure or variable. In your particular case, you would need to use DebugPrint.DebugPrint (your parameters) in order to tell the compiler that you refer to the function DebugPrint stored within unit DebugPrint referenced in the "uses" section. That's also why the compiler suggested that you should use '.' after DebugPrint. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax problem with first unit
On Sun, 2009-04-05 at 10:03 -0400, Francisco Reyes wrote: > Mehmet Erol Sanliturk writes: > > > Unit and function names DebugPrint are the same . > > Pascal is case insensitive . Making their cases different does NOT > > make them different . > > > > Please make them different and retry . > > Thanks. That worked. > > It may help newcomers like myself if this was mentioned on the ref document. > Just double checked and it does not mention this. > > Likely an error that people will only commit once, but still would be nice > to have int he ref doc. But the Pascal language has *always* been case insensitive. [As are FORTRAN, PL/I, ALGOL 60/68, COBOL and a host of others.] I wrote my first Pascal programs on punched cards around 1975, hosted on a Control Data Corp. Cyber 72 mainframe. The key-punch machines we used to punch the cards did not support lower case letters, so we could not readily prepare case sensitive input. This is why almost all the older generation of programming languages are case insensitive. Once we started using timesharing on the mainframe, we were automatically accustomed to lower case letters being treated the same as capital letters, as even the system commands were punched in capital letters on cards, but typed as lower case from a terminal. -- Regards, Dave [RLU #314465] === david.w.n...@ntlworld.com (David W Noon) === ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax problem with first unit
On Sun, 5 Apr 2009, Francisco Reyes wrote: > Mehmet Erol Sanliturk writes: > > > Unit and function names DebugPrint are the same . > > Pascal is case insensitive . Making their cases different does NOT > > make them different . > > > > Please make them different and retry . > > Thanks. That worked. > > It may help newcomers like myself if this was mentioned on the ref document. > Just double checked and it does not mention this. It most certainly does: see the section on reserved words, first paragraph. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Case Sensitivity
(snipped) Pascal is case insensitive . It may help newcomers like myself if this was mentioned on the ref document. Just double checked and it does not mention this. --- Interestingly, I was going over the lang ref guide last night and found that the case sensitivity is mentioned in section 1.3 for reserved words. It might be better to mention this in section 1.1 to cover more than just reserved words. To be complete, it would probably be good to mention it in several places in the documentation where someone might want to look for it, but this would make the document(s) very bloated. A problematic tradeoff. The only practical solution I see for newbies would be to completely read through the lang ref guide once. Some concepts may seem foreign but those you can go back over if needed. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] Remove unused functions in a class
Hello Jonas, Sunday, April 5, 2009, 2:09:33 PM, you wrote: JM> If you have a class hierarchy tbase->tderived1->tderived2 with a JM> virtual method called "vmethod", and nowhere in the program there is a JM> call to vmethod, then it is unused. Or if it is only called using JM> tderived2 instances, then if the linker does not find any direct JM> references to tderived1.vmethod or tbase.vmethod (e.g., via JM> "inherited" calls from tderived2 methods), it knows that the VMT JM> entries for vmethod in tderived1 and tbase can be set to nil. In fact I was thinking in something like this: TCustomFoo=class(TObject); TDerivedFoo=class(TCustomFoo) procedure Myprocedure(); virtual; end; TDeDerivedFoo=class(TDerivedFoo) procedure MyProcedure(); override; end; And in the code: var MyObj: TCustomFoo; begin MyObj:=TDeDerivedFoo.Create(); TDerivedFoo(MyObj).Myprocedure(); end; Something like this could kill the dead code detection ? A simple yes/no is enoght :) >> JM> that produces an error if you try to link a unit compiled with the >> JM> option using the external linker), but that hasn't been done yet. >> >> Just for curiosity which is the parameter set ? JM> Compile the compiler with -dvtentry. It's not been tested for a while JM> though, as far as I know. I'll play with it just for fun... JM> I also made a mistake in my previous explanation: currently, the WPO JM> does not yet perform the optimization the -dvtentry does. -dvtentry JM> looks at which VMT entries of a class hierarchy are never accessed, JM> and replaces those by nil. As a result, if those methods are not JM> referred directly, then they can be removed by the linker. I understand it in that way already. JM> The WPO looks at which class types can be instantiated in the program JM> and at the inheritance tree, and based on this determines which [...] JM> referenced directly, then they can be removed by the linker (and the JM> ones that are referenced can be turned into normal function calls). More or less I understand the WPO way of work. Thank you again. -- Best regards, JoshyFun ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
Hi! Am Sonntag, den 05.04.2009, 11:24 -0300 schrieb Osvaldo Filho: > http://www.opensubscriber.com/message/dia-l...@gnome.org/11515637.html The current version is available at http://k7103.svn.sourceforge.net/viewvc/k7103/branch/ng/dia-codegen/ Bye Hansi ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax problem with first unit
Michael Van Canneyt writes: It may help newcomers like myself if this was mentioned on the ref document. Just double checked and it does not mention this. It most certainly does: see the section on reserved words, first paragraph. In the ref document? Page10? Section 1.3? Just looked there and didn't see it it. There is a reference to case insensitivity, but that is not what I was suggesting. I was tying to suggest to mention that a function can not have the same name as a unit name. I am sure this is obvious to experienced users, but may not be for a newcomer. In particular it would be helpful if that note (ie name of fuction and unit name can't be same) was in the unit section. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax problem with first unit
Tomas Hajny writes: Note that although having the unit named equally to a function, procedure or a variable defined within the unit (or elsewhere) is not really advisable, it is possible, but you need to take scoping rules into account Thanks for the note. I wasn't purposedly trying to do it though. Just didn't know it would be a problem. That's also why the compiler suggested that you should use '.' after DebugPrint. Aha! The error didn't make sense, but with your explanation now it does. I just changed the unit name. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[4]: [fpc-pascal] Remove unused functions in a class
On 05 Apr 2009, at 17:12, JoshyFun wrote: TCustomFoo=class(TObject); TDerivedFoo=class(TCustomFoo) procedure Myprocedure(); virtual; end; TDeDerivedFoo=class(TDerivedFoo) procedure MyProcedure(); override; end; And in the code: var MyObj: TCustomFoo; begin MyObj:=TDeDerivedFoo.Create(); TDerivedFoo(MyObj).Myprocedure(); end; Something like this could kill the dead code detection ? A simple yes/no is enoght :) Not in case of whole-program optimization: --- dead.sorg 2009-04-05 17:24:25.0 +0200 +++ dead.s 2009-04-05 17:24:32.0 +0200 @@ -91,10 +91,7 @@ # [29] TDerivedFoo(MyObj).Myprocedure(); movlL_U_P$PROGRAM_MYOBJ$non_lazy_ptr-Lj2(%ebx),%eax movl(%eax),%eax - movlL_U_P$PROGRAM_MYOBJ$non_lazy_ptr-Lj2(%ebx),%edx - movl(%edx),%edx - movl(%edx),%edx - call*80(%edx) + callL_P$PROGRAM_TDEDERIVEDFOO_$__MYPROCEDURE$stub I'm not sure about -dvtentry. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case Sensitivity
Richard Ward writes: Interestingly, I was going over the lang ref guide last night and found that the case sensitivity is mentioned in section 1.3 for I think from seen this new thread and a few other posts that there is some confusion. When I posted my sample code I had the unit name and a function name with the same name, but different case. Someone wrote and mentioned that was the problem and that one can not have function and unit with same name. This person also mentioned that Pascal is case insensitive so these two names were the same. When I wrote that I didn't see something in the ref doc.. I was NOT refering to case sensitivity. I was refering to not seeing a note that one can not have a unit name be the same as a function name. I was never refering to case sensitivity. Sorry for not been more clear. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[6]: [fpc-pascal] Remove unused functions in a class
Hello Jonas, Sunday, April 5, 2009, 5:27:02 PM, you wrote: >> Something like this could kill the dead code detection ? A simple >> yes/no is enoght :) JM> Not in case of whole-program optimization: JM> --- dead.sorg 2009-04-05 17:24:25.0 +0200 JM> +++ dead.s 2009-04-05 17:24:32.0 +0200 JM> @@ -91,10 +91,7 @@ JM> # [29] TDerivedFoo(MyObj).Myprocedure(); JM> movlL_U_P$PROGRAM_MYOBJ$non_lazy_ptr-Lj2(%ebx),%eax JM> movl(%eax),%eax JM> - movlL_U_P$PROGRAM_MYOBJ$non_lazy_ptr-Lj2(%ebx),%edx JM> - movl(%edx),%edx JM> - movl(%edx),%edx JM> - call*80(%edx) JM> + callL_P$PROGRAM_TDEDERIVEDFOO_$__MYPROCEDURE$stub JM> I'm not sure about -dvtentry. Nice to see that, that's for sure a non easy objetive :) -- Best regards, JoshyFun ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax problem with first unit
Tomas Hajny wrote: Note that although having the unit named equally to a function, procedure or a variable defined within the unit (or elsewhere) is not really advisable, it is possible, but you need to take scoping rules into account when trying to access the function, procedure or variable. In your particular case, you would need to use DebugPrint.DebugPrint (your parameters) in order to tell the compiler that you refer to the function DebugPrint stored within unit DebugPrint referenced in the "uses" section. That's also why the compiler suggested that you should use '.' after DebugPrint. Tomas The following addition may be made to the above explanation for a little more clarification : When compiler scanned the assignment statement := , it found the name DebugPrint . Within the scope of the program DebugPrint is a unit name whereas there should be a variable name . For that reason , the compiler assumed that there should be a qualification of a variable name by the unit name such as ... := DebugPrint . x ... Instead of finding a period and variable name after the unit name DebugPrint , it found a left parenthesis . Due to this , it gave the message ... Expected . ( period ) but found ( left parenthesis ) . Thank you very much . Mehmet Erol Sanliturk ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax problem with first unit
On Sun, April 5, 2009 17:23, Francisco Reyes wrote: > Michael Van Canneyt writes: > >>> It may help newcomers like myself if this was mentioned on the ref >>> document. >>> Just double checked and it does not mention this. . . > In particular it would be helpful if that note (ie name of fuction and > unit > name can't be same) was in the unit section. Well, this is something more general, not specific to units - using the same identifier for different things (although possibly having different scope) may lead to conflicts, of course. As an example, the same is true for having the same name for a local variable (function, procedure) and a global one. In this context, placing such a note in the unit section isn't very logical. I haven't checked whether some hint in this sense appears in the general section about identifiers, but that is the right place in my opinion (if we want to mention something like that explicitly - note that it's quite logical and everyone understands that if two people have the same name, one needs to find some other means of differentiating between them. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] PasJS: Ext-Core v3 as the RTL
Hi all, Especially who is interesting in web programming. I saw yesterday Ext released their first beta for Ext-Core. I think it's the best candidate to be used as default RTL for PasJS. It's also will ease PasJS development because lots of things are already provided by this library, including cross-browser support. For further development, we could extend PasJS to use ExtJS UI framework as the default LCL-like library. Ideas? TIA. -- -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case Sensitivity
Richard Ward writes: > I was refering to not seeing a note that one can not > have a unit name be the same as a function name. Sure you can, the function just should not reside in the very same unit. This is a short-coming of the Pascal language definition. Vinzent. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Case Sensitivity / Multiple Names
Francisco Reyes wrote: I was refering to not seeing a note that one can not have a unit name be the same as a function name. I was never refering to case sensitivity. Sorry for not been more clear. --- Ahh, OK. Yes, I've run into that problem myself. The one I remember was where I was using the MacOSAll unit which defined a random function which then hid the FPC version of random with the same name declared in the system unit. The only reason I figured it out was that I tried passing a parameter which didn't work and someone pointed out to me what happened. I was told that you could use both versions and the FPC version could be accessed by calling system.random. That is, you can use the unit name as a dot notation prefix (like a record or method) to access the specific one you want. In addition, I am thinking it would be a nice feature for an IDE to color code the FPC RTL routines to give one a clue if you are trying to redefine a system function. There are reasons for allowing multiple defined names but it can be a bit confusing. By the way, I've tested the system.random function and three of the random functions supplied by Apple via MacOSAll, and I have found the FPC implementation to be the fastest most "accurate" and most flexible (due to the FPC function overloading.)- ROW ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Typed Constants vs. Variables
Where/why would one use a typed constant vs. a variable. i.e. const myConst : double = 2.0*Pi; var myVar : double = 2.0*Pi; It seems to me the typed constant is superfluous and can potentially lead to bugs. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Typed Constants vs. Variables
Richard Ward writes: Where/why would one use a typed constant vs. a variable. i.e. Any time you have a value you want to have in an accessible holder, but want to ensure you will not change it's value by mistake. It seems to me the typed constant is superfluous and can potentially lead to bugs. On the contrary. They help saveguards against bugs. Imagine a team of people working on different parts of a large system. One team defines a constant; someone on another team sees a piece of code and thinkgs he working with a variable. He tries to change it and the compiler throws an error because it is a constant. That error just saved that system from a logical, possibly hard to find, error. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
Err... how to use this codegen thing? Do I need to run it over Dia generated diagrams or what? Sorry, I don't understand Python. Johann Glaser wrote: > > Hi! > > Am Sonntag, den 05.04.2009, 11:24 -0300 schrieb Osvaldo Filho: >> http://www.opensubscriber.com/message/dia-l...@gnome.org/11515637.html > > The current version is available at > http://k7103.svn.sourceforge.net/viewvc/k7103/branch/ng/dia-codegen/ > > Bye > Hansi > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > > -- View this message in context: http://www.nabble.com/Generating-code-form-xmi-files-tp22848439p22902133.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Typed Constants vs. Variables
Typed constants ARE changeable (just like variables), the only place where they behave differently from variables is if they're declared in a local scope (i.e. function / procedure). Typed constants act like a static variables in C, where it's initialized only once during program execution. -- View this message in context: http://www.nabble.com/Re%3A-Case-Sensitivity---Multiple-Names-tp22897965p22902217.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Typed Constants vs. Variables
On 06 Apr 2009, at 03:37, Richard Ward wrote:
Where/why would one use a typed constant vs. a variable. i.e.
const
myConst : double = 2.0*Pi;
var
myVar : double = 2.0*Pi;
It seems to me the typed constant is superfluous and can potentially
lead to bugs.
Typed constants predate the existence of initialized variables.
Furthermore,
a) typed constants are initialized once (when the program starts), and
if changed keep their value until explicitly changed again (even if
they are declared locally in a procedure/function, and over multiple
independent invocations of such routines)
b) conversely, initialized variables are initialized every time their
scope is activated (or whatever the proper term for that is: once in
case they are declared in a program/unit scope, and every time a
function/procedure is entered if they are declared locally in a routine)
c) typed constants can be made read-only by using the {$j-} switch
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
