Monthly Archives: August 2014

Shoes 3.2.15 Bugs on Windows

Attention Windows users! Two bugs have been reported.

(1) Shoes 3.2.x may hang on Windows when it is in the background. This may take a long time to fix.

(2) Selecting Packaging with Shoes may appear to hang but actually if you bring the console window up you’ll see that it failed to load a .so (a dll). This too will take some time to fix and it affects earlier versions of Shoes – back to 3.2.13 – stuff that used to run.

Shoes 3.2.15

Shoes 3.2.15 is available for download (see tab above).


  1. New feature: You can set a finish= {proc} on edit_line. See here
  2. Updated the built-in manual to be more current with newer images and text. Added a manual section to direct the inquiring minds to the Shoes 3.2 wiki and other Internet resources.
  3. Linux installers have been renamed for ‘.run’ to ‘.install’ That means 3.2.14 users can’t package the newest Linux ‘install’ unless they also run 3.2.15. You need to upgrade to 3.2.15. if you intend to package for Linux. Shoe 3.2.14 will not detect that 3.2.15 is available when packaging. And you shouldn’t be packaging because it still doesn’t work like it should. Update anyway.

If you think that’s not worth a version number bump then you haven’t tried to update the manual and the wiki and this blog in sync. I still have to update the wiki and create 5 new posts.

Got around to it

Some would call it clean up, others would call it an essential must do first task – website statistics. I’m pleasantly surprised. There are a few people reading the blog articles and a decent number of Shoes downloads, 50+ a day or more. That surprised me. So far, Linux downloads are more than Windows and not that many are from packaging. How many are real people vs download eveything and repost it on their website under their banner is unknown.

How do I know they aren’t packaging? Because the first step in packaging is to GET an cgi script that returns the installers available. Other than me, no one would run that manually or even know about it. Now you know about it but you’re not likely to read the app_packager.rb source code to find the url. I didn’t set that up to make statistics easier. Unintended benefits!

I’ve been updating the Shoes manual in the last few days. New screen shots for installing and just getting the text to match what Shoes 3.2 looks like and does. The manual was seriously out of date. I’m also going to add a section for “where to go for more information” (my copy of the Wiki) and tell them what they could learn more about over there. Why has no one thought of that most basic idea? The manual doesn’t mention Shoes.setup (or gems) and it says nothing about Packaging. Those are not beginner level topics, but they should know where to go to learn more about Shoes.

That means I have to update my copy of the Wiki to cater to intermediate level folks as well as the “developers”. Fortunately, I’ve got some blog posts and pages here that would fill that role. Which requires editing, here and there, which takes time. Which delays the release of 3.2.15.

edit_line can handle enter key

A person complained on on the Shoes Mailing list that you can’t tell when the enter key is pressed in an edit_line control and it would be helpful to him if it could. So KCerb opened Bug 860 on Shoes4. I remember struggling with that issue for some app I was trying to write in Shoes 3 few years ago. I decided to fix it for Shoes 3.2.15 even though the Shoes4 folks put it off until a future release of Shoes4.

This is the kind of Cowboy coding practices that irritates people. It means Shoes 3.2 has “new” features that Shoes4 doesn’t. That’s different from restoring Shoes 3 features that were never intended to be in Shoes 4 (like packaging and binary gems). This time, I moved the goal posts on them. That’s annoying.

You can find 3.2.15 with this enhancement on the downloads page. It’s not everything I intented for 3.2.15 and I still have to document the new feature here and in the Shoes Manual but the feature is in the download(s). Which are named ‘.install’ for Linux instead of ‘.run’.

Here is a simple test program do
stack do
@el = edit_line do |e|
para e.text+"\n"
@el.finish = proc { |slf| para "enterkey #{slf.text}\n" }

Thinking out loud – linux packaging

Perhaps you’ve detected a love/hate viewpoint from me when it comes to packaging. I’m the only person who is willing to admit knowing about the insides (other than _why_the_stiff). That doesn’t mean I’m correct. It just means I think I can do something about the current state — which is actually worse than I wrote about in my last post because at the time I was update Red Shoes I’d chosen to do nothing about packaging.

How should it work. Think like an end user first. They download something, they cause their Operating System to execute that something and then presto they are looking at your GUI application and have no idea it was written in Shoes/ruby. They might have an icon on the desktop or in a system menu so they can run the program again.

What has to happen for that ‘vision’ to work cross platform? They need a version of Shoes 3.2 for that operating system and the execute that something installed it. No big deal because you packed your app with the right Shoes platform (7MB or so in size). In Linux, that Shoes was never really installed as I described above, it just got reinstalled when the user ran your download app. That’s a serious annoyance for resource constrained platforms like the Raspberry pi.

