MemeCode - Blog

Page: 0 5 6 7 8 9 10 11 12 13 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85 ... 90 ... 95 ... 100

Scribe v2.1 Update
Date: 21/4/2015 Tags: scribe	It may look like nothing is happening but really, there is. I have been toiling away on features and bug fixes in the v2.1 "trunk". Scripting The functionality I want is all there in beta form. I haven't however ported any plugins to use it. So this is at least ready for some more testing. Html Editing This is probably the least progressed of all the new features. Basic functions work but it's all so very fragile. I've been meaning to valgrind it heavily but the other features have been getting my time so far. Built-in Aspell I got this finished to the point where it can self install a dictionary (from an FTP link no less!) today. So it's out of alpha and into system testing. I'll also need to make some changes to the installer to make it part of the base install. Automated Crash Reporting No progress so far. Mac Native Look Most of the controls now use native paint methods. Which have all been updated to non-deprecated API calls. Also very importantly the string display code now supports sub-pixel positioning, which fixes the selection of text in Scribe causing glyphs to move around in the x direction slightly. Painting isn't perfect yet, but it's a lot better. Ready for beta I'd say. Calendar UI Refresh Still partially complete. No recent work. Logging All changes completed. Linux Betas I've done a lot of work to support arbitrary colour spaces which is heavily used by the Linux port. Also I've fixed a number of increasingly weird GTK interaction bugs. It seems if the bugs are getting weirder and less frequent, then you are reaching a decent level of stability. Also of note, I've removed all the ANSI api support in the Windows implementation of LGI which means that any hope of running it on Windows 9x is gone for good. XP has been the official minimum for a while now, and now it's cemented in the code as well.
(0) Comments \| Add Comment

The Current State of Scribe
Date: 23/2/2015 Tags: scribe	Maybe it's time to just bundle OpenSSL in Scribe? I'm thinking of statically linking it so that it's always available and there will never be any trouble with missing or mis-matched libraries. The downside is the download size will blow out a bit. Over 2 MiB for the Windows build, maybe even 3. Recently I've had a very bad time with people have all sorts of weird crashes, odd behaviour and connection issues. And it seems that these things are next to impossible to reproduce. Maybe it's the target market changing on me as the profile of the client gets higher. One of those odd behaviours is Scribe not saving it's settings between sessions. I suspect this has to do with the install folder being write only, but the software thinking it's in portable mode (i.e. store settings in the install folder). I'd love for someone to be able to reproduce that and tell me how. So I'm going to look into ways of avoiding pitfalls. I'm starting to think that making automatic crash reporting default to "on" is for the best. I'm simply not getting enough data to respond to problems. The HTML editing functionality is coming along nicely. I managed to send quite a few HTML messages over the last few weeks. But it's still pretty flakey. And also there are some thorny issues to sort out. However it's a lot better than even a month ago so there is hope. Also I finally fixed an old crash in the GWindow destructor on the Linux/GTK2 build. The other main sticking point there is the popup handling under the GTK2 platform isn't great. But I didn't see the point in tackling that when the software was still crashing all the time. Edit: So I think I've worked out the procedure for the not being able to save your settings bug: Install on Windows 8.1, user grants admin rights to installer. Installer writes files to the install folder and then offers the user to start Scribe If user starts Scribe, the installer runs Scribe.exe WITH ADMIN RIGHTS! User selects "Portable" mode during Scribe's first run. User configures some options and then exits Scribe. Scribe saves the options to the program files install folder and that works because it still has the ADMIN permissions from the installer. User runs Scribe again... this time with USER permissions... and now Scribe can't write to the program files folder anymore... DUN DUN DAAAA! Yeah I'm going to have to make sure that Scribe is aware that during startup that it may have ADMIN permissions, and not to assume it will be able to write to anything in the Program Files folder tree. However it should totally take advantage of having ADMIN rights to setup the registry for being the default client / registered client.
(0) Comments \| Add Comment

