OpenTemplot2024

[Martin Wynne]

That's a shame; we somehow need to clone you.

@nickom

Hi Nick,

What do you need to know? Users of Templot don't need to know the internal structure of a BOX file.

But if you do want to know it is all in the code files.

See the save_box() function in keep_select.pas which I uploaded earlier, and the declarations in bgkeeps_unit.pas which I shall upload shortly. Now uploaded.

function save_box(this_one, which_ones, rolling_backup:integer; save_str:string):boolean;

// new file format including text 17-2-00. (v:0.48 on).
// newer file format including unlimited shoves in StringList 1-5-01 (v:0.71.a on).

    // this_one       = if which_ones=-1, save only this index (echo, etc.)
    // which_ones     = -1 = this_one index only, 0=all templates  1=bgnd templates only  2=unused only  3=selected group only  4=library only   234a: 5=selected group are brick templates
    // rolling_backup = 0=normal save, 1=running backup,  -1=final backup on exit.
    // save_str       = if not '', is the path and file name to use, so don't ask him. (0.76.a 20-5-02).

// The 071 file format is the same as the 048 format with the addition of "Data Blocks" at the end of the file.
// To create the 048 format the shove timber data is duplicated in the template data record (first 30 shoved timbers only).

// The Data Blocks section commences with a byte containing an underscore character '_',
// Then 7 more bytes containing '85A_|.x' , where x is the version build letter  (ASCII single-byte characters).
// Then a 16-byte starter record containing the version info and 12 bytes of zeroes (spares):

//        Tblock_start=record
//                       version_number:integer; // the Templot version number.
//                       zero1:integer;          // 12 spares (zero)...
//                       zero2:integer;
//                       zero3:integer;
//                     end;

// Each DATA BLOCK comprises:

// 16 byte Tblock_ident comprising...

// 4 bytes = length of data segment x.
// 4 bytes = template index count.
// 4 bytes = code indicating content of block.  10 = shoved timbers,   20 = symbols
// 4 bytes = spare - set to zero.

// then x bytes = data segment.

// DATA BLOCKS are repeated until the END BLOCK, which comprises

// 16 byte Tblock_ident comprising all zeroes (segment length=0).

I will explain it all when I release a few more files. I explained it once before, but there have been quite a few changes since.

cheers,

Martin.

 

[Martin Wynne]

@nickom @NoIdea

Hi Martin, Nick,

Someone was asking for a breakdown of the binary part of a BOX file. I have now uploaded the current version of bgkeeps_unit.pas which contains the declarations. See:

https://85a.uk/templot/club/index.php?posts/11294

cheers,

Martin.

 

[nickom]

Hi Martin W, (just realised there are 2 Martins )
The chatGPT output was a very quick test to determine what it knew about Templot, the output was based on its model created sometime in 2023. "It noted that there is very little information about Templot available, so guessed based on how other similar tools work).

Anyway it could be a viable option if it was trained with actual questions and answers. I asked about the Box file format as a test, I suppose you never get any questions about this? I should have asked a higher level question about how to create a turn out , or even just a simple question how to get started.

On a general point about Templot, its future, should the bus situation occur, is important, but the solution to this is entirely in your gift.

Regards
Nick

 

[NoIdea]

Martin,

Can I just check the purpose of uploading these files?

https://85a.uk/templot/club/index.php?threads/opentemplot2024-files-ex-delphi5.926/

Am I right in assuming that these are copies of your working files that are modified in some way, not least adding copyright notices?

Martin

 

[Martin Wynne]

Martin,

Can I just check the purpose of uploading these files?

https://85a.uk/templot/club/index.php?threads/opentemplot2024-files-ex-delphi5.926/

Am I right in assuming that these are copies of your working files that are modified in some way, not least adding copyright notices?

Martin

@NoIdea @nickom @James Walters

Hi Martin,

The last time I released my Templot files as open-source was in 2018/2019.

Since then there have been a great many developments in Templot, not least the 3D plug track, with the result that those files are very out-of-date. I have been meaning for some time to release the current files as open-source -- so that if the dreaded bus does its worst, the latest code will be out there for anyone who wants to pick it up and run with it.

I did say a week or two ago that after releasing 244c I would do that. But it's quite a lot of work to tidy up the files and release them, and there didn't seem much urgency in view of the seeming lack of interest in them.

But the open source topics have come alive on here in the last few days, so I thought I would get on with it and get them released now. So that you and Nick and anyone else can have the latest code to work with.

These files are my current working files in Delphi5, released as-is. But with the addition of an updated copyright notice, and tidied up with a lot of commented-out stuff and other junk removed (I tend to use the PAS files as a jotter for all sorts of related notes, web links and bits of emails, etc.).

There are about 80 PAS files and 80 DFM files, so it is going to take me a while to work through them. There probably isn't a lot you can do with them until I have done all of them, but I can't do them all in one go. I thought you might like to see them as I work through them. When I've got them all done I will put them in a single ZIP, and then probably delete the 2018 files off the server.

As I develop Templot further I will try to release the files more often, a 6-year gap is daft. But without the interest in them there wasn't much incentive to get on with it.

Also of course, no-one is going to offer help with the chairs if they can't see the code. I'm hoping that there might be someone out there who would say "leave the GWR chairs to me". Or the flat-bottom baseplates, or whatever. I still have the REA K-crossing chairs to do and the slab & bracket variants, so it's going to be slow going if I have to do it all myself. Scaleforum is only 3 months away now.

