Each time you upgrade Ubuntu you have to tweak your Wine repo for the newer version. This is not a huge problem, you can just follow the instructions on Wine's site which are nice and clear.
Karmic seems to be a little weird with this. The issue comes when you want to actually install wine through Synaptic. You can't install the package "wine" anymore, you get an error like this: "wine: Depends: wine1.2 but it is not going to be installed". You can fix this easily by just installing the wine1.2 package, but it is kinda weird that they did not set up the dependencies properly. Oh well.
So in short, to install wine:
1) Follow the instructions to add the Wine repository.
2) Go to System->Administration->Synaptic Package Manager
3) Search for wine1.2
4) Install the wine1.2 package by double clicking it. Accept any dependencies it asks for.
5) Click Apply.
Nov 14, 2009
Nov 13, 2009
Accented Characters in Ubuntu
A long time ago I set up my computer so that it was easy to type accents, but with the recent Karmic release the settings are gone and since I forgot how to set it up. Now that I've rediscovered it, I can not only reset it but also blog about it!
So suppose you want to type French characters like é, ç, etc. In Ubuntu, you can activate these with the following steps:
1) Go to System->Preferences->Keyboard
2) Click the Layouts tab
3) Click the button saying Layout Options
4) Click the triangle next to the Compose key position
5) Choose which compose key you want. I use Right Win.
After that, you should be able to use the accented characters. You can do this by first pressing your compose key, then your accent (not at the same time!), and then the character. For example to do a é, I would hit the Right Win key, then the ' key, then the e key.
You can do special characters too, like æ, but those ones usually you have to figure out on your own (for those interested, that one is Right Win, a, e).
So suppose you want to type French characters like é, ç, etc. In Ubuntu, you can activate these with the following steps:
1) Go to System->Preferences->Keyboard
2) Click the Layouts tab
3) Click the button saying Layout Options
4) Click the triangle next to the Compose key position
5) Choose which compose key you want. I use Right Win.
After that, you should be able to use the accented characters. You can do this by first pressing your compose key, then your accent (not at the same time!), and then the character. For example to do a é, I would hit the Right Win key, then the ' key, then the e key.
You can do special characters too, like æ, but those ones usually you have to figure out on your own (for those interested, that one is Right Win, a, e).
Nov 12, 2009
sizeof(int) != sizeof(int*)
I've been messing around with something called RUDL, which is supposed to be a more Ruby-like port of SDL than Ruby/SDL. This is a pretty good idea, it worked really well with pygame in my opinion, and so I would like to see this kind of thing in Ruby.
Unfortunately the coders for RUDL have done something that is extremely annoying. In some parts of the code, they assume that ints and pointer types are compatible. This is true in a 32-bit environment, since ints and pointers are both 32-bit, however in a 64-bit environment this is not the case. An int is still 32-bit, but pointers are 64-bit. This means that if you are converting from a pointer to an int back to a pointer (or something of that nature), things will not always behave as you expect.
I've seen this kind of thing before, and the situations in which it arises can be subtle. One time I saw someone using the varargs() system and they passed in 0 as a pointer value. This is fine in a 32-bit system, but with the untyped nature of the varargs stuff gcc was only zeroing the lower 32-bits of the value. So setting the pointer to 0 was not actually setting the pointer to zero, so later on when they did if(!pointer) it didn't work and caused the system to crash.
In RUDL the issue is less subtle. Within SDL's audio mixing system, you can label groups with an integer. So the system is using pointers to index these groups. In a 32-bit world this works fine since there is a 1-to-1 conversion for pointers to ints. Unfortunately in a 64-bit world, your pointers do not have a 1-to-1 conversion, so sometimes you will get conflicts and things will act weird.
So yes, if you can avoid it, do not treat an int like it is a pointer! This will make your code non-portable. And even if you do decide to do this, please heed your compilers warnings! gcc does give out warnings for this scenario, and you should listen to them.
Unfortunately the coders for RUDL have done something that is extremely annoying. In some parts of the code, they assume that ints and pointer types are compatible. This is true in a 32-bit environment, since ints and pointers are both 32-bit, however in a 64-bit environment this is not the case. An int is still 32-bit, but pointers are 64-bit. This means that if you are converting from a pointer to an int back to a pointer (or something of that nature), things will not always behave as you expect.
I've seen this kind of thing before, and the situations in which it arises can be subtle. One time I saw someone using the varargs() system and they passed in 0 as a pointer value. This is fine in a 32-bit system, but with the untyped nature of the varargs stuff gcc was only zeroing the lower 32-bits of the value. So setting the pointer to 0 was not actually setting the pointer to zero, so later on when they did if(!pointer) it didn't work and caused the system to crash.
In RUDL the issue is less subtle. Within SDL's audio mixing system, you can label groups with an integer. So the system is using pointers to index these groups. In a 32-bit world this works fine since there is a 1-to-1 conversion for pointers to ints. Unfortunately in a 64-bit world, your pointers do not have a 1-to-1 conversion, so sometimes you will get conflicts and things will act weird.
So yes, if you can avoid it, do not treat an int like it is a pointer! This will make your code non-portable. And even if you do decide to do this, please heed your compilers warnings! gcc does give out warnings for this scenario, and you should listen to them.
Nov 8, 2009
flot
Recently I've been working with a Javascript library called flot, which does graphs purely in Javascript. It's a pretty handy tool for plotting graphs without resorting to Flash or Java - it's pure Javascript. Not only that, but it is really snappy and looks good! There's a cool example here that shows both the graphing capabilities and interactivity.
It's not as powerful as Flex by any stretch, but unless you need fancy morphing of graphs or things like that flot is just fine for you. And you have the benefit of not having to use Flex/Flash to do it!
It's not as powerful as Flex by any stretch, but unless you need fancy morphing of graphs or things like that flot is just fine for you. And you have the benefit of not having to use Flex/Flash to do it!
Nov 6, 2009
Case Classes in Ruby
After working a bit in Scala and using the case classes and pattern matching, I've found it's pretty nice to have and it would go well in Ruby! So I've whipped up a little something basic, you can check out the Git repo here: http://github.com/robbrit/ruby_case_classes
What are case classes? They're basically simple classes that don't really do much other than store a set of values (possibly, they don't even need to do that). They're good on their own if you have very basic classes that you want to use, for example exceptions.
With my code, you define a case class like this:
Case classes are handy on their own to save a few keystrokes, but where they help a lot more is with pattern matching. Pattern matching comes from functional programming and was adopted by Scala. It is a handy feature to have, so that's why it is here.
To do pattern matching:
Guards are basic equality conditions that you can use to match against. If the object fits the guards, then the block is executed.
Note there is a fall-through here. The case that is executed is the first one to match the object, later ones that match are not executed.
Some possible improvements:
- match against values instead of just types. For example:
- case class new() doesn't need named parameters
Any other suggestions are welcome.
There's one bug (that I know of). It doesn't work at the top-level. So if this is your entire file, it will fail:
What are case classes? They're basically simple classes that don't really do much other than store a set of values (possibly, they don't even need to do that). They're good on their own if you have very basic classes that you want to use, for example exceptions.
With my code, you define a case class like this:
case_class :ClassName, BaseClass, <parameters>The parameters you pass at the end are the fields of the class and when you instantiate the object you can set them:
case_class :Hello, Object, :titleUnfortunately at the moment you have to specify the name of the field.
...
h = Hello.new(:title => "some title")
h.title # => "some title"
Case classes are handy on their own to save a few keystrokes, but where they help a lot more is with pattern matching. Pattern matching comes from functional programming and was adopted by Scala. It is a handy feature to have, so that's why it is here.
To do pattern matching:
case_class :Blah, Object, :titleHere we have four examples of things you can match against. You can match against just a type, you can match against a type with a guard, you can match against just a guard, and you can have a "default" case if it doesn't match anything.
case_class :Blih, Object, :title
...
blah = Blah.new(:title => "hello")
match blah do
# Type matching
for_case Blih do
...
end
# Guard and type matching
for_case Blah, :title => "hello" do
...
end
# Just guard matching
for_case "_", :title => "hello" do
...
end
# Multiple guards, one of which is a method call
for_case "_", :title => "hello", :to_i => 0 do
...
end
# Match anything - you could put "_" here, but it's optional
for_case do
...
end
end
Guards are basic equality conditions that you can use to match against. If the object fits the guards, then the block is executed.
Note there is a fall-through here. The case that is executed is the first one to match the object, later ones that match are not executed.
Some possible improvements:
- match against values instead of just types. For example:
for_case [] do ...- inequalities instead of strict equalities in guards
- case class new() doesn't need named parameters
Any other suggestions are welcome.
There's one bug (that I know of). It doesn't work at the top-level. So if this is your entire file, it will fail:
include CaseClassesYou need to wrap it in some object. I'm probably having a brain-fart or something as to how to fix this, but for now you'll have this limitation. If anybody has a solution around that, feel free to let me know.
case_class :Blah, Object
Nov 3, 2009
Empathy Fail
The recently released version of Ubuntu, 9.10, comes with a new default messenger program called Empathy, which replaces the venerable Pidgin. This is great, I'm not a huge fan of Pidgin for anything other than simple chat like IRC or Google Talk. It doesn't support video/audio chat, it has issues with synchronizing MSN contact lists (or at least it did, I haven't used Pidgin for MSN since, well it was still called gAIM last time I used MSN with it), and it looks like someone like me designed the GUI for it (it is very bare and plain).
Next, I want to compare it with aMSN, which is what I use for MSN. If it supports simultaneous audio/video chat, then I'm sold (provided there aren't any showstopper bugs). aMSN doesn't do this, so if I want to talk to my parents on the other end of the country (who don't have Skype) it is either with audio or video, but not both.
Also aMSN is done with Tk. While the developers have done a great job making it look decent, it's like putting makeup on an 80 year old. They still look like they're 80. So I'm hoping for something that looks a little more modern.
So now I'm trying out Empathy to see why it is so much better. It supports video/audio chat, which is great. First step - it offers to import my Pidgin accounts. Nice! I'll try that. Unfortunately it doesn't work, and I really have no idea why.
I also can't seem to add any accounts to it other than ones that don't require a password - namely IRC. This is because when I create the account it asks for my keyring password which I don't know, since I don't use Ubuntu's keyring. Since I didn't provide the keyring password, the thing decides it doesn't want to create the account. UPDATE: If you need help resetting your keyring, you can follow my instructions here.
In effect, Empathy isn't much more to me than an IRC client. I'm sorry, I'll just continue to use Pidgin.
Next, I want to compare it with aMSN, which is what I use for MSN. If it supports simultaneous audio/video chat, then I'm sold (provided there aren't any showstopper bugs). aMSN doesn't do this, so if I want to talk to my parents on the other end of the country (who don't have Skype) it is either with audio or video, but not both.
Also aMSN is done with Tk. While the developers have done a great job making it look decent, it's like putting makeup on an 80 year old. They still look like they're 80. So I'm hoping for something that looks a little more modern.
So now I'm trying out Empathy to see why it is so much better. It supports video/audio chat, which is great. First step - it offers to import my Pidgin accounts. Nice! I'll try that. Unfortunately it doesn't work, and I really have no idea why.
I also can't seem to add any accounts to it other than ones that don't require a password - namely IRC. This is because when I create the account it asks for my keyring password which I don't know, since I don't use Ubuntu's keyring. Since I didn't provide the keyring password, the thing decides it doesn't want to create the account. UPDATE: If you need help resetting your keyring, you can follow my instructions here.
In effect, Empathy isn't much more to me than an IRC client. I'm sorry, I'll just continue to use Pidgin.
Nov 2, 2009
Stats App Revisited
A while back I mentioned that I was working on an addon for OpenOffice called ooregress, which adds some more advanced statistics functionality to OpenOffice Calc.
Unfortunately when I wrote it, it was for OpenOffice 2.4. I think they changed the API for OpenOffice 3.0, so my code no longer works.
Rather than try to repair my code, I decided to port the thing to Javascript so that I could release it as an easily accessible website. The issue with the original version was that it was written in JRuby so you would need JRuby actually installed to run it, and it needed the development files for OpenOffice installed on the machine (not to mention OpenOffice).
This one is in a website, so all you need installed is a supported web browser. Since this is a personal project, IE is not a supported web browser :P I am currently supporting Firefox, Chrome and Safari - I can probably support Opera too, I'd just have to install it.
A temporary link is here, although I won't guarantee that this will always be active. I've got it hosted on my SheevaPlug, which I turn off sometimes. UPDATE: The site is now statsan.com, and I've called it StatSan for STATiStical ANalysis.
I'm planning on putting all the code as open source (GPL) so that anybody can host their own version of it should you want to, I'll put up the link once I get something set up - I've got a local git repo of it, it's just a matter of creating something on GitHub and pushing everything over.
Anyway, why am I writing this? Well, a few reasons. First, my stats classes at school have required various stats software, including Excel, EViews and Stata. I've also tried R. For the most part, these programs fall into one or more of the following categories: tedious, hard to use, expensive, not cross-platform. I want to make something that is more streamlined, easy to use, free, accessible and portable. You don't get much more accessible and portable than JavaScript, since the vast majority of people have something installed that supports it to some degree or another (however I guess this isn't 100% portable since I'm not supporting IE).
There is one downside: JavaScript is slow. I'm sure if you were running a regression on 20 variables with hundreds of thousands of observations, it would make your computer cry. This is an issue that I've been thinking about a bit and will hopefully come up with some solution for (if that native code plugin that Google is talking about ever comes out, that would be awesome!).
So if you have to do stats calculations, feel free to check out this app and let me know what you think. If you find any bugs or come up with any features you'd like, feel free to let me know.
Unfortunately when I wrote it, it was for OpenOffice 2.4. I think they changed the API for OpenOffice 3.0, so my code no longer works.
Rather than try to repair my code, I decided to port the thing to Javascript so that I could release it as an easily accessible website. The issue with the original version was that it was written in JRuby so you would need JRuby actually installed to run it, and it needed the development files for OpenOffice installed on the machine (not to mention OpenOffice).
This one is in a website, so all you need installed is a supported web browser. Since this is a personal project, IE is not a supported web browser :P I am currently supporting Firefox, Chrome and Safari - I can probably support Opera too, I'd just have to install it.
A temporary link is here, although I won't guarantee that this will always be active. I've got it hosted on my SheevaPlug, which I turn off sometimes. UPDATE: The site is now statsan.com, and I've called it StatSan for STATiStical ANalysis.
I'm planning on putting all the code as open source (GPL) so that anybody can host their own version of it should you want to, I'll put up the link once I get something set up - I've got a local git repo of it, it's just a matter of creating something on GitHub and pushing everything over.
Anyway, why am I writing this? Well, a few reasons. First, my stats classes at school have required various stats software, including Excel, EViews and Stata. I've also tried R. For the most part, these programs fall into one or more of the following categories: tedious, hard to use, expensive, not cross-platform. I want to make something that is more streamlined, easy to use, free, accessible and portable. You don't get much more accessible and portable than JavaScript, since the vast majority of people have something installed that supports it to some degree or another (however I guess this isn't 100% portable since I'm not supporting IE).
There is one downside: JavaScript is slow. I'm sure if you were running a regression on 20 variables with hundreds of thousands of observations, it would make your computer cry. This is an issue that I've been thinking about a bit and will hopefully come up with some solution for (if that native code plugin that Google is talking about ever comes out, that would be awesome!).
So if you have to do stats calculations, feel free to check out this app and let me know what you think. If you find any bugs or come up with any features you'd like, feel free to let me know.
Subscribe to:
Posts (Atom)
