Idea Delivered

This will be available with the XPP 9.4 version release.

xyPerl: fix lookup for shared perl functions (modules), should be 1. current job, 2. style library, 3.syslib, 4. xpp perl folder

The lookup for CSS imported modules (the @import things) is the normal style lookup sequence 1. current job, 2. style library, 3.syslib.
And that allows you to 'share' common CSS settings among similar style bundles in a nice and convenient way.
(which is by the way a big plus when working with CSS compared to working with IF stylesheets).

It would be nice to have xyPerl work in the same way.
In similar styles you probably want to share 'perl functions' in the same way as you do with CSS settings.
Or even have perl functions (e.g. frills processing loops) that can be used by any of the styles you have.
(and yes this could be done by putting your perl module in the xpp perl folder, but that folder is not accessible from the pathfinder interface, so not a convenient place)

'Sharing' common things in a perl environment is done through using perl modules.
Modules are called in into the main xyPer program using a 'use' statement.
Perl will lookup a module based on the paths in the @INC array.
It would be nice if XPP could add the current job, the style library and the Lsyslib to the @INC for us.

Currently we can more or less do this ourselves but we need to hard code the style library name in the main xyPerl as inside composition we do not know what is the style library for a particular job.

Things would work a lot better if XPP can manipulate the @INC for us.

REMARK:
it would also be nice if there would be a possibility to force XPP to reload the perl modules you use in your main xyPerl.
Currently you need to store/exit and reopen the division in order to make this happen.
and that is very uncool while you are developing your shared functions.

Bart Terryn
Parents

  • This is a great idea and I am investigating the original request to support "use module" searching for Job, Library, Lsyslib via @INC. However, I have looked into the follow up comment about having to reopen the division to reload the module. Unfortunately, the perl interpreter has been embedded into the composition engine and I cannot find any way to tell the interpreter to invalidate modules. For that matter, I dont know what module to reload since they can be referenced via a "use" anywhere (even from another module). And I certainly do not want to reload all modules every time a "compose xxx" is initiated in the xyview.

    As an aside, while unstated, it is  implied that Pathfinder would need access to the ".pm" files for create, delete, copy, edit, etc. This is also being looked at.

Comment

  • This is a great idea and I am investigating the original request to support "use module" searching for Job, Library, Lsyslib via @INC. However, I have looked into the follow up comment about having to reopen the division to reload the module. Unfortunately, the perl interpreter has been embedded into the composition engine and I cannot find any way to tell the interpreter to invalidate modules. For that matter, I dont know what module to reload since they can be referenced via a "use" anywhere (even from another module). And I certainly do not want to reload all modules every time a "compose xxx" is initiated in the xyview.

    As an aside, while unstated, it is  implied that Pathfinder would need access to the ".pm" files for create, delete, copy, edit, etc. This is also being looked at.

Children
No Data