| Blog |
|
| Releases |
Page:
0 ... 5 ... 10 ... 15 17 18 19 20 21 22 23 24 25 ... 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85 ... 90
| Webscheduler Quirk | |
|---|---|
|
Date: 19/2/2010 | If your WebScheduler install starts writing .bin files instead of .ts and you check in the System settings and under Capture.deftype all you have is "error" then you need to restart the DVB Web Scheduler service. And everything will go back to normal.
This has been a community announcement for the edification of those who use google. This is one of those every few years of so problems I get with the saintly WebScheduler. |
| (0) Comments | Add Comment | |
| Thoughts on Lgi | |
|---|---|
|
Date: 10/2/2010 | Well it's been some years now since a decent build of Scribe or i.Ftp has been done for Linux or Mac, and I'm beginning to rethink my strategy with regards to Lgi and it's cross platform nature. One option that is increasingly attractive to me is making a "port" of Lgi to something like GTK. It's kinda cheating and it won't be pretty or super fast. But it would give my a leg up to making the apps run without huge issues on the platforms that I want to target. I think it especially makes sense for Linux because it's a standard library thats already installed and the current XCB codebase is likely going down the wrong track performance wise. I think XCB on the surface is a great idea, but in practice there is too little documentation, examples and community to help you through. I suspect the larger widget libraries are using a single X window at the top level and then managing all their own widgets as "virtual" sub-windows that X doesn't know about directly. Thats good for performance and good for visual flexibility, but a lot of work. If I was to retrofit my XCB codebase for that it would only mean I'll never finish anything.
So it's 2010, and I have a limited amount of coding time.. so what works for me is getting the most bang for buck. That means leveraging what I can to get the software running and stable even if it means making sacrifices in some areas with regards to speed and dependencies. The 2 target API's I have in mind are GTK and Qt, both of which are LGPL like Lgi, so I think license wise I'm ok. When I started Lgi, GTK and Qt weren't widely known or used, and I wouldn't have written Lgi if there was an obvious alternative. But now there are lots of obvious alternatives and I'm think I should maybe transition away from maintaining this large codebase I've built up over the years. I do have reservations with GTK, the unholy amount of whitespace it seems to use everywhere for one, but I have a lot of custom controls that I could use instead of the GTK controls. So maybe all I have to do is write a really thin layer that uses a bare minimum of GTK for a drawable custom control that gets reused by all the native Lgi controls. And I can still override the file open dialogs with the native ones etc. |
| (0) Comments | Add Comment | |
| Bug DB | |
|---|---|
|
Date: 5/1/2010 | At least no one can accuse me of not staying on top of the Scribe v2.00 bugs. There is only one major one left to deal with. Although I know of several that I haven't bothered to put in the Bug DB, the sort of stuff that really needs valgrind to sort out. Hence I've been poking around in the Mac build. |
| (0) Comments | Add Comment | |
| I'm done with anything nVidia | |
|---|---|
|
Date: 3/1/2010 | So far I've had a pretty messy run with nVidia stuff. First there was that awful awful experience I had with a nForce3 mobo, 6 months of my life poured in to getting that piece of crap running stable. I gave up in the end and ditched it. Then I bought an nForce4 mobo and a XFX 7600GS gfx card, which has been my core PC system for a couple of years now and it's been very stable as far as PC's go. It gives my Macbook a run for it's money in some respects.
The XFX card hardware is brilliant, never had an issue. But I'm stuck on some legacy nVidia driver for it because they deleted a piece of functionality that I really do NEED everyday. That is video mirroring to the TV out, i.e. play a video on the main screen in a window and get the whole video fullscreen on the TV. And they removed it completely from the driver UI some years ago, so I just stopped updating the driver after finding "the one true driver" (for me at least). I was pretty dark with nVidia over just that. However I recently upgraded to sp3 and the ethernet port now only runs at 100mbit. Which I cannot abide with. So my mobo has also lost it's stereo out port (just flakey h/w), the video card is stuck in driver limbo and now the ethernet is crippled. Apparently it's some nVidia driver issue. So yeah me and nVidia are done. I'm buying an Intel gigabit nic to go with my sound blaster, to replace the functionality that my mobo SHOULD'VE had all along. It's a stop gap till I spec up a hackintosh with some Core2 muscle. |
| (0) Comments | Add Comment | |
| Aspell | |
|---|---|
|
Date: 22/12/2009 | A week or 2 ago I added inline spell checking using the aspell plugin to Scribe. For the first few days it was going so well that I was about to package up a release a upload it. But then it started crashing, so I thought maybe it's not thread safe or something and moved the aspell code into a single thread where it would talk to the rest of the system via a threadsafe api. But the crashes continue and I'm no closer to fixing it, so I might have to release sans spell check.
I thought about valgrinding it to see if that would shed light on the problem, but a) the linux build sucks since I converted it to xcb/cairo, mainly because the lack of documentation and time to work on it, and b) the mac build is crashy too because I don't understand the HIView hierarchy and memory ownership rules properly (and MacOSX API doco is shit) so I had a crack at using wine and valgrind together to debug the windows build and the wine/valgrind PDB reading code barfs on Scribe's PDB's. *sigh* And to top of it off Aspell is compiled with gcc so there is no way to get a debug version compatible with MSVC6 such that I can debug the problem directly. And no you can't compile Aspell with MSVC because it uses various C/C++ language features that are specific to gcc (I tried). So I guess I'm looking for a good spell checker API that I can use in Scribe. I wonder what Firefox uses? Update: Solved! I had some other issues cause the Aspell thread to be constantly created and destroyed instead of being reused. Fixed that and now it doesn't crash almost immediately. I doubted it was an Aspell issue, but I couldn't be sure. By creating a working test harness for the Aspell code I could confirm that it worked fine in isolation and therefor the problem was in the way Scribe was calling the Aspell thread/plugin stuff. Sure enough it was. |
| (1) Comment | Add Comment | |
| Scribe Mail3/Sqlite Folders | |
|---|---|
|
Date: 17/11/2009 | I don't know about you, but the shine of a different back end to store mail in for Scribe v2 has well and truely worn off for me. By that I mean I expect performance to be considerably better than it is. I can even live with the bad write/commit speed, considering that locks need to be made and there are certain overheads to having atomic changes made to the database. However that said I was expecting positively snappy read/query times and well? Yeah it's not all that. Maybe it's the fact I'm using Sqlite rather than a big iron style SQL server. I regularly see SELECT statements take in order of 15-20 seconds to pull up a simple list of email in a folder, esp when the App is starting. I've added an index of the FolderId field so that in theory doing something like:
select * from Mail where FolderId=[inbox_id]should be a no brainer super fast query right? Well it seems that it's not, and it takes an awfully long time sometimes. It's not the end of the world. Now that I have an architecture that is flexible I can experiment with a range of back end storage solutions till I hit on something that meets my fast/powerful/portable/small requirements. One idea that I've got in the back of my head is generalizing the SQL backend to handle a number of different databases. For install, in the "portable" mode you'll probably be storing reasonably small amounts of mail and the existing Sqlite is most likely enough to do the job, but for desktop installs something with more grunt (and more memory / install footprint) could be used instead, trading portability for speed. And with a decent replication tool you wouldn't be tied to that back end forever, you could migrate easily to the next big thing, or just your DB to a different portable format. Or... and heres a big idea... I make the back end API open and people can plug their own storage in. Of course thats only open to programmers but if someone can produce a good back end implementation I would seriously consider making it available in the default install. The basic API is very controlled and there is already some documentation in the headers. And the existing back ends could be used as reference, as in you'd get source to them as well. If anyone wants a serious crack at that then email me. |
| (0) Comments | Add Comment | |