Twelve years!
You hit me with a cricket bat!
Ha! Twelve years!
Monday, February 28
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.)
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
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.
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.
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.
Posted by: Pixy Misa at
04:23 PM
| Comments (2)
| Add Comment
| Trackbacks (Suck)
Post contains 263 words, total size 2 kb.
Saturday, February 26
Biscuit.
Science.
Dresden Codak is why I don't have a web comic. Well, that and the lack of artistic talent. Say what you will about Order of the Stick* or Erfworld* or Penny Arcade** or XKCD*, Dresden Codak is a work of art.
The story proper (that is, Kim's story) starts here. The artwork in the older panels isn't as good as it is now, but it doesn't take long to start throwing up gems like Trouble in Memphis* or Girl vs. Bear.* Or Dungeons and Discourse* or, of course, the delightful and aforementioned Copan.* Or Rule 110,* which has one of the greatest lines in literary history.
Read it.*
* It's brilliant.
** Also brilliant, albeit erratic.
Posted by: Pixy Misa at
12:41 PM
| Comments (2)
| Add Comment
| Trackbacks (Suck)
Post contains 120 words, total size 2 kb.
Friday, February 25
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.
Let me guess, Kore wa Zombie Desu ka is in a post-midnight timeslot?
(Checks.)
Yup.
But then so is Kimi ni Todoke, and that show contains hardly any zombies at all.
Posted by: Pixy Misa at
12:03 AM
| Comments (2)
| Add Comment
| Trackbacks (Suck)
Post contains 35 words, total size 1 kb.
Wednesday, February 23
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
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
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
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.
58 queries taking 0.4313 seconds, 383 records returned.
Powered by Minx 1.1.6c-pink.