Monthly Archives: January 2014

Shoes Federales (3.2.b1) for Linux

Yesterday, I put up the raspberry pi version of Shoes. Today I have a slightly better version for the raspberry as well as binary distributions for Linux 32 bit and 64 bit.

  1. Raspberry Pi
  2. 64 bit Linux
  3. 32 bit Linux

These are .run files so in a terminal, chmod +x [downloaded-file} and then ./{downloaded-file}. You’ll see some messages about verifying integrity and you’ll be asked for the root password to install the desktop file. Shoes is installed in ~/.shoes/federales and you should find the icon/menu somewhere in Programming/Development/Education/Others. (you have to look in all of them because I can’t predict where it is on your system). You can always create a launcher of your own if you like.

If you’re running Ubuntu Unity or it’s less refined cousin in Fedora, then you have search for Shoes from Activities and then drag the icon into Activities. It works. It’s not pretty to me but it works.

Shoes Federales (3.2b1) for Raspberry Pi

I’ve uploaded Shoes 3.2 (federales) for the raspberry pi. It’s a .run file so you should have Midori save it in your home dir although any directory should work. When the download is complete, you’ll need to open a terminal and cd to where you saved the download. For example:
pi@tpi ~ $ ls -l
total 10392
drwxr-xr-x 2 pi pi 4096 Jan 30 02:13 Desktop
-rw-r--r-- 1 pi pi 5781 Feb 2 2013 ocr_pi.png
drwxrwxr-x 2 pi pi 4096 Dec 31 1969 python_games
-rw-r--r-- 1 pi pi 10624280 Jan 30 02:35 shoes-3.2b1-gtk2-armhf.run

Then make it executable to it can install itself.
pi@tpi ~ $ chmod +x shoes-3.2b1-gtk2-armhf.run
Run the installer
pi@tpi ~ $ ./shoes-3.2b1-gtk2-armhf.run
A little bit later, in raspberry time, you’ll get a half screen of dots and then the terminal prompt. So where is Shoes? Look at your desktop. See the Icon? You can use it. Shoes Federales (aka 3.2) has been installed in your ~/.shoes/federales directory and the desktop Icon/launcher is in ~/Desktop. You can delete the .run file if you like. You can re-install it as many times as you like – reinstalling won’t fix anything. From the opening splash screen, Read the Manual, and on the left side, select “AndSoForth” and then “sample”. NOTE: some samples will fail. It’s not you, they haven’t worked in years unless you want to fix them.

Shoes Federales- MinGW Issues

This is the third part of some blog posts about building Shoes and cross compiling. Part 2 gives a basic description of the Linux arrangement for cross compiling. This post is about MinGW and cross compiling for Windows.

This is not my first rodeo with MinGW and Shoes. I failed the first time a few years ago. Some might say it’s still not correct. Lets settle on it’s better and might be as good as it gets.

The Wine emulator runs many Windows programs on Linux or OSX. Shoes is not one of them (yet). Still, you’ll need Wine. I installed 1.6.something although 1.7.something would probably be a good idea I should get around to, one of these days.

There is no MinGW chroot configuration that I found on the internet (or none that were worth the effort). You can cross compile Shoes, and Ruby, and all their dependencies if you are patient and keep your goal in mind. To confuse things, I created some directories in /srv/chroot: mingw32, mingwgtk2. The first one is very minimal. It was enough to demonstrate the Shoes using Gtk3/Windows will run on Windows. The second one, mingwgtk2 is much more complete. You select between these in the env.rb associated with the rake linux:setup:mingw32 task.

Since Shoes on Gtk3 isn’t complete (for any platform) I’m only going to talk about the arrangement in /srv/chroot/mingwgtk2. It’s not a chroot – it’s just a place to build things and copy from. In Ubuntu synaptic, install the i686-w64-mingw32-gcc — your name may vary but the *-w64-ming* is the newer compilers that can produce both 32 and 64 bit. I’m using 32 bit (64 bit Windows 7 will run those productions well enough). Then get a copy of gtk+-bundle_2.24.10-20120208_win32.zip and inflate it. Mine looks like this.

ccoupe@bronco:/srv/chroot/mingwgtk2$ ls
bin gtktest lib src
etc include man ssl
gtk+-bundle_2.24.10-20120208_win32.README.txt info manifest usr
gtk+-bundle_2.24.10-20120208_win32.zip knap share

You may not have some of the subdirectories, yet. Notice include, lib, bin. Create the src dir
and copy your ruby source code over there. By the time your done downloading and compiling and configuring everything, the src directory is going to look like this:

