Feature request: Change ULP language to Python

[Anonymous]

Hi Autodesk,

Glad to see that you guys are investing into new features and development of EAGLE. Looking forward to see what comes out of this, and to try out the new version 8.

I was wondering if there would be any consideration of changing the User Language Program programming language to use something more standard like Python, since it's a simple, well-understood, and broadly-used language. And its integration into existing C / C++ codebases is assisted by a number of wrapper generators.

I know that I have zero desire to learn an app-specific language, and I'm sure many people likely have similar feelings, so a move like this would open up a lot of options in case I did want to write routines specifically for EAGLE in the future. It would also give EAGLE potentially access to the massive world of Python libraries, which could assist engineers in managing their Bill of Materials and integrating EAGLE with online services.

Thanks,
Max

ps. At the time of writing this, the Submit An Idea page doesn't have a category for EAGLE, so I couldn't submit this there.

[Anonymous]

++

Yes, please!  This is a great idea!

[Anonymous]

Can only agree, would be great with python support 🙂

And if you do add it, go for the latest Python 3.x and not 2.7

[matt.berggren]

Thanks folks, this is a great idea and something (somewhat) similar is rolling around in our heads at the moment.  Until we have a more concrete view, we'd love to keep getting feedback.  

Best regards,

Matt - Autodesk.

[Anonymous]

Now that EAGLE has a chance to step up the game at AutoDesk, If you're going to invest the effort in a new extension language, I'd suggest something that could be compiled so that people like me could write (and sell) plugins...

[Anonymous]

Hi dougR6AS9.

Maye you could use Cython for that (C/C++ python packages) that can be used for extending Python, and call into the plugin that way ?

[Anonymous]

@Anonymous I think there are a lot of good options.  If AutoDesk would build a similar ecosystem to what Adobe has for plugins, I'd use whatever tool(s) they provided.