Scribe v2.1
Date: 27/1/2015 Tags: scribe	So the v2.0 builds are basically stable as far as I can tell. Although there is some issues with some people connecting to SSL servers and one report of a crash at startup on MacOSX 10.10 (which I'm investigating). In the light of that I'm shifting my attention to the features in the v2.1 branch. I want to go through the things I'm aiming to get into that release: Scripting Firstly as you may have seen in previous blog posts there is a visual debugger now. There is also support for calling external functions (i.e. in a system or 3rd party DLL/so/dylib). This is all with a view towards making the plugin functionality script based rather than C++ binaries. The problem with C++ binaries is they are VERY dependant on a stable ABI (application binary interface). I hate having to rebuild the plugins every time I release. If the plugins are scripts they will generally just work between releases and not need updating. Html Editing This is a big missing feature and I'm committing to getting some basic functionality stable. To start with I want to match the text based functionality with a few extras like bolding, colours etc and then start adding more stuff like images and block quotes etc. It'll be a long road but I better get started. Built-in Aspell Instead of requiring the user to install an old Aspell independently, from v2.1 onwards there will be a modern version of Aspell pre-installed. Dictionaries will still need to be downloaded on demand. The port to windows has been done, and stability testing and integration is underway. Automated Crash Reporting It's most likely that in the first few releases of v2.1 there will be some automated reporting of crash dumps. Yesterday I wrote up a guide for reporting crashes and that will be the basis for the automated reporter. Mac Native Look The mac port is already looking a lot more native with scroll bars, check boxes and radio buttons all taking on native rendering. I'll be looking into integrating native edit controls as well. I don't like the current rendering of text in the edit controls... the kerning keeps jumping around. Calendar UI Refresh The calendar event window is in the process of being rewritten to be more modern and match existing systems. This will enable better workflow and integration with vCal files. Logging All the logging now goes through the log window instead of ending up just in 'Scribe.txt'. This means that users can access pertinent log information directly through the user interface. There will be an icon that you can put in the main toolbar to show that log, and it will change appearance when there are new messages. Linux Betas The GTK port on Linux has been running OK for a while now with a few issues. The main one is that the popup windows are all pretty flakey. And try as I might the GTK API doesn't leave a lot of room for fixing that. In any case I'll be getting some builds up and see how they go. If you think I'm missing something really obvious that chime in either on email or in the comments on this post. I'm looking to get the first build out sometime in Feburary.
(0) Comments \| Add Comment

"Invalid HTTP Request Headers" in Firefox
Date: 9/1/2015 Tags: firefox	For most of 2014 I've been using Firefox because I feel it's doing a better job of looking after my privacy. However it's not without it's cost. For instance today I found some pretty quirky behaviour in the Mac build of Firefox v34.0.5: Basically on this site it's dropping the leading "G" of the "GET" request. To make matters worse the problem is intermittent. I can reproduce with a clear cache. Internally Firebug is reporting the correct packet, but Wireshark shows the missing byte.
(0) Comments \| Add Comment

Scripting Debugger
Date: 16/12/2014 Tags: scribe scripting	And extern library function support!
(2) Comments \| Add Comment

Portable OpenSSL on Mac OS X
Date: 12/12/2014 Tags: dylib openssl	So it's been brought to my attention that Scribe's self install of OpenSSL on Mac doesn't actually work in v2.0.x, so the last week I've been looking into what it takes to do that. The main issue is that load paths, are by default, absolute and hardcoded. Which works against you when you want a portable install of something. Secondly the OpenSSL .dylib is made of 2 libraries; libssl and libcrypt. And when you dlopen the first (libssl) the system needs to be able to find libcrypt. The link is embedded in the Mach-O image as a LC_LOAD_DYLIB segment. You can see that by issue the command: otool -l ./libssl.1.0.0.dylib Part of the output you'll get: cmd LC_LOAD_DYLIB cmdsize 64 name /usr/lib/libcrypto.1.0.0.dylib (offset 24) time stamp 2 Thu Jan 1 10:00:02 1970 That absolute path is what is causing the dlopen of libssl to fail. So we need to fix that. And the tool to do it 'install_name_tool', which is provided from Apple. Now I had two problems. Firstly what do you change the path to? And how do you actually get the tool to change the path? Firstly Apple has several ways of locating shared libraries: @executable_path : relative to the main executable @loader_path : relative to the referring binary @rpath : relative to any of a list of paths. What I wanted is the path to be relative to the executable, so I want: @executable_path/libcrypto.1.0.0.dylib But how to call install_name_tool to actually do that? Well to start with I tried: install_name_tool -change /usr/lib/libcrypto.1.0.0.dylib @executable_path/libcrypto.1.0.0.dylib ./libssl.1.0.0.dylib Which is actually the right command. But because the new string is longer than the old string the command fails (silently I might add). The trick to getting it to work is to add the linker command: -Wl,-headerpad_max_install_names to the CFLAG variable in the OpenSSL root Makefile. This causes the load segments to have extra padding bytes so that you can change the paths as much as you want later. Now after rebuilding the OpenSSL dylibs you can reissue the install_name_tool command and the link path changes: MacOS matthew$ otool -l ./libssl.1.0.0.dylib ... cmd LC_LOAD_DYLIB cmdsize 64 name @executable_path/libcrypto.1.0.0.dylib (offset 24) ... Then I could dlopen 'libssl.1.0.0.dylib' and it would pull in the right libcrypt file (both as sitting in the same folder as the executable). I'm putting this here so I don't forget how to do this next time. Ha.
(3) Comments \| Add Comment

Portable OpenSSL on Mac OS X

Date: 12/12/2014
Tags: dylib openssl

So it's been brought to my attention that Scribe's self install of OpenSSL on Mac doesn't actually work in v2.0.x, so the last week I've been looking into what it takes to do that.

The main issue is that load paths, are by default, absolute and hardcoded. Which works against you when you want a portable install of something. Secondly the OpenSSL .dylib is made of 2 libraries; libssl and libcrypt. And when you dlopen the first (libssl) the system needs to be able to find libcrypt. The link is embedded in the Mach-O image as a LC_LOAD_DYLIB segment. You can see that by issue the command:

otool -l ./libssl.1.0.0.dylib

Part of the output you'll get:

    cmd LC_LOAD_DYLIB
cmdsize 64
   name /usr/lib/libcrypto.1.0.0.dylib (offset 24)
   time stamp 2 Thu Jan  1 10:00:02 1970

That absolute path is what is causing the dlopen of libssl to fail. So we need to fix that. And the tool to do it 'install_name_tool', which is provided from Apple. Now I had two problems. Firstly what do you change the path to? And how do you actually get the tool to change the path?

Firstly Apple has several ways of locating shared libraries:

@executable_path : relative to the main executable
@loader_path : relative to the referring binary
@rpath : relative to any of a list of paths.

What I wanted is the path to be relative to the executable, so I want:

@executable_path/libcrypto.1.0.0.dylib

But how to call install_name_tool to actually do that? Well to start with I tried:

install_name_tool -change /usr/lib/libcrypto.1.0.0.dylib @executable_path/libcrypto.1.0.0.dylib ./libssl.1.0.0.dylib

Which is actually the right command. But because the new string is longer than the old string the command fails (silently I might add). The trick to getting it to work is to add the linker command:

-Wl,-headerpad_max_install_names

to the CFLAG variable in the OpenSSL root Makefile. This causes the load segments to have extra padding bytes so that you can change the paths as much as you want later. Now after rebuilding the OpenSSL dylibs you can reissue the install_name_tool command and the link path changes:

MacOS matthew$ otool -l ./libssl.1.0.0.dylib
...
    cmd LC_LOAD_DYLIB
cmdsize 64
   name @executable_path/libcrypto.1.0.0.dylib (offset 24)
...

Then I could dlopen 'libssl.1.0.0.dylib' and it would pull in the right libcrypt file (both as sitting in the same folder as the executable).

I'm putting this here so I don't forget how to do this next time. Ha.

(3) Comments | Add Comment

Sitemap