deprecated: tqueue pmc

[coke]

The patch I just attached appears to satisfy the "before 1.0" deprecation requirement listed in DEPRECATED.pod. Parrot builds and passes all tests in make test. But since this is one of the few times I've ventured so far into Parrot's guts, so please note the following:

1. Basic approach was to grep the repository (fns . | xargs grep -in tqueue) and rip stuff out. Out went src/pmc/tqueue.pmc, t/pmc/tqueue.t and examples/pir/thr-primes.pir. Five tests were tossed out of t/pmc/threads.t and one test from t/op/gc.t. Ran makepmcrenumber to renumber PMCs. Updated MANIFEST.

Now, there may be some reason to take another look at the tests I ripped out, as those tests may be telling us something interesting about some other aspect of Parrot. On the other hand, if they were doing that, then they were not sufficiently focused tests to begin with.

2. Files I didn't touch: a. docs/book/ch05_pasm.pod: example of threading and long discussion beginning around line 2317. Note that this discussion says that "in the previous chapter" -- presumably, chap04 -- it is stated that Parrot has three different threading models. I couldn't locate any discussion of threading in docs/book/ch04_pir_subroutines.pod. So this section of ch05 needs revision for reasons above and beyond the discussion of tqueue.

b. languages/cardinal/src/classes/Queue.pir. See approx line 25. It appears that the Cardinal Queue class uses TQueue -- but I am not a Ruby programmer.

The patch was developed in the deprecate_tqueue branch in SVN. Please review it carefully and let me know whether it's okay to merge into trunk.

Thank you very much. kid51

[jkeenan]

Patch developed in deprecate_tqueue branch

[jkeenan]

The patch I just attached appears to satisfy the "before 1.0" deprecation requirement listed in DEPRECATED.pod. Parrot builds and passes all tests in make test. But since this is one of the few times I've ventured so far into Parrot's guts, so please note the following:

1. Basic approach was to grep the repository (fns . | xargs grep -in tqueue) and rip stuff out. Out went src/pmc/tqueue.pmc, t/pmc/tqueue.t and examples/pir/thr-primes.pir. Five tests were tossed out of t/pmc/threads.t and one test from t/op/gc.t. Ran makepmcrenumber to renumber PMCs. Updated MANIFEST.

Now, there may be some reason to take another look at the tests I ripped out, as those tests may be telling us something interesting about some other aspect of Parrot. On the other hand, if they were doing that, then they were not sufficiently focused tests to begin with.

2. Files I didn't touch:
a. docs/book/ch05_pasm.pod: example of threading and long discussion beginning around line 2317. Note that this discussion says that "in the previous chapter" -- presumably, chap04 -- it is stated that Parrot has three different threading models. I couldn't locate any discussion of threading in docs/book/ch04_pir_subroutines.pod. So this section of ch05 needs revision for reasons above and beyond the discussion of tqueue.

b. languages/cardinal/src/classes/Queue.pir. See approx line 25. It appears that the Cardinal Queue class uses TQueue -- but I am not a Ruby programmer.

The patch was developed in the deprecate_tqueue branch in SVN. Please review it carefully and let me know whether it's okay to merge into trunk.

Thank you very much.
kid51

[coke]

Fixing cardinal would be nice, but is beyond the scope of the ticket. Agreed on the book notes, but I'd probably add a note near the tqueue reference noting it was removed and that the docs are crufty.

When removing pmcs, also add an entry to PBC_COMPAT.

Regards.

[jkeenan]

Replying to coke:

Fixing cardinal would be nice, but is beyond the scope of the ticket. Agreed on the book notes, but I'd probably add a note near the tqueue reference noting it was removed and that the docs are crufty.

Done.

When removing pmcs, also add an entry to PBC_COMPAT.

Done. But do I also have to follow these instructions found inside PBC_COMPAT?

# After changing PBC_COMPAT either disable t/native_pbc tests or
# better, if you have an i386 box at hand, regenerate the PBCs
# with tools/dev/mk_native_pbc and commit the changes

If so, should I pursue 'either' or 'or'?

Regards.

[jkeenan]

Replying to jkeenan:

Done. But do I also have to follow these instructions found inside PBC_COMPAT? {{{ # After changing PBC_COMPAT either disable t/native_pbc tests or # better, if you have an i386 box at hand, regenerate the PBCs # with tools/dev/mk_native_pbc and commit the changes }}} If so, should I pursue 'either' or 'or'?

And if I do the regeneration, should I do that (a) while I'm still in branch, (b) before I commit the merged-in code to trunk, or (c) after everything else is committed to trunk?

[jkeenan]

Replying to jkeenan:

And if I do the regeneration, should I do that (a) while I'm still in branch, (b) before I commit the merged-in code to trunk, or (c) after everything else is committed to trunk?

Since most or all of the t/native_pbc/*.t tests are TODO-ed out at the moment, I decided to do nothing as far as regenerating the PBC. Branch was merged into trunk in r37028.

I'll mark ticket as fixed sometime over the weekend if no problems or serious objections emerge.

Thank you very much.
kid51

[jkeenan]

Replying to jkeenan:

Since most or all of the t/native_pbc/*.t tests are TODO-ed out at the moment, I decided to do nothing as far as regenerating the PBC. Branch was merged into trunk in r37028.

Correction: The most important part of the merge was in r37029.

[jkeenan]

At what point should discussion of Tqueue PMC be removed from DEPRECATED.pod?

[jkeenan]

 This Smolder test shows the results of make test immediately after the removal of the Tqueue PMC.

[coke]

Replying to jkeenan:

At what point should discussion of Tqueue PMC be removed from DEPRECATED.pod?

[coke]

Generally, as soon as it's removed from the repository.

Deprecated.pod shows things that are still in but have been scheduled for eventual removal; once they are actually removed, there's no point to warn about their removal any more.

Even with the ticket still open for a few days, I'd still go ahead and remove it now.

Regards. (Whoops: used the wrong box to enter all my text last time, sorry.)