There was a ‘download shoes if needed’ option. It’s been broken for years and it wasn’t clever enough in Linux to deal with Intel (64 vs 32 ) or ARM versions of Shoes/Linux. I think that’s fixable since the bash code to download and install Shoes with curl and or wget was already written – it justs need fixing. Testing is a major pain so I down’nt blame anyone for not doing it. Theres a lot of ways to get it wrong even when it looks like its working.

Current thoughts: Modify the static/stubs/sh-install to know where the current shoes lives on the web (remember the cobbler ability to change that url which happens at user install time, not at packaging time). Downloaded Shoes Apps should be kept in one place like ~/.shoes/+apps. It might be a single isp.rb file or an expanded hh.shy directory and the starting script within.

There’s a compilication (one of many). Linux uses the makeself ‘package’ and it can’t handle two separate tar balls inside, Shoes+Ruby and a separate Hackety Hack like directory structure. That’s why HH want’s to be built from source so it can duplicate/replace parts of Shoes. My current idea is: when packaging a .shy (tar’d directory) it will be copied into the Shoes tree under apps-install-{name} or something like that so all the images and binary stuff in {name} are part of the big tar ball {name}.run and when that is run on the users system, Shoes will install into ~/.shoes/federales and the apps-intall-{name} will be copied to ~/.shoes/+apps

Saddly, this brilliant brain fart may not work if you want to package a complex app and “Not include Shoes” since there is no Shoes to hide the app-install-{name} tree inside. I suspect I can find a solution. Actually, what Linux people want (IMNSO) is not to include Shoes but to download if needed. That’s certainly something I have to try first and then see how it can meld with the above vision. Cowboy coding or design for perfection?

Since I’m an maintenance programmer and lack vision, I’ll probably go cowboy and see what happens.

Nuances of Packaging – its still mostly useless.

I like: Shoes 3.2.15 downloads are a lot smaller for Linux and Windows (almost half) and slightly smaller for OSX.

Before I go launching off into the wild blue yonder doing things just because I can, it’s usefull to I collect my thoughts. Packaging is weird and fun and frustrating so we always need to keep the goal in mind and not get sidetracked in what can be done and stick to what should be done.

Packaging means different things to different people and Shoes folk use the term loosely. I’ll use 3 examples below.

  1. Isp.rb is a Shoes script that pings a website and logs the results. One file, one form.
  2. Ytm is a more complicated script and has data files that persist across invocations
  3. Hackety Hack is a very complicated system of scripts, direcotories, images, help pages and so on

They are all ‘apps’ and they can be packaged with Shoes IF NEEDED.. Packaging means creating a ‘container’ that is cross platform. isp.rb is simple, any Shoes can run it. Just point the shoes command line at it or open it from the Shoes splash screen. If you want your friends or workplace associates to run it, just tell them to install Shoes and put the script somewhere they can download it and run from their copy of Shoes.

Ytm (Yield to Maturity) has a .csv files you (pretend) have put some working into popluating and you want to share the script and that data file of precomputed results. So the container should include the script and the data file in that directory. You could copy both of them to the file server or send them in an email with a long explantion of how to put them together.
Or you could create .shy (a glorified tar ball or zip file thing) and you tell every one to install Shoes if they don’t have it, then they can use Shoes to open it. Easy peasy until the other person wants to write to that csv file with their own information. That will only appear to work. Shoes expands (inflates) the .shy in a tempory directory. The next time you run the .shy it inflate its original contents. Clever programmers, if they know whats happening can work around this problem if they are willing to and they understand what’s happening. Some folks consider .shy useless because of this problem.

Consider Hackety Hack which has a butt load of directorys,images,scripts and help text. I’ve got hh.shy for you and a hh.tar.gz. Shoes will handle the .shy (expand and run it and the os may delete it) but it knows nothing about the tar.gz. Still with me?

