We purchased a new printer for the house last night to replace the windows-only Dell printer that ran out of ink (and would cost almost as much as a new printer for replacements).
First, some advice: plan ahead, order online, don't buy from Staples. We paid $170 for this when Epson is offering them direct for $130 with free shipping. If we were not in need of immediate replacement we could have saved $40 and waited a week. Further, the rep at the store lied when he told us the printer was going to the back to get a unit "fresh off the truck", it was a unit another customer had returned with ink spilled and dried on the inside and some of the packaging torn open. Buyer beware. Otherwise, they seemed to clean it up and repackaged it well. I have half a mind to order the printer online and return this one within 14 days for refund to save the $40.
The printer itself is fairly impressive. Two paper trays (letter/legal plus photo/cardstock) and a built-in CD printing tray that slides out when you select CD printing, scanner with auto-document feeder, and built in 10/100 and wifi so we don't need to depend on any computer in the house to properly "share" the printer. All I had to do is select our access point on the front controls and give it a static IP on our router.
Ubuntu 9.10 detects the printer over the network in seconds and I was printing the Ubuntu test page in under a minute, so more than half the systems in the house were easy. Windows setup was not hard, but time consuming as loads of bundled software installed from the CD. The only complaint I have is the color seems a little off; printing the same image in both Linux and Windows shows a fairly radical difference in quality. The prints from Linux are still much better than printing from Windows to our older printer.
Next I tried to use the scanner function. Using GIMP to launch SANE (Scanner Access Now Easy), the printer was automatically detected and let me select either the flatbed or auto-document feeder. Both options work fine until I start the scan, at which point the Epson Artisan 810 locks up and needs to be rebooted.
There is a scan function from the front panel, not supporting anywhere near the scanner's full resolution and storing in JPEG format with obvious artifacts around text/etc, but at least we don't need to use a Windows system for basic scans until SANE is fixed. Since I have a stand-alone Epson scanner that works beautifully this isn't a huge issue for me, though it would be great to be able to use the auto-document feeder from Linux and be able to put this older scanner into storage.
Wednesday, January 13, 2010
Sunday, January 10, 2010
soy.windows.Window rendering, GLEW headache
I'm seeing "red" now with our Windows, in more ways than one. The rendering code for soy.windows.Windows is to the point that, by changing the glClear color, we're seeing red in the window rather than black. This is a big step forward given that porting to use GDK is a big part of the libsoy migration.
On the other side of "red" is anger over GLEW. I really wish I knew of a decent, mature alternative to GLEW. The project is so immature that, though one of the maintainers is a Debian developer, they do not provide the pkgconfig file for it. Without this file, which provides Waf with the location of the library and it's headers, we would have to write a search script to verify that it's installed and find it's location. None of the major distros I looked at provide the pkgconfig on their own.
It's also at least partially redundant with the functionality of gtkglext which I believe should be able to replace GLEW entirely.
On the other side of "red" is anger over GLEW. I really wish I knew of a decent, mature alternative to GLEW. The project is so immature that, though one of the maintainers is a Debian developer, they do not provide the pkgconfig file for it. Without this file, which provides Waf with the location of the library and it's headers, we would have to write a search script to verify that it's installed and find it's location. None of the major distros I looked at provide the pkgconfig on their own.
It's also at least partially redundant with the functionality of gtkglext which I believe should be able to replace GLEW entirely.
Friday, January 08, 2010
libsoy running on OSX - briefly
For the first time in 3.5 years, we had soy.windows.Window running on OSX. Just the basics; opening, (re)setting the title, resizing - but it worked. This is thanks to GDK, the windowing and event backend to GTK+, running on Mac OSX via native Quartz backend (not X11).
Shortly after we moved the window code to a background thread and it broke. The code runs fine on GNU/Linux and Windows, but on OSX all we get are white rectangles where the windows would normally be rendered. The rectangles even resize properly, and window events are getting processed by our code, just nothing rendered inside (not even the window title or buttons). I filed this bug and hope the problem to be solved quickly.
The problem could be as simple as a missing NSGraphicsContext.flushGraphics call (which is only needed when rendering is done in a non-main thread). If the bug hasn't been fixed by our next release I'll look into patching this myself.
Shortly after we moved the window code to a background thread and it broke. The code runs fine on GNU/Linux and Windows, but on OSX all we get are white rectangles where the windows would normally be rendered. The rectangles even resize properly, and window events are getting processed by our code, just nothing rendered inside (not even the window title or buttons). I filed this bug and hope the problem to be solved quickly.
The problem could be as simple as a missing NSGraphicsContext.flushGraphics call (which is only needed when rendering is done in a non-main thread). If the bug hasn't been fixed by our next release I'll look into patching this myself.
Tuesday, January 05, 2010
language mixing
After some work to update our ODE bindings for Vala, we discussed Bullet again last night and returned to the conclusion to drop further work on ODE and focus on Bullet for the next release.
It quickly became clear that the C bindings for Bullet are utter horse crap; praise for the effort for whoever wrote them, and I by no means intend to disparage your ability or intentions, but they're horribly incomplete and usable for little more than the two demo apps included in the source. Moreso, the C bindings are "higher level" than the C++ library, performing several steps automatically (such as calculating body inertia from mass and shape) which our 3d game engine needs more direct control over. I first wrote an alternative (ABI compatible) C header for it, and then started to rewrite it entirely.
I decided that if we're going to write our own Bullet compatibility layer, we may as well go all the way in wrapping it with GObject. The code is simple enough, but defining GObject in C involves a lot of boilerplate - in some cases more than the code itself. To get through this and retain my sanity, I started work this morning on a C++ code generator that takes the relevant functions and wraps them in the standard boilerplate.
The format I'm using is Genie-like for class and method definition, then C++ within dumped directly to the target .cpp. The code generator will generate the .vapi as it works and compile our wrapper as a static library which libsoy can link to directly.
Kudos again to Waf for making this rather eccentric use of their build system dead simple and clean.
It quickly became clear that the C bindings for Bullet are utter horse crap; praise for the effort for whoever wrote them, and I by no means intend to disparage your ability or intentions, but they're horribly incomplete and usable for little more than the two demo apps included in the source. Moreso, the C bindings are "higher level" than the C++ library, performing several steps automatically (such as calculating body inertia from mass and shape) which our 3d game engine needs more direct control over. I first wrote an alternative (ABI compatible) C header for it, and then started to rewrite it entirely.
I decided that if we're going to write our own Bullet compatibility layer, we may as well go all the way in wrapping it with GObject. The code is simple enough, but defining GObject in C involves a lot of boilerplate - in some cases more than the code itself. To get through this and retain my sanity, I started work this morning on a C++ code generator that takes the relevant functions and wraps them in the standard boilerplate.
The format I'm using is Genie-like for class and method definition, then C++ within dumped directly to the target .cpp. The code generator will generate the .vapi as it works and compile our wrapper as a static library which libsoy can link to directly.
Kudos again to Waf for making this rather eccentric use of their build system dead simple and clean.
Monday, January 04, 2010
libsoy building separately now
We've been working on the "libsoy" branch of PySoy for some time, a split of the compiled code to a GObject-based C library with Python bindings plus the pure Python code constituting PySoy itself.
Previously we were struggling to build this with Python's distutils system, which didn't support building system-wide C libraries nor using valac to do so. Jon and I started looking into Waf last week. It's pretty impressive; Python based (and works with Python 3), simple, intuitive, does everything we need with only a few dozen lines of script. Last night we setup libsoy in it's own repository and building (just a very basic soy.windows for now) on it's own.
I think we're settled to work with Genie, a comparison between the syntax of soy.windows in Vala vs in Genie makes that choice simple. The only complaint I have with Genie is needing to escape newlines inside struct {}'s (ie, line 32-35), but reportedly this is being fixed in an upcoming release to be more Python-like (ignoring newlines while inside () or {}).
After a bit of searching (through source code, I wish Waf had better API reference in it's docs) I found the gir= option for Vala building, and another hour later both soy-1.0.gir and soy-1.0.typelib were being generated, except both were empty save the "soy" namespace:
I've hit this before with trying to generate GObject Introspection from distutils but chalked it up to not building it correctly. As it turns out, this is a known bug in GIR and a previously unknown bug in valac to fail silently.
I'm still hoping the GIR developers will come to their senses and support nested namespaces, but given that they've stubbornly rejected this for months already I'm afraid we'll have to build a cross-language bindings builder based on Vala/Genie instead of helping to update PyGI for Python 3.
Previously we were struggling to build this with Python's distutils system, which didn't support building system-wide C libraries nor using valac to do so. Jon and I started looking into Waf last week. It's pretty impressive; Python based (and works with Python 3), simple, intuitive, does everything we need with only a few dozen lines of script. Last night we setup libsoy in it's own repository and building (just a very basic soy.windows for now) on it's own.
I think we're settled to work with Genie, a comparison between the syntax of soy.windows in Vala vs in Genie makes that choice simple. The only complaint I have with Genie is needing to escape newlines inside struct {}'s (ie, line 32-35), but reportedly this is being fixed in an upcoming release to be more Python-like (ignoring newlines while inside () or {}).
After a bit of searching (through source code, I wish Waf had better API reference in it's docs) I found the gir= option for Vala building, and another hour later both soy-1.0.gir and soy-1.0.typelib were being generated, except both were empty save the "soy" namespace:
<?xml version="1.0"?>
<repository version="1.0" xmlns="http://www.gtk.org/introspection/core/1.0" xmlns:c="http://www.gtk.org/introspection/c/1.0" xmlns:glib="http://www.gtk.org/introspection/glib/1.0">
<package name="soy"/>
<namespace name="soy" version="1.0" c:prefix="soy">
</namespace>
</repository>
I've hit this before with trying to generate GObject Introspection from distutils but chalked it up to not building it correctly. As it turns out, this is a known bug in GIR and a previously unknown bug in valac to fail silently.
I'm still hoping the GIR developers will come to their senses and support nested namespaces, but given that they've stubbornly rejected this for months already I'm afraid we'll have to build a cross-language bindings builder based on Vala/Genie instead of helping to update PyGI for Python 3.
Saturday, January 02, 2010
state of Vala IDEs
Wasted quite a few hours today trying to get a Vala/Genie IDE working.
VTG is basically broken, crashing at random. It had problems before this; having a fairly rigid concept of a "project", not supporting non-autotools build systems or libraries very easily, not supporting Genie, and the symbol mapping having odd quirks, so this is not a huge loss.
A newer Vala plugin for gEdit, Valencia, looks promising but doesn't support recent Vala versions and attempting to build it raised pages of errors.
Anjuta has always looked interesting, but I've never managed to get the Anjuta Vala plugin to compile. At present, it doesn't appear to work with Gnome 2.28.
I don't use Eclipse or Mono, so the final option is Valide. To my surprise, it's been packaged for Ubuntu and works out of the box. It supports Genie, it seems to have features on-par with VTG and the other IDEs, and works with the latest version of Vala.
My only complaint so far is the new project wizard doesn't list the AGPLv3 as a license option, but then none of the Vala IDE options do yet.
VTG is basically broken, crashing at random. It had problems before this; having a fairly rigid concept of a "project", not supporting non-autotools build systems or libraries very easily, not supporting Genie, and the symbol mapping having odd quirks, so this is not a huge loss.
A newer Vala plugin for gEdit, Valencia, looks promising but doesn't support recent Vala versions and attempting to build it raised pages of errors.
Anjuta has always looked interesting, but I've never managed to get the Anjuta Vala plugin to compile. At present, it doesn't appear to work with Gnome 2.28.
I don't use Eclipse or Mono, so the final option is Valide. To my surprise, it's been packaged for Ubuntu and works out of the box. It supports Genie, it seems to have features on-par with VTG and the other IDEs, and works with the latest version of Vala.
My only complaint so far is the new project wizard doesn't list the AGPLv3 as a license option, but then none of the Vala IDE options do yet.
Subscribe to:
Posts (Atom)