cheers,

Martin.

 

[Martin Wynne]

I asked about the Box file format as a test, I suppose you never get any questions about this? I should have asked a higher level question about how to create a turn out , or even just a simple question how to get started.

@nickom @NoIdea

Hi Nick,

You have rather lost me there. No-one needs to ask chatGPT about Templot when they can come here to get started and get the genuine information, see:

https://85a.uk/templot/companion/templot_explained.php

https://85a.uk/templot/companion/basic_working_methods.php

https://85a.uk/templot/companion/origins_intent.php

And lots of videos to watch at:

https://85a.uk/templot/companion/online_video_list.php

I'm not too clear how you "train" chatGPT? If you put stuff on a web page for it to read, surely folks can read it there for themselves? What am I missing?

cheers,

Martin.

 

[NoIdea]

Martin,

Got you. But isn't going to be a bit tedious releasing and re-releasing files as zip files?

Would you consider using something like Git instead? It can be set up in such a way that only you can commit, but everyone else can read, or only specific individuals can read.

From your point of view it would be a lot less hassle keeping stuff in sync - a bit of up-front learning will pay dividends later. After Git is set up it's write some code, commit, write more code, commit...

Apart from copyright notices I don't think anyone will mind about the state of the code.

And you can gitignore files that can't be open sourced.

From our point of view we just 'git pull'...

I'm happy to put together a detailed guide if that helps?

Martin

 

[nickom]

Hi Martin,

This is a long shot, and I'm probably way off track (pardon the pun). Could contributors of chairs or even other 3D components design them in 3D and output them in Step format, then come up with a way to convert these into a necessary format to be included in the template? Maybe even have a function to import them as step files rather than having to hard code every time a new design comes along.

Regards
Nick

 

[Martin Wynne]

Martin,

Got you. But isn't going to be a bit tedious releasing and re-releasing files as zip files?

Would you consider using something like Git instead? It can be set up in such a way that only you can commit, but everyone else can read, or only specific individuals can read.

From your point of view it would be a lot less hassle keeping stuff in sync - a bit of up-front learning will pay dividends later. After Git is set up it's write some code, commit, write more code, commit...

Apart from copyright notices I don't think anyone will mind about the state of the code.

And you can gitignore files that can't be open sourced.

From our point of view we just 'git pull'...

I'm happy to put together a detailed guide if that helps?

Martin

@NoIdea @nickom

Hi Martin,

Over the years I have spent many hours trying to fathom Git, but it's beyond me. Graeme spent some time trying to explain it to me but got nowhere. Over the years I've installed bits of Git programs and uninstalled them, and then done it again, likewise a Mercurial thingy. I've never understood what I was doing.

I think the problem is that my way of working with code just isn't compatible with how Git is intended to work. Invariably I have several files open at once, jumping to and fro between them, adding bits here, taking bits out there, moving chunks of code around. If I uploaded a file to Git today, I would be deleting it tomorrow and replacing it with something else. in the meantime someone might have downloaded it and found it incompatible with something I uploaded the day before. Leading to a lot of time-consuming explanations, going round in circles.

I think the best way of proceeding is that each time I release a Templot program update, before going any further I should zip up all the files and post them here. That's usually about every 4-6 weeks or so, which isn't long enough to get them into too much of a mess.

Then if you or anyone else wants to put them into a Git thingy, that's fine by me. Just don't expect me to understand what's going on there.

If I can see that the files are being at least looked at, I can probably keep up to date with it. But for much of the time over the last 6 years I would have been posting them into fresh air, and then there isn't much incentive to do it.

cheers,

Martin.

 

[nickom]

Hi Martin,

ChatGPT does't have access to the internet , it bases its output on trained data, which in turn is improved the more people ask questions, correct the answers etc.

The Templot website provides a comprehensive guide on how to use templot , but people are lazy, they want quick answers , I guess this is why you get so many support questions? ChatGPT isn't necessarily the answer to this , but with enough questions being asked and validated answers (say by you) being provided it will eventually be the Martin Wynne AI support tool, then as new functionality gets introduced there will be more topics that need support , further adding these into ChatGPT will then take over answering for you. Essentially you will only need to work with the AI to provide the ground truth information, rather than having to answer the same question over and again.

 

[nickom]

I asked it the following, the answer it gave is probably incorrect, but would be accurate if it was either corrected or was provide with the correct answer.


if i wanted to use chatgpt to help with supporting detailed questions about Templot, can you then take over as the way people get support for these questions

While I can't directly take over as the primary support mechanism for Templot or any other specific software, I can certainly help provide detailed answers to questions about Templot and other topics. Here are a few ways you can use ChatGPT to support detailed questions about Templot:

1. Providing Detailed Instructions and Tutorials​

I can provide step-by-step instructions and tutorials for common tasks and problems in Templot. For example:

• How to set up and configure Templot for a specific gauge.
• How to design a particular type of track layout.
• Troubleshooting common issues with Templot.

2. Answering Specific Questions​

Users can ask specific questions about using Templot, and I can provide detailed answers. For example:

• How to import and scale an OS map in Templot.
• How to create a specific track template or layout.
• How to export designs from Templot.

3. General Tips and Best Practices​

I can offer general advice on best practices for using Templot effectively. This might include tips on:

• Organizing and managing your Templot projects.
• Optimizing performance and efficiency.
• Ensuring accuracy and precision in track design.

4. Supplementary Learning Resources​

I can suggest additional resources, such as tutorials, forums, and documentation, where users can learn more about Templot.

