MemeCode - Blog

Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45 48 49 50 51 52 53 54 55 56

Muhahaha
Date: 5/5/2006	In the process of working on a cross platform Mutex written with inline assembly I had to peer into the bowels of gcc, cygwin and mingw to work out how to build threaded win32 apps with free software tools. So a number of pleasant things have occured in doing so. Firstly I can now build Lgi applications with both cygwin AND mingw. Prior to today I didn't even know the different between cygwin and mingw. However I'm now in the "know" and have separate makefiles for each. Sweet. Secondly I discovered almost by accident how to craft makefiles that replicate the Visual C++ functionality to a 't'. Something that has eluded me for some 4 years now! Ever since I started development on Linux I've been trying to build a makefile system that works the same as the Visual C++ build system I am used to. And finally I've done it. The last thing I had to fix was the creation of output file directories. That particular feat while obvious for makefile gurus always was an annoying "hack" in my makefiles. I used to have a prereq on my final target rule that called the mkdir command: target : makeoutputfolder $(deps) ...link command... makeoutputfolder : mkdir $(outfolder) But this had the unfortunate side effect of relinking the target every time, even if no dependencies had changed. So enter the solution: target : $(outfolder) $(deps) ...link command... $(outfolder) : mkdir $(outfolder) I know it seems simple but, hey the documentation is er... rather obtuse. Other than that, I've given up on wildcard rules to build source and now I get LgiIde to generate all the deps and write out rules for every source file in the project. This is garrenteed to work and you can nail the right source file even when multiple different source files have the same name. Sometimes brute force is called for and when your as dumb as GNU make that is definately true. And before you have a go at me for not using %build tool Y%, I use make simply because it's on every system under the sun and it's nice to be able to unpack my source and just build it. It's a lowest common denomiator thing. Anyway, Lgi now supports mingw and cygwin. For all your licensing needs.
(1) Comment \| Add Comment

Muhahaha

Date: 5/5/2006

In the process of working on a cross platform Mutex written with inline assembly I had to peer into the bowels of gcc, cygwin and mingw to work out how to build threaded win32 apps with free software tools. So a number of pleasant things have occured in doing so.

Firstly I can now build Lgi applications with both cygwin AND mingw. Prior to today I didn't even know the different between cygwin and mingw. However I'm now in the "know" and have separate makefiles for each. Sweet.

Secondly I discovered almost by accident how to craft makefiles that replicate the Visual C++ functionality to a 't'. Something that has eluded me for some 4 years now! Ever since I started development on Linux I've been trying to build a makefile system that works the same as the Visual C++ build system I am used to. And finally I've done it. The last thing I had to fix was the creation of output file directories. That particular feat while obvious for makefile gurus always was an annoying "hack" in my makefiles. I used to have a prereq on my final target rule that called the mkdir command:

target : makeoutputfolder $(deps)
    ...link command...

makeoutputfolder :
    mkdir $(outfolder)

But this had the unfortunate side effect of relinking the target every time, even if no dependencies had changed. So enter the solution:

target : $(outfolder) $(deps)
    ...link command...

$(outfolder) :
    mkdir $(outfolder)

I know it seems simple but, hey the documentation is er... rather obtuse. Other than that, I've given up on wildcard rules to build source and now I get LgiIde to generate all the deps and write out rules for every source file in the project. This is garrenteed to work and you can nail the right source file even when multiple different source files have the same name. Sometimes brute force is called for and when your as dumb as GNU make that is definately true. And before you have a go at me for not using %build tool Y%, I use make simply because it's on every system under the sun and it's nice to be able to unpack my source and just build it. It's a lowest common denomiator thing.

Anyway, Lgi now supports mingw and cygwin. For all your licensing needs.

(1) Comment | Add Comment

Opinion On Correct Behaviour
Date: 2/5/2006	One user asked in the forum about a particular behaviour that shows up in Scribe when you receive email from someone with a Contact record. Currently the behaviour is that if the incomming email has no name in the from field, the name from the matching Contact record is inserted, otherwise the name from the headers is used. In fact I had to force the code to do that with a flag, because originally it didn't do that, instead it overwrote the name part of the from address with the name from the Contact record. So both systems would appear to have some surface benifits. Firstly: a) Use the header name: you would see any change in the name the user supplies. If someone else uses the email address you'd see their name instead. (Believe it or not, but people share email addresses) b) Use the contact's name: when sorting folder by the from address all email's from that contact sort into the same place because they are forced to have the same name. Neither of these are more correct than the other, or at least I can't decide which is better. In fact I could live quite happily with either. But maybe you dear reader have an opinion or something I havn't considered, maybe a reason one way or the other that would sway the argument? What I'm not willing to do is add another user visible option to let people frig with this. It's such a tiny part of the product I can't in good conscience add an option. There is nicely customizable and there is confusing. I would err on the side of nicely customizable and not add an option. Your thoughts?
(5) Comments \| Add Comment

