| Blog |
|
| Releases |
Page:
0 ... 5 ... 10 ... 15 ... 20 24 25 26 27 28 29 30 31 32 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80
| Visual C++ 2008 Express | |
|---|---|
|
Date: 4/9/2008 | So I had reason to install Visual C++ 2008 Express today, mainly to compile some app that used SSE2 instructions in the inline assembly that Visual C++ 6 doesn't support. It's not like I'm changing religions.. *cough* I mean IDE versions or anything. Just compiling one app.
Anyway it took a right big ol steaming dump in my Firefox install didn't it. The .NET 3.5 installer without asking or warning in the least decides that it can install a Firefox add-on and modify the user agent string. Which is just wrong, WRONG, WRONG!. No Microsoft, you MAY NOT INSTALL ANY CRAP IN MY BROWSER FULLSTOP. No add-ons, no silverlight, no .NET no NOTHING. So. Deep breath. Google will aid you. 2 quick searches later I have the uninstall instructions. Basically it comes done to this:
Take a deep breath of fresh, Microsoft free, air. ;) |
| (4) Comments | Add Comment | |
| Imap / Scribe v2 | |
|---|---|
|
Date: 2/9/2008 | After getting a gentle push to read the docs more carefully from the IMAP protocol mailing list guys I'm close to having an implementation that understand the BODYSTRUCTURE field such that it can be picky about which parts of the email's body to download. In the case that you have an email with a large attachment it seems obvious that the client downloads just the text/html part for display without immediately fetching the attachment. Well thats easier said than done. I've got some code now that extracts the body structure into a XML dom tree and I'm hoping to expose that to the UI layers in Scribe so that I can start picking which bits I need for display instead of fetching the entire body of the message. I'll have to synthesize similar functionality on the mail2 backend but that shouldn't be too much work. It's already half there with the attachments as separate child objects of the email.
However the whole caching model is taking longer than I anticipated to get running smoothly. I keep finding that email is falling through cracks or asserts firing, telling me that something couldn't be found when it really should be there. Clearly it's a non trivial piece of code. Previously |
| (0) Comments | Add Comment | |
| DVB → Mp4 | |
|---|---|
|
Date: 2/9/2008 | For a long time I've had a private stock app that manages encoding DVB mpeg2 to whatever compressed video format is in fashion. Which at the moment is H.264.
So anyway recently I started pushing HD through it and well it did not like that at all. Basically after much head scratching I worked out that avisynth, which serves up frames to x264 was "guessing" the length of the input mpeg2 file, or more correctly, one of the filters in it's direct show graph was doing the guess. Unfortunately, because Avisynth has to report an exact length of it's AVI at startup it means that the video stream is only ever as long as Avisynth's "guess". This is unacceptable, and there is only one route around this, and that is not to use direct show (i.e. DirectShowSource). So the option is using Mpeg2source filter plugin (oh no yet another dependency!). And that relies on an indexer to produce d2v indexes of the mpeg2 first. So now my graph looks like this: 
This is a graphical editor for video processing blocks that I've been working on. Essentially the current system is a hardcoded version of this, but when I'm done, all the same functionality will be plug and play, probably with some scripting support as well. This week I did finally get my mpeg parsing library up to snuff so that it can dump out all the meta data for a mpeg video stream (not PS/TS, just video at this stage) which is a good step forward. At the moment the mpeg2demux stage runs Pvastrumento which is the best error correcting demuxer available. However I'm about halfway to having a demuxer myself, and I suspect that I can create something that can compete with the error correcting capabilities of Pvastrumento and probably produce a d2v file in the process. So that would greatly simplify the whole diagram and get rid of that ungainly d2v indexing step. Eventually I'll build up a library of components and graphs to handle the vast majority of media re-encoding needs and possibly release it as an application. |
| (0) Comments | Add Comment | |
| Imap Design | |
|---|---|
|
Date: 29/8/2008 | I've been working on the IMAP code for v2 a bit and thought I'd post an architecture diagram. Just for fun.
This how email gets from the server to the screen in the current dev build of Scribe v2. I had to write a new FETCH implementation in the IMAP class because the existing methods were too restrictive. Basically I'm moving more towards an API that maps far more directly to the protocol, exposing more power to the calling code. The new FETCH code parses the response on the fly and when it has a whole record, calls a callback method with the fields in a hash table. It's a lot faster and more flexible than the old code. So, reading mail works. Now just to add moving, deleting and mail change notification. |
| (1) Comment | Add Comment | |
| Translating Script Menu Names | |
|---|---|
|
Date: 13/8/2008 | Well I've finally settled on a solution to the translation of scripting menu commands. The new scripting support in Scribe v2 uses the new bytecode VM and I've extended the API to include a wrapper around LgiLoadString which is what Scribe uses natively to load strings from the lr8 resource file. So the script can use that to load it's translated name straight from the source. However that doesn't get it on a menu. So the new scripting engine runs each script in "./Scripts" on startup and the main function of each script calls "AddToolsMenuItem" which is a new function that registers a callback connected to a menu item in the tools menu. i.e.
AddToolsMenuItem(LoadString(IDS_REMOVE_DUPES), "DeleteDuplicateMessages");So you can see that the text of the menu will be translated and the 2nd parameter to that function is the name of the callback method to call when the user clicks the menu item. All in all it's very neat. There is another tricky part in the define "IDS_REMOVE_DUPES" is in a C header file. So originally I just copied the integer value that it mapped to as a literal into the script file. But I decided that it would break too easily and so I made the script engine cope with C style #include and #define so that I can just include the resource defines straight into the script and then use the actual name of the string. Neat. Previously, Previously. |
| (7) Comments | Add Comment | |
| Deleting Scribe v2.00 Plugins | |
|---|---|
|
Date: 8/8/2008 | I'm seriously considering deleting the whole plugin feature from v2.x of Scribe and replacing it completely with the scripting engine. For the most part the plugins are fragile because of their dependency on C++ ABI's not changing. Also they tend to be a little bit of glue between the application and some 3rd party tool or library. This should ideally be handled by a script so that the ABI dependency goes away and the functionality is "open source" allowing the user to tweak it to their own preferences.
This will mean that the scripting language will have to support calling into the operating system and shared libraries (DLL's). I think I can make the basic part of that work ok. I'm a lil worried about more complex types not being represented in the scripting language. Currently it's limited to a range of basic types, string, int, list etc governed by the types support by the Lgi GVariant class. Maybe it needs to a custom data type, and I have some idea on how that might work. But at this stage I'm working on making the script engine cope with registering hooks and callbacks so that it can take over the functionality of the existing plugins. See how far I get. |
| (0) Comments | Add Comment | |