The Shoes packaging menu (or command line ~/.shoes/federales/shoes -p allows you to create a container and installer for your chosen operating systems. The container includes all of Shoes and your script (just one file) 8MB upto 15MB in size. It creates a .run and when the user downloads that, a temporary copy of Shoes will be expanded and that be used to execute that one script and when your user quits or crashes, the temporary copy of Shoes will vanish and the next time you execute, it’s all brand new again. Think about, it might be a good thing for some folks. That’s Linux behaviour. It’s even more different behaviour for my.exe and

Are you still awake? Here’s an important fact. Shoes is/was/never/maybe-not-really designed to package complicated apps other than Hackey Hack (and that app broke packaging long ago and still doesn’t work).

Bottom Line: Packaging probably does not do what you want. It may never do what you want. I might fix some of the Linux issues and I may not. Ultra Bottom Line: don’t use packaging.

Don’t Panic

You might see Shoes 3.2.15-gtk2-*.install files in the download directory. For the moment, those are the Linux installers for Shoes. You might even notice that they are less than one half the size of 3.2.14’s .run files. 7MB instead of 19MB.

Gob smack me too! 3.2.15 was built without debug symbols. If you’ve got a small memory device running off a flash card like the raspberry pi, that actually makes Shoes on the pi ‘not really that slow’ . I could blow some smoke about paging and locality of ELF sections and other things. What matters is is it’s faster and smaller with makes if faster to download and package.

Why did I change the name from .run to .install? Because someone on the mailing list actually tried to package a Shoes script in Linux for Linux and he found the process a tad bit confusing. Sure I could write some better wiki docs but that’s not a good solution. It should be easier and for Linux (which is what I care about the most) I could be a lot better. First step – change the name so Shoes installers are not confused with packaged Shoes scripts and they cause “huh?” moments.

Yeah, I’ll have to do some code slinging in shoes/lib/app_packager and modify a bash script or two in order to get the download if needed option working again. For Linux. My plan is not to run the fricking installer every time. Install shoes 3.2 Federales once if its not there and then run thes users script. That won’t happen anytime soon, if ever for Windows unless I learn a whole lot more about Windows.

That’s the plan for 3.2.15 – better Linux app packaging. And smaller sizes.

The quiet release of 3.2.14

So, I found a bug in cache.rb and I didn’t need all the previous days of angst about hpricot and sqlite3 gems. We can’t learn without some mistakes. Maybe you can but I still make mistakes and continue to learn how little I know.

Shoes 3.2.14 is available for download for all platforms. The only improvements from 3.2.13 are that hpricot and sqlite3 gems are included with Shoes 3.2. Hackety Hack appears to works on all plaforms (don’t package it) See previous post on how to get Hackety Hack installed.

The 3.2.14 release pretty much gets 3.2 up to doing things that Raisins could do and Policeman failed to do as well I we all had hoped. A limited form of packaging is working for all platforms from all platforms. There is a working website to support packaging. Shoes is updated for Ruby 2.1 and gems 2.2. OSX 10.9, Windows 7, and modern Linux downloads that really work (x86_64, i686, armhf (aka raspberry). Many reported bugs with Shoes 3.x have been fixed – although not all bugs have been fixed and odds are high, there will be newly discovered bugs.

Gem currents sway back and fro

The mystery continues about those Shoes Gems. Mysteries to me at least. Some of those other gem’s in Ruby’s internal gem directory cannot be ‘require’d by Ruby irb. Shoes fails on those too. I think I should keep Shoes gems out of there. It’s should be easy enough to create a new directory for shoes gems and teach cache.rb and the rakefiles to use it. That directory would be inside the Shoes App tree, not in ~/.shoes/+gems. Kind of like the jailbreak but hidden and only for a few ‘historical’ gems.

Of course, just copying those historical gems to ~/shoes/+gems would be even better. Easy enough with another button/panel in Cobbler. Kinda of like copying the sample scripts out of the tree. Each Shoes distribution would have a ‘shoesgems’ directory or something similar with precompiled binaries.

It would be much harder to copy the shoesgems during the initial Shoes installation so I’m not going there. Which means that packaged scripts (or shy’s) that require the gems wouldn’t run/install either. So, there’s no need for the user to copy them to ~/+gems.

It is confusing and that’s why I’m blogging about the decision and choices. Modifiying the rakefiles to build and copy the gems to a Shoes directory instead of a Shoes/Ruby directory should be easy (OSX complications might lessen). In fact, I might do it in OSX first – it’s the hardest and the one with biggest problem of the current scheme.

When Shoes 3.2.14 is finished

I’ve got the Linux and Windows versions of Shoes 3.2.14 sorted out when it comes to using the Shoes built in gems (hpricot, sqlite3). It was mostly a problem with my build/testing setup. If the GEM_HOME environment variable is set (which rvm will set) then the Ruby inside Shoes got a bit confused. A lot confused. Don’t have rvm – not a problem. But I do have rvm and I suspect many Shoes Folks do. It was an easy fix in cache.rb to delete it, if it’s there (for sandboxed Tight Shoes). Finding that problem was a little tedious.

Shoes 3.2.14/OSX is being a bit picky and hissy. I think the otool/install-name-tool dance is required.

For convience, or continuity or ‘just because I can’, I’ve extracted Hackey Hack and made it available for download (see download tab. It works well enough for me with Shoes 3.2.14. I do not care about Hackety Hack other than Shoes 3.2 ought to be able to run it. It does. Except for the OSX problem with 3.2.14 not being available. Stay tuned.