FWIW, I use Scala for most of my EAGLE file manipulations.  Another tool I really like is Nokogiri.  I've heard that Beautiful Soup is good too, but I haven't tried it.  (Which is funny because I'm a python programmer at the day job...)

<stream of consciousness>I find it interesting that the Cadsoft people decided to add a completely separate ULP language that generates the script that is run to make the actual changes to the schematic or board.  I would have thought it would be simpler to add the control structures into the scripting language itself.  Maybe the original programmer wasn't around any more and it was easier to start from scratch with the ULP language rather than trying to  figure out how to modify the script parser...</stream of consiousness>

/me shrugs

[jorge_garcia]

Hi dougR6AS9,

The ULP language is basically C, however I totally see the appeal. One of our users actually made a python wrapper for the EAGLE ULP language. Its not complete but it lets you do quite a bit. If you guys want to check it out in the meantime you can find it here:

https://github.com/rmawatson/PyEagle

He has a few cool examples, so have fun guys and let me know what you think.

Please accept as solution if my post fully resolves or you issue, or reply with additional details if the problem persists

Best Regards,

[Anonymous]

OK, one more try.  I keep getting "Authentication Failed. Authentication Ticket Mismatched, failed authentication." and "Authentication Ticket Mismatched, failed authentication.  Return to my original page" here on this forum.  And I thought Element14 was bad!!!  Sigh...

jorge.garcia wrote:
> The ULP language is basically C, however I totally see the appeal.

First off, hi Jorge, it's Doug Wellington. I tried to change my display name here on this forum, but apparently that doesn't actually do anything.

My main intent in contributing to this thread was to request that, if anything is done with EAGLE scripting, it would be nice to be able to make a plugin that had some kind of obfuscation and/or DRM that would let there be an ecosystem for creating and selling plugins. I would definitely also want the ability to give away free plugins and source code.

> One of our users actually made a python wrapper for the EAGLE ULP language.

Yes, I've been using that since before it was published on Github. 🙂

So, speaking of ULP stuff, I wrote up a blurb on the Element14 web site about a couple scripts I wrote: Two scripts to help layout a board from a multi-page schematic but now, none of the links to the ULP downloads work. I've also written dozens of blog posts over the years and none of those links work anymore either. Is anyone at AutoDesk smart enough to figure out how to map those old links to the new ULP download site (when that goes online)?

Alternatives for me are:

1. Try to find all my posts and edit the links
2. Leave everything alone and broken
3. Just delete all the posts
4. Give up on linking to the EAGLE website and use either Github or my own web page 

I think everything except #1 results in fragmentation of the community. I know it's tough to make a transition like this when a product gets assimilated into a larger company. EAGLE is not alone, check out how hard it is to buy T-Splines directly from Autodesk...

Regards,
Doug

[jorge_garcia]

Hi Doug!

I thought it was you, but didn't want to venture a guess and be wrong :(. The ULP downloads thing is still a WIP but it will get there. Now you can post a link to E-14 on a personal post as useful information.

We don't have any authority on the E-14 site so we can't grab from there as Autodesk. We do have plans to consolidate the community so you won't have to worry about fragmentation, however what's on E-14 belongs to them.

It's super nice to hear from you here, don't be a stranger.

Best Regards,

[Anonymous]

Well if it is compiled at the end, whats the point of a scripting language and the whole openness and customisability of ulps. 

edit: Just saw that you just want the option to have a DRM system. Which makes sense.

[Anonymous]

How can I upvote this 1000 times??? 

I worked on a project a few years back (10) and we embedded Python into the tool. It was awesome.

KiCad also has Python scripting.

You just need to expose a set of objects that users can manipulate... could be super awesome

[rachaelATWH4]

.

---

[rachaelATWH4]

---

@Anonymous wrote:

You just need to expose a set of objects that users can manipulate... could be super awesome

---

I agree adding something like Python would be really cool. I suspect it's more complex than it sounds though otherwise they would probably have done it already and you might end up with just another embedded language with the same restrictions as ULP. 

You can of course use Python by calling it from ULP using the system() command but then you can't so easily read the internal data models from there, you'd need to read that in ULP and pass the data to Python so having a better and more direct implementation as well as ULP would probably be really useful.

Best Regards,

Rachael

[Anonymous]

I think the primary difference between forcing users to use an application-specific language versus a broadly-accepted language (i.e. Python, Lua, or even Javascript via something like Fabrice Bellard's QuickJS Javascript Engine, which is tiny) is that it moves peoples' thinking from:

"Oh jeez, do I have to use this toy language that has no use anywhere else and learn all of its quirks, scoping, and object-model weirdness?"

to:

"Oh wow, you can do that? Ok, let's go."

There's a reason language adoption tends towards openly-specced languages with predictable core behavior, embeddable runtimes, and tons of answers on StackOverflow.

[Andreas.Schimke]

Hi,

I almost agree to your statement, but this is a special case in my eyes.

The ULP language is not only old it is very old and it wasn't created by the Autodesk people, instead it was developed by the company CadSoft more than 20 years ago (this is not a bullet proof fact, maybe @jorge_garcia  no it more in detail). Now Autodesk has the challenge to adopt it to the current state of art and in parallel enhance the functions of the Eagle itself.

For my self I would like to have a fix for some annoying errors (like the dimension tool) or the support for pcb panels, instead of bringing now a new script language for Eagle.

Regards,

Andreas

[rachaelATWH4]

Haha, don't get me wrong, I think adding in support for Python as well is a good idea, I just think they'd have done it already if it were that easy. If it's not done right you just end up with another variant of ULP with a different language syntax and all the same restrictions.

---

@Anonymous wrote:

"Oh wow, you can do that? Ok, let's go."

---

Funnily enough this was actually what I thought when I found EAGLE had ULP and I could do stuff with it. It's basically c with things like pointers removed so not hard to learn.

[Anonymous]

When I said it was easy, I wasn't trying to oversimplify the process.

Python is well suited for embedding, it's not something that you have to 'Cram into' an application, embedding is part of the core of the language

https://docs.python.org/3/extending/embedding.html

I'm familiar with this because I've done it, and it was far easier than you might think, and the rewards for doing it were spectacular. 

A gut-estimate is that a mid-level engineer could add Python to Eagle in 1-2 months of effort. I have NO idea what the development team is like, but it's got to be better at Autodesk than it was at Cadsoft... one certainly hopes so.

What I would say to any of the "managers" on that team is that once they add Python to the application, they could start building features with that embedded capability, and in less than a years's time, streamline the process of adding advanced features greatly. The time spent adding Python would pay for itself in future development speed and capability. 

It would also boost Eagle as a tool, which presumably is in their overall best interest, as it is a money-maker at least somewhat.

I work as a software contractor, so if they want, I can even do it for them.

[Anonymous]

This strikes me as a bit of a sunk cost fallacy.

I agree that top-level user facing features like what you're describing (I'd love to see proper hierarchical design and design block instancing by reference instead of by value, and a proper panelization system rather than a ULP that copies a design and creates new part designators).

I still think it's worth looking at moving away from ULP as the program's premiere automation language, but of course I don't know what kind of engineering resources Autodesk has available to do these things.

[jorge_garcia]

Hi Everyone,

Glad to see this pop up. Its good to point out that this is a goal, to incorporate Python into the electronics workflow. Especially considering that Fusion360 has a python scripting engine built into it, this is really just a matter of time.

With that said, as Rachael pointed out we wouldn't just kill ULP. There are a lot of very useful ULPs that users have made throughout EAGLE's history that need to be available. So this would be an additional language that would be available. I'm pretty sure it's popularity would quickly outstrip the use of the ULP language.

Just to provide a little insight, this hasn't been done is for reasons beyond just technical. There are timing issues involved as well as a few other things that have weighed into why this hasn't been done yet. With that said the circumstances needed for this to be implemented are coming together so it probably won't be long before some compatibility with Python is available.

Let me know if there's anything else you guys need from me.

Best Regards,