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.

Neolious coding

Oh baby has tonight been a full head of steam. I’ve been slugging through the options systems and the subroutines for actually doing the installations. A mock up of the style #2 GUI which is one of the ones I posted back in december when I did three different concept drawings. She is almost ready for a live test, I think as soon as I correct the item selection code to work properly (not tied to mouse position) it will finally be time for that Alpha Release, two weeks later then originally planned but hey it’s still is more feature complete on the inside then previously planned for it xD

Here is a screen shot of Neo running during a test run of the mock up from the trunk.

Free Image Hosting at www.ImageShack.us

I solved most of the layout issues and I think it will probably be playing with the spacers and splitters to finish the rest of getting it to ‘look nice’. The main window is hand written but the display dialog is an extended sub-class of a prototype made in QT Designer.

What I am thinking is to have 3 drop-in modules each implementing the NPM_MainWindow class. Where each module implements one of the user interface styles and the programs init code loads the appropriate module. The advantage being the freedom to do any thing desired with the main window, while preserving the rest of things that have been done. Technically user created UI could be allowed to be loaded. I really want to play with the dock window stuff in Qt4… lol.

I need to start setting up the documentation (internal first, then the manual), ironing out the key commands, and setting up for the german translation in addition to my remaining to do’s but all of that is non-critical as far as getting an experimental release out there. I think goal for Beta time would be getting the portsnap/csup/cvsup stuff sorted out and a settings + about + help dialog in the run. A better website design would be nice too… hahaha

I know what I can’t figure out today, I can figure out in the days to come.

Hooah !

Nights labour

Spent most of the night working on the port searching code and options module. I think the options module is now almost like what I originally envisioned of it. Aside from being integrated into the not yet written settings dialog and no read/write accessor methods wrapping around the configuration dictionary keys.

So far across the various prototypes, tests, and mock ups I’ve written over 3,000 lines of code (wc -l *.py for each directory gives sums adding to >3700L). The way I work I guess is a bit heavy on files but it tests the hell out of things 🙂

So far the current working system is almost 700 lines of Python code. Aside from not being very feature complete yet (for my tastes) I think it is coming along quite nicely and maybe should be marked higher then the pre-alpha status I set on sourceforge… But I guess I have higher expectations of my own work then I do others lol. The > 700 lines of code in the SVN now represents the work done in R&D by the previous coding. One thing I like about SVN and CVS as opposed to manually backing things up with cp/tar is there is no fear about ‘accidentally’ deleting files permanently before they serve their use hehe.

I’m hoping to soon have enough files for a quick snapshot that can handle the basic pkg_* commands and searching the local ports tree. I have tried to keep both the quality of the code and the programs design as high as possible at every phase but I don’t really consider myself a good programmer. Just someone that knows what he wants and can wrap his head around it piece by piece until it all falls into place.

Hmm, why do I feel more like a Japanese Beaver then a Spider right now? Haha/

NPM Code List

A quick list of standing to do’s so I can be sure I don’t miss things, I really should look at using the tracker service on Source Forge for this hehe. But I’d rather spend my time writing the solutions 😉

In no particular order:

  • extend QLineEditdone a different way (for now)
  • do concept drawings of settings dialog
  • integrate logger and options module
  • remove dependency on psearch — it really is that simple a program!
  • fill in stubs for various port actions; install/upgrade/delete and prepair for various capabilities that need further development *wink*mostly done and evolving
  • ability to select items by means not tied to the mouse pointer location
  • consider a better name then port_viewer.pyrenamed pkgviwer.py
  • begin work on the ground work to begin the German translation
  • performance tests of our background process handling
  • mock up of NPM_MainWindow in style number 2done, minor changes to go (mostly educational advancements
  • gui for cvsup/csup/portsnap operations
  • replace search box and refresh button with tool bar in mock up layout
  • tabbed about dialog, kde-style

S’all I can think of right now. I know I really need to look deeper into Qt’s layout handling and widget geometry related facilities not to mention the coordinate system.

Open Formats

After a little bit of research into the idea of recording my desktop to video for some tutorials I got to thinking. I expect this post will probably take a draft of an essay like feeling to it lol.

Some people are down right insane when it comes to the issue of open or closed in the software world, rightly so in some cases. The idea of which is ethically better MP3 or OGG is irrelevant to most people, they just want to listen to music.

When it comes to selecting or using a given file format for media I am generally indifferent to what it is in so far as it works without giving me headaches. I don’t care if it is a .wmv or a .gnu as long as it does what I need it to do. And often the user-perspective is what prevails when people look at file formats, just as it should be.

However the world is not so nice. One thing I like about the Open Source side of the software world is often things are developer centric, users second. Although a great deal of software is done with users in mind – developers should come first in my humble opinion. Because without developers there is no software.

Open Formats are by definition open, you can do what ever you like with them. One reason that OGG has gotten to be as common as it is with Game Developers is because it is essentially free. Need to read OGG Vorbis files and play them as audio? BINGO You can code it, want to create them? BINGO You can code it. Want to create an MP3 Encoder and all hell breaks lose !!!

Because the creators of proprietary formats generally own the format they can do any thing they want. With the proper patent, copyright, and intellectual property protection… Company Foo could create the BAR format for handling audio or video files. What if Company Foo says “Gee, every one seems to be listing to music on .bar files.” And decides you have to pay them $1 for every .bar file? Absurd but sadly it is not so far fetched in this wonderful age. Of course most people want their stuff to actually get used – that is one thing I tip my hat to the creator of the RAR Archive format. Any one can create a tool to extract .rar archive files and give it away for free, code included. But no one is basically allowed to do that with programs to create .rar files. Which I think is a fair compromise personally, any Joe can extract the .rar file but the programmer that owns the format gets to make some money off people wanting to create the files.

From the user perspective, who cares what the format is? You want to have the ability to read (listen/watch/extract) and write (create, encode, compress e.t.c.) files in a given format and without having to pay for software and bend to licensing terms just ‘because’ some one wants to control the format.

From a developer point of view put into users perspective… Developer Ham wants to create some thing to write .bar files out for a program he is using and wants to give away for free along with the code to do it. But Company Foo puts an end to it because they own the BAR format.

If all users were developers, they could create their own open formats — heck already done ;-). Developers write the programs that end users use. Without users who don’t code owning a format is useless because the customers being developers themselves could create their own open formats to share.

