Transcript output logic is wicked, flush or not. Especially if you Halt now.
Check for stepGlobal senders and implmenters and see it in all its glory with flags and all. You can then understand why things are weird. Some World doOneCycle peppered around may confuse things a bit more. Use a log file and tail -f it if you are on OSX or Linux. It will at least be in the order you issue things. Phil On Tue, May 10, 2016 at 1:15 PM, Johan Fabry <jfa...@dcc.uchile.cl> wrote: > Hi Vince, > > some of your problem may be in the Transcript buffering some of its > output. It is best to add a ; flush to the end of all your printing, e.g. > Transcript show: 'waiting...'; cr ; flush. > > HTH > > On May 10, 2016, at 07:31, Vince Refiti <vin...@gmail.com> wrote: > > Hello > > I am playing around with Semaphore, and wrote the following: > > | coll count sem | > coll := Array withAll: (1 to: 100). > count := 0. > sem := Semaphore new. > coll do: [ :each | > count := count + 1. > (count >= 5) > ifTrue: [ > Transcript show: 'waiting...'; cr. > sem wait ]. > > [ [ 2 seconds asDelay wait. > Transcript show: each printString, ' ', count printString; cr ] > ensure: [ > count := count -1. > sem signal ] ] fork ] > > The output is: > > waiting... > 1 End of statement list encountered ->5 > 2 4 > 3 3 > 4 2 > waiting... > waiting... > waiting... > waiting... > 5 8 > 6 7 > 7 6 > 8 5 > 9 4 > 10 3 > 11 2 > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > 12 11 > 13 10 > 14 9 > 15 8 > 16 7 > 17 6 > 18 5 > 19 4 > 20 3 > 21 2 > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > 22 14 > 23 13 > 24 12 > 25 11 > 26 10 > 27 9 > 28 8 > 29 7 > 30 6 > 31 5 > 32 4 > 33 3 > 34 2 > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > 35 17 > 36 16 > 37 15 > 38 14 > 39 13 > 40 12 > 41 11 > 42 10 > 43 9 > 44 8 > 45 7 > 46 6 > 47 5 > 48 4 > 49 3 > 50 2 > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > 51 20 > 52 19 > 53 18 > 54 17 > 55 16 > 56 15 > 57 14 > 58 13 > 59 12 > 60 11 > 61 10 > 62 9 > 63 8 > 64 7 > 65 6 > 66 5 > 67 4 > 68 3 > 69 2 > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > 70 23 > waiting... > 71 23 > 72 22 > 73 21 > 74 20 > 75 19 > 76 18 > 77 17 > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > waiting... > 78 23 > 79 22 > 80 21 > 81 20 > 82 19 > 83 18 > 84 17 > 85 16 > 86 15 > 87 14 > 88 13 > 89 12 > 90 11 > 91 10 > 92 9 > 93 8 > 94 7 > 95 6 > 96 5 > 97 4 > 98 3 > 99 2 > 100 1 > > I was expecting 'waiting...' to alternate with the 'each-count' lines. > Also the entire statement paused for 2 seconds, spat out some lines, then > waited a little longer, and then finished. > > Can someone please explain this pattern? > > Thanks, Vince > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University > of Chile > >
