Recent

Author Topic: Strategy to convert a TP 5.5 application to Lazarus - "Objectification"  (Read 3733 times)

otoien

  • Jr. Member
  • **
  • Posts: 89
Re: Strategy to convert a TP 5.5 application to Lazarus - "Objectification"
« Reply #15 on: December 13, 2019, 01:02:10 pm »
Good summing up. One change that you're likely to see is that you can't cast an integer to a pointer any more, you'll find places where there's ambiguity between pointer and integers to use ptrint or ptruint which are "pointer sized integers".

Where you know that you have mandatory data structures (e.g. to match the format of data blocks arriving from an internal device) it's worth putting an explicit size check in the declaring unit's startup code and making sure that the program halts rather than relying on an assertion (which can be disabled).

MarkMLl

Thanks - one advantage now of being a physiologist that created this code and not a computer scientist, was that I was taking a rather conservative approach and think I did not use too risky coding expressions although they would be more efficient. So I suspect these problems might not surface, but who knows... With respect to memory allocations, I think I was pretty consistent with using new and dispose, which would account for the size of the data structures and and not malloc and free. It is only when reading binary files that data structure size has to be taken into account, but I have already solved reading TP record structures in the parameter files containing 48 bit reals etc.

« Last Edit: December 14, 2019, 11:43:17 pm by otoien »
Unless otherwise noted I always use the latest stable version of Lasarus/FPC x86_64-win64-win32/win64

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: Strategy to convert a TP 5.5 application to Lazarus - "Objectification"
« Reply #16 on: December 13, 2019, 01:17:49 pm »
I'm /so/ glad that's small-C conservative (sorry, we had an election here yesterday).

When considering data structures etc. the things that will cause you trouble are changes in integer size and changes in alignment (i.e. the risk of padding inserted by the compiler to align 32-bit integers onto 32-bit addresses).

https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-250003.1.1

https://www.freepascal.org/docs-html/current/prog/progse32.html#x198-2030008.2

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

otoien

  • Jr. Member
  • **
  • Posts: 89
Re: Strategy to convert a TP 5.5 application to Lazarus - "Objectification"
« Reply #17 on: December 14, 2019, 01:17:42 am »

Thanks, I will keep my eyes out of these kind of problems.
Unless otherwise noted I always use the latest stable version of Lasarus/FPC x86_64-win64-win32/win64

guest64953

  • Guest
Re: Strategy to convert a TP 5.5 application to Lazarus - "Objectification"
« Reply #18 on: December 14, 2019, 05:57:17 pm »
First having it to build with FPC is a success. Keep this original codebase then fork it. Modernize the fork by rewriting it using Object Pascal (both Delphi mode or ObjFPC mode should be fine).

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: Strategy to convert a TP 5.5 application to Lazarus - "Objectification"
« Reply #19 on: December 14, 2019, 06:38:50 pm »
Quote
Unfortunately I've not had time to look at FPC's support of AVR yet, but I would like to say that while Eclipse's Arduino stuff works it makes Lazarus look ****ing good: the startup time is around 35 seconds and there's so much functionality that it obscures the basic purpose.

Yup. But my electronics are, as said, dspic based, but that Java contraption is slow too (but Netbeans based)

Make that 65 seconds for Eclipse to fully initialise: is this really the best that the "mainstream developer community" can do?

I've had an interesting exchange in the Arduino forum about an itch I'd scratched and written up, and am told that the IDE developers are refactoring a whole lot of stuff to make it easier for an arbitrary IDE to call the compilers etc. https://github.com/arduino/arduino-cli

I've been eyeing up the deficiencies of the Arduino IDE for a long time, and it occurs to me that it's so easy to knock a UI together using Lazarus that a moderate amount of work could produce something vastly better than the opposition.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

otoien

  • Jr. Member
  • **
  • Posts: 89
Re: Strategy to convert a TP 5.5 application to Lazarus - "Objectification"
« Reply #20 on: December 14, 2019, 11:12:22 pm »
Quote
Unfortunately I've not had time to look at FPC's support of AVR yet, but I would like to say that while Eclipse's Arduino stuff works it makes Lazarus look ****ing good: the startup time is around 35 seconds and there's so much functionality that it obscures the basic purpose.

Yup. But my electronics are, as said, dspic based, but that Java contraption is slow too (but Netbeans based)

Make that 65 seconds for Eclipse to fully initialise: is this really the best that the "mainstream developer community" can do?

I've had an interesting exchange in the Arduino forum about an itch I'd scratched and written up, and am told that the IDE developers are refactoring a whole lot of stuff to make it easier for an arbitrary IDE to call the compilers etc. https://github.com/arduino/arduino-cli

I've been eyeing up the deficiencies of the Arduino IDE for a long time, and it occurs to me that it's so easy to knock a UI together using Lazarus that a moderate amount of work could produce something vastly better than the opposition.

MarkMLl

The mikroPascal compiler/IDE I am using with dsPIC microcontrollers (all from dsPIC 30F4013 to dsPIC33EP512MU814) and PIC24 chips load in about 4 seconds, and has many nice features, particularly abstraction of chip pins, access to the chip definitions, and lots of libraries for different devices built in. There is also a separate visual development environment (VTFT). However bug fixing, especially in the IDE has been close to non-existent in the last few generations, so I am using an IDE a couple of versions back (which did not have some of those bugs) with the latest compiler. Yesterday an implied answer to the lack of bug fixing came: All the resources seems to have been used to create a new IDE (NECTO) based on QT5 and the Katy editor that will milk users for more money. The Pascal versions are several years into the future. How I wish the current compiler had been open source and written in/based on the Lazarus IDE!
« Last Edit: December 14, 2019, 11:55:12 pm by otoien »
Unless otherwise noted I always use the latest stable version of Lasarus/FPC x86_64-win64-win32/win64

 

TinyPortal © 2005-2018