Monthly Archives: July 2014

Backing down and wandering about

I continue to learn. That means mistakes were made. Enough with the Negative Nancy self inflicted recriminations. Be positive! I got this to work on Shoes 3.2, Raspberry PI.
hh-rpi

You could die, have a long conversation with the diety of your choice and be sent back to earth as an avenging angel while it starts up. The opening animation just swamps the Pi in all the wrong ways. Not a teaching tool for the pi. I’m disappointed but not surprised.

I did not cross compile the hpricot and sqlite3 gems. Thats even more sucky than I remembered. I just used Shoes Cobbler to install the gems on the systems that have the compilation tools and libs to do so.

So where does that leave us with those Shoes Gems (hpricot, sqlite3)? I don’t want them tightly tied into to building Shoes 3.2. Perhaps a separate project ‘shoes-extras’ or ‘shoes-pack’ gemset, based more on rake-compiler. Not really a Shoes thing. Just cross compile the gems. And make them available to Shoes – maybe another Cobbler button to load them from the website and install them into the ~/.shoes/+gems

Sqlite3 would be the interesting one. That gem should include the ruby gem stuff AND the sqlite3.so and .h and .c

Gems

I’m having second thoughts about the Shoes 3 gems. So far, Shoes 3.2 doesn’t include Sqlite, hpricot, and json. Mostly because they are woefully out of date and depend on native libraries that most users don’t have so they too would have to be built and distributed with Shoes. Picking any version to include with Shoes 3.2 is just continuing the out-of-date problem. Shoes 3.2 has ways for experienced Ruby folk to get them installed.

On the other hand, it’s not Shoes for newbies without them (even if nobody uses them). Let’s review them.

  • Json – there a version that comes with Ruby 2.1.x. Is it api compatible?
  • Hpricot – There’s a slightly newer version but I don’t think it’s actively maintained. For Shoes 3.2 that’s probably a good thing -it won’t change. Cross compiling it for Windows might be a problem. Who knows what silliness might be required on OSX or which missing system libs are needed. I was doable before, it might not be that hard. I’ll talk about Nokogiri later.
  • Sqlite3 – A moving target but probably the easiest to accomodate. They distribute a dll so I don’t have to cross compile it for Windows. I would need to cross compile the sqlite3 gem

The real problem is the ext’s and the damn extconf.rb rakefiles and Ruby reluctance to be cross compiled. The way it work’s now for ext’s is lame. Adding 3 or 4 more would be painful. It might help some future mainainer if I make it less lame. It’s also silly to rebuild all of Shoes just to test a change in a gem or ext extconf.rb. They’re dynamically loaded – you don’t have to recompile everything for that. Nor should I have to recompile all gems because I add a # to shoes.rb

I haven’t worked the details yet but the overarching idea is they are gems and not part of Shoes. Separate build process. Perhaps they could be gems at a special Shoes gem repository. I don’t know.
Maybe a rake task ‘gems:sqlite3’ … that knows about the cross compile. Maybe not.

Shoes 3.2.13

This release fixes two bugs:

  1. Bug 264 – Gtk/Linux (and therefore Windows)
  2. Bug 230 – OSX – enable/disable edit_box

You might not be impressed but I’m pleased to get to the point of fixing bugs other than ‘can’t compile’ or ‘packager fails’ #230 actually required me to write Objective-C code. I got Textmate working well enough and I got lldb to work with OSX shoes (Loose Shoes OSX build). I tell ya, the sky’s the limit! The opportunity is endless!

trivia

Well, I did the hardest thing first to get the Mac Mini properly set up on the home network. I bought a desk for it. One you assemble yourself. Of course that means moving furniture and picking a style and color of your desk and assembling it. That takes longer than you think. I’m single so I don’t have to check with the style police after I decide what would please me so that saves many days.

TextMate (2) seems to be the popular editor for OSX. It comes with a theme I can’t stand. It took a while to find where to set a new one. View->Theme. I selected Dawn because it’s the first one that doesn’t suck. Now I get onto actually trying to understand ShoesTextView and see if I can add some functionality.

Cocoa Time

Let the journey begin with a single step. That step would be learning how to run the lldb debugger on OSX. Single Step? Get it?

I choose to verify/fix this report about OSX edit_box not being disabled. The author provided a test example and clue to the solution. Nice!
The example did fail on OSX and did work on Linux/Gtk2. I thought the example also needed another test,
once it’s disabled at creation, can be enabled later? That’s bug230.rb at my Github.

Reading Objective-C and Cocoa isn’t that hard to read. You already know what it’s supposed to do. Sure enough, it doesn’t process the attr parameter in cocoa.m:shoes_native_edit_box – it must do that somewhere else to set up sizes, fonts the other style options (initFrame seems likely). I could test for :state here though. Is that the smell of a hack approaching? I do believe it is. Perhaps the enabled/disabled state should be a new instance variable in the class. That feels less hacky and it might be useful for some future. I’m going slow with this because I do not know enough Objective-C or Cocoa to go cowbody. Learning experiences ahead!

I also learned the generated Info.Plist and much of App file structrure is pretty dated. It still works, for now.