ccoupe@bronco:/srv/chroot/mingwgtk2/src$ ls -1
cjc-curl-cfg.sh
cjc-ffi-cfg.sh
cjc-gdbm-cfg.sh
cjc-gif-cfg.sh
cjc-iconv-cfg.sh
cjc-jpeg-cfg.sh
cjc-openssl-cfg.sh
cjc-ruby-cfg.sh
cjc-yaml-cfg.sh
curl-7.34.0
dieterv
gdbm-1.8.3
gdbm-1.8.3.tar.gz
giflib-4.2.3
giflib-4.2.3.tar.bz2
jpeg-9
jpegsrc.v9.tar.gz
libffi-3.0.9
libffi-3.0.9.tar.gz
libiconv-1.14
libiconv-1.14.tar.gz
openssl-1.0.1f
openssl-1.0.1f.tar.gz
patch-gdbm-1.8.3
ruby-1.9.3-p484
ruby-1.9.3-p484.tar.gz
tarnyko
tml
yaml-0.1.4
yaml-0.1.4.tar.gz

You might not have the dieterv, tarnyho, and tml directories. They came with the packages I downloaded.. That scopes out the hard part of the tasks ahead. Some of those are optional Ruby dependencies (ffi, gdbm, iconv, openssl, yaml) and some are Shoes dependencies (curl,gif,jpeg,ruby). Build the ruby dependencies first. (configure, make, make install)

Everything started with a Mother configure:

ccoupe@bronco:/srv/chroot/mingwgtk2/src$ more cjc-ffi-cfg.sh
#! /bin/bash
# execute it instead of ./configure
export CC=i686-w64-mingw32-gcc
export CPPFLAGS="-I/srv/chroot/mingwgtk2/include"
export LDFLAGS="-L/srv/chroot/mingwgtk2/lib"
./configure
--build=x86_64-linux-gnu
--host=i686-w64-mingw32
--prefix="/srv/chroot/mingwgtk2"

Many of the cjc-{pkg}-cfg.sh are the same. I’m only to talk about the ones that are special. Obviously you’ll have to change the paths to match your setup. Don’t freak out when it doesn’t work. It’s easy to miss a character or two. This isn’t the place to rant about autoconf and configure. Just accept that you aren’t going to change it. –host is the system you are building for and –build is the system you are using to build with, except you’re using CC for the compiler and Includes and libs are different. DO NOT make up values for –host or –build. DO NOT expect configure to guess your compiler (because it will guess and it may also seem to work). Review the terminal output every time you run the configure.

gdbm
I should write a long ranting post about this bad boy. You need to find the patches the RubyInstaller folks used and apply them. Until you get it right. Copy your Mother script and add
--enable-libgdbm-compat to it, in the proper place, of course. Expect trouble.

For iconv add --enable-shared to your configure. No, I don’t remember why.
Do the same for yaml.

openssl
Oh God! I thought gdbm was hard. openssl doesn’t use autoconf but it looks like it does only IT DOESN’T and it doesn’t respect the CC env variable. There is very little on the web about cross compiling this sad puppy.
ccoupe@bronco:/srv/chroot/mingwgtk2/src$ more cjc-openssl-cfg.sh
#! /bin/bash
# execute it instead of ./Configure
export CPPFLAGS="-I/srv/chroot/mingwgtk2/include"
export LDFLAGS=-L/srv/chroot/mingwgtk2/lib
./Configure
--cross-compile-prefix=i686-w64-mingw32- mingw zlib-dynamic shared
--prefix="/srv/chroot/mingwgtk2"

Congratulations, you’ve built the Ruby dependencies. Or you built Ruby and came back here to rebuild the missing ones. Been there, done that.

Ruby
#! /bin/bash
# execute it instead of ./configure
export CC=i686-w64-mingw32-gcc
export CPPFLAGS="-I/srv/chroot/mingwgtk2/include"
export LDFLAGS="-L /srv/chroot/mingwgtk2/lib"
#export PKG_CONFIG_PATH="/srv/chroot/mingwgtk2/lib/pkgconfig"
./configure --enable-shared --enable-load-relative
--disable-install-doc
--enable-pthread
--build=x86_64-linux-gnu
--host=i686-w64-mingw32
--prefix="/srv/chroot/mingwgtk2/usr/local"

–enable-pthread doesn’t do that for Windows. It could, but it doesn’t in 1.9.3. –enable-load-relative which was so important on Linux? – not so important for Windows. Doesn’t hurt so we might as well keep it as a reminder.

Check the output of the Ruby build.

I think I mentioned you have to do a make install, didn’t I? That copies things into the –prefix locations (include,lib,bin). Only you don’t want to be root (it’s not needed).

Shoes dependencies (gif,jpeg, curl)
gif and jpeg just use copies of the Mother configure script. Easy.

