Ticket #192 (closed todo: fixed)

Opened 5 years ago

Last modified 5 years ago

deprecated: tqueue pmc

Reported by: coke Owned by: jkeenan
Priority: normal Milestone: 1.0
Component: core Version: trunk
Severity: medium Keywords: tqueue deprecated
Cc: Language:
Patch status: new Platform: all

Description (last modified by coke) (diff)

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

Attachments

tqueue.deprecated.patch Download (20.2 KB) - added by jkeenan 5 years ago.
Patch developed in deprecate_tqueue branch

Change History

  Changed 5 years ago by kjs

  • platform set to all
  • type changed from bug to todo

Changed 5 years ago by jkeenan

Patch developed in deprecate_tqueue branch

  Changed 5 years ago by jkeenan

  • status changed from new to assigned
  • component changed from none to core
  • patch set to new
  • keywords tqueue deprecated added
  • version set to trunk
  • owner set to 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

follow-up: ↓ 4   Changed 5 years ago by 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.

in reply to: ↑ 3 ; follow-up: ↓ 5   Changed 5 years ago by 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.

in reply to: ↑ 4 ; follow-up: ↓ 6   Changed 5 years ago by 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?

in reply to: ↑ 5 ; follow-up: ↓ 7   Changed 5 years ago by 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

in reply to: ↑ 6   Changed 5 years ago by 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.

follow-up: ↓ 10   Changed 5 years ago by jkeenan

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

  Changed 5 years ago by jkeenan

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

in reply to: ↑ 8   Changed 5 years ago by coke

  • description modified (diff)

Replying to jkeenan:

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

  Changed 5 years ago by coke

  • description modified (diff)

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.)

  Changed 5 years ago by jkeenan

No complaints; closing ticket.

  Changed 5 years ago by jkeenan

  • status changed from assigned to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.