There’s a post over on the Smart Mobile Studio dev blog explaining that, due to an arrangement between them and the company that Eric Grange works for, they’ve obtained the exclusive rights to DWS’s Javascript code generator, and it’s

hereby withdrawn from public use. Any company currently deploying this technology, or a derivative of it, is bound by international law to abandon it.

Well, there’s just one problem with that: they can’t do it.  The JS codegen units, like the rest of DWS, were published under the Mozilla Public License, with an MPL header at the top and everything, and the MPL grants those who download the code

a world-wide, royalty-free, non-exclusive license under intellectual property rights (other than patent or trademark) Licensable by Contributor, to use, reproduce, modify, display, perform, sublicense and distribute the Modifications created by such Contributor (or portions thereof) either on an unmodified basis, with other Modifications, as Covered Code and/or as part of a Larger Work.

The only ways that a license grant under the MPL can be terminated are specified in section 8: if the licensee fails to comply with the terms of the MPL, or if the licensee tries to sue the developer.  It very conspicuously does not say that the developer can revoke the license.

Even Borland understood this.  They never tried to strip InterBase (which they published under the MPL at one point) of its open-source status when they decided they wanted to keep working on it as a proprietary project.  They just stopped contributing to Firebird, started pretending like it didn’t exist instead, and kept working on InterBase and trying to differentiate it with new and better features.  And they certainly didn’t assert that people using or developing Firebird were in violation of international law.

