Almost not related to Shoes: I wanted to discover how many of the hundreds of the daily downloads are what I would consider legitimate – real people downloading Shoes or real people using the Shoes packaging. How many bots, or idiot leachers or just evil folks and what are their IP#’s ? Some of them need to go into .htaccess in deny entries.
So I created some ruby scripts to process a collection of Apache (combined format) log files and stuff them into a local Sqlite3 db. I’m not a fan of SQL, but it’s the right tool for this. After many syntax errors I’ve got 7 days of shoes.mvmanila.com log entries (3475) which is enough to pick out the evil-doers, the idiots, the clueless and the friends.
Did I mention I don’t like SQL. I barely know what I’m doing. If someone one wants to help me analyze these logs, contact me at firstname.lastname@example.org and I’ll share the Ruby scripts and database. Because some of us jusst like to know things. I share your pain.
sqlite> select * from logentry where browser='Ruby'; shows me the Shoes (or other Ruby), AKA real people are using packager. If I knew SQL better I could probably figure how to count them or I could parse the results into a ruby hash based on the url (what are people really packaging for). Yes it would be butt easy to bin them into a ‘friends’ table and to populate an ‘evil doers’ table (because they POST instead of GET or they GET on things like index.php which just don’t exist at the site. Create another table for script kiddies. Some might end up in .htaccess deny entries.
Yes, I can track user behavior IF they use this site. I don’t care unless you abuse this site. There is a lot of abuse going on and has been ever since I went live. It always will occur but that doesn’t mean I have to accept it forever. I can clean my house and lock the doors when I want.
Available at the usual places
New with 3.2.24 or here (same place)
- Added show_console command for OSX and Linux to match Windows.
Dumber that dumb console. Works with readline if you don’t expect too
much. Although -w and –console switches do work on the command line
you probably don’t need them now that you can call Shoes::show_console
- OSX: new cshoes script for using Shoes from the command line.
Fixes some annoyances.
wiki: Command line for OSX
Fixed with 3.2.24
- Restore old behavior with ask/alert/confirm auto converting to string
- OSX: Fix issue #08 (again)
- OSX issue #20, 137 – command line incomplete, multiple apps
- dialog works better
- OSX: ask() dialog gets an icon like alert() and confirm()
- Windows: can now find the correct timezone for Time.now
- Windows packaging bug
Byebug is a Ruby debugger and it works on Shoes if it’s launched from the terminal (Linux, Windows) and if you can compile the gem and if your do the
require 'byebug' and insert the byebug command into a shoes script where you want debugging to start. Obviously, not integrated into Shoes but if It could be taught to use the Shoes-IRB console that might be very interesting. No promises.
I’ve been swimming in the deep waters as has contributer @passenger. Laying the ground work for a better future.
No, really we are. It’s also spring time and outside calls. The potatoes in the garden look good for this early. I’ve been looking for a new car – an endeavor that gear heads take very seriously.
Still, I did managed to come up with a scheme to handle gems better but that’s a developer improvement you say?! On the other hand I’ve got nokogiri built in to Shoes 3.2.23 instead of hpricot. That turned to be a huge effort. On the other hand, if the gem can be built by Ruby (all platforms) , it can be included into a Shoes build, if you build Shoes from source. It’s not difficult one you know what to do which turns out to be ‘a wee bit tricky’. Anyway, that’s in the Shoes 3.2.23 bets Plus some bug fixes and tweaks.
At the moment, you can’t package your Shoes app with platform dependent binary (‘C‘) gems. I have a cunning plan.
To test the default custom packager I need some icons and an a Shoes app (must be shy’able app). I ‘ll use my Shoes app, ytm – Yield to Maturity calculator which is stored in the ~/Projects/ytm/ directory on my system. I don’t want the icons inside the ytm/ – a decision I’ll probably change later. For now, being a clever boy, I’ll create ~/Projects/icons/ytm/ and do the dirty work in there. For now I only care about the icon on the Desktop.
For Linux that’s
PNG image data, 128 x 128, 8-bit/color RGBA, non-interlaced. I’ll be using Gimp on Linux so the first thing to do is create a gimp file ytm.xcf, and create a new file 128*128 with a transparent background and then set the text tool to 48 pts and cleverly create this minimalist thing that I export from Gimp into a png.
It’s only a test. It doesn’t have to be pretty! I’ll name it ytm-128.png. Then scale it and export for 64×64, 48×48, 32×32 and 16×16. you can easily guess the the names.
Now I need to make a Windows ico file. And a OSX icns file. Gimp is less helpful to clueless folks like me. I have ImageMagick so it’s a simple
$ convert ytm-16.png ytm-32.png ytm-64.png ytm-128.png ytm.ico. That’s a larger file (90Kb) than I’d like but it’s only a test. The interwebs is filled with cloud apps to do the work for you. I used IConvertIcons. Good enough for me.
ccoupe@bronco:~/Projects/icons/ytm$ ls -ld ytm.*
-rw-rw-r-- 1 ccoupe ccoupe 20974 Nov 27 00:26 ytm.icns
-rw-rw-r-- 1 ccoupe ccoupe 99678 Nov 27 00:18 ytm.ico
-rw-rw-r-- 1 ccoupe ccoupe 1033 Nov 27 00:28 ytm.png
-rw-rw-r-- 1 ccoupe ccoupe 2824 Nov 26 22:44 ytm.xcf
I’ve been working on the Shoes hanging bug on Windows. It hasn’t been easy and I’m way above my pay grade on Windows internals. So many rabbit holes to explore. Every time I think I know what’s happening, I’m proven wrong.
Today, once again. I think I know what’s going wrong. I’ve got clues and hypotheses. I’ve confirmed some “that’s not right” behavior deep down in Shoes and Gtk/win32. I’m also smart enough to know that I don’t know my ass from a hole in the ground. I’m getting a lot more Windows education than I ever wanted.
At the moment, I think gtk/win32 and Ruby have different ideas about what an ‘fd’ is and that I should ‘unify‘ them. [snort]. One fd table to rule them all. Or a hack so each (Gtk, Ruby) believes their is one unified fd table. I’m leaning towards the hack. And then I’ll fix the real problem.
Or Shoes 4 will be released.
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.
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.
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.
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