Example Interaction for Templot Support​

User: How do I import an OS map into Templot and scale it for a P4 gauge layout?
ChatGPT: Here's a step-by-step guide to import and scale an OS map in Templot for a P4 gauge layout:

1. Obtain an OS Map: Acquire a digital version of the OS map you want to use. Ensure the map is in a high-resolution image format such as JPEG, PNG, or BMP.
2. Prepare the Map Image:
   • Save the map image to your computer.
   • Use image editing software to crop the image to the specific area you want to model, if necessary.
3. Open Templot and Set Up the Project:
   • Launch Templot and create a new track plan.
4. Import the OS Map Image into Templot:
   • Go to the Background menu and select Background Shapes.
   • Click Add, and then choose Image.
   • Locate and select the OS map image file you saved.
5. Scale and Position the Map:
   • Use the F3 mouse action to adjust the position of the map on your workspace.
   • To scale the map to the correct size, use the F4 mouse action. You may need to know the scale of the OS map and the corresponding scale for your layout.
   • For P4 gauge (1:76.2 scale), calculate the conversion factor from the OS map scale to the model scale. For example, if the OS map is 1:25,000, 1 cm on the map equals 250 meters in reality. In P4 scale, 250 meters / 76.2 = 3.28 meters in the model.
6. Verify the Scale:
   • Cross-check specific distances on the map with your model layout to ensure accuracy.
   • Use a ruler or measuring tool within Templot to measure distances on the imported map and confirm they match your scale calculations.

By following these steps, you can accurately import and scale an OS map in Templot for your P4 gauge layout.

Conclusion​

While I can't replace a dedicated support team, I can provide substantial assistance with detailed questions and instructions related to Templot. For continuous and real-time support, combining my capabilities with a dedicated support forum or team might offer the best results. If you have any specific questions or need detailed help with Templot, feel free to ask!

 

[Martin Wynne]

1. Obtain an OS Map: Acquire a digital version of the OS map you want to use. Ensure the map is in a high-resolution image format such as JPEG, PNG, or BMP.
2. Prepare the Map Image:
   • Save the map image to your computer.
   • Use image editing software to crop the image to the specific area you want to model, if necessary.

@nickom

Hi Nick,

NO.

Templot can fetch map tiles directly and scale them for you. There is a perfectly good video explaining how to do that at:

https://85a.uk/templot/companion/get_map_from_the_web.php

The correct answer from ChatGPT would be to provide the above link. Which is just as easily found via Google, etc., or at:

https://85a.uk/templot/companion/hmkwindex.php

As far as I can see ChatGPT will just lead folks up the garden path with meaningless waffle.

cheers,

Martin.

 

[nickom]

Hi Martin,

That's no problem. I'm not trying to force anything on you; I'm only throwing ideas into the hat with the goal of reducing the support burden.