curl is not needed at runtime for Shoes/Windows but you have to have one when to compile. No is not the time to fix Shoes (it’s not as easy as you’d think). Build a minimal curl. (yes you could enable ssl and tls and god what else, but why?)
ccoupe@bronco:/srv/chroot/mingwgtk2/src$ more cjc-curl-cfg.sh
#! /bin/bash
# execute it instead of ./configure
export CC=i686-w64-mingw32-gcc
export CPPFLAGS="-I/srv/chroot/mingwgtk2/include"
export LDFLAGS="-L/srv/chroot/mingwgtk2/lib"
./configure
--build=x86_64-linux-gnu
--host=i686-w64-mingw32
--without-gnutls
--without-ssl
--without-zlib
--disable-ldap
--disable-ldaps
--disable-dict
--disable-telnet
--disable-pop3
--disable-imap
--disable-smtp
--disable-gopher
--disable-manual
--disable-rtsp
--disable-versioned-symbols
--disable-tls-srp
--without-librtmp
--without-libidn
--prefix="/srv/chroot/mingwgtk2/usr/local"

After all of that, building Shoes for MinGW/Windows/Gkt2 is just a small matter of how you want to
deal with pkgconfig. You can write a shell script to find all the .pc and rewrite the prefix inside the .pc to the path of your ‘not really a chroot’ Or you can use some of the rewrite code I left in the env.rb rakefile. Or some combination. I’ll show you the sh/sed script but it’s up to you to not blinding execute it in the wrong directory. Don’t be root.
find -name '*.pc' | while read pc; do sed -e "s@^prefix=.*@prefix=$PWD@" -i "$pc"; done

Shoes Native build.
After all the work on the Gtk2 and ruby cross compile, it was dead easy to create a rake file target and tasks.rb and env.rb that uses the Windows native controls.

Very Important
All of these Shoes/Windows share a problem: Occasional hangs. Thread deadlock. I’m convinced this is mostly a Ruby 1.9.3 problem. Running under Wine, it’s 100% reproducible. There’s no obvious reason that ruby and Shoes (with or w/o Gtk) should be fighting over a critical section, but they do.

Federales Part 2: Shoes dependencies and cross compiling

This post is long on words and short on details. If I listed every command required, this would a multi-chapter and woefully out of date before you could read to the end.

As I said in the previous post, What is Shoes Federales, you can’t depend on Ruby being compiled and installed with the proper options that would allow you build a Binary Distribution of Shoes. And even if it was proper, thats only one architecture and their are many architectures. You could setup Virtual Machines with OracleBox or VMWare and install two or three Linux and Windows OS’s and then install all the development tools needed to build Shoes and then if you have some way to sync the Shoes source code (git clones, nfs, rsync, samba). You log in to each VM, build and package Shoes and all is good. You could do that. I started to do that. There are quite a few obstacles on that path but once you’ve learned that the default ruby you install on the xx VM can’t work for anybody else w/o rebuilding it properly you’ll look for a better way. Don’t get me wrong – you still need All those VM’s for testing the final packaging so install away – you’ll need them. Do the minimal install possible – just what a newbie would install. I installed a Minimal Debian 7.2 (32 bit), SuSu (64) and Fedora 20 (64) in 6 hours. that’s just to get a login prompt and get the guest box additions installed. It took about that time to get Win 7 installed.

Here’s another fact you can’t avoid. Ruby is a pain in the ass to cross compile unless you compile on a system with a running Ruby. Don’t believe me? Try it or skip way ahead when to where I describe the MinGW setup.

I happen to be using Ubuntu 13.10 (64 bit). If you are not running a Debian based distribution then you’ll have extra learning. As you probably know, you can run a 32 bit linux app on a 64 bit system. You can also install 32 bit compilers and 32 bit -dev packages. Or the arm compilers and libs. Don’t do that yet. It’s very confusing and and is just buggy enough to make you think you did something wrong. What does work much better (for debian) is chroot and even better for numb nuts like me is schroot. I’m not going to tell you how to apt-get it or how to set up the .conf files. You are only a few clicks with Google from finding decent blow by blow description of how to set it up. Pay attention to the debootstrap instructions.

I created three [s]chroots at /srv/chroot/ debx86, deb386, debrpi. I’ll talk about debrpi later so ignore that one for now. The first is just enough of a Debian 7.2 file system that when I schroot into it, I can run apt-get and install what ever packages I need like the build-essential (for gcc and binutils), gkt3-dev, and so on. It’s all installed in the chroot and not your running system. Also install ruby (any version whatever the debian default is). No we aren’t going to copy that ruby to build Shoes. We just use it to compile the Ruby that we do want to copy. The [s]chroot environment is sufficiently sandboxed to be really annoying sometimes. Learn to accept it. Do the same schroot dance for the 32 bit version of Debian. Because of the magic of muli-arch being able to run 32 bit apps on a 64 bit host, you’ve installed 32 bit compilers, headers & libraries in the schroot and you’ve haven’t cluttered up your booting Linux. Yes, if you’re paying attention it’s the almost the same amount of work if you just installed the dev tools in each of your VM’s except you don’t waste 5 or 10 minutes logging in to a VM with a deep desire to strangle the pointy haired person who decided what menu’s and command prompt are used for SuSe and Fedora and curse the odd way VirtualBox’s shared folders is damn near useless unless you sudo (assuming sudo is installed). There is no need to deal with those annoyances in a chroot.

