Mxing a code squishy

Well, last night I got an alpha grade (imho) release set up on source forge and today I got it posted on forums.pcbsd.org.

It is some what ahead and behind schedule in the same regard, I originally planned to release a mock-up (non functional but ‘looks’) around the new year. Instead I’ve taken a few weeks to push on a head to some thing that actually works.

I had also road mapped a beta with a few more features then are currently ready to be released between Jan 2008 and June 2008 but it’s more likely that I’ll hit a 1.0 by June… hehe. So I’m both behind and ahead of my time goals. Software Schedules are not really some thing I believe in setting in stone, so much as setting a point on the calendar some where between when I expect to be done by and when I think it should be done by.

Since making use of SVN was not in my original plans I do have a bit to consider now.

I want to continue coding so I can keep the pace of development going. But I need to consider the chances of bugs being found in any one that actually tries the snapshot I released. And I do not want to muck with merging branches later if that happens… The stuff I released is not complete but it should be fairly stable, or I wouldn’t have let it hit SVN >_>.

What I am thinking is to limit my self to continuing things in the trunk that need to be done without effecting the released code much. Which is copied to the tags directory so it’s saved in SVN. Then after about a weak or so, go back to un-restrained work. So I can deal with things like redoing the NPM_DisplayDialog the way I would like to redo it.

Before I am willing to bump status to Beta, I want to have NPM able to update the ports tree (portsnap/cvsup/csup) and configure ports. I tested the config gui awhile back before taking the code to sourceforge but I never got it fully working. I need to figure out just how I am going to get a connection between checkboxes and options that I can parse back out of the GUI.

I should also make it look for stored configurations rather then just in the makefile.[0]. Those two things are really what I am interested in coding feature wise. I also want to remove the dependancy on psearch because it really is a simple app and we might get a slight performance boost.

I also want to fix the translation systems up a bit, work on another prototype of the NPM_MainWindow user interface style and do some concept art for NPM’s configuration dialog. I don’t expect a GUI way of changing NPM’s settings to be released until RC status though.

NPM test 1, phase 1 results

I was a little disatisified with the phase 0 results. What I had done was checkout a copy of the sources onto the test machine end removed the diagnostic messages of echoing the command and arguments to be run in the background. A few oversites later namely a missing equals sign and the lack of –verbose switches (as can be seen in the video’s uninstall segment) I basically got it working but not quite happy with it.

Sat down tonight after watching a movie and set to work on getting her working smoothly out of the source tree. After that was done and with a little poking at portupgrade later…. I ran a group of live tests to check for the ‘it actually works’ factor with the core things and got no show stoppers. The only bad things I can say is I don’t care much for the port{upgrade,install} output dots and the occasional lag in updating the QTextEdit widget but it’s probably no slower then doing it from my shell.

here is a copy of the last commit message from editing source code:

CODE PASSES FOLLOWING TEST CASES:

update package listing (right listview)
view pkg_info for selected package (xevil)
remove selected package (xevil)
search ports tree (for xevil)
install port (xevil)

xevil was selected because it is one of the ports I have installed that is a suitable test case (small, fast/easy to install/deinstall) and one of the time wasters I have setup that I can live without if I frag it on there install.

I’m going to upgrade the development status on source forge to Alpha shortly and tomorrow I hope to have a file release ready op, Most of what remains is logistics really, before the Alpha Release the following needs to be compelete:

0/ make demo video (I would write the script now if it was a quarter after 4am’ish) — couldn’t get mic working, just as well with my house…

1/ mini faq thingy uploaded to website and update the sites download page

2/ readme file generated with basic testing instructions blah blah — also included a template for a desktop icon.

3/ update trunk/src/const.py NPM_VERSION – probably will get bumped to “0.48.Xa” ore “0.48.Xpre” and clean up some of the comments

4/ read SVN handbook on tagging and branching and put it to work – I want the alpha release split off the trunk.

5/ get file release prepared — done and done!

6/ forum post typed up for forums.pcbsd.org – done

7/ get my ass back to coding — what I should be doing lots of hehe.

Hooooooaaaaahhhhhhhhhhhhh !!! Now if I can get audio working in XVidCap and enough silence to do it with my crappy mic, this gonna be a nice start.

Sadly most of this is gonna have to wait until after dark…

fucking family already has given me a headache and it’s only 1617 local..

Rush Hour

Today we got cable hooked back up on the bed room sets. Caught Rush Hour on, so finally some thing good on but it was also about the only dang thing on TV !!! A few months without cable and I ain’t been missing much haha!

War, huh, yeah
What is it good for
Absolutely nothing
Uh-huh
War, huh, yeah
What is it good for
Absolutely nothing
Say it again, y’all

War, huh, good God
What is it good for
Absolutely nothing
Listen to me

Ohhh, war, I despise
Because it means destruction
Of innocent lives

War means tears
To thousands of mothers eyes
When their sons go to fight
And lose their lives

I said, war, huh
Good God, y’all
What is it good for
Absolutely nothing
Say it again

