LTSpice import coming to Mac and Linux-Progress Reports

Hello Everyone,

Sorry for missing last week's update, we had to close part of the week

due to hurricane Matthew. If you were impacted by this hurricane, then

wish you a speedy return to normalcy and that your families are all OK.

At this point, I've gone through each of the ULP sections and listed the

functions that I'm certain will have to be re-written or changed. The

damage isn't too bad, there are 10 functions which will likely have to

be rewritten or heavily modified. There are also two global variables

which may need to be changed.

Here's a breakdown:

Lines                Description

-

               -

0661-0672            testsyscommand- Function used to debug, currently

                      uses windows commandline parameters.

0675                 SearchStartDrive- global variable

0677                 SearchLastDrive- global variable

0688-0692            Just an if statement that checks

                      if the ULP is running under Win.

0701-0713            check_windows_root

0746-0847            file_search

1248-1283            readconfig & saveconfig

1342-1349            makedir-only supports window

1914-1919            imp_dirname- assumes windows dir.

3850-3856            call_system

4064-4077            dosfilecopy

4146-4229            Beginning of main, needs to be

                      cleaned up.

4310-4321            Ex_WaitOnHandshake

At this point, I know the beginning of main is probably going to require

the most work. I want to implement a dialog that will allow users to

specify all of the paths needed by the ULP, should the ULP fail to find

them automatically. This adds flexibility for different user setups and

should be more resilient across the three operating systems.

Now I'd like to ask for your opinions on how to proceed. I'm currently

trying to determine what the best implementation would be. On one hand I

was thinking I could these OS dependent functions from the main ULP. I

would then create three different include files one for each OS in which

each of these functions is adjusted for the needs of the OS. At the

beginning of the main ULP is would detect what OS it's running under and

then only include those function definitions. Logistically this seems

easier to manage to me.

The other option would be to modify these functions in place and use

something like a switch statement within these functions to run the OS

specific code. This has the advantage of keeping everything in one file.

What would you guys recommend? Feel free to suggest any other approach

you think might be suitable.

Thanks everyone for your attention.

Best Regards,

Jorge Garcia

On 10/12/2016 06:09 PM, Jorge Garcia wrote:

 

Now I'd like to ask for your opinions on how to proceed. I'm currently

trying to determine what the best implementation would be. On one hand

I was thinking I could these OS dependent functions from the main ULP.

I would then create three different include files one for each OS in

which each of these functions is adjusted for the needs of the OS. At

the beginning of the main ULP is would detect what OS it's running

under and then only include those function definitions. Logistically

this seems easier to manage to me.

 

The other option would be to modify these functions in place and use

something like a switch statement within these functions to run the OS

specific code. This has the advantage of keeping everything in one file.

There are two primary reasons for separating code into different files.

The first is isolation.  By having separate compilation units, must of

the code internal to functions is hidden from callers, thereby offering

a layer of security by denying other compilation units access to the

inner workings of the function.  The second primary (can one even have a

"second" primary?) reason is maintainability.  By having all related

variables and code in one source file makes it much easier to maintain.

However, specific to Eagle, ULP is not a compiled language.  It's a

scripting language that is interpreted at run time.  It does not support

linkages to external modules.  This somewhat nullifies the first reason

for having separate files leaving maintainability as the only motivation

for separate files.  That unto itself is enough reason for separate files.

With that in mind, the downside of having separate files is

distribution.  A file is not being distrubted any more; instead a

package of files is being distributed.  Separate files would best be

distributed as a compressed archive, such as zip, 7z, or tar/gzip.  It

is a good bet that all of us have used compressed archives in one form

or another.  So, I don't see that as enough motivation to abandon

separate files and use an all-in-one ULP.

Bottom line, I suggest using OS-specific files.  To go one further, I

would suggest that the OS detection not be done in the main file, but

instead be done in a separate file:

    ltspice.ulp:

        ...

        #include "oslib.ulp"

        ...

    oslib.ulp:

        string osStr;

        osStr = detect_os();

        // osStr now contains either "win", "lin", or "mac"

        #include "system-" + osStr + ".ulp"

        #include "filecopy-" + osstr + ".ulp"

        ...

But, this isn't going to work.  First, #include requires a string

constant.  Second, #include is not a statement - it's a preprocessor

directive.  Consider the following construct:

    int cmd;

    cmd = 2;

    if (cmd == 1) {

            #include "true.ulp"

    } else {

            #include "false.ulp"

    }

