Future of mecbox format?

[Martin Wynne]

@Alistair Ward @graeme

Hi Alistair, Graeme,

Did one of you, or did I dream it, post to say that you had a new 64-bit float file format working for saving template box files from T3?

The reason for asking is that I'm wondering what to do about the .mecbox format which I created for interchange of data between T2 and T3. It's based on the old Windows .ini text-based format.

I've been doing a lot of work recently in math_unit.pas on creating DXF and STL exports for 3D printing and laser cutting, which you have probably seen:

https://85a.uk/templot/club/index.php?forums/plug-track.34/

There are many consequent additions to the latest .box files which I haven't yet added to the mecbox files. I'm wondering whether there is any point in doing so, bearing in mind:

it is a lot of tedious work, and

the ability to read and/or make use of the changes is missing from T3.

I'm wondering if it would be possible to continue using the 80-bit extended float format in T3? And therefore be able to read .box files directly from T2? I could find no easy way of doing that originally for T3, hence the mecbox format. But it has dawned on me very late in the day, that Linux+Wine handles the 80-bit extended format just fine. The .box files from T2 on Windows are loaded and used just fine in T2 running on Linux+Wine, with Microsoft and Windows nowhere in sight. If Linux can do it, why not T3?

If it is possible, the entire mecbox format can be ditched, thank goodness. I know binary files are frowned on, but they are just so much easier to code than writing for XML or other text-based formats.

Talking of math_unit.pas, it is next on my alphabetical list for posting the T1 files. I've been holding back because at present I'm making changes to it on an almost daily basis. But on that basis I never will get it posted, so maybe I should just post it as-is at some arbitrary cut-off point, such as 31st December?

Also dxf_unit.pas and dxf_unit.dfm have seen massive changes since I originally posted them as T1 files, with many more changes to come, so it would be best to ignore those, and wait for a similar arbitrary cut-off for them too.

cheers,

Martin.

 

[Martin Wynne]

.
p.s. to the above.

A couple of links which may or may not be helpful. Can any of this stuff be kludged into Lazarus?

https://www.linuxtopia.org/online_books/an_introduction_to_gcc/gccintro_70.html

https://www.vinc17.net/research/extended.en.html

Martin.

 

[graeme]

Hi Martin,

Sorry for not replying sooner, but I did not get an email notification for this post, for some reason, though the follow-up with the links came through fine (and thank you for those - I will take a look this week).

Anyway, to summarise our current position/thoughts:

• The extended format is not supported on all platforms, and in fact Lazarus actually implements it as double behind the scenes on platforms where it is not supported (which is most of them, of course) so in order to have any chance of cross-platform-ness we have had to eliminate extended and replace it everywhere with double.
• Some while ago I wrote a routine which would take an extended field as an array of bytes and return a double with the corresponding value. I then used this to read a T2 file into a byte array and pick it apart, dumping out the individual fields. This was just a proof of concept, and I am sure that the code will have fallen behind the latest version of the file, but my intention is for it to form the basis of the ability to read T2 files directly. (I don't recall mentioning this before, being just a PoC, but I may have done, and that could be behind your feeling that we already had something working.)
• We do intend to use a text-based format at some stage in the future to aid the cross-platform goal, but that is probably some way down the track and not likely to be based on the ini format.

The net result of all this is that we are agreed that it would not be a problem for us if you were to drop the mecbox format, particularly if it can save you some work.

The main thing we do need is the latest layout of the box file format as it changes (as represented in keep_select).

As regards the math unit, Alistair is doing far more in that area than I am, so I will defer to him on that one.

Thanks and cheers,

Graeme

 

[Martin Wynne]

@graeme @Alistair Ward

Hi Graeme,

Thanks for the reply. Before working on the .mecbox format I did write some code in Delphi to create an 8-byte version of the .box file format. Delphi is happy to allow extended values to be assigned to doubles, and performs the conversion automatically (or the FPU does). It wasn't too difficult to write a one-way conversion, just tedious. I think I called it .otbox or .box3 and you may see some references to it. The snag is that there is no way in Lazarus to write a reverse conversion from doubles to extended, so it would be a one-way traffic for the data from T2 to T3, although in theory I could also write an inbound conversion in Delphi. Perhaps I should have persevered with it.

The net result of all this is that we are agreed that it would not be a problem for us if you were to drop the mecbox format, particularly if it can save you some work.

Thanks -- that was my main reason for posting.

The main thing we do need is the latest layout of the box file format as it changes (as represented in keep_select).

Yes. The .box file format is constantly changing (I have made some changes today), but I am planning to release a program update later tonight, so I will post the current versions of math_unit and keep_select as soon as that's done.

I saw on Github that Alistair is working in math_unit and has created a new TCurve class, using an external library for the transition calculations. Being on Github means I can barely fathom the details of it or how it fits into which version of Templot, or for what purpose, but I shall be interested to learn more about it.

cheers,

Martin.