Re: [fpc-pascal] dynamic array contents and system.move
José Mejuto het geskryf: > architectures. Much better would be "move > (array1[0],array2[0],elements*sizeof(element))" but even in this case > the result is undefined, but it is a bit more exact as the programmer Now this is a perfect example, of why I love Java (at least what I have seen of it - I am no Java expert). In your example, the developer need to have knowledge of the internal structure of an array before they can use the move() function. Java and good programming practices like OOP states that you should try and hide the internal structure from a client using your structure. This gives you the freedom to change the internal structure without the need to change client code. This is the reason why things like Iterator exists in design patterns. What if move() and the developer assumes the data is one continuous block of data, when in fact it might not be. [I don't know internal structures of FPC] Seeing that dynamic arrays are a collection of pointers (I think I understood this correctly), each memory block pointed to by each pointer could be in a totally different memory location. So copying a continuous block of memory will result in rubbish data as a result. [ Extract from Java Documentation ] static void arraycopy(Object src, int src_position, Object dst, int dst_position, int length) Copies an array from the specified source array, beginning at the specified position, to the specified position of the destination array. usage example: -- // playerList is existing array int newSize = 2 * playerList.length; // Size of new array. Player[] temp = new Player[newSize]; // The new array. System.arraycopy(playerList, 0, temp, 0, playerList.length); - Note: No need to know internal data structures like an array item is actually a pointer to the actual data in memory etc... Much easier to work with. Requirements like having to know the internal structure, simply to be able to use that structure is not a cleaver design practise. But lucky for me, I hardly ever use arrays - I much prefer classes. ;-) Maybe the solution is as simply as introducing a new function in FPC called arraycopy(), which can then hide the complexity of internal data structures? As always, just my 2c worth of info. Use it, don't use it - I don't care. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What project management tool does FPC developers use?
On Tue, Apr 27, 2010 at 6:05 PM, Frank Church wrote: > What project management tool does FPC and Lazarus developers use? I > mean besides mantis for bug tracking? > I am thinking along the lines of JIRA, Redmine, Fogbugz etc. > > Add "Trac" to the list http://trac.edgewall.org/ Best Regards -- Zaher Dirkey ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
So why is it a problem, that one is a pointer, and the other not? Because it is easier, or more often overlooked. The problem is not that one is a pointer (to an array) and the other one is the array itself. That would be fine if it is told to the programmer that way and if it would be consistent. But then why am I not able to derefference this pointer with MyArray^? Why can I use an index on that pointer? In these cases it does *not* behave like a pointer but like an array. That's what makes it ambiguous. So at least I would expect that these realy confusing things are clearely explained in the help so that a programmer is not lead to false assumptions. Say that it is a pointer to an array (and do not let the user think it is "an array"!). And say that although it is a pointer you still cannot derefference it but you need to use the first index to get the beginning of the array. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] dynamic array contents and system.move
Hello FPC-Pascal, Tuesday, May 4, 2010, 9:41:27 PM, you wrote: M> I have never found anything that says, that an array (not a M> static-array, just an array), always and under any circumstances must M> ensure that the identifier of the whole array is equal to the first M> data-element in the array? M> I don't even think there is a guarantee that all the data elements are M> found at consecutive addresses in memory. (which is also required in M> order to use move) The problem is a bunch of literature that many people encumber but are wrong in definition. Some definitions are fine, like the wikipedia one: "In computer science, an array data structure or simply array is a data structure consisting of a collection of elements (values or variables), each identified by one or more integer indices, stored so that the address of each element can be computed from its index tuple by a simple mathematical formula." And of course the "pascal gurus" that shows us that to copy an array (static) the proper way is "move(array1,array2,elements*sizeof(element))" when as far as I know the result of this operation is undefined but luckily works in most architectures. Much better would be "move (array1[0],array2[0],elements*sizeof(element))" but even in this case the result is undefined, but it is a bit more exact as the programmer is not assuming that the array pointer is the same address as the first element. So nobody can copy an array accessing its identifier, but at least accessing the first element, assuming that data is contiguous. -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] XML Iteration
Lee Jenkins escreveu: Frank Church wrote: I am having some problems with XPath. EvaluateXPathExpression raises exceptions with some search strings and I am not sure if it is my limited knowledge of XPath, or a buggy XPath implementation. The attached demo uses the example from http://www.w3schools.com/xpath/xpath_examples.asp and I am running 0.9.28.2 beta on Windows I'm trying to put together a simple test application for xpath now and I've noticed, there doesn't seem to be a way in fpc xml implementation to simply save to a string, an xml document or node. ReadXML() ReadXMLFile() All have no implementation to write a value to a string, only Text, Stream and File. I have to create an intermediary stream, save it to that and then convert that to string or use TStringStream in order to convert them to a string. Odd. Also the wiki page: http://wiki.freepascal.org/XML_Tutorial#Create_a_TXMLDocument_from_a_string May be this can help you: procedure Str2XmlFile(var XmlTree: TXMLDocument; const S: String); var Stream: TStringStream; begin Stream := TStringStream.Create(S); try ReadXmlFile(XmlTree, Stream); finally Stream.Destroy; end; end; Luiz Is incorrect. The example will error out because the string passed in is interpreted as a file path, not as a string representation of an xml document. -- Warm Regards, Lee ___ 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] dynamic array contents and system.move
On 04/05/2010 20:11, "Vinzent Höfler" wrote: I fear you've simply no clue about the usage, internals and purpose of dyn. arrays so I stop this discussion. As you always do once someone does not share your point of view, even after you tried so hard to convince him. :P Well, never mind. Still, dynamic arrays are a bitch, because they only *pretend* to be arrays up to a certain point. Comparing this data type with classes, or even file type (thus, records) is pointless, because those types do not have a counterpart like the dynamic array has in the form of the "static" array. A class is a class - is a pointer^Wreference type. Always. Ever. In every context. In contrast, an array is an array is - yes, either an array or a pointer. Maybe. Is it really that hard to admit to the fact, that the design of dynamic arrays makes promises which the abstraction can't keep, rather than neglecting this fact each and every time this discussion comes up? Yes, of course, a dynamic array is a precise data type you should know how to handle. This would be the end of discussion if it were the only array-like data type. Unfortunately, the point of reference is the old style static array which the dynamic counter-part tries to resemble - and fails to do so. The dynamic array simply fails the principle of least surprise. No more, no less. Then the problem is the name, even so it has a different name "dynamic array" versus "static array". They have many difference. And I never heard any one complaining about the other differences: Size: Fixed for static Variable for dynamyc Initialization None for static (declare it, and access it) SetLength for dynamic (access, it before (via []) and get an error) So why is it a problem, that one is a pointer, and the other not? Because it is easier, or more often overlooked. Then maybe that's a fault of the documentation, not of the data-type? To me the data-type itself has no surprises at all. But it did need proper learning of what it is supposed to be. You say "array is an array " and I ask where is that broken? An array is a collection of data elements, which can be accessed via an index (kill me, if I used the wrong words in this sentence, I am sure you can pick them and turn them against me, but I am equaly sure, you can (willingness assumed) detuct what I tried to express.) I have never found anything that says, that an array (not a static-array, just an array), always and under any circumstances must ensure that the identifier of the whole array is equal to the first data-element in the array? I don't even think there is a guarantee that all the data elements are found at consecutive addresses in memory. (which is also required in order to use move) It may be (or maybe not) that such promises are made for "static array"; but should that mean they must be made for every other type of array, for any future type of array too? Yes, of course, a dynamic array is a precise data type you should know how to handle. This would be the end of discussion if it were the only array-like data type. Unfortunately, the point of reference is the old style static array which the dynamic counter-part tries to resemble - and fails to do so. So all similar data types have to stick to the same principles? 1) then what between an - instance of a class - object (as in "type foo=object end") 2) Why bother having 2 data types at all. If they must be so equal, then they either both *must* use SetLength, or none of them must. procedure Foo; var a: Array of integer begin a[1] := 7; end; why does that crash? It doesn't crash with a static array?, and they are both array-like types. According to your words, I would expect the above to work... And now wait, before some one says that's silly. Why can they not auto-expand, auto-shrink? If I access an element, then setlength is called automatically Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
On 5/4/2010 3:11 PM, "Vinzent Höfler" wrote: The dynamic array simply fails the principle of least surprise. No more, no less. OK. You are correct. Now can we move on? Doug C. - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Vinzent Höfler schrieb: >> I fear you've simply no clue about the usage, >> internals and purpose of dyn. arrays so I stop this discussion. > > As you always do once someone does not share your point of view, Indeed, because I don't want to waste too much of my "fpc time" with writing useless emails. > The dynamic array simply fails the principle of least surprise. No more, no less. If you think so, don't waste time with writing emails, just don't use them. Period. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + 64bit Windows => anybody?
Lukas Gradl escreveu: Thanks. BTW: are you using the latest DCPCrypt? Recently I applied a lot of 64-bit fixes for DCPCrypt - extensively tested under 64-bit Linux. Once I get a 64-bit Windows FPC going, I'll test on that platform too. Latest DCPCrypt is in Lazarus-CCR git repository at SourceForge. Or released version v2.0.4.1 in downloads section. Could'nt find a version number in my copy - but there is some Mr. Geldenhuys in the Changelog, so I think I've one of your versions. You can try http://donaldshimoda.blogspot.com/2010/02/dcpcrypt-for-64-bits-is-here.html Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
> I fear you've simply no clue about the usage, > internals and purpose of dyn. arrays so I stop this discussion. As you always do once someone does not share your point of view, even after you tried so hard to convince him. :P Well, never mind. Still, dynamic arrays are a bitch, because they only *pretend* to be arrays up to a certain point. Comparing this data type with classes, or even file type (thus, records) is pointless, because those types do not have a counterpart like the dynamic array has in the form of the "static" array. A class is a class - is a pointer^Wreference type. Always. Ever. In every context. In contrast, an array is an array is - yes, either an array or a pointer. Maybe. Is it really that hard to admit to the fact, that the design of dynamic arrays makes promises which the abstraction can't keep, rather than neglecting this fact each and every time this discussion comes up? Yes, of course, a dynamic array is a precise data type you should know how to handle. This would be the end of discussion if it were the only array-like data type. Unfortunately, the point of reference is the old style static array which the dynamic counter-part tries to resemble - and fails to do so. The dynamic array simply fails the principle of least surprise. No more, no less. Vinzent. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] renaming XML element
Sorry, I messed up the structure of the example ... Am Dienstag, den 04.05.2010, 19:30 +0200 schrieb Marc Santhoff: > Example > --- > Now: > > > whatever or nothing > > ... > <nextsibling> > ... > > > Afterwards: > > > whatever or nothing > > ... > > ... > -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] renaming XML element
Hi, since I'm only rarely using XML and the DOM unit I have to ask: I need to rename an element inside an XML tree. I've learned that elements are immutable in the DOM implementation, so renaming has to be done by - makeing a new element with the new name - copying over the complete subtree (childs, attributes, #text) - attaching the new element directly after the to be renamed one - removing the old element node Is this correct? And how would I do that using the DOM implementation, I'm really not sure what methods to use ... Example --- Now: whatever or nothing ... <nextsibling> ... Afterwards: whatever or nothing ... ... All of the nodes except root may have attributes, text content and child nodes. Marc -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + 64bit Windows => anybody?
On 4 May 2010 17:50, Lukas Gradl wrote: > > Could'nt find a version number in my copy - but there is some Mr. Geldenhuys > in the Changelog, so I think I've one of your versions. I'm not in-front of my work computer, but I think I updated the *.lpk file's version number. I'll double check tomorrow. > I just use it for some DLLs - that works as expected. But they are so small, > that I'm not able to tell for shure that FPC will work correctly unter > Win64... Well, I need to try anyway, so will find out soon. > You know, some fancy GUI-Toolkit, a little bit more VCL-compatible than some > competitor from South-Africa... *runningawayasfastaspossible* :-) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + 64bit Windows => anybody?
Thanks. BTW: are you using the latest DCPCrypt? Recently I applied a lot of 64-bit fixes for DCPCrypt - extensively tested under 64-bit Linux. Once I get a 64-bit Windows FPC going, I'll test on that platform too. Latest DCPCrypt is in Lazarus-CCR git repository at SourceForge. Or released version v2.0.4.1 in downloads section. Could'nt find a version number in my copy - but there is some Mr. Geldenhuys in the Changelog, so I think I've one of your versions. I normally use FPC on an 64-Bit Ubuntu and crosscompile to windows 32 and 64 Ah, so there is hope. I just use it for some DLLs - that works as expected. But they are so small, that I'm not able to tell for shure that FPC will work correctly unter Win64... What I never tested was LCL on Win64, but I think this is not an important option for you, Graeme *g*... What is LCL? ;-) You know, some fancy GUI-Toolkit, a little bit more VCL-compatible than some competitor from South-Africa... *runningawayasfastaspossible* Lukas -- -- software security networks Lukas Gradl Eduard-Bodem-Gasse 5 A - 6020 Innsbruck Tel: +43-512-214040-0 Fax: +43-512-214040-21 -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + 64bit Windows => anybody?
Lukas Gradl het geskryf: > > I use FPC to compile Win64 DLLs. No Problems with the compiler so far, > only had some problems with UIB and DCPCrypt, Thanks. BTW: are you using the latest DCPCrypt? Recently I applied a lot of 64-bit fixes for DCPCrypt - extensively tested under 64-bit Linux. Once I get a 64-bit Windows FPC going, I'll test on that platform too. Latest DCPCrypt is in Lazarus-CCR git repository at SourceForge. Or released version v2.0.4.1 in downloads section. > I normally use FPC on an 64-Bit Ubuntu and crosscompile to windows 32 > and 64 Ah, so there is hope. > What I never tested was LCL on Win64, but I think this is not an > important option for you, Graeme *g*... What is LCL? ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TCgiApplication in cgiapp unit - mostly deprecated
Lee Jenkins wrote: > I don't think so because the framework itself doesn't incorporate any > communication protocols. Using your favorite existing Server platform (like > fpWeb/LazWeb) you write a small method for when a request comes in like the > one below to handle the request/response: > (...) OK Lee, I will wait a public release, thanks. Graeme Geldenhuys wrote: > Not 100% sure what you mean. Maybe "is it alive?" If so, yes tiOPF is > still actively being used and developed. A new branch was started > recently to work on tiOPF3 features which will include Unicode support > (but FPC is lagging behind Delphi on that one now). > > tiOPF2 is very stable for many years already - hence the reason there > are less commits than say 5 years ago, but that is just a sign that > framework+applications are working well, not that tiOPF is dead. Sorry my bad english :( but you get: "is it alive?" Thanks for the information about tiOPF! Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC + 64bit Windows => anybody?
Graeme Geldenhuys schrieb: Hi, I often hear of developers using FPC on 64-bit Linux. My development machine is the same. But I can't say I have ever heard of anybody using 64-bit Windows with FPC. Does FPC support 64-bit Windows? If so, is it stable (like 64-bit Linux) or still experimental? I use FPC to compile Win64 DLLs. No Problems with the compiler so far, only had some problems with UIB and DCPCrypt, but nothing which couldn't easily resolved... I normally use FPC on an 64-Bit Ubuntu and crosscompile to windows 32 and 64 or Windows 32 to compile to Win64 - an Win64 Installation I never used for compilation. What I never tested was LCL on Win64, but I think this is not an important option for you, Graeme *g*... regards Lukas -- -- software security networks Lukas Gradl Eduard-Bodem-Gasse 9 A - 6020 Innsbruck Tel: +43-512-214040-0 Fax: +43-512-214040-21 -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Clipboard on WindowsCE
Hello, I have previously fixed a Clipboard problem: http://bugs.freepascal.org/view.php?id=13486 Please try to upgrade to 0.9.29 (you can use a snapshot) and try again. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Clipboard on WindowsCE
Does anyone know how to activate the clipboard when programming for Windows CE? I can do it OK when programming for Win32 etc, but not for WinCE. The message when the program is run is "IndexOfCached FormatID Internal Error: Invalid FormatID 0 for clipboard". Sure enough, there are no valid formats on the clipboard (count = 0). I have tried adding formats (AddFormat) and new formats (RegisterClipboardFormat) but without success. The installed platform for Lazarus/Free Pascal is Windows XP (Home). I have been trying for months, but with zero success. It only needs to work (currently) for text as I have no need for images etc at present. Are there any missing ingredients? I have more recently downloaded Lazarus 9.28.2 (previously it was 9.26.0) and FPC 2.2.4 (previously it was 2.2.2) and still get exactly the same problem, despite compiling it on a different computer (but still XP operating system). When run with Win32 it works fine on the XP platform, but when recompiling for WinCE using virtually the same code (but modified for WinCE as done successfully for other programs not using the clipboard), it fails at runtime on the Windows Mobile 6.1 and 6.5 platforms with same message as reported originally. There are no compiler errors, so that side of it is presumably OK. It has to be to do with the implementation of the Clipboard components, doesn't it? I have tried all the options I can think of, and those suggested by others, but can get no further forward. I have even tried running Lazarus under Linux, but this does not work either. Can anyone give any more suggestions of how to overcome the problem? Any help would be gratefully received. An example of its successful implementation on Windows CE would be a great help. Regards __ Information from ESET Smart Security, version of virus signature database 5083 (20100503) __ The message was checked by ESET Smart Security. http://www.eset.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
