I'm currently in a very constructive email chat with a (I guess) indish guy who keep constantly asking me how to do things in Curses::UI that are not even implemented. That's good, because he requested some rather usefull features like adding single items to a Listbox widget. Never thought of that and actually never did that.
When thinking about Curses::UI and hacking it I always want to keep backwards compatibility, that's because I'm lazy and don't want to change my own programs that use Curses::UI. This can't be bad for other people.
The problem is, as I took over Curses::UI there weren't really much tests. In fact, all tests in Curses::UI just test weather the modules compile, not their actual function.
But how to test something that is rather a visual thing than something you can catch in the source. I mean, usually you test a module by knowing what a method should return and then using Test::Simple or Test::Moore. I guess about 75% of all subs in Curses::UI don't return anything. They just do something on the screen. And they don't know weather their call just worked or didn't. That's rather strange.
It's actually not an excuse for not testing the 25% subs that return something. I'm going to do that before I release Curses::UI 0.80. The other problem that all the Test::* modules usually do output something, which can be hard if the screen is locked by Curses calls. This is a thing I've to figure out before I write the tests. The POD isn't tested either and this is something I consider as really bad. So besides all the other stuff I do I have to fix the and write tests for Curses::UI
Another thing I just wonder about is versioning of modules. I got Curses::UI when it was version 0.70 or something and kept increasing the version number in steps of 0.01 for quite a while now. I think it's psychological more usefull to releas a verion 1.0 someday to tell people that I believe it is ready, stable and useable. Maybe I should create something like a releas plan. It should be easy to release a 1.0 version till christmas. I will release the next version, that has mostly bugfixes and the new tests I'm going to write till end of this month as a 0.8 version. After waiting for some fixes I'll go up to version 0.9 and if I find now showstoppers I'll release it as 1.0. Sounds far more easy than it will be. Only in writing all those test I will intoduce new bugs, find some, fix some bugs and write some new features, so I shouldn't be that optimistic.
I'm somehow to stupid to fix parrot, at least at the moment. I posted my problems to the list and the issue was quite fast solved. So the disassembler works again.
My URM compiler, that brought me into all this is now in Parrot CVS 🙂 I'm happy.
Unfortuanetely I'm not quite sure what to do next. I finished all my exams and am free now to do what I like, at least for a week.
I got one outstanding project, that involves MS products and some just for fun hacking on the page of my local linux user group Luusa. As the only perl maniac in my group I couldn't really convince them to use Perl, so they took PHP.
So I can decide to do MS stuff or PHP. Sounds great :-(.
Another example for just my luck is that today the Hacking Parrot guide was released. Would ther have been something like that before I wouldn't have had to figure out everything on my own. I think I'm going to read it tomorrow, after havin celebrated my new freedom of not having to write exams till next February.
I had a really hard day. Actually I had two really hard days. I'm still trying to figure out why the disassembler crashes. And I'm quite close, the problem is what I'm close to.
Parrots Memory Management.
It seems as if it crashed because somehow one of Parrots own printf implementations overwflows the memory and that's really wired.
But I don't think that I'll be able to find out what's happening, the MM seems to be one of the most complex parts of Parrot.
Actually I think I'll have a break and find out afterwards where the bug is….
This was a perfect day. As usual, I wasn't doing what I should have done, but started with a regretful thought: Let's have a look into how the Parrot Disassembler works and what Parrot actually does with the nice PASM my URM compiler is writing.
It didn't work
It segfaulted directly, and I started debugging the debugger….
It wasn't that hard, cause all the trouble was only caused by some uninitialised vaiables and the according memory mess.
But the main problem is that I still can not disassemble, because at some point it still segfaults and I don't know what is happening at this point.
So maybe it's time to ask people who know what they are doing.
My other problem at the moment is that my Parrot CVS is a total mess and that checking out needs a long time with 64k because Parrot got all the ICU (Unicode) stuff in it's repository. So I can't send a patch to the list. 😦
But thank God it's friday, I'll have some drinks and maybe I'll have some good new ideas.:-)
After hacking the whole day and thinking of so many things I thought maybe there is someone out there who wants to know what I'm doing, so I start blogging, my life – or better my life with perl.
What I should do at the moment: Studying stuff for university exam in Computer Science Theory, you know, all that suff about context free languages, touring machines and NP problems.
What I actually do at the moment:
Hacking on my URM to Parrot Assembly compiler. If you don't know what URM is, have a look here
The state of this stuff:
It works, creates nice little pasm files and has no bugs (as far as I know). The problem is like with every quickhack that becomes public that I got to make it more Parrot compatible, but I don't understand everything of Parrots built system. And I don't understand
So I'm pretty stick now at the moment, having played enough with Perl 5.8.1 and not knowing what to do with URMC (besides replacing every / in my program with
Maybe I should start studying 🙂