questions SALT+ GIT for legacy apps
7 posts
• Page 1 of 1
questions SALT+ GIT for legacy apps
Hello,
I have to manage legacy applications written in APL for my company. So far the dev team was of 1 or two people max, managing separated codes. Today, as the team grows, we want to start using source management (GIT).
We are now considering SALT to export our sources in text files. I have the following problems:
- Our main applications contain several layers of namespaces and classes. I found how to ]Snap the application to properly save the sources and structure of the app. But then I have no idea how to ]load it in a clear WS without flattening the structure.
- I considered keeping the WS, and saving elements in a single folder using ]Save. But then I don’t understand how to update it to follow the checkouts in GIT, without having to ]load manually all the impacted functions.
Can someone please guide me on the most effective way of using source control with APL?
Thx in advance
I have to manage legacy applications written in APL for my company. So far the dev team was of 1 or two people max, managing separated codes. Today, as the team grows, we want to start using source management (GIT).
We are now considering SALT to export our sources in text files. I have the following problems:
- Our main applications contain several layers of namespaces and classes. I found how to ]Snap the application to properly save the sources and structure of the app. But then I have no idea how to ]load it in a clear WS without flattening the structure.
- I considered keeping the WS, and saving elements in a single folder using ]Save. But then I don’t understand how to update it to follow the checkouts in GIT, without having to ]load manually all the impacted functions.
Can someone please guide me on the most effective way of using source control with APL?
Thx in advance
- Mateo
- Posts: 6
- Joined: Tue Mar 22, 2016 7:41 am
Re: questions SALT+ GIT for legacy apps
]SNAP will make a copy of all your code onto text files.
It can do the entire workspace (by default) or only a subset with the use of modifiers -class and -patterns.
To recreate the workspace as it was when you ]SNAPped it you can use the -loadfn modifier to create a program (a script, really) to load each piece one by one. This will recreate the STRUCTURE (namespaces etc.) as it was. It will even recreate the latent expression (⎕LX).
The program/script will be stored in the same location as the rest of your files under the name load_ws.dyalog
For example if you did a
You can then boot using the file thus created:
All the text files created can be stored in a Source/Version Control system.
For example, if you ]SNAP in a GIT or SVN repository you can then simply add and commit from there.
As you keep working in APL your files are automatically updated when you edit an APL object (e.g. program or scripted namespace) and you can commit them once in a while when satisfied.
Note that if you create new objects or modify non editable objects (e.g. non text variables) you will need to rerun ]SNAP with the same original argument in order to pick up those changes and you will need to ADD them in your control system.
For example, if you originally did
and later on you add function AVG, you will need to again do
It can do the entire workspace (by default) or only a subset with the use of modifiers -class and -patterns.
To recreate the workspace as it was when you ]SNAPped it you can use the -loadfn modifier to create a program (a script, really) to load each piece one by one. This will recreate the STRUCTURE (namespaces etc.) as it was. It will even recreate the latent expression (⎕LX).
The program/script will be stored in the same location as the rest of your files under the name load_ws.dyalog
For example if you did a
- Code: Select all
]SNAP \my\project -loadfn
You can then boot using the file thus created:
- Code: Select all
)CLEAR
⎕se.SALT.Boot '\my\project\load_ws.dyalog'
All the text files created can be stored in a Source/Version Control system.
For example, if you ]SNAP in a GIT or SVN repository you can then simply add and commit from there.
As you keep working in APL your files are automatically updated when you edit an APL object (e.g. program or scripted namespace) and you can commit them once in a while when satisfied.
Note that if you create new objects or modify non editable objects (e.g. non text variables) you will need to rerun ]SNAP with the same original argument in order to pick up those changes and you will need to ADD them in your control system.
For example, if you originally did
- Code: Select all
]SNAP \my\project
and later on you add function AVG, you will need to again do
- Code: Select all
]SNAP \my\project
- DanB|Dyalog
Re: questions SALT+ GIT for legacy apps
Hi Dan,
Thank you for your clear answer. I understand now the use of the boot scripts.
I did a few tests, and I obtained good results with relatively small projects. However, when I tried to snap a biggest one I got this :
* Command Execution Failed: circular reference: unable to create load fn
I don't know what I should be looking for to correct this.
FYI I had to 'clean' manually the ws, because it contained functions that had already been ]Saved by a colleague and had a SALT comment line at the end. It is possible that full namespaces or instances suffer the same problem, and I did not find how to 'cut the link' with SALT scripts. Could that be the cause of the issue ?
Thank you for your clear answer. I understand now the use of the boot scripts.
I did a few tests, and I obtained good results with relatively small projects. However, when I tried to snap a biggest one I got this :
* Command Execution Failed: circular reference: unable to create load fn
I don't know what I should be looking for to correct this.
FYI I had to 'clean' manually the ws, because it contained functions that had already been ]Saved by a colleague and had a SALT comment line at the end. It is possible that full namespaces or instances suffer the same problem, and I did not find how to 'cut the link' with SALT scripts. Could that be the cause of the issue ?
- Mateo
- Posts: 6
- Joined: Tue Mar 22, 2016 7:41 am
Re: questions SALT+ GIT for legacy apps
Hi Mateo,
it is hard to tell exactly what happened here without access to the workspace that was ]SNAPped. If you want me to have a look at the problem you are experiencing send me the workspace.
My guess is that there were at least two classes in the workspace that required each other to be present and the program to create the load_ws program was unable to determine which one to put in first (the chicken or the egg?)
BTW, ]SNAP will take into account object that have already been ]SAVEd and won't resave them again if they don't need to.
For example, if you have a number of utilities ]saved in folder \my\utils then ]snap won't save those again BUT will create a load_ws script that will bring those back properly.
In other words you will see lines that perform a LOAD of these utilities from \my\utils in the load_ws script.
/Dan
it is hard to tell exactly what happened here without access to the workspace that was ]SNAPped. If you want me to have a look at the problem you are experiencing send me the workspace.
My guess is that there were at least two classes in the workspace that required each other to be present and the program to create the load_ws program was unable to determine which one to put in first (the chicken or the egg?)
BTW, ]SNAP will take into account object that have already been ]SAVEd and won't resave them again if they don't need to.
For example, if you have a number of utilities ]saved in folder \my\utils then ]snap won't save those again BUT will create a load_ws script that will bring those back properly.
In other words you will see lines that perform a LOAD of these utilities from \my\utils in the load_ws script.
/Dan
- DanB|Dyalog
Re: questions SALT+ GIT for legacy apps
Ok I understood the meaning of the error.
I found the cause: I have a class deriving from the standard dyalog gui element Edit.
It is not a proper circular reference, but I understand that SALT does not know where to find the prerequisite for the 'Edit' class?
I found the cause: I have a class deriving from the standard dyalog gui element Edit.
- Code: Select all
:Class GUI_SearchBar : 'Edit'
It is not a proper circular reference, but I understand that SALT does not know where to find the prerequisite for the 'Edit' class?
- Mateo
- Posts: 6
- Joined: Tue Mar 22, 2016 7:41 am
Re: questions SALT+ GIT for legacy apps
Hi. The 'edit' base class should not be a problem.
Can you tell me what
/Dan
Can you tell me what
- Code: Select all
]version
- Code: Select all
]uversion
/Dan
- DanB|Dyalog
Re: questions SALT+ GIT for legacy apps
We are currently using v14 unicode :
- Code: Select all
]uversion
APL Windows 14.0.23160.0 W Development Unicode 0d81556b
SALT 2.4
UCMD 2
.NET 4.0
- Mateo
- Posts: 6
- Joined: Tue Mar 22, 2016 7:41 am
7 posts
• Page 1 of 1
Return to Source Code Management
Who is online
Users browsing this forum: No registered users and 1 guest
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group