I like schroot over chroot because it mounts /home and stuff in the chroot for me so I can just cd into my Shoes3.2 dir and run my rake tasks to build, package and edit the files. You do have to set your shell PATH up each time to remove the /home/yourname/rvm because that ruby won’t run in a chroot. Confused? Of course you are. I suggest you try setting up a chroot and doing the debootstrap and apt-get dancing – eventually the light bulb will go off and you’ll understand.

Before I discuss the raspberry pi schroot or the MinGW setups this would be a good time to back out of the weeds and remember why we went in there.

Dependencies.

Shoes has dependencies. You can’t run Shoes with a ruby lib and a jpeg lib and a [un]gif.lib. You might need a curl lib and of course you need the graphics libs. But there’s more – Ruby has needs to. Perhaps openssl and yaml would be useful And ffi and dbm. It would be nice if the end user of your binary shoes has installed exactly the same libraries that you have. As we used to say, when I was growing up, “People in hell want ice water, too”. There is not a chance in hell that the end user will have what you want and certainly not the versions you want. On the bright side, sometimes it’s not that big a deal because you can bundle the needed libs (dependencies) You absolutely have to do this for Windows. You have to include some of them for Linux. Which ones? That is the $64,000 question.

We know we have to include a properly built libruby and whatever libs it wants so we have to have them to copy. Ruby dependencies tougher. You’ll have to (cross) build or install them before you compile Ruby otherwise the Ruby build thinks you don’t want the missing libs. You have to watch ruby being built and check the logs to see what it didn’t find. It’s up to you if they go missing.
I don’t most Shoes folks would miss dbm (and cousins ndbm, sdbm) but then I don’t know much, so I built (apt-get install in schroot) all the Ruby dependent libs except curses and Tcl/Tk – Those would be counter to Shoes. Then I created a little shell script that configures the Ruby build. You need a script of your own because you’ll run it several times and then clone/modify it for the next thing to build. Of course you need to download the ruby source code. I put it and my script in /opt/src {chroot}/opt/src

I build the Ruby binaries to live in /usr/local (–prefix) because (1) you need the chroot installed ruby if yours fails to run. It could happen. Inside my chroot I have /usr/local/ first in my $PATH. It’ll make sense once you’ve played with chroot. Note: you have to install your ruby to /usr/local as root so su, or login to the schroot as root to run ‘make install’. You also have to root in the chroot to run apt-get. Just like a real system.

Here’s the script I use to configure Ruby (i386, x86_64 & raspberry)

#! /bin/bash
# copy this to the ruby dir or soft link it.
./configure --enable-shared --enable-load-relative
--disable-install-doc
--prefix="/usr/local"

After that, you apt-get install all the other dependencies (gtk2-dev, etc) into the schroot. Then setup the Shoes Rakefiles for the architecture to want to build. Modify the appropriate make/{arch}/env.rb with the values you need. rake, edit, rake clean, repeat until it it compiles and links everything. Each architecture choice in the Shoes rake builds into a different subdirectory. Look at the crosscompile file to see which one is setup at the moment. You can tar that up and move to the VM or wherever you what for a test. Hint: if you ‘export DISPLAY=:0.0’ when inside the chroot you may be able to test your 64 and 32 bit linux builds.

PLEASE NOTE: THERE IS ALTERNATIVE CODE in the env.rb files because I didn’t always build things
the way I’ve described. Some of the code is useless and some of it it is left as hints of what you can do.

Raspberry Pi (Raspbian)
You need to do some Google searching to find the instructions for setting up a schroot with raspian and the Qemu emulator. You’ll have to build or apt-get Qemu first and install it properly before you do the debootstrap and apt-get install ruby and all the dependencies. It’s surprisingly easy. Then build your ruby properly. Be aware: running gcc and ruby under the emulator is slow – it takes about the same amount of wall clock time as doing it on the raspberry itself.

Also note that for the raspberry, I don’t login into the chroot and build shoes inside the chroot. Instead, I installed the Ubuntu arm compiler after verifying that it will use the hardfp capabilities of the raspberry. I used that to compile and build shoes. So I only used the chroot to build ruby and install all the dependencies of ruby and shoes. In the env.rb I rewrite the paths returned by pkg-config to point to the longer paths into the chroot. For the Raspberry, it’s a mix of chroot work then using the ‘big’ system. For bonus points, once you get to build and link, you can chroot in and then run Shoes under the emulator (set DISPLAY) and it runs! That’s far more magic than we should expect.