This would be the best course of action for Optimale Systemer AS to take as well.  They’re free to continue further, proprietary work on it, and now they’ll need to if they want to differentiate it from what’s already out there.  Anyone else is still free to use, or even to fork and continue working on, the existing code.  (Which, by the way, has been deleted from SVN in the Google Code repository’s head, but is still available if you check out to revision #1462.)  Their current position is legally untenable, claims of “international law” notwithstanding.  It would never hold up in court, and I certainly hope they don’t waste any resources proving that.  They’d be much better spent continuing to improve their product.

I wonder if any other developers will be willing to take up the mantle and continue work on the open-source JS codegen, the way Eric did for DWS itself after Matthias Ackermann stopped working on it?

…and couldn’t.  The payment processor they’ve got set up doesn’t like free email accounts (which pretty much everyone on the entire Internet has) and the only alternative they offered was to mail them a check.  (Seriously?  Do they think it’s still the 90s or something?)  And they didn’t even accept PayPal, which is kind of ridiculous in 2012.  So, note to anyone out there who wants to handle payments for something: please avoid Digital River like the plague until they shape up their act.  Do not make it difficult for your customers to give you their money.

So I emailed Jon Lennart Aasenden about it, explaining the problems I’d had.  And it’s kind of magical, the way words like “your broken payment processor just lost you a few hundred dollars” can motivate people to act.  I had an email back from Jon within about 5 minutes, and a new purchase link about 3 hours later.

It was with a service I’ve never seen before, called Gumroad.  And I was a bit shocked at how simple it was.  They asked for my email address and my card data, and that was it.  No signups or logins, no restrictions, no runarounds, no ridiculous forms asking me to fill in my mailing address when I’m buying a digital download… nothing.  It was just like handing the cashier my card at a physical store.  They took the card info, processed the payment, and emailed me the download link.  Hopefully the Smart team will be smart enough to set this up as their default payment system!

My experience there was what online payment should have been like all along, and seeing it now, I’m a bit surprised that it’s taken someone this long to come up with it!  It’s one of those things that seems obvious in hindsight.  And according to the email I got from the Smart team, it was just about that simple on their end too:  “Gumroad made me go WOW when I started to worked with it.  Everything was set up within minutes.”

I looked around their site a little, and it really does look like it’s just that easy to set things up, with a simple JSON-based REST API.  The one downside I noticed was that the cut they take of payments was a couple percentage points higher than other, more established services such as PayPal or Google Checkout.  (Though I suspect that if they get more business, economies of scale will allow them to bring that down.)  And they provide an optional callback system where their server can call your server to allow you to process things on your end, to do things like generate a license key, or update a user’s account with new data.

Overall, I’m pretty impressed with the system.  This is something I’d like to see become successful.  So if anyone out there wants to handle payments for something, please avoid Digital River like the plague, and try Gumroad instead.  Your customers will thank you.

With Black March, we intend to fight back.  The entertainment industry is made up of corporations, and when people note that corporations are abusing their power, one of the standard responses to any complaint is “if you don’t like it, then don’t buy their products.”  So we’re deciding not to.

March is the final month in the first financial quarter, and we’re celebrating it with a worldwide boycott of all entertainment industry products.  For one month, we will not buy any music, movies, books, magazines or video games from any company that is part of the problem.  This is a move designed to leave a gaping hole in the industry’s finances for the first quarter.  The Internet has become an essential part of our society, and interference with its operation will not be tolerated.

And although the Black March site doesn’t mention it, I think that what you do do is as important as what you don’t do.  Not everyone creating and distributing entertainment is part of the problem.  On the other side of the spectrum, we’ve got independent music and film creators who create and distribute their work without industry control.  We’ve got game developers like Stardock, who produce and sell high-quality games and refuse to violate their users’ rights with DRM.  We’ve got authors like Howard Tayler, a former computer programmer who’s been supporting himself and his family for several years now on the revenues from merchandise from his consistently-funny webcomic Schlock Mercenary.

There are people, and even a few companies, that are working with the Internet instead of against it to make their income, and I think that it’s important to support them.  They’re the future we want to help create as we reject the outdated past that the dinosaurs of the industry are trying to keep us stuck in.

A while back, I purchased Elemental, the latest game by Stardock, a company with a reputation for making high-quality games and for being a lot more ethical than many gaming companies.  Their Sins of a Solar Empire was the best-selling game of 2008, for example, even though they refused to put any DRM on their software.  (So much for piracy destroying sales!)  They’re also the guys who created Impulse, a Steam competitor that ended up getting bought by GameStop last year.

Elemental, unfortunately, was not a high-quality game.  The basic concept was decent–not exceptional, but not *bad* either–but the game itself was a slow, crashy, bug-ridden mess.  Several patches over the course of several months eventually got it to a mostly-decent state, but in no way did it live up to expectations.

They just did something that does a lot to redeem them in my eyes.  I woke up this morning with the following letter in my email:

Dear Stardock Customer,

If you’re receiving this email it means you purchased Elemental: War of Magic before November 1, 2010.

Elemental: War of Magic was a game we had very high hopes for. Unfortunately, it was a disappointment both to us, as well as to many of our customers. Stardock’s success in its nineteen years of existence has been because people know when they buy something with our name on it, it’ll be excellent. With Elemental: War of Magic, we failed that expectation.

For the past year, Stardock has been working on something new — Elemental: Fallen Enchantress. We went back to the drawing board to create not an expansion, but rather a new game in the Elemental universe.

Fallen Enchantress is currently in beta. The beta has already been added to your Stardock account and the final version will automatically be added free of charge on the day of release.

To access the beta, visit: [download link].

We hope you find Elemental: Fallen Enchantress to be a game that lives up to the expectations you had for War of Magic. We thank you for your support and we look forward to your feedback.

Sincerely,
Brad Wardell – President & CEO
Stardock Entertainment

I really appreciate that.  They didn’t have any obligation to do that, but it’s the right thing to do.  When your customers pay for something and then obviously do not get their money’s worth, you acknowledge it and find a way to make up for it.  If only more game companies (or software companies in general) out there had leaders with Brad Wardell’s conscience and sense of responsibility…

http://tvtropes.org/pmwiki/pmwiki.php/Main/SinsOfASolarEmpire

…a logical fallacy which asserts that given two positions there exists a compromise between them which must be correct.  [It] implies that the positions being considered represent extremes of a continuum of opinions, and that such extremes are always wrong, and the middle ground is always correct. This is not always the case. Sometimes only X or Y is acceptable, with no middle ground possible. Additionally, the middle ground fallacy allows any position to be invalidated, even those that have been reached by previous applications of the same method; all one must do is present yet another, radically opposed position, and the middle-ground compromise will be forced closer to that position.

I added emphasis to a very important part of the explanation.  All you have to do to make something bad look good is come up with something even worse to compare it to.  And given the human capacity for imagination, that’s not such a difficult task.

You’ve probably heard of SOPA and Protect-IP by now.  Pretty much everyone who looks at these bills, outside of the entertainment industry, agrees on a few simple points:

1. These bills would give private corporations the power to censor the Internet
2. These bills are unconstitutional, as they violate the 1st amendment
3. These bills are evil and need to be stopped

Well, there’s some good news, and some bad news.  The good news is that as more and more people are finding out about them, they’re talking to their congressional representatives, and it looks like support for these bills is falling.  It’s looking likely that they won’t pass.

The bad news is the Golden Mean Fallacy.  Take a look at Stop American Censorship, one of the sites that’s working to coordinate the opposition to this legislation.  Check out the quotes down at the bottom, from experts on the subject.  I was a bit horrified to see multiple people saying, in effect, “the DMCA is OK, but this goes too far!”

That’s the Golden Mean Fallacy talking.  If we accept the Digital Millennium Copyright Act as legitimate, we’ve already lost.  It’s every bit as unconstitutional and every bit as evil as SOPA, and to be honest I’m  shocked that it’s apparently never been subject to judicial review on 5th or 14th amendment grounds.  You probably know of the 5th amendment as the one that says you can “take the 5th” in court, meaning that you have the right to not incriminate yourself.  But it also guarantees that you cannot “be deprived of life, liberty, or property, without due process of law.”  The 14th amendment reiterates the whole “due process of law” thing, applying it to the states as well as the federal government.

In layman’s terms, we have a guarantee, repeated twice, in the Bill of Rights that nobody can be punished for a crime without due process of law, which means (among other things) that they have the right to a fair trial.  This is just as important as a foundation for our freedoms as the First Amendment, and the DMCA tramples all over it.

How does a copyright act trample on the right to due process?  I know it sounds strange at first, but the DMCA is a strange law.  It allows copyright owners to send takedown notices to allegedly-infringing Internet sites, claiming that they are hosting infringing material.  Under the law, this material must be removed right away, unless the owner believes that no infringement is taking place and is willing to start a fight over it.

This may not sound too unreasonable, until you realize that it puts the burden of proof on the accused.  It throws one of our most sacred legal traditions, the presumption of innocence (aka “innocent until proven guilty”) out the window.  Now you’re guilty, by default and without a trial, until proven innocent!  You need look no further than chillingeffects.org to see the damage that this is doing, by allowing copyright holders to make false or exaggerated copyright claims and get away with it.  The presumption of innocence and the right to due process exists for a reason!

But the DMCA does even worse than that: it also allows the use of DRM technology.  Have you ever had a problem activating a program that you legitimately bought?  Something goes wrong and you can’t use it even though you’ve paid for it and done everything right?  Then you can see the problem here.  It’s like the takedowns, but even worse, as you have no way to fight it.  The DRM software is unaccountable.  If it has a bug, (and all software has bugs,) you’re not innocent until proven guilty.  You’re not even guilty until proven innocent.  You’re simply guilty, and screw the proof!  It doesn’t matter if you actually broke the law or not, the copyright owner’s interpretation of the law is enforced upon you and there’s nothing you can do about it.

So the worst thing about SOPA is not SOPA at all.  It’s the opportunity it provides for the Golden Mean Fallacy to legitimize another piece of equally-evil legislation.  Until the DMCA is repealed, and not only repealed but reversed, giving DRM technology the legal status it truly deserves, which is that of malware with no legitimate use, problems like SOPA will continue popping up again and again, because it’s built on the foundation of rights abuses codified by the DMCA.

Wikipedia is blacked out today, replacing its articles with a page urging people to contact their Congressmen in opposition to SOPA.  That’s a good gesture, but ultimately meaningless.  SOPA is getting enough opposition now that it’s not going to pass.  We’ve already won this battle.  What people need to contact their congressmen about is rooting out the source of this abuse.  “Repeal and reverse the DMCA,” not “stop SOPA,” needs to be the soundbite on people’s minds if we’re to truly protect our freedom in the Internet Age.

Our development office is in Lynnwood, Washington, (about half an hour from Seattle,) and on-site work is preferred, though some exceptions do (infrequently) get made on a case-by-case basis.  It’s a good location, right across the street from a major mall (plenty of places to go for lunch!), with good pay and working conditions.  The office has a friendly, engineer-centric culture, and it really helps that the manager is a former coder and the boss still is one.  No pointy hair here!

Only those who know what they’re doing need apply.  The developers take an active part in the interview process, and we’ve got really high standards.  We understand that the only way to develop good software is with good developers, and we try hard to make sure that that’s all we get.  But if you’re good and you can demonstrate that you know what you’re doing, you’re likely to get an offer.

If anyone’s interested, send me a resume at mwheeler@wideorbit.com and I’ll see about getting you an interview.

I’ve fixed a few bugs in the parser, and updated the executor to support the Environment object.  I added an Examples folder with two simple Hello World projects.  They both display a message box with a simple greeting.  The message box, of course, is not built in to the scripting system, so it has to be imported from the Delphi project.  These two sample programs demonstrate the two ways to do this: through external unit registration and with an Environment object.

The rsCompiler unit provides a class called TrsTypeImporter that’s used to import new types, variables, constants and routines (hmm… maybe I should change the name to just TrsImporter?) to make the compiler aware of them.  To register a new external unit, call RegisterStandardUnit on the compiler.  It takes two parameters: a unit name and an anonymous reference to a procedure that takes a TrsTypeImporter as an argument.  The first time a unit with that name is used in the script, the compiler will call the method reference, providing an importer to register things with the compiler.  A unit named “system” is always used, so if you want to import things that will always be available to the script, call RegisterStandardUnit and use “system” as the unit name.

Any units registered with the compiler also have to be registered with the script executor by a similar process.  The interface for the executor’s RegisterStandardUnit system is not stable yet, but it currently allows you to register your standalone routines in the callback.  I’ll add support for registering classes and external variables soon.

The second, simpler way to do imports is through the Environment object.  The second sample program shows how this works.  You declare a class and register it with the compiler, and every public method and property on it will be available to the script engine as if they were global routines and variables declared in the “system” import.  Then you register an instance of the class with the script executor before loading the program.  (It’s important to note that the Environment has to be registered with the compiler before compiling, and with the script executor before loading the program.)

It’s possible to use both systems together, of course.  If you want to break up your external routines into groups, you could declare and register multiple external units, but still have a group of globally-available methods in an Environment object.

Hopefully these examples will show people how to get started.  I’ll add some more examples as needed and when I get some more features ready.

Note: This is an alpha version.  There are probably plenty of bugs in it.  There are still features I haven’t gotten around to implementing.  The sight of the code would probably send Barry Kelly fleeing from the room, screaming in horror.  So use at your own risk, and I take no responsibility if this causes your system to crash, your data to come out all wrong, or demons to fly out your nose.  Specifically, the program keyword is not implemented yet, (only units,) var parameters don’t work yet, and a handful of features aren’t implemented in the script executor.

Having said that, here’s a few cool features I’ve come up with:

• Class creation:  Defining a new class inside the script code is not supported yet, but the basic framework is there, and script units implement new classes with their routines as methods, accessible to the script executor through the RTTI system.  I’ll add class creation pretty soon.
• Automatic registration: Ever try to register a class with the script engine in PascalScript?  It’s a painful process involving generating a registration unit that basically redeclares your entire class, and then has to be kept in sync or things break.  (And if you get the dependency order wrong, it fails silently,  leading to weird errors further down the line.)  I figured that was way too complicated, so for RTTIScript, all you have to do is register a class reference, and it uses the RTTI system to figure out the internal members and dependencies for you.
• Execution environment: You’ll often have a bunch of little standalone routines and global variables that you want to import into a script to have available at all times, to provide an interface between the script and your program.  So I introduced the concept of the “environment:” You create a class and register it with the compiler, and it treats all the class’s public methods and properties as globals for the script.  (This also means that you can use property getters and setters to have the script’s interaction with its “global variables” invoke side effects.)
• Script saving: I know Eric Grange thinks that a fast compiler is good enough and a bytecode version of a script is not necessary, but I don’t agree.  By his own tests, even a very fast script compiler can take 2 seconds to compile a 100,000 line script.  I’ve actually got an example of one that big in a project that the author wants to convert over once the TURBU project is ready.  Adding a two-second lag into the loading process and making the player wait while a level loads, which should feel instantaneous, is unacceptable.  I don’t have script saving implemented yet, but it’s definitely on the to-do list.

Anyway, the alpha version is available for any guinea pigs curious developers out there who’d like to take a look at it.  It requires Delphi XE, it’s pretty fast, and when I get the rest of the features set up it’s going to be awesome!  Feel free to check it out, and to submit a bug report if you find some errors. (Which I’m sure plenty of people will.)

They shouldn’t be.  I create the renderer in CreateWnd and I destroy it in DestroyWnd, which should get called as part of the component destruction process.  But as it turns out, DestroyWnd is not actually called anywhere!

By tracing through the VCL code, it looks like DestroyWnd is supposed to get called from a call stack that looks something like this:

TMyControl.DestroyWnd //virtual
TWinControl.DestroyHandle
TWinControl.RemoveControl
TControl.SetParent(nil)
TControl.Destroy

But earlier in the form destruction process, TWinControl.Remove gets called.  It does not call RemoveControl on the control being removed, and at the end of the routine, it says:

AControl.FParent := nil;

By directly setting the field to nil instead of calling SetParent(nil), it makes it so that when SetParent(nil) is called, the entire body of code gets short-circuited, so that RemoveControl is never called.  In fact, it’s not just my control.  I put a breakpoint on the first line of TWinControl.DestroyHandle, ran the program, and closed it, which generates and then frees almost 30 TWinControl descendants.  The breakpoint was never hit.

I’m seeing this in Delphi XE.  I haven’t tested it in any other version, but from what I can see, it appears that any VCL control created in XE will never call DestroyHandle during component destruction, leading to all window handles (and other resources, such as my rendering contexts) being leaked.

Can anyone confirm this, or say if it affects other versions?  I didn’t see this in QC, so I wrote up a bug report.  Please vote for it, especially if you work on a program with lots of complex forms and have users who would be, shall we say, unamused to suddenly hit an “out of resources” error for no good reason…

There is a better way, by the way.  Python has it; it’s called “slicing.”  You know how in Delphi, you can use array[subscript] notation to get a single item out of an array?  Well in Python you can use an extended version of that to get a subrange (a slice) out of an array.  For example:

returns “string”.  (In Python, strings start at index 0.)  Also, you don’t need a value on both sides of the colon.  If you don’t provide one, it translates to the beginning/end of the array, as appropriate.  So “mystring[:6]” returns “Python” and “mystring[14:]” returns “slicing”.

Now, using a colon here isn’t very Pascal-ish.  Colons are for variable declarations.  But we do have a range operator that’ s used with arrays: the double dot.  Wouldn’t it be nice to be able to do stuff like this in Delphi?

The compiler could translate this syntax to calls to Copy easily enough.  Also, they could improve on the concept a little.  If you feed Python a negative number in a slicing expression, it will error out.  But if Delphi could automatically translate myArray[..-5] into myArray[..high(myArray) - 5], grabbing everything except the last  X number of elements would be that much easier.

Any thoughts?