LTSpice import coming to Mac and Linux-Progress Reports

For some reason the formatting got all messed up

Lines                    Contents

-

               -

1-300               Documentation

300-693               Global Variables

____533-656          ____Syntax Definition Symbol

695-847               File Functions

849-4140          Export-Import Functions

____889-1874          ____Export

____1877-4024          ____Import

________2247-2862     ________Parse Library Lines

________2865-3858     ________Parse Schematic Lines

________3859-4024     ________Import Setup Menu

____4026-4140          ____Export Menu

4142-4596          Main

____4232-4337          ____main export

____4339-4596          ____main import

________4365-4488     ________import a library

________4490-4573     ________import a schematic

____4574-4596          ____main diagnostic

• • Indicates key sections

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

Hi Jorge,

I think of the suggested options I would prefer having separate files for OS specific versions of things and then including the appropriate one in a single OS detection section rather than having to make each function more complicated checking which OS in many places. It'll make the code tidier this way and a lot more manageable.

Alternatively if a lot of the OS specific functions are only OS specific because of a small part of their functionality and you can boil the OS specific tasks down to a common set of functionality then maybe you can create a library that does these tasks and deals with the OS specific stuff in the background, leaving the majority of the actual function code completely untouched. Then you could substitute those calls in many functions if they were doing similar things and it might speed up your task quite a lot.

Best Regards,

Rachael

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

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.

Hi Chuck,

Aghhh!!! I totally didn't realize that the ULP language didn't support

preprocessor if, elseif. Well, it's better to figure that out now rather

then when I'm knee deep in the implementation.

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.

I'm not too concerned about distribution since this would ship with all

three main distributions of EAGLE.

I'm also not sure if I want to go as far as creating a framework that

would handle os-specific functionality for ULPs. I do think that is a

really good idea but not something I want to add to the scope of the

current project.

I agree that the best way to proceed right now is going to be to split

the ULP into a few files to make everything manageable and that is going

to be the approach I follow from here on in.

I'm going to go figure out git now, my goal for next week is to have

this project up on github so that more eyes can look at the code and to

open the possibility for collaboration should anyone want to give me a hand.

Thanks everyone.

Best Regards,

Jorge Garcia

On 10/13/2016 03:13 PM, Jorge Garcia wrote:

...

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.

 

Hi Chuck,

 

Aghhh!!! I totally didn't realize that the ULP language didn't support

preprocessor if, elseif. Well, it's better to figure that out now

rather then when I'm knee deep in the implementation.

I should qualify that... There are no /documented/ conditional

directives.  That's as of the 7.2 ULP docs.

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.

 

I'm not too concerned about distribution since this would ship with

all three main distributions of EAGLE.

Okay.  I was thinking more in terms of a package that one would download

from cadsoft (or whatever it may be called today).

 

I'm also not sure if I want to go as far as creating a framework that

would handle os-specific functionality for ULPs. I do think that is a

really good idea but not something I want to add to the scope of the

current project.

I understand.  My intent was not to suggest an expansion of the scope of

this project, but merely to consider that what you write today may be

extended and modified by individual users in years to come to include

os-specific functionality that is not required by this LTSpice project.

For instance, I might want to take what you write, and add a

schematic().jumpThroughFlamingHoops() function.  While jumping through

hoops may be common to all os's, igniting the flames may be implemented

differently on windows than it is on mac or linux.

Perhaps my metaphor is somewhat out there, though I can think of several

times in the distant past that I had to fight the urge to set my Windows

computer on fire.

I guess the point is that as the separation of functions is designed, it

would be helpful to consider a structure that makes it easy to extend.

Enjoy,

    - Chuck

Hello Everyone,

I'm a little late this week. So this week I was able to figure out how

to get the ULP up on github along with the other necessary files that

aren't included in the Linux/Mac distributions.

You can find the repository here, for anyone interested.

https://github.com/cadsoftcomputer/EAGLE-LTSpice-port-to-Linux-and-Mac

The additional folders are misc, ltspice_lib, and ltspice_examples.

Follow the instructions the github page in order to setup the folders on

your computer.

The changes to the code so far have been minor, I commented out an

unnecessary check and corrected a minor spelling error. More changes to

come.

See you all next week!

Best Regards,

Jorge Garcia

P.S If anyone is looking for a Git GUI interface, SourceTree is very good.

Hi Guys,

This will be a short one. This week I wasn't able to get any work done

on the code. I received a new Linux box this week and I have set it up

with all of my tools to start Linux integration next week. The github

repository should show some commits next week.

Thanks for following along.

Best Regards,

Jorge Garcia

Hi Guys,

This will be a short one. This week I wasn't able to get any work done

on the code. I received a new Linux box this week and I have set it up

with all of my tools to start Linux integration next week. The github

repository should show some commits next week.

Thanks for following along.

Best Regards,

Jorge Garcia