Release 1.0

This post is announcing the 1.0 release of the Mozilla External String Guide prompted by bug 494970. This will be the last release by me for the courses OSD600 and OSD700. I have had a great time with these refreshing couple of courses and all the people involved. I look forward to continuing work in the community, even if it is only in my free time. Also I am sure I will be applying the things I have learned here to other open source groups I have always wanted to, but was previously apprehensive about contributing to. That isn’t to say that what I have learned in these courses only apply to open source, I have also learned plenty of things which will apply to work and life.

This release

Since the upgraded fix to the FPPP hasn’t been perfected yet, I have decided to, in 1.0, put the “mostly fixed” version up. All of the static-analysis generated pages have been updated. This seems appropriate for 1.0 because it removes the long standing error in these documents.

Beyond that I have reviewed the main documentation and corrected any errors I could see.

As of now I am not sure whether or not I can actually close the original bug, there is usable documents and references.

Problems up to now

Recently, the only really big complaints I could think of were:

1. The FPPP bug, which is now partially fixed and is still being worked on.
2. Lack of documentation (conversation) in the static-analysis generated pages, which has pretty much been left hanging towards not being necessary.

The future

As stated in my opening, I do look forward to continuing work in this community. The main documentation may still be missing some parts, without more experience I can’t guaranty a complete work. If I work on some extensions in the future I may be able to see what I might have missed before, but what I will most likely be working on is the static-analysis. The static-analysis is code, and has a distinct end point.

0.9 Release

This release:

As stated in earlier posts I wanted to find some more things to document that are specific to external strings. I added sections:

Comparisons: Comparator functions instead of a virtual comparator class

Finding text within strings: Documenting the finder methods was really important due to the difference between the way they work with internal and external strings. There is also a wide variety of methods used.

I (as usual) have been working on FPPP, but I have been coming closer to the code and hopefully that means to the problem.

Have a look: Mozilla external string guide

Good things this release:

Back on track!

Scary things this release:

This is 0.9, 1.0 is around the corner!

(Some) Things learned this release:

The existence of unicharutils and the seeming lack of info on it…?

Comparator function and virtual comparator class, again info?

Finding an in-code example of a method with a name as common as “Find” in a particular case (IE with strings) can be quite difficult.

See “What was supposed to be release 0.8″ for more.

Work state

With release 0.9 here and 1.0 just around the corner we are all pushing to get things done! Even thought I have moved away from what I initially thought my project plan would be, lots of great things are on the way. The first thing on my list is still the FPPP, but due to it’s complexity I must move forward on other fronts. I have decided I need to document more things particular to external strings, as compared to internal strings. However I still stand by documentation common between both internal and external. We have talked about having on common page which splits into two, one page for the specifics of each. This sounds good, at some point, but until that point having people read through internal strings then go over to external strings and realize the one thing they needed was one of the things that are different between the two doesn’t sound so great. Not that anyone spoke out against the current setup, just saying.

Current tasks:

1. Find and document some things specific to external strings (0.9)
2. 1.0 check over and general clean up
3. Work on FPPP (God willing, 1.0)

Tracing through type-printer.js

In my first attempts of creating a minimal testcase I reported everything worked as it should. However at the time I didn’t realize that in type-printer.js (the possible source of the FPPP) the Dehydra function process_type(type) was used exclusively. Using process_type() keeps everything together and has all needed type information. I had been using other Dehydra functions to generate similar output, but this would be a huge problem going through as much code a type-printer.js does.

Since I wanted to see the code (problem) in progress I decided to trace the data route through type-printer.js so I could get what I wanted directly:

Function:	Variable/list/call:
1) process_type(t)	t
2) interestingType(t)	t name = t.name typeList[name] += t
3) input_end()	p in typeList dumpType(typeList[p])
3.1) dumpType(t)	t members = m in publicMembers(t)
3.1.1) publicMembers(t)	t Base in publicBases(t)
3.1.1.1) publicBases(t)	t base in t.bases base.type
3.1.1) publicMembers(t) (return)	member in base.members
3.1) dumpType(t) (return)	m in members p in m.members typeName(p.type)
3.1.2) typeName(t)	t

In other word what I am looking for *should* be visible at “t.bases.type.members.parameters.type”. Yet it seems my test code doesn’t generate a “path” like this, and I wonder where I might have gone wrong. One possible reason I might have miscounted is because I was often Thrown through a loop with the JavaScript 1.7 additions… Literally, a loop.

I would much rather watch the flow through a debugger, which I am attempting to do now. A post on the should be up soon. It is (hopefully at least) half written and waiting for me to figure out the second half.

What was supposed to be 0.8 Release

*Note: This is a somewhat incomplete version of what my 0.8 release post was going to be. It isn’t full of links, and probably doesn’t make sense sometimes. However I thought there might be some information worth sharing in it., so I am sharing it anyway.

This “release”