One might expect that this example of conditional includes would include

only "false.ulp".  But because #include is a preprocessor directive,

Eagle will try to include BOTH of the files.  Additionally, Eagle

doesn't have any preprocessor conditionals that would allow:

    #if OS == OS_WIN

        #include "filecopy-win.ulp"

        #include "system-win.ulp"

    #elseif OS == OS_MAC

        #include "filecopy-mac.ulp"

        #include "system-mac.ulp"

    #elseif OS == OS_LIN

        #include "filecopy-lin.ulp"

        #include "system-lin.ulp"

    #else

        #error "invalid value for OS"

    #endif

So, that's out as well.

Two things left to do... I'll talk about the ugly one first.

Consider a function called filecopy that does something different for

each OS:

    filecopy.ulp:

    int filecopy(string to, string from) {

        int rc;

        if (os == OS_WIN) {

            rc = ... do windows copy here

        } else if (os == OS_MAC || os == OS_LIN) {

            rc = ... copy mac files here

        }

        return rc;

    }

Yuck.  This means that code for all supported OS's must be in memory.

A cleaner method is to determine the OS at install time, not at run

time.  The distribution ZIP file (and I use "ZIP" generically, of

course) would contain the main ulp, then three nested zip files - one

for each OS.  The use would determine which os-specific zip file to

unzip.  The ULP files within each os-specific zip would contain a

collection of ULP's that abstract the nuances of each OS to a common

interface.

    JGprog.zip:

        JGprog.ulp

        oslib-lin.zip

        oslib-win.zip

        oslib-mac.zip

There are several benefits to this approach:

• The detection of the underlying OS is determined once at install

    time by the user.

• Code for only a single OS is included from JGprog.ulp.

• CPU cycles are not wasted when determining which os-specific code

    should be executed.

Jorge, What you're building here is a library that abstracts os-specific

functions.  With a little bit of planning, this library can be designed

to be extensible, and used by other ULP's.

Of course, there are as many opinions as there are engineers.  My

preceding monologue was not meant to put the reader to sleep, but

instead it was meant to consider an approach that had not yet been

mentioned, and that at least bears discussion.

HTH,

    - Chuck

Chuck Huber wrote:

 

A cleaner method is to determine the OS at install time, not at run time. The distribution ZIP file (and I use "ZIP" generically, of course) would contain the main ulp, then three nested zip files - one for each OS. The use would determine which os-specific zip file to unzip. The ULP files within each os-specific zip would contain a collection of ULP's that abstract the nuances of each OS to a common interface.

 

JGprog.zip:

JGprog.ulp

oslib-lin.zip

oslib-win.zip

oslib-mac.zip

 

There are several benefits to this approach:

 

 

• The detection of the underlying OS is determined once at install time by the user.

 

• Code for only a single OS is included from JGprog.ulp.

 

• CPU cycles are not wasted when determining which os-specific code should be executed.

Yes, this please! Well a combination of this and what I (and subsequently Chuck) said. I'd still pull the OS specific stuff out into it's own generic and much more useful OS abstraction lib and then use calls to that library from the ULP functions that need to make OS specific calls. Then do as Chuck suggests above and make it deal with installing the correct OS specific library at install time.

Best Regards,

Rachael

Chuck Huber wrote:

 

A cleaner method is to determine the OS at install time, not at run time. The distribution ZIP file (and I use "ZIP" generically, of course) would contain the main ulp, then three nested zip files - one for each OS. The use would determine which os-specific zip file to unzip. The ULP files within each os-specific zip would contain a collection of ULP's that abstract the nuances of each OS to a common interface.

 

JGprog.zip:

JGprog.ulp

oslib-lin.zip

oslib-win.zip

oslib-mac.zip

 

There are several benefits to this approach:

 

 

• The detection of the underlying OS is determined once at install time by the user.

 

• Code for only a single OS is included from JGprog.ulp.

 

• CPU cycles are not wasted when determining which os-specific code should be executed.

Yes, this please! Well a combination of this and what I (and subsequently Chuck) said. I'd still pull the OS specific stuff out into it's own generic and much more useful OS abstraction lib and then use calls to that library from the ULP functions that need to make OS specific calls. Then do as Chuck suggests above and make it deal with installing the correct OS specific library at install time.

Best Regards,

Rachael