LiveCode Forums.

Hi there,
I have created a little password generator (nothing the world needs, but great for practicing). It consists of roundabout 170 lines of code and 4 textfields, 7 checkboxes, 4 labels and 3 buttons for the GUI. After having made a standalone of it, I am wondering about the file size, which is 18 MB . That seems quite a lot for such a tiny program - or no?

What you have is your code bound to the LiveCode engine, plus any components it uses (dialogs, libraries, etc.). And on Mac it may actually contain two LiveCode engines, if you build for both 32- and 64-bit compatibility. This will be true of just about any system that includes its engine to produce a true standalone application.

For small things, this seems big. But with applications frameworks for even compiled languages growing all the time, that's still smaller than many small apps, like Apple's Calculator and many others.

But moreover, as you add features to your app, the size will increase only by the amount of your new code and objects.

So if one feature produces a standalone at 18 MB, a hundred features may be only 20 MB. The engine size is fixed, and includes all of its capabilities. Your additions to use those capabilities come at a very small increase in size.

File sizes have a minimum limit for each version of the IDE for just a blank stack. Back in the iteration before 7.x, the size for a stack alone was something like 1.5 megs. Through the 6.x series it grew a little bit, until 64 bit was introduced in 7.x, where it jumped to something like 10 megs for stack turned exe.

I have no idea what it currently is at, and it also depends to some degree on which OS the standalone is intended for. For instance, in early 8.x my blank stack turned exe came in at the following :
Windows - 10.5 MB
Mac App folder - 12.4 MB
Linux 32bit - 12.5 MB
Linux 64bit - 13.9 MB

So this is the lowest size value you can have, no code, no controls, no anything.

On the other side of that, you could (if you start producing a number of programs) create 1 stack that is turned into an exe file of the least size, and write code to launch all the stacks you create as apps. Before being compiled, many quite large stacks are literally in the KBs if no outside materials (images, etc) are included.

I see Richard popped in while I was composing this as well, but I'm leaving it as it sits

Okay so this is weird now:
in 9.0.4 I created a standalone of an empty stack. The Linux version of the empty standalone is even larger (20.8 MB) than my program's standalone (18.2 MB).

Forget it: I accidentally created 32-bit version. The 64-bit version has 18.2 MB ! As for the Windows version, both stacks have the same size too.

Anyhow - seems like I should add some features to my password generator, in order to "justify" the file size .

Meh. Add what you need when you need it. True, size increases going forward will be relatively smaller.

But even out of the starting gate, when compared with systems of similar scope and packaging (bundles on macOS and Snap or Flatpack packages on Linux) LC standalones aren't all that much bigger than many others.

FourthWorld wrote: ↑

Sun May 19, 2019 8:55 pm

Add what you need when you need it.

Completely agree with that statement...

FourthWorld wrote: ↑

Sun May 19, 2019 8:55 pm

But even out of the starting gate, when compared with systems of similar scope and packaging (bundles on macOS and Snap or Flatpack packages on Linux) LC standalones aren't all that much bigger than many others.

I think that depends on what exactly that means (I've never used flatpack, snap, etc). I have used other languages, though. Lazarus/free pascal creates a large executable *if* you leave it as is with a default compile. However, you can then run "strip" (linux, the IDE has compatible switches for Mac and Win) and see that drop to about 1.5 megs, and like Lc, adding code and objects scales it up slowly.

If you meant something else, ignore the above

Running strip on Lc exes of course does nothing, since there isn't anything to strip (debugging info, symbols, etc), but as I was mentioning earlier, if you start dev'ing lots of programs, you can ship just an initial minimal 'launcher', and use that to launch your collection since you should know where your collection resides. At that point, barring an engine release update, your 'programs' come in KB sizes.

True standalones are historically rare on Linux. I have no experience with Lazarus, but if it includes a scripting language I would expect similar sizes roughly on par with LC.

Snap and Flatpack are Linux packaging subsystems that create true standalones from tools normally dependent on system DLLs and other components. As such, they're a closer match to how LC works than, say, a Python script, which depends on the OS to provide whatever version if Python is needed, along with whatever GUI framework is used.

FourthWorld wrote: ↑

Mon May 20, 2019 12:59 am

I have no experience with Lazarus, but if it includes a scripting language I would expect similar sizes roughly on par with LC.

Lazarus would arguably be more on par with Borland's Delphi (in particular, vers. 7) than a scripting language per se.

https://en.wikipedia.org/wiki/Lazarus_(IDE) wrote: Lazarus is a free cross-platform visual integrated development environment (IDE) for rapid application development (RAD) using the Free Pascal compiler.

Software developers use Lazarus to create native-code console and graphical user interface (GUI) applications for the desktop, and also for mobile devices, web applications, web services, visual components and function libraries for a number of different platforms, including Mac, Linux and Windows.

An application created using Lazarus on one platform can generally compile and execute on any platform for which a Free Pascal compiler exists. For desktop applications a single source can target Mac, Linux, and Windows, with little or no modification. An example is the Lazarus IDE itself, created from a single code base and available on all major platforms including the Raspberry Pi.

So in this context, it is not carrying the weight of including a vm to run on, although it is a hi level language about on par with earlier VB (direct competitor with more capability at the time), and has 'object' controls you can place (LCL instead of VCL).

I think another problem in understanding exactly which category Lc falls into comes literally from how many categories some languages fall into. For instance, if you go to the "List of Programming Languages" on Wikipedia, you'd find Lc listed as a Scripting language as well as these other scripting languages - - but while a number of those languages I would think would be roughly the same as Lc appear in a LOT more categories, Lc is only placed twice, the second being "Object-oriented class-based languages", where as Rebol for instance is also in "Reflective Language" where I would think Lc would be, and "Object-oriented prototype-based languages" where again I would think you would find Lc since I believe the two are pretty comparable (other than Rebol kind of being in a coma right now).

I wouldn't have thought Lc would be comparable to Flatpack or AppImage or Snap (read up on those) since those seem to be more like a packaging / distribution system than an actual programming language was my understanding.

Functionally, you're right: LC isn't a packaging system. But in terms of the size of deliverables, I believe it's a fairer comparison than "DLL-hell" apps.

I'm not sure I get that comparison, for one thing, aren't scripted languages supposed to be (relatively) free from "DLL-Hell" status, since they are interpreted and so, theoretically, anywhere the interpreter runs, the finished product should run? Other than the specific libraries required for said interpreter.

Unless you are making the argument that because of the the distribution method of the interpreter, Lc should be compared to a packaging system because it distributes its interpreter with each and every compiled standalone in cases where you don't have a centralized launcher as mentioned above, where as most scripting languages distribute the interpreter separately in a mass download scenario (i.e. python, java, etc), or run in a browser (javascript, coffeescript, etc).

Even then I think the comparison fails, as you would still need to package your software in some way beyond just compiling it, since most end users aren't going to deal well with just a zip file, contrary to how we did it years past.

Snap packages are generally larger than .deb packages, because they're more self-contained.

As such, they more closely reflect the minimal-dependency portability of LC apps.