This release [was supposed to be] an attempt to reproduce the incorrect behavior Dehydra (or the analysis script I was using) displayed when generating docs for external string in Mozilla. The reproduction was to take place in a minimal testcase to help show exactly where the error was occurring. However once I built my own analysis script from scratch everything worked as it should. Trying to get closer to what the erroring script analyzed, I set up an example similar to the way the the Mozilla code was written. In this case my first analysis script failed altogether not displaying the information I wanted nor the errors I was looking to reproduce. I then realized my analysis script was working in a much different way than the original script I was looking to fix. I analyzed the original script by hand and attempted to narrow it down to one of the methods it uses for analysis which also produces the error results. I decided going through gdb might be a good idea.

Good things this release

Got a hold of Taras who pointer me toward a Minimal TestCase. Though I think he might expect me to file a new bug for him to take care of.

Learned about Minimal TestCases!

Learned about JSLib!
Became reacquainted with X11 tunneling!
Realized the two above were a waste of time when I thought, “Wait… How does this script run via Dehydra?” and read the docs.
Discovered my new friend write_file(filename, data); to write to a file from JavaScript using Dehydra.

Bad things this release

Delaying the release by days.

Release Delay

This is the first of my releases to be delayed. Sometimes these things happen, both in school projects and in software documentation updates/bug fixes. However, I decided to explain the situation instead of just hiding until it was fixed. At least this way I can get some experience from the situation.

What I was aiming for:

Correcting the Function Pointer Parameter Problem (FPPP) or, in the very least, successfully reproducing the unwanted behavior in a Minimal TestCase.

Contributing factors:

These are just some factors which helped inevitably lead to a delay, these are not excuses.

1. The source of the FPPP is tricky and elusive, what works in my current Minimal TestCase doesn’t in real code. (More on this on the release)
2. The machines at CDOT were down (power cut) this weekend. Now, this definitely isn’t an excuse. I read on IRC that this was going to happen, however put off copying all my testcase code and such over until, well, until it was too late.
3. From the point I realized my mistake if I started from scratch I would have stayed up all night and got to the point I was at on the CDOT machines… That is, by the time I got access to the CDOT machines again. So I stayed up all night working on another project until I got access to the CDOT machines again.

When it comes right down to it I can’t *say* I have a “release” until I have something more than a testcase saying “it should work.” At the very least I want a testcase saying “this is WHY it doesn’t work,” and better than that an actual fix once and for all for the FPPP!

I strive to release quality material to the community, and will not waste both of our time trying to push over incomplete work as a release. With that, it is my plan to put out some definitive work in the next couple days.

Thank you,
-Roger Dikce

(*Now that’s practice for a press release right there.)

First Minimal TestCase Attempt

I was working on the Minimal Testcase I mentioned before about the Function Pointer Parameter Problem and a strange thing happened. It seems that Dehydra performs  as expected with function pointers as parameters. However because this is a minimal example it is kind of in an ideal condition; what I will do now is try to find out what real world condition is causing it to act incorrectly with the static-analysis docs. I might already be on the way to fixing this myself!

I think it might be very beneficial to the OSD600 course if it included a formal introduction to minimal testcases. If it does already… It escaped me!

Minimal Testcase

I’ve just been asked to produce a minimal testcase, specifically for the Function Pointer Parameter Problem. I have a feeling that these pages will be my friends for a while:

Minimal Testcases:

QA/Minimal Test Cases – MozillaWiki

Reducing testcases – MDC

Back to Dehydra basics (review):

Dehydra – MDC

As a matter of fact, I think this one just saved my life:

Using Dehydra – MDC

0.7 Release

About

This is release 0.7 of the Mozilla External String Guide. More information is here and this is the project plan blog post.

In This Release

This release saw some page additions and changes which have been waiting to be done for a while now. The additions include:

• Memory Allocation
• Literal Strings
• String Concatenation
• Local/Member Variables

Changes to the page include moving methods out from under Helper Classes and Functions” to “Using Strings.” A note was also added about MOZILLA_EXTERNAL_API under “Includes.”

Interesting Things This Release

Some of the examples included is code taken from the Mozilla Cross-Reference.

It seems the final word is that the static analysis docs do not have to have information added to them.

Problems This Release

I was supposed to get a new contact for help on the Function Pointer Parameter Problem, but haven’t heard much. However as I have other things to work on I didn’t take a head on approach yet. I really want to get this problem fixes, so the time to push is now.

Times Keep Rolling

Lately in the Document Mozilla External Documentation Guide project we (those involved on the Bugzilla page) have been talking about the issue of adding extra documentation to static-analysis docs. These pages are machine generated and have their own bug at the moment, which I am also working on. The initial concern was that these docs were nothing but lists and didn’t include any discussion. However recently it has been stated that these pages are like that for a reason and should remain as such. When the question, should I create “parallel docs which are more descriptive,” was posed the answer was a definitive “no.” It was said that I should instead work towards making the static-analysis docs work as well as they can. So far I haven’t heard any different, and there is work to be done there for sure. I figure the question is there and still standing, until I hear otherwise the answer I received will be the one I take.