From a developer perspective, do you want to have to pay licensing fees to Company Foo to encode support for .bar files in your program whether or not you will be making money off your program? Using a different (free) format versus paying any thing they want to use .bar sounds like a good idea to me.

If there was 1 developer in the world and all the others were users, you could be a millionaire overnight or go flat broke selling closed software 😉

(mutters enough rambling)

Generally for multi-media formats all I care is that it does it’s job. Acceptable file size to content quality ratio – 200MB for life like quality of Audio and Video or 20MB for a pile of junk, gotta balance it for the task.

The one thing I do expect, is to be able to use the files fairly and without headaches. I don’t have problems with .WMV files because they are very easy to play with the right codecs. Now trying to create and edit WMV files can some times be a different story :o)

NPM_DisplayDialog

Spent most of the night watching Simpsons but I started work after awhile.

Worked on a compromise between the pkg_info/pkg_delete display needing to pass on the software packages name to be operated on to the appropriate slot and my own code minded need to place the actual implementations of those slots in its own file along side other port-related actions. I also removed the hidden column since I realized I already had a method to cram the spitted name and version back together and store it in an instance variable for passing on.

The internal QAction object for each entry in the context menu has it’s connect() signal connected to a python slot. Since we need to know what was activated (and I am not a genius with context menus in QT3) when the action is activated the slot calls an external function (the real slot if you like) with the name of the selected package.

So right clicking the package in the list brings up the context menu, which saves a reference to the item selected; suitable for running the pkg_delete/info commands on directly. When selecting the action to perform from the context menu, it causes the activated() signal to be sent to the wrapper slots for that action. Which intern call the implementations from another file with the item/package name that was set by displaying the context menu.

There might be a better way of doing it but I ain’t found it yet. And personally I am one that prefers to try the simplest solutions to a problem first and see if they work before complicating things. And this way of doing it is quite simple, at least to my brain cells.

I also skipped using the poor looking mockup of a display area I wrote to pack the output of running a command, such as make into a window for display. The mockup was based on a translation to Python I did of a C++ Example from QT3. It worked but did not look very nice and although I prefer to hand-code things when it’s not to major because it normally ends with me knowing WTF is going on. I fired up QT Designer and used it to create a simple Dialog with buttons I can edit into what I want and spend time getting it to do what I want rather then look nice.

Generated the python version of an ui.h file from it and wrote a subclass of it that modifies it (for testing at this point) and extends it with the extra functionality we want, being able to run the requested process and display it’s output. So far I am enjoying this and because the .ui files created by QT Designer is just a custom XML format, it is easy to edit by hand as well as through Designer (A GUI for making a GUI the easy way). Later on the subclass from the ui.py file might get replaced with a handwritten equivalent but I’ll worry about that later.

Some standing issues are:

0/ Define usage style for the Display Dialog while it ‘runs’ including changes to the options sub-system as needed.

1/ Set up the pkg_delete / pkg_info handlers to use it for displaying their output.

2/ (later) figure out how we can get the Dialog to display properly when resized, namely having the buttons and display widget resize with the window !

The above 3 items are what I would be doing tonight, if tonight was not really this morning because it is after 0500 in the local morning !!!!!!!!!!!!!!!!

The sad thing is I am hungry and wide awake but not sleepy in the least. I guess programming for a couple hours has that effect =/

Man, I love to code…