This accidentally fell out of her pocket when I bumped into her. Took me four goes.

Monday, February 28

Geek

Embedded Magic

I spent a couple of days last year working on a simple scripting language for Minx (beyond what is already possible with templates, which support loops, conditions, and subroutines). 

I had looked at just using Python (but Python sandboxing is broken and long since deprecated), JavaScript (but none of the embeddable JavaScript libraries were production-ready) and Lua (but LunaticPython appeared to have been abandoned at the time, didn't compile out of the box, and once I patched it, didn't really work with multi-threaded applications).

I had a complete parser and was starting to implement the runtime system (I did say that it was a simple scripting language) when I discovered that some other people had picked up LunaticPython, dusted it off, and fixed all the issues I had with it.

Which is why Lua will be the official Minx scripting language.  (Or at least, the first such.)

/images/SayakaAndTheCrab.jpg?size=500x&q=95
This blog is turning into a wall of text, so here's a picture of a defenseless crab being menaced by a giant Sayaka Isoyama.

Now, Lua is neat language, clean and simple but very capable.  It's not used much for developing applications because its standard library is much smaller than, say, Python's, but for augmenting an existing application, it's perfect.  It's interpreted, but it's pretty snappy even so.  It's actually faster than Python, which means that user scripting could in theory outrun the application itself.  (With the proviso that it takes roughly a microsecond to make a function call from Lua back to Python to retrieve shared data.  Oh, and I'm currently running Minx under Psyco rather than standard Python, which gives it a roughly 2x speed increase.)

Recently there's been significant development on LuaJIT, which is exactly what you'd expect.*  And it's apparently pretty awesome - comparable in performance to C for numeric code, with no code changes.

And someone** has picked up LunaticPython, dusted it off, adapted it to LuaJIT, and renamed it Lupa.  Which means in theory that user scripting could run rings around the application itself.  Not that there's anything wrong with that.

If you want to read about the minutiae of Just In Time Compilers until your head falls off, go here.

The only problem remaining is that there's no first-class .Net implementation of Lua, or not that I know of.  That's a problem for Miko; if you want to be able to preview a post on your site before syncing it to the server, and your site uses Lua scripting, then Miko has to support Lua.  LuaInterface looks to be the way to go there, but I haven't had a chance to try it yet.  The advantage I have with Miko is that I don't have to worry about performance of the core engine to anywhere near the same degree: If there's a slow script gumming up the works, it's your slow script, since it only hosts your blog.

Oh, and yeah, the plan is for Miko to have a scripting IDE built in.  Nothing hugely complex, but a decent code editor and a very basic debugger.

* A Just In Time compiler for Lua, just as Pysco is a JIT for Python.
** Someone named Stefan Behnel.

Posted by: Pixy Misa at 02:06 AM | Comments (3) | Add Comment | Trackbacks (Suck)
Post contains 532 words, total size 4 kb.

Sunday, February 27

Geek

Miko Magic

I'm going to be taking a couple of months off work soon to try to catch up with my two-year backlog of mee.nu and mu.nu stuff* and one of the projects I'm keen to get up and running is Miko, the long-awaited Minx desktop client.

The basic design for Miko at this point is that it will be a container for a little single-site Minx implementation, running right on your desktop.  You can work online, with changes mirrored straight to the server, or offline, with changes synced when you click the little sync button.

All the posts and comments will be stored in a local database (as well as on the main server).  All your images and files will be mapped to a local folder, so you can upload any number of images just by dropping them into a folder and clicking sync.

The way it will work is that there'll be a simple Visual Basic GUI wrapped around a core written in IronPython.  The core won't be a full version of Minx, but it will contain the functionality needed to edit and preview your site offline.**

I'm probably going to be supporting the Blogger and/or WordPress APIs as well, but that will only allow you to do basic stuff, not all the cool stuff that's buried just under the surface of Minx that will be exposed in release 1.2, which is the other big thing I'll be working on the next couple of months.

/images/MikoAndCat.jpg?size=500x&q=95
Excuse me, but you appear to have a cat on your head.

This will also be a test run for the idea of migrating Minx to Mono.  IronPython, the .Net / Mono implementation of Python, is coming along quite nicely; they have a 2.7 release candidate out now.  With Mono, I'd lose access to a couple of libraries I use in Python (like PIL), but gain the ability to easily call code written in Ruby (via IronRuby) or PHP (via Phalanger) or Cobra or Boo.

Most of the Minx code ports right over to IronPython (with some changes to the templating system, which is dog slow in IronPython unless you replace some instances of String with StringBuilder), but I haven't got the whole framework converted much less done proper performance and stability tests.  So I'm starting out with a stripped-down instance with just the functionality needed to host a single site for a single user.  If that works out well, then we'll see.

* Not to mention my two-year backlog of sleep and my two-year backlog of seeing my family.

** Except possibly for Lua scripting, which is coming soon.  I have that working nicely for the server, but don't yet know how to make it work properly in Miko.

Posted by: Pixy Misa at 04:52 PM | Comments (1) | Add Comment | Trackbacks (Suck)
Post contains 457 words, total size 3 kb.

Geek

Black Magic

This:

    Protected Overrides ReadOnly Property CreateParams() As CreateParams
        Get
            Dim cp As CreateParams = MyBase.CreateParams
            cp.ExStyle = cp.ExStyle Or &H2000000
            Return cp
        End Get
    End Property 'CreateParams


If you have, oh, say, a Winforms VB.Net application with a tabbed interface and a variety of controls including a web browser and text boxes and so on, and you resize it, it will flicker like mad.  You can set it to double-buffer, and nothing whatsoever will change.

Add this little snippet of code to the form and suddenly the flicker is gone.  Just gone.  It works exactly how you would expect.

Why is this not the default - no, the only available - setting?

It's Microsoft.  Don't ask why.

Why are you working in Visual Basic?

Because I haven't done any Windows GUI programming in ten years, and VB.Net lets me doodle around, get a workable interface, and then write all the serious stuffs in IronPython.  (Importing all of IronPython adds about 1.4MB to the project for immeasurable added functionality.)

Okay, why are you working in Windows at all?

Miko, the desktop client for Minx.  Although the aim is for it to be more of a peer than a client.

Cool.  Why Winforms rather than WPF?

Yeah, well.  WPF is very much its own universe.  I can slap together a Winforms app and it seems to work much the same way that pre-.Net Windows coding did.  With WPF, even the form designer looks broken to me.

I didn't understand any of that.  Do you have any more pictures of Sayaka Isoyama?

Of course.

http://ai.mee.nu/images/SayakaAndTheDottedBikini.jpg?size=500x&q=95

Posted by: Pixy Misa at 04:23 PM | Comments (2) | Add Comment | Trackbacks (Suck)
Post contains 263 words, total size 2 kb.

Friday, February 25

Geek

Thunderbolt and Light Peak

Ah, good work, Intel engineer dudes.

I'd heard of Light Peak, Intel's future desktop I/O technology set to replace USB and Firewire and eSATA.  I hadn't looked into it all that closely, and what I didn't realise is that it's a rejiggered version of DisplayPort.

DisplayPort is actually a modern display interface.  VGA is just a standard connector for age-old separate colour and sync connections.  DVI is digital VGA - it actually incorporates horizontal and vertical retrace intervals.  HDMI is just a different cable for DVI with a sideband for audio.

DisplayPort is a packetised 10Gbps (and more recently, 20Gbps) general-purpose I/O interconnect that just happens to be sold as a video connector.

Light Peak, now renamed Thunderbolt, extends this to offer two bi-directional 10Gbps channels per port that can carry PCIe and DisplayPort data simultaneously.  You can daisy-chain up to seven devices (including two 2560x1600 monitors) per port.  And the standard Thunderbolt socket is identical to mini-DisplayPort, and works as that if you plug a DisplayPort monitor into it.

Basically, it's just killed off USB 3, Firewire, eSATA, DisplayPort, HDMI, DVI, and 10Gbps Ethernet as far as the desktop goes.

And all I can say to that is it's about time.

There's one big limitation (apart from the fact that the only device supporting it right now is the new Macbook Pro): The maximum cable length for the copper version is just 3 metres - 10 feet.  To run longer distances, you'll need an optical cable; I don't know if that runs off the same port (by building the optical components into the cable itself) or not.

All in all it looks like a very nice - and very welcome - piece of engineering.

Update: Apparently, yes, the optical transceivers will be built in to the cable, so the standard port remains standard and you simply use copper cables for short runs and fibre for longer runs.

Posted by: Pixy Misa at 02:12 AM | Comments (4) | Add Comment | Trackbacks (Suck)
Post contains 322 words, total size 2 kb.

Wednesday, February 23

Geek

Either Bioware Need To Work Less, Or I Do

Dragon Age II is out soon.  I haven't yet finished the original.

Mass Effect 3 will be out at the end of the year.  I haven't yet finished the original.

I only completed Planescape: Torment in 2007.  Give me a break here, guys!

Posted by: Pixy Misa at 09:10 PM | No Comments | Add Comment | Trackbacks (Suck)
Post contains 52 words, total size 1 kb.

Saturday, February 19

Geek

Inline Comments Broken In Chrome 10 Beta

Seems to be their fault; works everywhere else.

Posted by: Pixy Misa at 11:28 PM | No Comments | Add Comment | Trackbacks (Suck)
Post contains 15 words, total size 1 kb.

Friday, February 18

Geek

The Times, They Are A Changing

I was just poking around LiquidWeb's configurator - mu.nu used to be hosted there, years ago, and I was very happy with their support, and only moved because they didn't have quite what I was looking for when it came time to upgrade - anyway, I was poking around their configurator, and I noticed this:
Need more RAM? See our Enterprise Series Servers.
More than 64GB, that is.

The Enterprise Series goes up to 256GB.  That's quite a lot for a web server.

Posted by: Pixy Misa at 06:45 PM | Comments (6) | Add Comment | Trackbacks (Suck)
Post contains 87 words, total size 1 kb.

Thursday, February 17

Geek

I Got A New Router

Actually an integrated ADSL modem/router thingy - a Netgear N1000.  With my old 834G I had seven network dropouts this morning; with the new one, no dropouts since lunchtime.

Not sure why it failed after years of faithful service, but it looks like it did.

Posted by: Pixy Misa at 06:47 PM | Comments (2) | Add Comment | Trackbacks (Suck)
Post contains 50 words, total size 1 kb.

Geek

Cobra: Like Python, But With Teef

I've just spent the last hour tinkering with Cobra, a .Net/Mono-based application programming language.

I quite like it.  It's not perfect, but having dabbled in language design myself, I understand that there is no perfect language.  It's not just the limitations of human designers, or bad decisions that you end up stuck with; there are simply trade-offs that have to be made.  Making X elegant makes Y less so.

Occasionally there are clever and robust new ideas that allow us to make both X and Y elegant, but given the progress (hah!) in languge design since Algol 60 which appeared before I was born, I don't hold out a huge amount of hope that things will change significantly before I retire.

Anyway...

It's Python-like, though it's not Python.  (They also have a handy Ruby comparison page.)

It's fast - though Mono has a longer setup time than Python (~100ms vs <20ms, from my cursory testing), once it's up and running it's about as fast as Psyco, the sadly abandoned Python JIT compiler.  Which means, significantly faster than native Python.

And it has real threads.  One of the big problems I have with Python at my day job is that Python doesn't really do threads as a means of increasing performance.  The Global Interpreter Lock (the GIL) ensures that only one thread is executing Python code at any time.  Which means that if you spawn 50 threads, they'll all wait for each other and run little faster than one thread - and possibly quite a lot slower.

The reasons for this are support for non-thread-safe libraries and more efficient single-threaded execution (less locking is required if you're the only thread active at any given time).

The downside is that to get any scaling at all you have to go to multiple processes, and that requires a lot more code refactoring (and potentially a lot more memory) than multiple threads.

Anyway, .Net/Mono is fully multi-threaded; no such limitations apply.

What I don't like about Cobra: 4-space indenting.  I used to use 4 spaces, but lately I've been using 2, and I'd have to change back!!

That, and the Mono thing.  I haven't looked at Mono all that closely; Python has been my main programming language for most the past 4 years (with a brief but horrible excursion into PHP in 2008).  I know Python.  It just works.  Mono I'm not sure about.

Tomorrow, I think I'll venture into Boo-land.

Posted by: Pixy Misa at 04:52 AM | Comments (8) | Add Comment | Trackbacks (Suck)
Post contains 411 words, total size 3 kb.

Geek

Go Go Gadget Gnu Compiler Team!

I was just trying to confirm some confusing benchmark results, when I discovered something:

Python compiled with GCC 4.4.5 runs up to 50% faster than Python compiled with GCC 4.1.2.

Eineus runs CentOS 5 with the older version of GCC; Futaba runs Fedora 13 with the newer version.  Both are 32-bit and have Python 2.6.6 compiled from source.  (And they're OpenVZ VMs on the same host, so no hardware differences at all.)

[andrew@eineus ~]$ python test.py
Native
Loop: 0.943
String: 1.490
Scan: 0.547
Total: 2.980

[andrew@futaba ~]$ python test.py
Native
Loop: 0.600
String: 1.070
Scan: 0.537
Total: 2.207

That's good to know.

Psyco results don't vary much, since that has its own compiler.  But for some reason, the string scanning benchmark, which ran measurably slower under Psyco before, is now pretty much equal in speed to native Python.

It's a shame that Psyco has been pretty much abandoned; I understand that the code is unlovely cruft, but it's an incredibly useful tool.

Update: You can see how things have evolved over time with respect to CPU and compiler speeds:

All My Servers Are No Longer The Same Speed (2010)
All My Servers Are The Same Speed (2006)

Update: Did some more testing.  Python 2.6.6 compiled with GCC 4.4 on x64 averages 50% faster than the same version compiled with GCC 4.1 on x86.  It's pretty consistent across the board, too.

Posted by: Pixy Misa at 04:05 AM | No Comments | Add Comment | Trackbacks (Suck)
Post contains 234 words, total size 2 kb.

<< Page 1 of 2 >>
82kb generated in CPU 0.0252, elapsed 0.4685 seconds.
57 queries taking 0.4519 seconds, 369 records returned.
Powered by Minx 1.1.6c-pink.
Using https / https://ai.mee.nu / 367