Skip to main content

Adobe LR4 (LightRoom4) and Lua

I have been hacking on Lua and Lightroom4 for the last week or so and I have to admit that while I was skeptical of Lua and it's potential I'm actually starting to like it in this space. It appears to be fast and efficient while some of the syntax sugar seems to be less than modern and is probably suffering from the not invented here syndrome as the developers were inventing the language with a sense of strong national pride.
For example many languages, Python for example, 0(zero), '' (empty string), None (same as nil or null) are treated as false. In Lua you have to explicitly test the values then perform the logical operations.

I have one good thing to say about LR4 and Lua. The sandbox seems to work really well during the development cycle. There is a flag that can be set where LR4 will reload your code if it has changed. It makes development a lot easier. (but there may actually be a memory leak).

And that's about where the good news ends. The GUI controls are amazingly limited. Given today's toolbox you'd think Adobe would give me access to more controls. Like a date-picker or a proper list control. But more importantly if you're going to provide documentation for a feature like auto_completion then it needs to work exactly like the documentation says it should, and it should work exactly the same on all platforms.
auto_completion/completion does not work the same on Windows and OSX.

And while the particular bug I've been chasing was reported 4 years ago(2008) the response was that it was documentation that was leaked into the public and that it was going to be fixed ASAP. In the meantime the feature is now available on OSX but has not been ported to Windows.

Finally, I wish I knew what the LR4/Lua community or ecosystem looked like. After spending $100 on Lua [LR4] I can see that since Lua plays such a minimal role that there is no real need for consulting or freelancing etc in this space. It's strictly a support role.

Comments

  1. Are you a photographer? I havent used LR much --- what can you do with lua with it? Why did you have to pay $100 for lua? isn't it free?

    Jordan

    ReplyDelete
  2. Typo. I meant LR4; which is not free. I've fixed that now thanks. I'm not a photographer. I was working for a Photostudio that uses LR4 and then uses custom exporter plugin to upload the images to their servers.

    ReplyDelete
  3. Hrrm I thought LR4 was a lot more than $100.... Lua seems big in game and related development but I haven't used it much.... more of a .NET/Android guy myself....

    Jordan

    ReplyDelete
  4. Lua is not my favorite language. I've only outlined a few reasons in this post. But there is a strong argument for it. When faced with the need to design a DSL or not I think Lua is probably a better choice. (a) because it is already defined even with the cruft (b) it's really small, and (c) pretty quick... with a bytecode compiler too. It's certainly better than a DSL of the day.

    ReplyDelete

Post a Comment

Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: http://www.eeti.com.tw/drivers_Linux.html (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the setup.sh answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).

TL;DR;

I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…