MinGW
MinGW cross compiles is sufficiently complicated that I’ll start a new blog post.

What is Shoes Federales?

federales64I need to step away from the coding for a little bit, take a deep breath, collect my thoughts and [insert favorite metaphor here]. Since I’m approaching a release milestone, I’m going to state my original goals and my progress and deviance from them. Along the way, I’ll do some self serving cheer leading and toss out hints of future activities. Because I do things that way.

The problem I wanted to solve was that Shoes (Red Shoes, aka 3.0 and 3.1) has been languishing from neglect while Shoes 4 is being developed. So I set out to do a maintenance release. Truth be told, even before I decided that, I thought Shoes would be a neat thing to have on my new Raspberry Pi and other Pi folks might like Shoes and I would gain some cross compiling skills by building Shoes on my big Ubuntu box. My original goals a few months ago:

  1. Ruby 1.9.3 support (2.x.y too?)
  2. Gtk3 support
  3. Linux only enhancements. No changes for MsWin or OSX
  4. Fix gem support. Allow system wide gems to be used or improve Shoes ability to manage its own gems.
  5. Packaging – create .deb for shoes, shoes+app+gems
  6. Clean up rakefiles
  7. Improve cross compilation – specifically to Raspberry pi

Before I discuss each goal, please note that I do not have a goal of competing with the Shoes 4. I have not added any new features to the Shoes Language or layout. No new widgets. I did fix a bug or two and I did add a couple of Constants to Shoes but I also deprecated some features – primarily user level packaging of Shoes apps. That has been seriously un-maintained and it continues to be un-maintained. So, how have I done?

