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

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

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