2005 - December (Yay, things are moving again!)
2005 - May (pretty much through November)
2005 - April
2005 - March
Ok, finals are over (have been for a week...), my memory played a vicious trick on me: it convinced me that my exam last wednesday was in the afternoon while it really was in the morning. Life goes on and as a consolation prize, I got my expected A+ from my VLSI class.
Time to get back to MT so I may have an interesting project to show off at job interviews and other such... with my academic bad luck stream. I need a proof that I have been doing something useful with my time.
Planned side-project: custom alarm clock - one with multiple mid/long-term patternable presets... one which I can use to set alarms at exactly the times I want for unimportant things like, humm... exams, weeks in advance. (Patterns like every X minutes/hours, every X days, XYZ days of the week only, specific days of the month, yearly (specific date), etc.)
Looks like my efforts to code safeguards against coding accidents such as leaks and multiple and/or untimely deletion have mostly succeeded... except that now, I appear to have opened a can of far more subtle class of bugs... instead of crashes or leaks that were obviously caused by my code, I get crashes that seem to be related to some random threading intolerance in WinSock and MFCs - although overall threading tolerance appears to have improved a lot between MFC70 and MFC71, one of the problem areas appears to be CSimpleString - one of the odd problems I have seen is the framework trying to clean up deleted object.
In any case, finals start next week so now would be a good time to put MT back on ice for a short while.
[2004-04-11] Turned out most of these odd "new problems" were caused by CAsyncSocketEx not being written to handle kamikaze ("delete this") derived classes - at least not from within its asynchronous overridables. IIRC, CAsyncSocket was more tolerant and all my custom classes are written to be suicide-happy.
The core is still not quite completed since I had to spend quite a bit more time on debugging some unexpected crashes and plug memory leaks. Now that these bits of code have been reshuffled to proper order, the new yet incomplete core is able to passively download whole files crash-free and leak-free... at least under controlled network (LAN) conditions and ~1MB/s download speed.
Next steps are to give the core some initiative and start rebuilding the GUI so I can have some control over the core and a more convenient way to see what is happening.
Peer protocol packet handling is back in working order, the thread pool (using the Win2k/XP QueueUserWorkItem API) appears to be working as expected, as does the virtual file and a few other things... a few more small steps and the peer protocol should be working again soon, I might be able to start my first download using the new core this weekend.
The core is now minimally functionnal:
- No bandwidth management/limiting
- Upload is not working yet
- Downloading is partially functionnal
- Passive connections only (wait for peers after tracker updates)
I also ran in a very obscure little bug...
while(!SomeList.IsEmpty()) {
SmartPtr<SomeClass> sPtr = SomeList.Head();
...
}
Looks like my notion of what seems like a good idea changed quite a bit over the last year.
It has been a nearly year-long break of MT-coding and almost four months since my last line of job-related C/C++ code. I am finally starting to feel like coding as a hobby again.
Given how much I messed up my source trees since the last usable build, it is seems like it will be much simpler to go with a thorough rewrite and proceed with 0.2.0.0 rather than try and fix everything that went wrong.
Since my last site update, I also got a new PC (P4-3G/1GB RAM) and a new laptop (Athlon64-3000+/512MB RAM) which should allow me to test MT under what is now considered common hardware... this allowed me to discover that there was no obvious cause for the obscure timing bug where MT would do nothing on faster PCs - these builds worked fine on lower-end hardware (P3-1G) though.
What to expect from MT0200?
- It should work on modern PCs (MT01xx worked only on ~1GHz P3s and lower thanks to some obscure timing issue)
- It should not be a CPU hog (older builds were sane, later ones became hogs probably due to some unexpected finite recursive loop)
- It should also be somewhat more memory-efficient
- It should have fewer bugs (one can always dream - MT0200 will be >70% fresh or rewritten code, except the GUI part that may end up <30% rewritten, mostly for adapting to architectural changes)
- Still using MFCs for the GUI and CAsyncSocket for networking, this makes using threads quite inconvenient since MFC resources are directly accessible only to their creator GUI thread - all others must use safe handles, dangerous casts or other ugly tricks.
- [2005-04-11] Actually, the VC7.1 MFCs are far more threading-friendly than VC7.0's... threads can access MFC objects almost as freely as the main thread, with little to none of the previously necessary work-arounds.
- Still a plain Win32 dialog app (no fancy COM/ATL stuff, maybe for MT0300)
Right now, I am in the process of auditing my 0.1.x.x code and extracting reusable code and ideas.
If all goes well, things should go a roughly like this:
- March: rebuild the core (using some salvaged code from MT01xx's)
- April: rebuild the GUI (re-using most of MT01xx's)
- May: May-be have the first fully functionnal alpha
I wonder how close to functional and stable the first public build will be... probably not much closer than the first 2003-12 builds but I can always keep my fingers crossed.
Hits since December 5, 2003:
Generated on Wed Dec 28 23:02:55 2005 for MoonlightTorrent(.com) by
1.4.5