Re: [fpc-pascal] Migrate Delphi XE5 to FPC/Lazarus, any advice?
On 07.06.2018 12:04, Bo Berglund wrote: I found this when searching but it is dated back in 2007 so it does not cover how to deal with the string to unicode string change in Delphi 2009 and forward Which might be a major issue as Delphi uses UTF-16, While Lazarus uses UTF-8. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Migrate Delphi XE5 to FPC/Lazarus, any advice?
On Thu, 7 Jun 2018 12:44:10 -0500, R0b0t1 wrote: >Can you explain the functionality now missing from GLScene that can't >be added back? If I remembered correctly I tried to use GLScene 1.0.something instead of the older version 0.8.2 and the showstopper was that the Canvas property had been removed in the 1.x version and this was heavily used throughout the code. Since I was just porting the code without understanding the inner workings I could not work around it so I returned to 0.8.2 and patched this for the unicode changes. The software I am looking at consists of 3 seprate projects for 1D, 2D and 3D processing. I think I will change foot here and look at the 1D first since this is a pure Delphi native application. Uses Delphi's own graphics. 2D uses GLScene for graphics and 3D is mainly a C++Builder project with some parts implmented using Delphi and the graphics via VTK (which no longer supports Borland compilers). I think 3D is out for FPC... -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
Am 07.06.2018 um 12:42 schrieb Martok: What actually happens is that the memory is released back to the heap (but *not* to the OS, at least on Linux), with the result that concatenating elements will introduce a substantial hit particularly if space for a new element allocated from the heap isn't contiguous. Writing a preallocating wrapper *where needed* for heavily grown arrays is fairly simple. The thing is: it's rarely worth it ;-) I recently did that for a wavefront mesh loader that appends vertices one-by-one to an array, and for a scene with some 400k vertices, the difference was just some milliseconds out of several seconds overall. Turns out the allocator usually finds a spot where the array doesn't need to actually be copied around for a while, and the pure bookkeeping of realloc is very cheap. It would be worth though to think about extending the memory manager to make use of the realloc syscall (not sure about its actual name) on some OSes as the OS can "copy" memory to a different virtual address by just re-mapping pages. I think at least linux really does this. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Migrate Delphi XE5 to FPC/Lazarus, any advice?
On Wed, Jun 6, 2018 at 10:25 AM, Bo Berglund wrote: > I have this big tomographic data interpretation and visualization > program on my hands for maintenance. It was started back in 2002 by > another developer using Delphi7 and the main development was done up > until 2009 using D7, BDS2006 and RAD2007 by the same guy, who then > left. > Later on when I took over maintenance I unicodified it and updated the > GUI using Delphi XE5 back in 2014-15. I also had to patch the GLScene > code to make it work, not much but essential. > > Now in view of the way Embarcadero is licensing the development system > I am thinking about moving over to FPC/Lazarus instead. New functions > have been called for and the original developer is able to consult. > > So I am looking for advice on what to think about when doing this > migration to FPC. > The project uses an older version of GLScene, which cannot be replaced > by any current version because of the way GLScene obsoleted methods > and properties in the older versions such that I never could make it > work back in 2014, hence the unicode patch of the older version. > Apart from this it only uses standard functions in Delphi as far as I > know. Plus our own components, which we have full control over... > > Suggestions, links etc appreciated! > Yours is a very interesting problem (so please keep the list updated on it if you can), but one that Lazarus and FPC are a very good fit for. Most of the functionality that is hard to duplicate is found in the newer versions of Delphi, such as libraries that rely on anonymous functions and so on. Have you attempted to port the code? People will probably be able to help better if they are aware of specific problems you are having. Can you explain the functionality now missing from GLScene that can't be added back? You may need to maintain your own patches to that component, but I fail to see how it would be impossible to bring forward. This isn't to say bringing it forward will be trivial, but even if it is not, getting your codebase compatible with Lazarus/FPC is likely a good longer term goal. Cheers, R0b0t1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
Mark Morgan Lloyd schrieb am Do., 7. Juni 2018, 11:46: > On 04/06/18 12:00, Nitorami wrote: > >>> It would be reasonable to assume that the predefined + might be>> > substantially more efficient than a programmer-defined one could be. > >> Yes, that's one of the reasons I vote for keeping the new feature>and > allow to overload the operator. > > I don't think that argument holds water. Concatenation of dynamic > structuresis a slow function in the first place. I am not a core developer, > but Iconsider that regardless how you do it, it will require a call to > setlength,which in turn will call the operating system to allocate memory > for the nowlarger structure. That takes much more time than a few assembly > instructionsfor a normal pascal procedure call. > > The obvious workaround is to preallocate a dynamic array to a nominal > size and then to trim it using SetLength(0), I'd assumed that it would > retain ownership of the memory but I've just checked. > > What actually happens is that the memory is released back to the heap > (but *not* to the OS, at least on Linux), with the result that > concatenating elements will introduce a substantial hit particularly if > space for a new element allocated from the heap isn't contiguous. > Of course SetLength(0) releases the memory as the value of a dynamic array with length 0 is Nil, so nothing can be saved there. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
On 07/06/18 10:45, Martok wrote: What actually happens is that the memory is released back to the heap > (but *not* to the OS, at least on Linux), with the result that > concatenating elements will introduce a substantial hit particularly if > space for a new element allocated from the heap isn't contiguous.Writing a preallocating wrapper *where needed* for heavily grown arrays isfairly simple. The thing is: it's rarely worth it ;-)I recently did that for a wavefront mesh loader that appends vertices one-by-oneto an array, and for a scene with some 400k vertices, the difference was justsome milliseconds out of several seconds overall.Turns out the allocator usually finds a spot where the array doesn't need toactually be copied around for a while, and the pure bookkeeping of realloc isvery cheap. The bit of code I was looking at was a mainframe emulator reading a tape to find the block positions, I was appending elements individually using a user-defined + and it wasn't exactly fast (resulting in a tape load time probably slower than the hardware would have had 60 years ago)... although obviously not as bad as Nitorami's suggestion that every concatenation would result in a syscall. I'd been expecting that SetLength() would do the same as it does with a string, i.e. prune the valid range without releasing memory. What I've done so far is only interim code and I've got lots of ways round it, but the reality check was useful :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
> What actually happens is that the memory is released back to the heap > (but *not* to the OS, at least on Linux), with the result that > concatenating elements will introduce a substantial hit particularly if > space for a new element allocated from the heap isn't contiguous. Writing a preallocating wrapper *where needed* for heavily grown arrays is fairly simple. The thing is: it's rarely worth it ;-) I recently did that for a wavefront mesh loader that appends vertices one-by-one to an array, and for a scene with some 400k vertices, the difference was just some milliseconds out of several seconds overall. Turns out the allocator usually finds a spot where the array doesn't need to actually be copied around for a while, and the pure bookkeeping of realloc is very cheap. -- Regards, Martok Ceterum censeo b32079 esse sanandam. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Migrate Delphi XE5 to FPC/Lazarus, any advice?
On Wed, 06 Jun 2018 17:25:21 +0200, Bo Berglund wrote: >Suggestions, links etc appreciated! I found this when searching but it is dated back in 2007 so it does not cover how to deal with the string to unicode string change in Delphi 2009 and forward https://www.freepascal.org/~michael/articles/lazport2/lazport2.pdf -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
On 04/06/18 12:00, Nitorami wrote: It would be reasonable to assume that the predefined + might be>> substantially more efficient than a programmer-defined one could be. Yes, that's one of the reasons I vote for keeping the new feature>and allow to overload the operator. I don't think that argument holds water. Concatenation of dynamic structuresis a slow function in the first place. I am not a core developer, but Iconsider that regardless how you do it, it will require a call to setlength,which in turn will call the operating system to allocate memory for the nowlarger structure. That takes much more time than a few assembly instructionsfor a normal pascal procedure call. The obvious workaround is to preallocate a dynamic array to a nominal size and then to trim it using SetLength(0), I'd assumed that it would retain ownership of the memory but I've just checked. What actually happens is that the memory is released back to the heap (but *not* to the OS, at least on Linux), with the result that concatenating elements will introduce a substantial hit particularly if space for a new element allocated from the heap isn't contiguous. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