Once of the advantages of a Loose Shoes (default build to dist/) is that’s easier to debug. For now (because of the Plist and/or the shell launch script), you have to point lldb to Shoes.app/Content/MacOS/shoes-bin. Then you can set breakpoints and start the app. I wouldn’t expect that to work with a OSX/Tight Shoes because of the pango-module stuff. Maybe I can setup a .lldb init script in dist/ from the rake file? That would be fun and potentially useful since it’s likely I’ll be spending some time with my new best friend, lldb.

I should install a decent project aware text editor like Geany). I think I’ll buy another mac keyboard too and an Apple mouse and keyboard tray for that desk. Maybe I can find a better, used monitor. Damn! I knew that would happen – let Mac in the network and it takes over!

Cowboy coding

Here’s the setup.
Shoes.app do
flow do
check(checked: true).click do |c|
# alert "#{c.checked?}"
para "Check 1 #{c.checked?}\n"
end
para "Check 1"
end
flow do
@c = check(checked: false).click do |c|
para "Check 2 #{c.checked?}\n"
end
para "Check 2"
@c.checked = true
end
para "First line or Last line?\n"
end

has different results on Linux(GTK) vs OSX. In Linux, the click block is run before the user gets a chance to check or uncheck. IMNSHO, that’s wrong and if the click block runs something complicated – like an SQL query, all kinds of strange things could happen. OSX does’nt run the click block at startup.

That undefined behaviour has been there for years and years. So I decided to ‘Go Cowboy’ — I asked the Shoes 4 team what they think and then without waiting for their answer, I changed Shoes 3.2 Linux to match OSX behaviour. Since Shoes 3.2 Windows uses GTK2, it applies there as well. That’s cowboy problem solving in action.

That’s a change you’ll see in 3.2.13.

Shoes 3.2.12

Oh happy day! I fixed the bug with url and visit — samples/class-book.rb. This also fixes bug reports #140, #208, #236 and perhaps a few more. Actually, I didn’t fix it. Ashbb fixed it several years ago and it got lost somehow. Considering how many hours I spent almost getting to where ashbb was, and the number of reported bugs that can be cleaned up, I think it is worthy of a Shoes 3.2.12 release It’s not like I’ll ever run short of teeny version numbers.

Unbounded huh?

I found a bug with Shoes 3.2 and versions of Ruby > 1.9.1. Actually I found a boat load of ‘huh?’ questions. I happen to have a copy of Shoes r1314 source (Shoes 3, maybe 3.1). It took a few minutes with the (single!) rakefile to get it to compile x86_64, ruby 1.9.1. samples/class-book.rb works. It doesn’t work on Shoes 3.2 – it segfaults if shoes 3.2 and the script are started from the command line. If you run the script from the splash screen ‘open an app’ like then you get a Shoes console message. Grrr.

Either way you get to app.c:372 and app.c:316 and rb_cUnboundMethod as it tries to process ‘/’ at startup if the Shoes derived class has defined ‘url x,:y’ paths. I happen to have my ytm (yield to maturity) Shoes app and I thought it should work. It doesn’t for the same reason that class-book doesn’t.

It has every thing to do with rb_cUnboundMethod. Do a google search and the top items are Shoes posts from back in the Ruby 1.8.5 days. Oh my! There just aren’t that many C programs that embed Ruby to have built much of a Google knowledge base. I think I know the intent of the code but I’ll bet I haven’t thought it through deep enough to replace it with something that works.

Hackety Black Hole

I’m still working on the website(s) dark hole of good intentions, unrealized. New background image for new theme. I added a Links menu up top.

Then I got distracted checking the links to Hackety-Hack. The good news? Hackety can (does) work with Shoes 3.2 if you run the source code (github) The bad news: I’m not likely to fix it anytime soon for packaging. There are tar balls and then there are tar babies and I know the difference. I’d be willing to help someone else. It’s certainly do-able with Shoes 3.2 and some changes to my packaging scheme. I’d don’t want to own it. My plate is full.

Then again, Shoes 4 shows what they intend for apps like Hackety. It’s something I should think about. It’s not like I’m happy with the current Shoes 3.2 packager. Tar babies! Every where I look!

Walkabout

I’m moving things around. This is the new home for the Shoes 3.2 blog posts. Why Walkabout?  Would you like the short story or the long story?

I like to think why_the_luck_stiff just went on hiatus, a walkabout.  He’ll be back.  Is that a romantic or religious notion? Hell yes. Before the Shoes Team decided to re-implement Shoes 3 with JRuby (aka Shoes 4), I proposed ‘walkabout’ would be the release after we got ‘policeman’ out.  Nobody objected.  It’s still a good name.

We kind of screwed up with the Policeman release. I’m embarrassed about that. It was bad. No excuses. Since then,  The “team” began working on Shoes 4 and a certain impatient person whose name matches mine waited a year to two and then created Shoes 3.2 (Federales) to tide us over until Shoes 4 arrives.

Federales (Shoes 3.2) is the most current version of Red Shoes. It’s really current: Ruby 2.1.x, all platforms + raspberry pi. Gem handling that works (Gems 2.2.2). Packaging that really works for all.

There is no ‘walkabout’ release, yet. Shoes is quirky and brilliant. I’m just quirky and plodding. So this blog is mostly about the Federales version of Red Shoes (MRI-ruby or cruby). If I do something amazing, I’ll name it ‘walkabout’ and won’t have to change the blog title or url, unless I want to.