The next option (I'm sure there are others) would be to recruit a group of volunteers who are conversant enough with the software and willing to support beginners in getting to grips with the software.

What do you see as the major barriers to wider adoption by the Railway Modelling community.

Regards
Nick

 

[Martin Wynne]

Hi Martin,

This is a long shot, and I'm probably way off track (pardon the pun). Could contributors of chairs or even other 3D components design them in 3D and output them in Step format, then come up with a way to convert these into a necessary format to be included in the template? Maybe even have a function to import them as step files rather than having to hard code every time a new design comes along.

Regards
Nick

@nickom

Hi Nick,

I don't really see how that can work. Take for example a BB crossing chair. Apart from being scaled up or down, it has to be generated to match the currently selected rail section. At the required crossing angle. With the required flangeway gap. And then inserted at the required location, aligned onto the rail, with an option for the outer jaws to be loose.

So given say a CAD file for a 1:6 BB chair with a 1.0mm flangeway gap to match C&L rail, how would Templot insert it for say 1:6.83 crossing angle with a 0.8mm flangeway gap to match SMP rail?

At present Templot starts with the required dimensions and then generates a chair to suit. Each crossing chair in a track plan could be unique and different from all the others.

I think it best if I get the files released so that folks can see how the existing code works, and then possibly feel able to write something similar for other needed chairs.

cheers,

Martin.

 

[Steve_Cornford]

Hi Nick, I think you will already find that there such volunteers with membership of the Templot club, and that we do try and help others, but Martin often beats us to it.
It seems to me that becoming reliant on the guesses that the Chatterbox thingie spreads is not helpful and will only result in Martin and others wasting time correcting misinformation, as has just been demonstrated above.
Steve

 

[nickom]

Hi Nick, I think you will already find that there such volunteers with membership of the Templot club, and that we do try and help others, but Martin often beats us to it.
It seems to me that becoming reliant on the guesses that the Chatterbox thingie spreads is not helpful and will only result in Martin and others wasting time correcting misinformation, as has just been demonstrated above.
Steve

Hi Steve, That's good to hear. The future looks bright for Templot.

 

[Martin Wynne]

Hi Martin,

That's no problem. I'm not trying to force anything on you; I'm only throwing ideas into the hat with the goal of reducing the support burden.

The next option (I'm sure there are others) would be to recruit a group of volunteers who are conversant enough with the software and willing to support beginners in getting to grips with the software.

What do you see as the major barriers to wider adoption by the Railway Modelling community.

Regards
Nick

@nickom

Hi Nick,

Thanks for that.

I enjoy designing Templot and making it work, and I'm happy to share it with anyone else interested. How widely that is within the railway modelling community is really up to them, it doesn't directly make any difference to me.

But sharing is not the same as throwing it at folks and telling them to get on with it. If I invite someone to share it they can reasonably expect some help and advice in using it. But how to manage that without it taking over my entire hobby time is something I've never been able to work out.

The essential problem is the time imbalance between question and answer. A question might take a couple of lines to ask, and take 5 minutes to post. A full answer and explanation can easily take me a whole evening to prepare, with screenshots and diagrams, or sometimes making a video clip. Two or three of those, when I was hoping to get on with some coding, or some 3D printing, and you can see that it can get very frustrating. And nowadays tiring too. But what the solution is I just don't know, even after all these years.

cheers,

Martin.

 

[Rusty]

I think the problem is that my way of working with code just isn't compatible with how Git is intended to work. Invariably I have several files open at once, jumping to and fro between them, adding bits here, taking bits out there, moving chunks of code around. If I uploaded a file to Git today, I would be deleting it tomorrow and replacing it with something else. in the meantime someone might have downloaded it and found it incompatible with something I uploaded the day before. Leading to a lot of time-consuming explanations, going round in circles.

I think the best way of proceeding is that each time I release a Templot program update, before going any further I should zip up all the files and post them here. That's usually about every 4-6 weeks or so, which isn't long enough to get them into too much of a mess.

Then if you or anyone else wants to put them into a Git thingy, that's fine by me. Just don't expect me to understand what's going on there.

It's a real shame that you couldn't feel comfortable with using Git, the way of working that you describe is perfectly workable and compatible with Git, however if it doesn't click then it doesn't click unfortunately. The example you give isn't a problem within Git because your upload and subsequent deletion and replacement is all recording in the Git change set. Someone else working on the files can pull in your change set and it will apply the same deletion and replacement to their files in exactly the same way you made your modifications.

With the number of users willing to help I struggle to see how that can be co-ordinated without using a version control system in one form or another. GiT is the de-facto standard and more than capable so the issue is more how all the Templot helpers can co-ordinate using Git but then respecting your difficultly with getting to grip with Git then a mechanism needs to be worked out how to maintain the Git repository with the latest version of the files with your updates without needing yourself to mess around with the Git operations. Perhaps it needs someone else to maintain the Git repository and you just send them the updated files to upload and maintain the open source repository.

The tricky part is that if one of the helpers makes a change to the code to correct a bug or add a new chair how do they feed that change back to your code base for you to include the changes in the code you are using? Fortunately using Git it's easy to generate a zip archive or a list of changes so we could generate that information for you so that you can see what has been edited by one of the helpers.

I do think with all the different offers for help with maintaining the OpenTemplot the first and overriding issue for the helpers to sort out is how to co-ordinate all the different developments via Github so that there is a central reference of a version controlled code base so everyone knows what baseline position is otherwise it it all going to get too fragmented. Only then can you start exploring opening up some of the new options, compiling under Lazarus, Typescript and Electron etc.

 

[Martin Wynne]

It's a real shame that you couldn't feel comfortable with using Git, the way of working that you describe is perfectly workable and compatible with Git, however if it doesn't click then it doesn't click unfortunately. The example you give isn't a problem within Git because your upload and subsequent deletion and replacement is all recording in the Git change set. Someone else working on the files can pull in your change set and it will apply the same deletion and replacement to their files in exactly the same way you made your modifications.

With the number of users willing to help I struggle to see how that can be co-ordinated without using a version control system in one form or another. GiT is the de-facto standard and more than capable so the issue is more how all the Templot helpers can co-ordinate using Git but then respecting your difficultly with getting to grip with Git then a mechanism needs to be worked out how to maintain the Git repository with the latest version of the files with your updates without needing yourself to mess around with the Git operations. Perhaps it needs someone else to maintain the Git repository and you just send them the updated files to upload and maintain the open source repository.

The tricky part is that if one of the helpers makes a change to the code to correct a bug or add a new chair how do they feed that change back to your code base for you to include the changes in the code you are using? Fortunately using Git it's easy to generate a zip archive or a list of changes so we could generate that information for you so that you can see what has been edited by one of the helpers.

I do think with all the different offers for help with maintaining the OpenTemplot the first and overriding issue for the helpers to sort out is how to co-ordinate all the different developments via Github so that there is a central reference of a version controlled code base so everyone knows what baseline position is otherwise it it all going to get too fragmented. Only then can you start exploring opening up some of the new options, compiling under Lazarus, Typescript and Electron etc.

@Rusty

Hi Adrian,

Welcome to Templot Club.

I think there is some misunderstanding here. As I understand it, the Git system is intended for open-source projects. There is no way that Templot2 can be an open-source program because it includes some licensed proprietary components which can't be open-sourced.

The immediate idea is to have two versions of Templot -- Templot2 which I shall continue to develop for a short while in its present form as a closed-source Windows executable. And open-source OpenTemplot2024 which is or can be a collaborative project by whoever wants to get involved in it, which hopefully would last forever.

I'm happy to release all the Templot2 code as a basis for that -- it might go off in a different direction, such as Martin's web-based version. New ideas and functions can obviously flow in both directions, but the two can't remain in perfect sync while Templot2 has extra functions such as the sketchboard engine.

I'm assuming OpenTemplot2024 would be based on Git in some way, but it won't be me putting my files on there, I've been burned by the unfathomable Git thing too many times. I shall post my files here, and if they are wanted on Git I'm happy for someone else to copy them there.

I hope that makes sense. It is only what we tried to do 6 years ago, but it never quite got off the ground.

cheers,

Martin.

 

[NoIdea]

Hi Martin,

Mercurial

Hmm.

Invariably I have several files open at once, jumping to and fro between them, adding bits here, taking bits out there, moving chunks of code around.

That's normal. A Git commit can be a single line in a single file:

"Added byte to Int8Array Intrinsic conversion"

Or loads of files:

"Merge Variable and Constant parser into Field Parser"

Or even:

"2.45a"

As I understand it, the Git system is intended for open-source projects

It's for source code version control. It's intended to be, and is, a distributed system that doesn't rely on a central server. It's real benefit is that more than one developer can work on the codebase at the same time. We use it at work for closed source internal application development.

There is no way that Templot2 can be an open-source program because it includes some licensed proprietary components which can't be open-sourced.

These files are added to a special gitignore file and are never published.

I think the best way of proceeding is that each time I release a Templot program update, before going any further I should zip up all the files and post them here.

While @Rusty's observations are valid I'm mindful of my first (and so far, only) requirement is to ensure Martin is not disturbed. In my case a zip file every six weeks works because all I'm doing is translating the code.

The downside is that contributions are much less likely.

That said, a maintainer could diff the content of the zip files and commit the changes to a Git repo. Martin, this would require additional work to put the zip file together each time.

Martin

 

[Rusty]

I think there is some misunderstanding here. As I understand it, the Git system is intended for open-source projects.

Okay - I'm beginning to see some of the misunderstanding we have here, we're talking about slightly different things but using the same words.

Git is a distributed version control system. It is an application you install on your local computer to manage your software development, it can include any code, public or commercial and the Git repository can stay local to your machine, you don't need to connect to the internet to use it. It's very good for any software development, I use it at work for our toolset development.

I suspect what you are referring to is actually GitHub, yes it has Git in the title because under the hood it uses Git version control system but GitHub is actually a internet based web front end over the top of Git. That is generally but not exclusively used by Open Source projects. Private repositories can be set up - limited to specific users for the commercial components.

Either way - it doesn't "click" for everybody and if you've been burned with it, then I can understand the reluctance to use it. To that end it is up to the helpers to find a way to manage the Templot2 code and OpenTemplot code within Git, hopefully replacing the commercial components with open sourced equivalents if they exist.

So yes for minimal disturbance to yourself then simply get the occasional zip file update would be appreciated. In the meantime I can continue the discussion with the other Martin w.r.t. code management. Please let me know if you'd like it splitting off into a different thread.

 

[Rusty]

While @Rusty's observations are valid I'm mindful of my first (and so far, only) requirement is to ensure Martin is not disturbed. In my case a zip file every six weeks works because all I'm doing is translating the code.

The downside is that contributions are much less likely.

That said, a maintainer could diff the content of the zip files and commit the changes to a Git repo. Martin, this would require additional work to put the zip file together each time.

Perhaps we need a tag, label or thread to clearly mark a discussion "Do not disturb Martin" just to indicate a response from him is not expected or required!

So I'm not sure I see why what I suggested would require additional work to put the zip file together. The Git application works out differences for us so I'm not clear what additional work you think it involves.

However my suggestion would be first try and get an update if possible from Alastair and/or Graeme on what progress they have made and their current plans to avoid duplication of effort. Unfortunately it appears they have split off their own development and ploughed their own furrow, not checked in here for over 2 years and yet still updating their local copies only 2 weeks ago. [ note Templot3 is just the name for Alistair's personal copy of the repository - he appears to still push updates back to the OpenTemplot repository.]

On GitHub OpenTemplot is listed as an organisation, presumably setup by Alistair/Graeme.

So the question is are we going to try and collaborate and work together or does OpenTemplot2024 end up being a completely separate development? They may have figured out open source replacements for the commercial components and some of the cross platform issues.

 

[nickom]

Hi All,

This topic is growing with every post, and we have a number of conflicting topics that is confusing us all, (me at least)

• Primary, objective 1
  • not cause Martin any more hassle than he already has.
• Objective 2
  • For the Templot community, succession planning.
  • To support this, Martin made the decision to open-source the project.
• Objective 3. (covered by the user community already)
  • Develop a group of power users to provide Templot support. Allowing Martin to focus on 1 and his hobby.

Current status:

• Templot is being actively developed in Delphi Pascal 5

Where we need to get to:

• Open Source Templot will need to carry on using modern (free) tools and toolchains, if we are to stand a chance of encouraging more people to pick it up

Obstacles

• We need to convert the pascal code over to Javascript (not 100% sure about this).
  • noidea is working on a code parser to do this

We need a tool to manage this:

• GitHub and Git are very complex tools but absolutely essential for open-source development. Multiple contributors invariably introduce new features and, of course, bugs .....

This whole venture will ebb and flow as people come and go, drop it and pick it back up, nothing is guaranteed, it relies on goodwill and enthusiasm.

With this in mind should we start to form a plan of action or does this defeat the point of opensource?

Thought on this:

A terms of reference or similar, nothing complex or legal or any of that, just a set of guidelines to keep us pointing in the right direction:

1. Agree with Martin the chosen Architecture and subsequent structure:

• Monolithic like Pascal is currently
• or decoupled
  • Processing engine.
  • UI
• Language
• Management tool
• How new code from the main branch is merged in to OpenSource branch.
• How often.

So on and so forth.


Regards
Nick

PS , I'm not trying to force any of these ideas onto anyone; please take what I have written as ideas, ramblings etc.

 

[Martin Wynne]

@nickom @NoIdea @Rusty @Alistair Ward @graeme

This is all getting very interesting. I've tagged in Alistair and Graeme above -- we last heard from Graeme in this topic:

https://85a.uk/templot/club/index.php?threads/opentemplot.522/

p.s. if there are now too many Martins, I'm happy to be referred to as mw.

Just a word for users of Templot2 wondering where all this is going. Nothing is changing there. I'm currently working on 244e to get the slab & bracket chair variants done, and get the chair outlines for the XN, XA, AA, BB chairs a better match to the REA 8-sided designs. This is also needed for the K-crossing chairs, so it makes sense to get it done first.

mw.

 

[Rusty]

Hi All,

This topic is growing with every post, and we have a number of conflicting topics that is confusing us all, (me at least)

• Primary, objective 1
  • not cause Martin any more hassle than he already has.
• Objective 2
  • For the Templot community, succession planning.
  • To support this, Martin made the decision to open-source the project.
• Objective 3. (covered by the user community already)
  • Develop a group of power users to provide Templot support. Allowing Martin to focus on 1 and his hobby.

Current status:

• Templot is being actively developed in Delphi Pascal 5

Where we need to get to:

• Open Source Templot will need to carry on using modern (free) tools and toolchains, if we are to stand a chance of encouraging more people to pick it up

Obstacles

• We need to convert the pascal code over to Javascript (not 100% sure about this).
  • noidea is working on a code parser to do this

We need a tool to manage this:

• GitHub and Git are very complex tools but absolutely essential for open-source development. Multiple contributors invariably introduce new features and, of course, bugs .....

This whole venture will ebb and flow as people come and go, drop it and pick it back up, nothing is guaranteed, it relies on goodwill and enthusiasm.

With this in mind should we start to form a plan of action or does this defeat the point of opensource?

Thought on this:

A terms of reference or similar, nothing complex or legal or any of that, just a set of guidelines to keep us pointing in the right direction:

1. Agree with Martin the chosen Architecture and subsequent structure:

• Monolithic like Pascal is currently
• or decoupled
  • Processing engine.
  • UI
• Language
• Management tool
• How new code from the main branch is merged in to OpenSource branch.
• How often.

So on and so forth.


Regards
Nick

PS , I'm not trying to force any of these ideas onto anyone; please take what I have written as ideas, ramblings etc.

Hi Nick,

I would agree with the majority of what you say, I was thinking along the same lines. The only slight difference in opinion is the obstacles, I'm never comfortable in rewriting code with a lot of intellectual property into another language as the nuances don't always translate very well and a few other reasons. It appears that the free pascal compiler works completely cross platform including Apple M1/M2* silicon (declare an interest here writing this on a MacBook with an M1 chip). So for myself it seems sensible at this stage to keep it in Pascal as the main branch of development, from which export to alternatives can be explored and tested as they all have pros and cons. This has the added benefit that if it stays in Pascal then it makes it a lot easier to feedback updates or additional components back to Martin to include in his Templot2 code base if he chooses to do so.

With respect to terms of reference and guidelines - I agree that would be very good to establish which is why I mentioned that on GitHub OpenTemplot is listed as an organisation. Alistair and Graeme may have already set it up and hence my question. Rather than starting all over again do we try to pick up on their work and work together to move forward?

If we could open up the OpenTemplot organisation on GitHub to the new helpers then a lot of these technical discussions could be made there to avoid generating confusion on the forum here, and then just pick up the code files from Martin as and when he feels comfortable to make a release.

 

[Rusty]

This is all getting very interesting. I've tagged in Alistair and Graeme above -- we last heard from Graeme in this topic:

Hopefully not too confusing - I'm trying to avoid that. Likewise I've just raised an issue on the OpenTemplot GitHub page to see if we can get their attention that way.

 

[NoIdea]

I'm happy to be referred to as mw.

Refer to me as No Idea as my initials are MW as well

 

[NoIdea]

We need to convert the pascal code over to Javascript (not 100% sure about this).

• noidea is working on a code parser to do this

@nickom - Treat my idea as a side project. I'm months and months away from having anything like complete. It makes more sense to develop the pascal code.

 

[nickom]

@nickom - Treat my idea as a side project. I'm months and months away from having anything like complete. It makes more sense to develop the pascal code.

Hi No Idea,
For the avoidance of doubt- this question relates to Open Source templot and to parsing the Pascal files into a different language.
this is not related to the main Templot program development in Pascal.

l was going to ask how the parser would handle separating the UI parts of the pascal files. for the main syntax differences I could see how it would be relatively straightforward, but with the embedded UI design elements its a lot more complicated, design intent is going to tricky to define in the parser.



For info , I used ChatGPT to help build the following parser stub, ( I know people don't like ChatGPT but it really saves a lot of time with the coding grunt work)

don't take this as a syntactically correct conversion, it is just a first attempt.

Best regards
Nick

const fs = require('fs');
const path = require('path');
// Function to map Pascal types to JavaScript types
function mapPascalTypeToJs(pascalType) {
const typeMapping = {
'Integer': 'Number',
'Real': 'Number',
'Single': 'Number',
'Double': 'Number',
'Extended': 'Number',
'String': 'String',
'Char': 'String',
'Boolean': 'Boolean',
'Byte': 'Number',
'Word': 'Number',
'Cardinal': 'Number',
'SmallInt': 'Number',
'ShortInt': 'Number',
'LongInt': 'Number',
'Int64': 'Number',
'UInt64': 'Number',
'Pointer': 'Object'
};
return typeMapping[pascalType] || 'any';
}
// Function to convert Pascal code to JavaScript
function convertPascalToJs(pascalCode) {
let jsCode = pascalCode;
// Replace program structure
jsCode = jsCode.replace(/program\s+\w+;/, '');
jsCode = jsCode.replace(/begin/g, '{');
jsCode = jsCode.replace(/end\./g, '}');
// Replace writeln with console.log
jsCode = jsCode.replace(/writeln\(/g, 'console.log(');
// Replace variable declarations
jsCode = jsCode.replace(/var\s+(\w+):\s+(\w+);/g, (match, varName, varType) => {
const jsType = mapPascalTypeToJs(varType);
return `let ${varName}; // ${jsType}`;
});
// Replace assignment operator
jsCode = jsCode.replace(/:=/g, '=');
// Replace if-else structure
jsCode = jsCode.replace(/if\s+(.*?)\s+then\s+begin/g, 'if ($1) {');
jsCode = jsCode.replace(/else\s+begin/g, 'else {');
jsCode = jsCode.replace(/end;/g, '}');
// Replace procedures and functions
jsCode = jsCode.replace(/procedure\s+(\w+);/g, 'function $1() {');
jsCode = jsCode.replace(/function\s+(\w+)\((.*?)\):\s+(\w+);/g, (match, funcName, params, returnType) => {
const jsReturnType = mapPascalTypeToJs(returnType);
return `function ${funcName}(${params}) { // returns ${jsReturnType}`;
});
jsCode = jsCode.replace(/end;/g, '}');
// Replace for loops
jsCode = jsCode.replace(/for\s+(\w+)\s+:=\s+(\d+)\s+to\s+(\d+)\s+do\s+begin/g, 'for (let $1 = $2; $1 <= $3; $1++) {');
jsCode = jsCode.replace(/end;/g, '}');
// Replace while loops
jsCode = jsCode.replace(/while\s+(.*?)\s+do\s+begin/g, 'while ($1) {');
jsCode = jsCode.replace(/end;/g, '}');
return jsCode;
}
// Define the path to the input Pascal file

const pascalFilePath = path.join(__dirname, 'input.pas');
//console.log(pascalFilePath, 'ghghghghg');
// Check if the file exists
if (!fs.existsSync(pascalFilePath)) {
console.error('Error: The Pascal file does not exist at the specified path:', pascalFilePath);
process.exit(1);
}
// Read Pascal file and convert it to JavaScript
fs.readFile(pascalFilePath, 'utf8', (err, pascalCode) => {
if (err) {
console.error('Error reading the Pascal file:', err);
return;
}
const jsCode = convertPascalToJs(pascalCode);
const jsFilePath = path.join(__dirname, 'OUTPUT', 'output.js');
fs.writeFile(jsFilePath, jsCode, 'utf8', (err) => {
if (err) {
console.error('Error writing the JavaScript file:', err);
return;
}
console.log('Conversion complete. JavaScript code saved to', jsFilePath);
});
});

 

[nickom]

Hi Nick,

I would agree with the majority of what you say, I was thinking along the same lines. The only slight difference in opinion is the obstacles, I'm never comfortable in rewriting code with a lot of intellectual property into another language as the nuances don't always translate very well and a few other reasons. It appears that the free pascal compiler works completely cross platform including Apple M1/M2* silicon (declare an interest here writing this on a MacBook with an M1 chip). So for myself it seems sensible at this stage to keep it in Pascal as the main branch of development, from which export to alternatives can be explored and tested as they all have pros and cons. This has the added benefit that if it stays in Pascal then it makes it a lot easier to feedback updates or additional components back to Martin to include in his Templot2 code base if he chooses to do so.

With respect to terms of reference and guidelines - I agree that would be very good to establish which is why I mentioned that on GitHub OpenTemplot is listed as an organisation. Alistair and Graeme may have already set it up and hence my question. Rather than starting all over again do we try to pick up on their work and work together to move forward?

If we could open up the OpenTemplot organisation on GitHub to the new helpers then a lot of these technical discussions could be made there to avoid generating confusion on the forum here, and then just pick up the code files from Martin as and when he feels comfortable to make a release.

Hi Adrian,

The main challenge is going to be converting code developed in Delphi V5 Pascal to a modern variant. Is the conversion native in Free Pascal? If this can be sorted, it's definitely the path of least resistance.

Compiling the version Martin W converted was really easy, but this isn't an option moving forward. It requires too much effort for no gain.

Regards
Nick

 

[Rob Manchester]

Hi All,

This topic is growing with every post, and we have a number of conflicting topics that is confusing us all, (me at least)

As a long time Templot user from outside this 'development group' I find it all totally confusing . I will just watch this unfold and keep my fingers crossed. I just want a copy of Templot that I can continue to use on a desktop PC with a big screen, not an app on some tablet thingy. Model railways is often a 'retirement' project so access and ease of use is a primary concern, some of us haven't got as many marbles as we used to have !

Must go and take my daily Omega3 tablets.....and eat a Chicken Tikka.

Rob

 

[Martin Wynne]

As a long time Templot user from outside this 'development group' I find it all totally confusing . I will just watch this unfold and keep my fingers crossed. I just want a copy of Templot that I can continue to use on a desktop PC with a big screen, not an app on some tablet thingy. Model railways is often a 'retirement' project so access and ease of use is a primary concern, some of us haven't got as many marbles as we used to have !

Must go and take my daily Omega3 tablets.....and eat a Chicken Tikka.

Rob

@Rob Manchester

Hi Rob,

Don't worry, I just want Templot2 on a big screen too. It isn't going anywhere while I can still remember what I had for breakfast. After that it will be for others to take it forward into the unknown. They are just getting ready.

cheers,

Martin.

 

[Paul Boyd]

It isn't going anywhere while I can still remember what I had for breakfast.

So, er, what did you have for breakfast? Just checking

(Yeah, I know, a boiled egg!)

 

[Rob Manchester]

@Rob Manchester

Hi Rob,

Don't worry, I just want Templot2 on a big screen too. It isn't going anywhere while I can still remember what I had for breakfast. After that it will be for others to take it forward into the unknown. They are just getting ready.

cheers,

Martin.

MW,
Not worried with you in charge. The issue with breakfast is to remember if you had any never mind what it was ! Scotch Oats and blueberries for me each day..........

Rob

 

[Rusty]

Compiling the version Martin W converted was really easy, but this isn't an option moving forward. It requires too much effort for no gain.

My apologies - I'm just starting about thinking about how to help so I've probably missed something along the way.

Please could you expand on this so I can understand.

1. What exactly isn't an option moving forward? An open sourced pascal version?
2. If this isn't the option moving forward what is the option to move forward?
3. What is it that requires too much effort for no gain?

Thanks

 

[Martin Wynne]

My apologies - I'm just starting about thinking about how to help so I've probably missed something along the way.

Please could you expand on this so I can understand.

1. What exactly isn't an option moving forward? An open sourced pascal version?
2. If this isn't the option moving forward what is the option to move forward?
3. What is it that requires too much effort for no gain?

Thanks

@Rusty

Hi Adrian,

I think Nick means that when I released the 2018 files, I converted them all so that they would open, compile and run in Lazarus straight off. It was a lot of work, and there is no way I could do that again now every time I release a set of files.

For example the Delphi wrappers for the Windows EMF metafile functions were replaced with direct calls to the API (the code is still in math_unit.pas, commented out). Plus a lot of faff to get the HTMLviewer package linked in, and other changes. If you diff the files you will see the changes needed. Lazarus has upgraded several times since, so there are probably other changes needed now.

One issue that I never got to the bottom of was that when run in the Lazarus IDE everything worked fine. When run stand-alone, the exe was using 30% CPU continuously even when idle. Templot does a lot of work in the Application.OnIdle event, and Lazarus didn't seem to be implementing that properly. That may no longer be the case in the latest versions of Lazarus.

To get round the problem for the release version of OpenTemplot (Templot3) I had it launched from a separate window. If you wish to try it, you can still download it from:

https://85a.uk/downloads/templotmec.exe

n.b. BOX files from that program are not compatible with Templot2. It's not really intended for actual use -- there is a lot of stuff missing: no sketchboard, no PDF output, no file viewer.

Apologies Nick if that is not what you meant.

cheers,

Martin.

 

[NoIdea]

l was going to ask how the parser would handle separating the UI parts of the pascal files. for the main syntax differences I could see how it would be relatively straightforward, but with the embedded UI design elements its a lot more complicated, design intent is going to tricky to define in the parser.

The parser is only responsible for converting a stream of tokens into an internal representation of the structure - classes, methods etc. It's the emitter that has to handle to conversion to another language / platform.

In your CharGPT version, for example, converting a byte to a number will probably not work while saving/loading binary box files. The correct conversion is byte > Int8Array.

 

[NoIdea]

The main challenge is going to be converting code developed in Delphi V5 Pascal to a modern variant. Is the conversion native in Free Pascal? If this can be sorted, it's definitely the path of least resistance.

Except that every time Martin makes a change to the master source that change will need to be converted in the open source version.

 

[NoIdea]

I just want a copy of Templot that I can continue to use on a desktop PC with a big screen, not an app on some tablet thingy.

As do I, Rob.

I'm thinking of the young 'uns when I suggest a tablet version!

 

[nickom]

@Rusty

Hi Adrian,

I think Nick means that when I released the 2018 files, I converted them all so that they would open, compile and run in Lazarus straight off. It was a lot of work, and there is no way I could do that again now every time I release a set of files.

For example the Delphi wrappers for the Windows EMF metafile functions were replaced with direct calls to the API (the code is still in math_unit.pas, commented out). Plus a lot of faff to get the HTMLviewer package linked in, and other changes. If you diff the files you will see the changes needed. Lazarus has upgraded several times since, so there are probably other changes needed now.

One issue that I never got to the bottom of was that when run in the Lazarus IDE everything worked fine. When run stand-alone, the exe was using 30% CPU continuously even when idle. Templot does a lot of work in the Application.OnIdle event, and Lazarus didn't seem to be implementing that properly. That may no longer be the case in the latest versions of Lazarus.

To get round the problem for the release version of OpenTemplot (Templot3) I had it launched from a separate window. If you wish to try it, you can still download it from:

https://85a.uk/downloads/templotmec.exe

n.b. BOX files from that program are not compatible with Templot2. It's not really intended for actual use -- there is a lot of stuff missing: no sketchboard, no PDF output, no file viewer.

Apologies Nick if that is not what you meant.

cheers,

Martin.

Hi Martin, It is, thank you.