questions SALT+ GIT for legacy apps

SALT, SPICE, Subversion, etc...

questions SALT+ GIT for legacy apps

Postby Mateo on Wed Mar 23, 2016 3:07 pm

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
Mateo
 
Posts: 6
Joined: Tue Mar 22, 2016 7:41 am

Re: questions SALT+ GIT for legacy apps

Postby DanB|Dyalog on Thu Mar 24, 2016 1:20 pm

]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
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
with an appropriate add/commit

and later on you add function AVG, you will need to again do
Code: Select all
]SNAP \my\project
with an appropriate add/commit
DanB|Dyalog
 

Re: questions SALT+ GIT for legacy apps

Postby Mateo on Fri Mar 25, 2016 8:39 am

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 ?
Mateo
 
Posts: 6
Joined: Tue Mar 22, 2016 7:41 am

Re: questions SALT+ GIT for legacy apps

Postby DanB|Dyalog on Fri Mar 25, 2016 11:42 am

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
DanB|Dyalog
 

Re: questions SALT+ GIT for legacy apps

Postby Mateo on Fri Mar 25, 2016 12:23 pm

Ok I understood the meaning of the error.
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

Postby DanB|Dyalog on Fri Mar 25, 2016 12:53 pm

Hi. The 'edit' base class should not be a problem.
Can you tell me what
Code: Select all
]version
or
Code: Select all
]uversion
produces?

/Dan
DanB|Dyalog
 

Re: questions SALT+ GIT for legacy apps

Postby Mateo on Fri Mar 25, 2016 12:56 pm

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


Return to Source Code Management

Who is online

Users browsing this forum: No registered users and 1 guest