Nine Frickin Months For This?
Date: 27/4/2006	Yes Oh Yes, Nine long bloody months, a bout of RSI, periods of despair and madness, and not but least; completely crap documentation. It doesn't DO anything yet, but omg I'm so proud! gloating parent Update: Getting more things working:
(2) Comments \| Add Comment

Known Feature Requests
Date: 19/4/2006	I've been getting a bunch of similar feature requests for Scribe that I have already planned to implement for v1.89-test2 so I thought I'd just mention that bugzilla is the right place to check for existing feature requests and track their progress. So the main points for the next release(s) are: #91: Mail will be passed from the connection thread to the GUI thread during receive not at the end. #92: Account preview will list new mail first, and may cache old headers as well. #93: There will be a function to replicate Scribe folders to another mail2 file. This most likely will allow either a subset of folders to be replicated or all the folders, similar to the Outlook replication tool. These seem to the functions people are missing the most.
(2) Comments \| Add Comment

Linux Builds
Date: 14/4/2006	I've just spent most of the night checking out the codebase and building Lgi, LgiIde and i.File on linux. The xml project files are still very platform dependant so I'm making version for Linux and Cygwin and their associated Makefiles for the upcoming Lgi release. I'm also fixing various things that broke in the latest round of changes I'm doing for Scribe v1.89 test2. My aim is to do the next release of Scribe on Win32 and Linux at the same time. There are a bunch of Linux builds that need doing for other apps, i.Ftp, i.Hex and so on. Currently I have Fedora 4 on my machine. And after booting between Windows and Fedora several times tonight it does highlight just how slow Linux's GUI is and also the boot/shutdown times. I guess you get what you pay for. All the classic Linux pain was still there. I had to learn how to use Yum... yet another annoying command line package utility (however it did, surprisingly, do what I asked of it). I couldn't play xvid movies out of the box. Mounting my windows drives was still all command line voodoo instead of some nice GUI tool. Ntfs drivers weren't installed by default. And the screen was shifted 16px off the right edge of the LCD. sigh Linux still sucks. I'm glad I have a Mac now. It makes me happy. I will however make some small token attempt to intergrate with Gnome for font settings and mime->application lookup. No promises though. (The current Lgi codebase looks for KDE settings)
(2) Comments \| Add Comment

Dump Server
Date: 13/4/2006	When you write client/server network software like an email client it's inevitable that some user, somewhere, is going to try and connect to a server that your app doesn't work with. And so it's normal to include logging in your app to capture the conversation between the client and server to a file. Scribe has an option to dump all the bytes to a log file in hex format, e.g.: Read = 18 00000000 2B 4F 4B 20 48 65 6C 6C 6F 20 74 68 65 72 65 2E +OK Hello there. 00000010 0D 0A .. Write = 11 00000000 55 53 45 52 20 74 65 73 74 0D 0A USER test.. Read = 24 00000000 2B 4F 4B 20 50 61 73 73 77 6F 72 64 20 72 65 71 +OK Password req 00000010 75 69 72 65 64 2E 0D 0A uired... Write = 11 00000000 50 41 53 53 20 74 65 73 74 0D 0A PASS test.. Read = 16 00000000 2B 4F 4B 20 6C 6F 67 67 65 64 20 69 6E 2E 0D 0A +OK logged in... Write = 6 00000000 53 54 41 54 0D 0A STAT.. Read = 18 00000000 2B 4F 4B 20 39 33 32 20 32 35 30 34 39 31 31 39 +OK 932 25049119 00000010 0D 0A .. Write = 6 00000000 55 49 44 4C 0D 0A UIDL.. Read = 1024 00000000 2B 4F 4B 0D 0A 31 20 55 49 44 39 36 30 34 2D 31 +OK..1 UID9604-1 00000010 30 36 37 36 31 30 34 33 35 0D 0A 32 20 55 49 44 067610435..2 UID 00000020 39 36 30 36 2D 31 30 36 37 36 31 30 34 33 35 0D 9606-1067610435. 00000030 0A 33 20 55 49 44 39 36 31 30 2D 31 30 36 37 36 .3 UID9610-10676 00000040 31 30 34 33 35 0D 0A 34 20 55 49 44 39 36 31 31 10435..4 UID9611 ...etc etc Thats nice by itself but it really only lets you look at the data. What would be really nice is to actually be able to run your software locally under debug mode with something that made the same responses as the server in the field. So thats what "DumpServer" does, it reads in the log file and pretends to be the server in the log file, sending all the bytes under each read to the client. And it has a nice GUI as well: Now I can fire up Scribe and get it to interact with the "server" just like the user does and hopefully find the point where things go off the rails in my own code. How cool is that?
(1) Comment \| Add Comment

Sitemap