1. Ruby 1.9.3.
This took a lot longer than I expected. You could always compile Shoes with Ruby 1.9.3 but you might also get a screenful of complaints out of Ruby about constants and/or gems. I don’t like warnings unless I know enough to ignore them. It turns out there were two or three problems. Ruby 1.9.3 hardcodes the location of ‘rubygems.rb’ For example, mine was deep in /home/ccoupe/.rvm/ and on your machine it might be /home/yourname/rvm or /usr/lib/ruby1.9. Well, that explains why no one can build a binary Shoes on linux and expect it to work on someone else’s machine. It turns out that Ruby can be compiled with ‘–enable-load-relative’ (H/T to Michal Papis – Thanks). Load relative does look for rubygems.rb relative to where the running ruby is in the file system. For more fun, you should know that when it finds rubygems.rb one of the first things is to look for rbconfig.rb. Ruby has the benefit of keeping track of where it loads things from and there can be multiple places to load from. Ruby will do it’s best to look in all of them until it gives up. It also means that if ruby loads rubygems.rb from /home/ccoupe/.rvm… and then shoes.rb loads rubygems or rbconfig from ./shoes/ruby/lib it is a different rbconfig (as far as Ruby is concerned they came from different load paths so they are different files. That all happens before before the first bit of Shoe’s ruby code starts. Way before cache.rb attempts to clean up the mess. Lesson: compile your Ruby with –enable-load-relative if you can.

The next problem is that when Ruby goes looking for rbconfig.rb (or rubygems.rb) at start up, load relative or not, it is hardcoded to look for lib/ruby/1.9.1/{arch}.rbconfig.rb and it turns out Shoes stores its copy of Ruby in ruby/lib/{arch}rbconfig.rb. Puzzling things can happen in that case including the fact that many Shoes things work just fine, but not all Shoes things. You might never know what went wrong if you ignore those console error messages. The choice I made was to get Shoes’ copy of Ruby to look like lib/ruby/1.9.1 (note the switch between lib/ruby and ruby/lib – that took me too long to find). While I was poking around in app.c, world.c and friends I removed any chance of using Ruby 1.8.7 – I’m a deprecating machine, I ya.

I also found a way to jailbreak Gems from the Shoes sandbox (more on that later) and a way to compile Shoes on Linux that doesn’t require copies of Ruby, jpeg, [un]gif and so on. For obvious reasons, that Shoes binary will never have a chance of working on anyone else’s machine. I call it Loose Shoes. Some could reasonably argue it should be called Tight Shoes because it’s tightly tied to the users OS and configuration. It’s also smaller in size without a dangling copy of Ruby to drag around. At the time I was thinking of the Shoe Sandbox and binary distributions where everything has to be tightly controlled for things to work. So Loose Shoes turns out to be a build from source with whatever you have for a Ruby and Tight Shoes is a Shoes built for binary distribution and all the dependencies are tightly controlled. Like I said, there’s a good argument for the opposite meaning. But, having decided, I moved on.

2. Gtk3 support
Since all recent Linux distributions include Gtk3 and not Gkt2 (they also don’t include the development headers for either, but ignore that pesky fact in pursuit of truth, beauty and the American Way). Clearly, Gkt3 is the future (like it or not). So I added Gkt3 support to Shoes (gtk.c, version.h, common.h and later, world.c). I also left the Gkt2 code in so I can compile Shoes either way just by setting a Constant in the Rakefiles. That turned out to be a good idea. I still have a couple of show stopping Gtk3 bugs to fix before that version of Shoes hits the interwebs. I also noticed that Gkt3 and Gtk2 also claim to have Windows versions and Gtk3 runs on OSX/Quartz so no X11 on OSX required. Very interesting possibilities if that works. More on that later. So, I don’t have Gkt3 support fulling working because I was chasing shiny things that appeal to me more.

3. Linux only enhancements. No changes for MsWin or OSX
Almost all of my work was done on Linux. That’s almost the same thing, right? The OSX part was probably mostly true.

4. Fix gem support. Allow system wide gems to be used or improve Shoes ability to manage its own gems.

Early on, I decided that I didn’t want Shoes to include built in gems and extensions. Nobody, including me, has ever wanted to maintain a copy of Hpricot and Sqlite. They aren’t included or built in Federales (the source code is still there like an appendix). Nobody loves the binject extension or wants to maintain it. Bloopsaphone and portaudio? Gone (aka not built). Minitar – not maintained – probably still works for shy. My thought was to replace that with Zip – I think there is a ruby api/gem that would work and there’s also an api in rubygems for tar files that I haven’t looked into. I kept chipmunk because I like it and ftsearch because the manual likes it. So two extensions, no gems included.

For Loose Shoes (compiled from source for your Linux box and pre-existing Ruby), Shoes will use Gems you’ve installed in the system or with rvm. It will also use gems in ~/.shoes/gems+ so if you have some older gems in gem+ expect some confusion and error messages.

For Tight Shoes (Shoes intended to be distributed as binaries), in cache.rb, it checks for a file in ~/.shoes/federales named getoutofjail.card. If it sees that file, then it adds ENV[‘GEM_HOME’] to the Shoes/Ruby load path and the end users RVM gems are available for Shoes scripts. I have done nothing to improve or upgrade Shoes own gem handling code. As far as I’m concerned the only thing I intend to do with Shoes.setup is to delete it one of these days. It probably doesn’t work in Federales. I don’t know. I don’t intend to find out.

On the to-do list is to write a separate program in Shoes to manage gems (any gems or gemset or bundle). I’m not likely to get to that for quite a while. It would be a nice task for someone who wants to write a moderately difficult Shoes script or two. they could even use the Shoes.setup code that I threatened to delete as as a starting point.

5. Packaging – create .deb for shoes, shoes+app+gems
Not a whole lot progress to report on this. I did get nsis working to build Windows exe’s. Does that count for anything? Probably not. The fpm gem could do most of the heavy lifting here but I’ve got a lot of questions and haven’t bothered to look for answers.

6. Clean up rakefiles
Lets just agree to disagree about whether I improved the rakefiles. I deleted the bundler/cucumber stuff. The OSX folks can add it back in if they care to work on Shoes 3.2 and if it actually does something useful for them. If you just want to compile Shoes in Linux, it’s not needed and it gets in the way – a negative contribution. I commented out the check with github to get a version number. Ever try to compile Shoes when the internet connection is down? Very annoying while it waits for github to timeout. Yeah, it needs to be put back in. Perhaps when a package is created would be a good time to get a new version number. Also, it always returns 1540 for me no matter what I commit to github so it’s kind of useless as a version number.

If you get the feeling that I don’t particularly like the rake build system, you would be correct. But, it mostly works, it exists, and it can be abused for good purposes which is what I did when I got around to cross compiling and building binary distributions (Tight Shoes). The default is to build Shoes for whatever platform ruby is running (Tight Shoes) That will build a static libshoes.a and include that in the shoes program. Minimal dynamic linking for Loose Shoes, just against the dependent libs on your system. No funny copying of unneeded libraries. There was one very small change to chipmunk.rb needed for that to work. No need for the launching script that sets LD_LIBRARY_PATH either. No confusion with Loose Shoes about where things live. Just ask ldd. I added an install task which copies Loose Shoes to ~/.shoes/federales and produces a .desktop file that might work on your Linux Menu system when copied to the proper directory. since Ruby doesn’t move (or get copied), I can do this. It’s giggalishly small. But you can’t share it because it won’t work over there.

I also complicated the crap out things by adding some linux:setup: namespace tasks so you can cross compile (Loose Shoes) for Linux-x86_64, Linux-i686, Raspberry, and several variations of MinGW. More on that below. I know every one loves abstraction, but sometimes it’s very annoying. This is one of those times. It’s just freaking compile and link of C programs and some file copies and file system links. I still question whether I should have moved to Cmake but I didn’t. There is a set of files (env.rb and tasks.rb) for each Tight Shoes target (which gcc calls ‘host’ so beware of the shifting terminology). env.rb is mostly setting up constants that tasks.rb uses. There is commonality but in this case, don’t get elegant because every cross compile setup is going to be different and until you’ve done it enough times on enough platforms you many lack the knowledge of what has to be done and over engineer an abstraction that is worse than none at all.

That said – I did clean up the rakefiles and then I polluted them with a collection of cross compiling targets that work for me. They won’t work for you unless you create a setup like mine and there is no commandment that you have to set things up my way and in the Cecil way I left plenty of hints and unused code that can be used to do it differently.

So, I don’t like the Rakefiles or my changes. But it works and I don’t think I’ve done anything that would prevent Windows folks from building Shoes with their MinGW/Msys/Rubyinstaller setup nor have I intentionally destroyed anything OSX folks need should either of the OSX or MinGW folks attempt to build Shoes3.2

7. Improve cross compilation – specifically to Raspberry pi
Yes, I did that and for a whole lot more than the raspberry. It deserves a separate and longer post to describe how it works for me. Tight Shoes — binary distributions are cross compiled. Even if you are on a 64 bit linux and want to build a 64 bit linux binary of Shoes, you need to set up a cross compile arrangement. Why? Re-read point #1 of this post. You can’t use your installed Ruby and expect it to work anywhere but your own system. You have to build a separate Ruby and distribute that (and any .so’s that Ruby wants like libyaml, openssl and so on) as well as the regular shoes dependencies of libjpeg, libgif/libungif (or both). You just have to do it. If you want to argue that point, try it your way and then we can compare notes about theory and facts.

Enough grumpiness.
I’m delighted that I can build Shoes for Windows using the native widgets, Gtk2 or Gtk3. I can build 32 bit linux and 64 bit linux binaries that runs on recent Suse, Fedora, and Debian without requiring the end user to install anything. I can do the same for the Raspberry Pi. I have to fix the Shoes Gtk3 bugs before that’s worth much more than a brag. Still, it’s good progress. There are Windows threading problems and most of that solution should be done in Ruby so that could be a problem I have to solve. I’m also hopeful that Gtk3 on OSX would allow Shoes 3.2 (or 3.3) without anyone having to learn much about Objective-C or Cocoa. I’m not likely to do the the OSX work, but I’m hopeful someone will step up. Red shoes is not dead — It’s in the recovery room. Upgraded from Critical to stable.

Oh, one more thing. Or two things. I created a new icon and named my fork Federales because I’m just different and ornery. Federales is a rift on Policeman so there is some continuity in the naming. The icon background is the Mexican flag for obvious pun reasons.

Shoes 3.2b1 (Gtk2) For Windows

Updated

There is a new Shoes 3.2 (beta 1 Gtk2) that can be downloaded for Windows. It should run all the samples that Red Shoes 3.1 does with a few exceptions. It might even run existing Shoes programs if they don’t use Shoes.setup — that won’t work (so samples/simple-rubygems.rb won’t either). I suspect the samples that download from the internet may discover threading errors. Some of those samples don’t work on Linux either.

What makes this interesting? It uses (and includes) the Gtk2 GUI toolkit – the same toolkit as Linux versions of Shoes. It doesn’t depend on someone on the development team knowing how to code Windows GUI in C — in fact, this Shoes 3.2 Windows application was built entirely on Linux. I tested it briefly with Windows 7 and XP (virtual machines). As always, I seek feedback. Send me email at ccoupe@cableone.net or at the Shoes mailing list.

[Update 2014-01-23]
I created a Shoes 3.2 (beta 1 MSW) (download here). This one doesn’t use Gtk — it uses the normal windows controls and the Shoes code for them. It does run and it might be a tiny bit quicker. It shares some bugs with the Gtk2 version and IMO, it has some new bugs. I only did it to see what happens and close up a karmic gap. My interest is fixing the Gtk2/Gtk3 versions.

Shoes 3.2a1 (Federales) for Windows. Proof of concept.

Chipmunk-Windows

[Updated Jan 12, 2014 for Shoes3.2.a1]
Recognize it? It’s the Shoes simple-chipmunk sample. Wait! Is that running in Windows 7 with Cecil’s silly Federales icon instead of the regular Shoes icon? Yes it is. It’s also more much more than that.

I cross compiled that on Linux and created an installer (on Linux). I copied the shoes3.2.exe to Windows 7 and double clicked the installer, and I took the installer defaults because I know very little about Windows.  The Ruby inside is 1.9.3 . We never got policeman to use anything newer than 1.9.1 on Windows.  You can’t see it from the screen shot, but it is running on Gnome 3.6 libraries that are included with the installer.  [pause]  That’s right – it’s not using the problematic windows code in Shoes that no one was willing to maintain.  I didn’t update the Windows code, either.  Instead I used Gnome’s cross platform capabilities. The gnomes at Gnome.org did the hard work.

[Pause more while the implications bubble up]

Yes, any developer  with a properly set up Linux or OSX box could produce that Shoes for Windows installer and never have to use cmd.exe or MSYS or RubyInstaller to build any part of it.

Gnome claims to have a OSX Quartz (not X11) layer. [Pause]  So, in theory no one has to  learn Objective-C to maintain Red Shoes for OSX because the Gnomes did it. So the windows and cocoa code could be deleted from Shoes? That’s the theory and it just might work if an OSX developer or two try it.

Pretty heady stuff, eh?

[Reality Break]

It’s Gtk3 and I haven’t fixed the Shoes bugs with that. On the plus side, those known bugs fail the same way on Windows.  See my previous post. As I write this post, the Shoes3.2/Windows  complains (and dies) for lack of GSetting’s for dialogs. Like the splash screen “open an app” and simple-dialogs/color.  But the manual and console works and you can run the samples from the manual (and get the known errors). I’ll bet it hangs or croaks if you attempt to download something from the net.

I’m calling it Alpha-1 but it’s really just a proof of concept. You shouldn’t use it for developing Shoes scripts. It’s NO WHERE good enough to use.  Oh one more thing,  Clicking on packaging anything  just won’t work  – don’t bother downloading if you hope it will fix a current problem with Red Shoes.  It won’t fix anything.  Proof of Concept.  More known errors than Jesus had disciples.

But, some folks will  try it. Let me know if it installs and kind of works like I described. You could clone or fork the source but If I were you, I’d wait – because it’s not ready.

 

Shoes 3.2 Alpha 1

I’ve been busy upgrading Shoes 3 (aka Policeman)  to be a maintenance release that works better for Linux users. I have lofty goals and I also know reality can cut the knees out of lofty. Still, for those Linux users willing to take a few minutes, they might enjoy helping me test this release and sending a bug report to ccoupe@cableone.net or to the Shoes Mailing list  .  I’m calling this release ‘Federales’ because its a Policeman maintenance release, but different enough that I want a new name.

Alpha release means that I know what doesn’t work. I need to tell you what doesn’t work: There is nothing new for Windows or OSX users. Sorry. . There are graphics/clipping bugs – minor until you try samples/simple-accordian.rb or samples/simple-menu.rb. I already know about them, so no need to report that. If you use Link and Linkhover as a variation of ‘para’, they won’t work until you change them to Shoes::Link and Shoes::Linkhover. Some constants like PI have to be Shoes::PI.  Sorry.  I plan to fix the Gtk bugs. Link and Linkhover. Probably not anytime soon.

Enough with the Negative Nancy downers dude, what does Federales (a1) do for Linux users?

  1. It uses Gtk+-3.0 which is kind of like ah, modern. Less apt-gets and yums to get it working. None, I hope.
  2. Very good  chance the binary releases will work for your Linux. Your feedback is requested.
  3. You can use  gems that Shoes doesn’t  include.  It’s  not obvious yet because I’m too busy to write the release notes on how to do that,  but see the cache.rb file and then ‘touch getoutofjail.card’ in the proper directory. That directory is likely to change soon.
  4. Did I mention there is a Raspberry pi binary download?  And it works. (for me). Please report your experience with it.

Installing Shoes Federales-a1 is simple. Download from the links below and save it wherever your browser will let you in your home directory. Open a terminal and cd there.  Then do ‘tar zxf <the-downloaded-file>. It should create a directory starting with ‘shoes3.2a1’ plus your choice of architecture. For example, on my suse VM, Firefox just puts it in Downloads without my options. OK.

ccoupe@linux-n295:~> cd Downloads/
ccoupe@linux-n295:~/Downloads> ls
shoes3.2a1-x86_64-linux.tar.gz
ccoupe@linux-n295:~/Downloads> tar -zxf shoes3.2a1-x86_64-linux.tar.gz
ccoupe@linux-n295:~/Downloads> ./shoes3.2a1-x86_64-linux/shoes ./shoes3.2a1-x86_64-linux/samples/simple-chipmunk.rb

If I were you, I’d move/rename the directory to be something less awful. Shoes doesn’t care. I happen to like the chipmunk demo, If you don’t specify a file name to load, you’ll get the normal Shoes splash screen animation. Try it. Try some of the other samples. (some will fail). Delete it when you’ve seem enough.

So, where do I get this Shoes 3.2 Federales Alpha 1 Release for my Linux so that I can tell you what I really think?

Please leave a comment here, send an email to the -Shoes Mailing list or email me directly.