War, whoa, Lord
What is it good for
Absolutely nothing
Listen to me

War, it ain’t nothing
But a heartbreaker
War, friend only to the undertaker
Ooooh, war
It’s an enemy to all mankind
The point of war blows my mind
War has caused unrest
Within the younger generation
Induction then destruction
Who wants to die
Aaaaah, war-huh
Good God y’all
What is it good for
Absolutely nothing
Say it, say it, say it
War, huh
What is it good for
Absolutely nothing
Listen to me

War, huh, yeah
What is it good for
Absolutely nothing
Uh-huh
War, huh, yeah
What is it good for
Absolutely nothing
Say it again y’all
War, huh, good God
What is it good for
Absolutely nothing
Listen to me

War, it ain’t nothing but a heartbreaker
War, it’s got one friend
That’s the undertaker
Ooooh, war, has shattered
Many a young mans dreams
Made him disabled, bitter and mean
Life is much to short and precious
To spend fighting wars these days
War can’t give life
It can only take it away

Ooooh, war, huh
Good God y’all
What is it good for
Absolutely nothing
Say it again

War, whoa, Lord
What is it good for
Absolutely nothing
Listen to me

War, it ain’t nothing but a heartbreaker
War, friend only to the undertaker
Peace, love and understanding
Tell me, is there no place for them today
They say we must fight to keep our freedom
But Lord knows there’s got to be a better way

Ooooooh, war, huh
Good God y’all
What is it good for
You tell me
Say it, say it, say it, say it

War, huh
Good God y’all
What is it good for
Stand up and shout it
Nothing

— Edwin Starr, War

Test 1, Phase 0

booted my test machine

set up for video taping

svn’d a copy of npm source

edited source to prepare for test

began test.

Not 100% what I wanted but this is the first live test of install and deinstall operations.

Video Sample

I tested doing a portinstall of xgalaga, confirmed it ran, and then removed it. The pkg_delete operations output left a little bit to be desired! But hey, it did work…

I want to prep a script and get the code ready for a small battery of live tests under real world conditions. Once the code is suitably able to pass an acceptible amount of the tests… Alpha release.

Before I video the next one through I want to have a properly written out and planned script to follow for the video. I also really would like to try and get my Mic working (not tested yet) so I could use voice over and some background music wouldn’t hurt if it didn’t add more then a few megabytes to the out file.

Currently tests will take the first priority and continuing feature implementation will take secondary until the Alpha release is ready op.

I want to triple check but I think I’ll be able to host the video on the website for download and I can probably upload it to YouTube. Using rapidshare for this one was just to make it available (temporarily). The final one made for the alpha release will be much better.

My main concern though is getting NPM ready hehe.

Social Civics returns

I can’t believe it, I forgot to do part of the test 🙁

Got back 2 of the 6 or so tests I sent out, one with a score of 100% and the other with a 98% because I forgot to answer one of the questions lool.

*sighs* Oh well, I guess it’s ok for how fast I tried to do them.

Another night spent working on NPM…

Some of the stuff done to night

begin of internal docs

prepping files for translation (wrapping more strings, now using QKeySequence e.t.c.)

trying to get set up for translations (including the beginning of the German one).

rewriting the display dialog to remove usage of Qt Designer / pyuic generated code.

To be honest, I think I could run a live fire test tomorrow with a 2 minutes worth of changes.

AMD Knocking me off the chair

The other day I bumped into an AMD K6 family processor and looked it up when I got home, when I read some thing about trasnlating to a RISC like instruction set I nearly fell off my chair… Today I looked up a little more. I would guess the K6 is probably up this ally as well.

RISC86 Microarchitecture

The Nx586 processor fully implements the industry standard x86 instruction set to be able to run the more than 50,000 applications now available. This implementation is accomplished through the use of NexGen’s patented RISC86 microarchitecture. The innovative RISC86 approach dynamically translates x86 instructions into RISC86 instructions. These RISC86 instructions were specifically designed with direct support for the x86 architecture while obeying RISC performance principles. They are thus simpler and easier to execute than the complex x86 instructions. Note that this approach is fundamentally different than RISC processors, which have no support whatsoever for the x86 instruction set architecture. The RISC86 microarchitecture also contains many state-of-the-art computer science techniques to achieve very high performance, including register renaming, data forwarding, speculative execution, and out-of-order execution.

The benefits of this approach are several. First, the performance advantages of RISC design are applied to the x86 instruction set. Second, the execution unit can be smaller and more compact. Third, the execution units can be more specialized to give specific performance enhancements. Finally, it will be easier to add additional execution units in future designs. The RISC86 microarchitecture not only gives the Nx586 processor high performance today, but also allows for significantly higher performance in the future.

AMD Website, Nx586

cpu-info.com, Nx586

Spent most of yesterday being driven out of my fscking mind… Would have a better chance of surviving walking in front of an on coming 18-Wheeler then getting work done :

Hopefully with an early start today, I mihgt be able to get stuff done before hell breaks lose again.