January 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] looking for another iterator :)

by Ben Coman

On 22 January 2018 at 00:47, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi Ben and Clement > > I have a collection (a dictionary in my case) and I want to get > maximum 5 bindings out of it and iterate on them. > I want keysAndValuesDo: or do: but only up to 5 elements. > > aDict atMax: 5 do: [:each | ] "atMax" sound a bit like comparison rather than counting. Perhaps better would be... aDict atMost: 5 do: [:each | ] "or" aDict for: 5 do: [:each | ] but rather than introduce three or more messages... aDict atMost: 5 do: [:each| ... ] aDict atMost: 5 select: [:each| ... ] aDict atMost: 5 collect: [:each| ... ] why not introduce just one method?.... (aDict any: 5) do: [:each| ... ] (aDict any: 5) select: [:each| ... ] (aDict any: 5) collect: [:each| ... ] cheers -ben > So I learned from:to:do: > > aCollection atMax: 5 do: [:each | ] > > Does it make sense? > > Stef > > On Sun, Jan 21, 2018 at 1:16 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> I don't think we do. Do you need it on SequenceableCollection or >> HashedCollection too ? >> >> Recently I was trying to iterate over the first N elements of a collection >> and since there was no #first:do: I used #from:to:do:. I guess you could use >> that too: >> >> aCollection from: 1 to: (aCollection size min: 1000) do: aBlock >> >> Which guarantees you iterate at max over 1000 elements. But that API is >> SequenceableCollection specific. >> >> On Sun, Jan 21, 2018 at 11:44 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> On 21 January 2018 at 18:36, Stephane Ducasse <stepharo.self(a)gmail.com> >>> wrote: >>> > Hi >>> > >>> > I would like to iterate at max on a certain amount of elements in a >>> > collection. >>> > And I was wondering if we have such iterator. >>> >>> I'm not clear what functionality your asking for. Could you present >>> it as code & result if you assumed the iterator you want was >>> available? >>> >>> cheers -ben >>> >> >> >> >> -- >> ClÃ©ment BÃ©ra >> Pharo consortium engineer >> https://clementbera.wordpress.com/ >> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >

Jan. 22, 2018

Re: [Pharo-users] looking for another iterator :)

by Richard Sargent

SomeCollection every: 5 do: [:subset | subset collect: [:each | ...]] etc. If you want the first five only, return from the do: block. Possibly, #every: by itself answers an iterator / collection conforming instance. On Jan 21, 2018 14:47, "James Foster" <Smalltalk(a)jgfoster.net> wrote: > Since âatMax:â doesnât seem as clear to me, Iâd prefer âupToMax:â or > âwithMax:â or (especially) the following: > > upTo: anInteger timesDo: aBlock > upTo: anInteger timesSelect: aBlock > upTo: anInteger timesCollect: aBlock > > James Foster > > > On Jan 21, 2018, at 8:56 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > I thought about something like that... > > > > SequenceableCollection >> atMax: numberOfItems do: aBlock > > "Execute the iteration with at the maximum numberOfItems. If the > > receiver contains less than numberOfItems iterate them all." > > 1 to: (numberOfItems min: self size) do: [:index | aBlock value: > > (self at: index)] > > > > This is an abstraction that we need to treat some samples. > > > > Stef > > > > On Sun, Jan 21, 2018 at 5:47 PM, Stephane Ducasse > > <stepharo.self(a)gmail.com> wrote: > >> Hi Ben and Clement > >> > >> I have a collection (a dictionary in my case) and I want to get > >> maximum 5 bindings out of it and iterate on them. > >> I want keysAndValuesDo: or do: but only up to 5 elements. > >> > >> aDict atMax: 5 do: [:each | ] > >> > >> So I learned from:to:do: > >> > >> aCollection atMax: 5 do: [:each | ] > >> > >> Does it make sense? > >> > >> Stef > >> > >> On Sun, Jan 21, 2018 at 1:16 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >>> I don't think we do. Do you need it on SequenceableCollection or > >>> HashedCollection too ? > >>> > >>> Recently I was trying to iterate over the first N elements of a > collection > >>> and since there was no #first:do: I used #from:to:do:. I guess you > could use > >>> that too: > >>> > >>> aCollection from: 1 to: (aCollection size min: 1000) do: aBlock > >>> > >>> Which guarantees you iterate at max over 1000 elements. But that API is > >>> SequenceableCollection specific. > >>> > >>> On Sun, Jan 21, 2018 at 11:44 AM, Ben Coman <btc(a)openinworld.com> > wrote: > >>>> > >>>> On 21 January 2018 at 18:36, Stephane Ducasse < > stepharo.self(a)gmail.com> > >>>> wrote: > >>>>> Hi > >>>>> > >>>>> I would like to iterate at max on a certain amount of elements in a > >>>>> collection. > >>>>> And I was wondering if we have such iterator. > >>>> > >>>> I'm not clear what functionality your asking for. Could you present > >>>> it as code & result if you assumed the iterator you want was > >>>> available? > >>>> > >>>> cheers -ben > >>>> > >>> > >>> > >>> > >>> -- > >>> ClÃ©ment BÃ©ra > >>> Pharo consortium engineer > >>> https://clementbera.wordpress.com/ > >>> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > > > > > >

Jan. 22, 2018

Re: [Pharo-users] looking for another iterator :)

by James Foster

Since âatMax:â doesnât seem as clear to me, Iâd prefer âupToMax:â or âwithMax:â or (especially) the following: upTo: anInteger timesDo: aBlock upTo: anInteger timesSelect: aBlock upTo: anInteger timesCollect: aBlock James Foster > On Jan 21, 2018, at 8:56 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I thought about something like that... > > SequenceableCollection >> atMax: numberOfItems do: aBlock > "Execute the iteration with at the maximum numberOfItems. If the > receiver contains less than numberOfItems iterate them all." > 1 to: (numberOfItems min: self size) do: [:index | aBlock value: > (self at: index)] > > This is an abstraction that we need to treat some samples. > > Stef > > On Sun, Jan 21, 2018 at 5:47 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Hi Ben and Clement >> >> I have a collection (a dictionary in my case) and I want to get >> maximum 5 bindings out of it and iterate on them. >> I want keysAndValuesDo: or do: but only up to 5 elements. >> >> aDict atMax: 5 do: [:each | ] >> >> So I learned from:to:do: >> >> aCollection atMax: 5 do: [:each | ] >> >> Does it make sense? >> >> Stef >> >> On Sun, Jan 21, 2018 at 1:16 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> I don't think we do. Do you need it on SequenceableCollection or >>> HashedCollection too ? >>> >>> Recently I was trying to iterate over the first N elements of a collection >>> and since there was no #first:do: I used #from:to:do:. I guess you could use >>> that too: >>> >>> aCollection from: 1 to: (aCollection size min: 1000) do: aBlock >>> >>> Which guarantees you iterate at max over 1000 elements. But that API is >>> SequenceableCollection specific. >>> >>> On Sun, Jan 21, 2018 at 11:44 AM, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> On 21 January 2018 at 18:36, Stephane Ducasse <stepharo.self(a)gmail.com> >>>> wrote: >>>>> Hi >>>>> >>>>> I would like to iterate at max on a certain amount of elements in a >>>>> collection. >>>>> And I was wondering if we have such iterator. >>>> >>>> I'm not clear what functionality your asking for. Could you present >>>> it as code & result if you assumed the iterator you want was >>>> available? >>>> >>>> cheers -ben >>>> >>> >>> >>> >>> -- >>> ClÃ©ment BÃ©ra >>> Pharo consortium engineer >>> https://clementbera.wordpress.com/ >>> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > >

Jan. 21, 2018

Re: [Pharo-users] [Moose-dev] feenk log

by Tudor Girba

Hi, > On Jan 21, 2018, at 10:37 PM, Ben Coman <btc(a)openInWorld.com> wrote: > > On 21 January 2018 at 23:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> There is a difference in performance. The Announcement is slower (about 2-3x slower). However, for 1M events the difference is measured in a 200-400ms, which is very small. > > So you mean each event <1ms difference? > btw, what is the biggest usage of events? I guess mouse movements? > How many such events typically in 1 second of movement? > How is performance on StackInterpreter VM? > I guess we should keep that performant for platforms lacking JIT like > iPads, etcâ¦ It depends on the scene. We are still looking into how to evaluate this. Thatâs why we still have both implementations around. >> The benefit of using Announcement is that we can reuse the tooling around Announcement, such as blogging and debugging. > > This looks really useful. Can you describe the difference between the > red and blue lines in the picture of the first link? Each event goes through two passes, like in JavaScript: - The first is called âcapturingâ (or filtering) and goes from the root to the leaf. This is to allow a parent to prevent a child to react to an event. - The second one is called âbubblingâ (or handling) and goes from the leaf to the root. This is to find the most specific element to handle the event. Cheers, Tudor > cheers -ben > >> >> Still, the way it is used in Bloc is different from the typical usage in that Bloc registers to all Events (which are Announcements) and then dispatches through them to specific Element method (like BlEventListener>>clickEvent:). Still the cool thing is that you also can still register from the outside to a specific event using a normal when:do:. >> >> We will write a piece of doc about it. >> >> Cheers, >> Tudor >> >> >>> On Jan 21, 2018, at 4:46 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> this looks really cool. >>> For the event I remember the discussion with glenn about the difference and I forgot. >>> >>> Stef >>> >>>> On 21 Jan 2018, at 15:54, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> Hi, >>>> >>>> Here is an update of the work on Bloc and GT. As always, please do let us know what you think. >>>> >>>> Bloc: >>>> - Eventing saw a deep overhaul. They are now dispatched using the Announcements engine. The previous mechanism is still in place in order to help people compare the impact. In the process, we also cleaned the propagation of events, and we made them debuggable through inspector extensions: >>>> https://twitter.com/feenkcom/status/955086133519618048 >>>> https://twitter.com/feenkcom/status/946482609680539649 >>>> - Embedding Bloc elements in Morphic is even easier now: >>>> https://twitter.com/feenkcom/status/946676667002556416 >>>> - We continued the work towards an interactive creation of a graphical scene: >>>> https://twitter.com/feenkcom/status/948492946541858816 >>>> - Theme experiment >>>> >>>> GT: >>>> - The documentation of Mondrian is available when you download the code and can be viewed using GT Documenter: >>>> https://twitter.com/feenkcom/status/939394586115563520 >>>> - The Mondrian extensions of BlElement are now extracted in a more general package that enables Bloc elements to be used in graph scenes. >>>> >>>> Have fun, >>>> The feenk team >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Obvious things are difficult to teach." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> -------------------------------------------- >>> StÃ©phane Ducasse >>> http://stephane.ducasse.free.fr >>> http://www.synectique.eu / http://www.pharo.org >>> 03 59 35 87 52 >>> Assistant: Julie Jonas >>> FAX 03 59 57 78 50 >>> TEL 03 59 35 86 16 >>> S. Ducasse - Inria >>> 40, avenue Halley, >>> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >>> Villeneuve d'Ascq 59650 >>> France >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Beauty is where we see it." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."

Jan. 21, 2018

Re: [Pharo-users] looking for another iterator :)

by Ben Coman

On 22 January 2018 at 00:47, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi Ben and Clement > > I have a collection (a dictionary in my case) and I want to get > maximum 5 bindings out of it and iterate on them. > I want keysAndValuesDo: or do: but only up to 5 elements. > > aDict atMax: 5 do: [:each | ] > > So I learned from:to:do: > > aCollection atMax: 5 do: [:each | ] > > Does it make sense? Just some random thoughts. Perhaps something more generic... aDict doN: [ :each :n | aCollection add: each] while: [ :each :n | n <=5 ] For #select: & #collect: there is a distinction to make whether it is 5 elements processed or 5 elements returned. aDict select: [ :each | "do something" ] while: [ :iterator | iterator selectedCount <= 5 ]. "or..." [ :iterator | iterator processedCount <= 5 ]. "or..." [ :iterator | (iterator element ~= "breakElement") cheers -ben > Stef > > On Sun, Jan 21, 2018 at 1:16 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> I don't think we do. Do you need it on SequenceableCollection or >> HashedCollection too ? >> >> Recently I was trying to iterate over the first N elements of a collection >> and since there was no #first:do: I used #from:to:do:. I guess you could use >> that too: >> >> aCollection from: 1 to: (aCollection size min: 1000) do: aBlock >> >> Which guarantees you iterate at max over 1000 elements. But that API is >> SequenceableCollection specific. >> >> On Sun, Jan 21, 2018 at 11:44 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> On 21 January 2018 at 18:36, Stephane Ducasse <stepharo.self(a)gmail.com> >>> wrote: >>> > Hi >>> > >>> > I would like to iterate at max on a certain amount of elements in a >>> > collection. >>> > And I was wondering if we have such iterator. >>> >>> I'm not clear what functionality your asking for. Could you present >>> it as code & result if you assumed the iterator you want was >>> available? >>> >>> cheers -ben >>> >> >> >> >> -- >> ClÃ©ment BÃ©ra >> Pharo consortium engineer >> https://clementbera.wordpress.com/ >> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >

Jan. 21, 2018

Re: [Pharo-users] [Moose-dev] Re: feenk log

by Ben Coman

On 21 January 2018 at 23:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > There is a difference in performance. The Announcement is slower (about 2-3x slower). However, for 1M events the difference is measured in a 200-400ms, which is very small. So you mean each event <1ms difference? btw, what is the biggest usage of events? I guess mouse movements? How many such events typically in 1 second of movement? How is performance on StackInterpreter VM? I guess we should keep that performant for platforms lacking JIT like iPads, etc... > The benefit of using Announcement is that we can reuse the tooling around Announcement, such as blogging and debugging. This looks really useful. Can you describe the difference between the red and blue lines in the picture of the first link? cheers -ben > > Still, the way it is used in Bloc is different from the typical usage in that Bloc registers to all Events (which are Announcements) and then dispatches through them to specific Element method (like BlEventListener>>clickEvent:). Still the cool thing is that you also can still register from the outside to a specific event using a normal when:do:. > > We will write a piece of doc about it. > > Cheers, > Tudor > > >> On Jan 21, 2018, at 4:46 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> this looks really cool. >> For the event I remember the discussion with glenn about the difference and I forgot. >> >> Stef >> >>> On 21 Jan 2018, at 15:54, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> Here is an update of the work on Bloc and GT. As always, please do let us know what you think. >>> >>> Bloc: >>> - Eventing saw a deep overhaul. They are now dispatched using the Announcements engine. The previous mechanism is still in place in order to help people compare the impact. In the process, we also cleaned the propagation of events, and we made them debuggable through inspector extensions: >>> https://twitter.com/feenkcom/status/955086133519618048 >>> https://twitter.com/feenkcom/status/946482609680539649 >>> - Embedding Bloc elements in Morphic is even easier now: >>> https://twitter.com/feenkcom/status/946676667002556416 >>> - We continued the work towards an interactive creation of a graphical scene: >>> https://twitter.com/feenkcom/status/948492946541858816 >>> - Theme experiment >>> >>> GT: >>> - The documentation of Mondrian is available when you download the code and can be viewed using GT Documenter: >>> https://twitter.com/feenkcom/status/939394586115563520 >>> - The Mondrian extensions of BlElement are now extracted in a more general package that enables Bloc elements to be used in graph scenes. >>> >>> Have fun, >>> The feenk team >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Obvious things are difficult to teach." >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr >> http://www.synectique.eu / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Julie Jonas >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.tudorgirba.com > www.feenk.com > > "Beauty is where we see it." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Jan. 21, 2018

Re: [Pharo-users] Aare questions

by Stephan Eggermont

CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Yes sure. But at this is an important requirement for me, I prefer to > talk about it first :) Distributed systems design is a different subject. Different constraints, different solutions. Stephan

Jan. 21, 2018

Re: [Pharo-users] Aare questions

by Stephane Ducasse

Ok so we redid everything in parallel. Too bad anyway I will continue and my changes are in my clone. I will update the booklet once I get it. Stef On Sun, Jan 21, 2018 at 6:05 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > > HI cedrick > > > I tried to start a booklet with Stephane but it is too complicated right > now. Stephane started a simpler version. > > > For now saving and loading is not important. :) > > > Yes > > > > I put below a summary of the reflexion/discussion I had with Max. > > > Thanks. > Now you should publish your code. > I would have preferred to work from a working code. Because now it is > like poking in the dark. > > Cedrick what did you get running? > > > Actually, I got the workflow working and the tests as you. And then I was > able to run some examples (as I tried to wrote in the booklet). > > I just dinât know yet how to publish on GitHub and friendsâ¦ I discussed with > Max about thenâ¦ Iâm learned a bit after how to use these tools especially > for the booklet as we chattedâ¦. > Then end of the semesterâ¦. No timeâ¦. Should be better soon. > > So sorry for that :) > > I join the last pdf I hadâ¦. Fuzzy (especially since I tried to include > automatically classes comments) but there are details of installation and > what I could make work: > > > - rethink persistence (process definition and orchestration, realization) > > => persistance is essential and was central to Aare. Beside removing > Omnibase references (and implication of WfManagedObject), some of the > application features were very dependant on the persistence (like logging, > tracing process evolution). All of these features are to be thing again > considering as much as possible a loosely coupled solution. A general > purpose storage solution like Voyage could be used. At first, in image > storage will be used to focus on the running aspects of the library. > - rethink interaction > => Designing a general interaction sub-system is probably the more > challenging tasks. Aare was web based. We want workflow to be UI agnostic. > Moreover, we want to associate , > remove Magritte (replace UI or build an independant system based on > Annoucement for instance) > > > > Yes I agree. Now I would like to be able to > - define a super simple workflow: I picked sequence: start -> task1 -> task2 > > > Done in WfWorkflowLibrary (with convenience method). An example in 2.4 > > > > > - execute it and script it resolution. > > > See 2.5. > > My way of running them and where I stopped and is a bit stuck. > > To me we need now to design an interaction model (based on Annoucement ?) > > > > Running a workflow. > > Once a workflow is defined, to be executed, he calls the method #executeIn- > newFrame. This method instanciate and populate the worklist (WfWorklist) > that keep track of the state of the running workflow. > > workflow := WfWorkflowLibrary simpleBranch. > frame := workflow executeInNewFrame. > > To see running activitions (activities that are started but not completed > yet): > > frame worklist running. > > Once a activation is over, it has to be completed by sending the message > #completed. For now, there are only manual completions but we could imag- > ine in the future automatic or semi-atomatic completion based on extrenal > interaction or if delegated to a program for instance. > > anActivation := frame worklist any. > anActivation complete. "complete mannully one activation" > "or" > frame complete: anActivation. > > The workflow is running until there are no possible (accessible) activation > left. This state is called implicit termination and can be checked with: > > frame isCompleted. > > Here is the code of the WfFrameÂ»>completeAll > > WfFrame>>>completeAll > [self workList allRunning isEmpty] whileFalse: > > [self completeActivation: self workList allRunning first]. > > > > > > I would like to understand the difference between frame and activation. > > > The frame is the container of the workflow resolution, the Â« manager Â» â¦ A > workflow runs in a frame (subworkflows in subframes)â¦ > > Activations are when a step (one activity defined in a workflow) is > activated (we are starting for real to do the activity). > > > > WfWorkflowManager managers workflow definitions > > (static) and activations (dynamic). > WfFrame is also a part of the dynamic side, connecting activations to a > workflow. > Workflows are hierarchical, i.e. a step can have a sub workflow (see > WfWorkflowLibrary>>simpleSubflow) > > > Yes for now I do not want to understand this part. > > > You have too to get the workflow running I think. > > > > > 3) > > Going back to activations, here is my current understanding. > > Once a step is activated (all condition on Edges leading to are true - to > evaluate outgoing conditions of a step, the step execution has to be > complete first) , we get an activation instance (Iâm not 100% sure how > completion of an activity and outgoing conditions are managed). > > As far as I understand, a step can always be activated (e.g. manually). > However, activating a step propagates the values of conditions on the edges > to the next steps and their activations ("dead" or "alive"). Hence, an > activation responds to #isAlive with true if at leat one incoming token was > true ("alive") (see WfStep>>continueInFrame:fromStep:alive: and > WfActivation>>isAlive). The conditions are evaluated once #complete is sent > to the activation. > Activation instances are created by two ways (slightly different for the > start step), but generally they are created when a step receives tokens from > the outgoing edges of an upstream activation (see > WfStep>>continueInFrame:fromStep:alive:). > > > Activations are central. > > > > On the exemple of BLActivationHistoryItem that you gave, Iâm not sure if > itâs an activation of a history item stored in the history (subclasss of > WfHistory?). > > My idea was that it should represent a record for an activation (there might > be multiple records for a single activation). So "HistoryItem" would be the > general description of a record, of which "ActivationHistoryItem" is a > special case for activations (I hope that makes sense). > > > 4) > Moreover I donât see clearly the difference with a scheduler and a BP engine > (they are at least really complementary). Do you see any ressemblance > between Activation and ScheduledJob ? > > I actually would like to have a (simple) scheduler with the BP engine :) > > Well, it's certainly a matter of point of view. I would argue that an > activation is something close to a "job". A "scheduled job" would be a more > specific case of a "job", a job that is in a queue. An activation has no > notion of scheduling but simply represents the idea of what happens when > traversal between two nodes occurs. A scheduler would be one way of managing > activations (WfWorklist seems pretty close to a scheduler, holding running > and completed activations). > > > > Too subtle for me. > > > For now, the are no real workflow engine. More a state machine providing > access to activable steps (and running oneâ¦ hence remaining ones). > > I/We will need a scheduler (even simple ones). > > Max explains below: > > > > To me the scheduler right now is not really existing besides having a list > of simultaneous/parralelized steps to realize (activated or not). Activated > means currently being done. > > You're right, I think. The application that Workflow was designed for > required manual interaction, hence there was no need for other methods of > scheduling (e.g. by time or event). > > > > This activation role is about logging and interacting with responsible > users. But it is more than that. Itâs the actual job being done. > > Yes. > > > > 5) > > Concerning run time modification of a process. Is it true that we can modify > a currently executed workflow (steps that are not yet activated ?) ? I think > that is possible (an cool). When activated, it shouldnât. Would you think it > would be interesting to allow activations to be suspended/resume (frozen), > cancelled ? > > The history of workflows consists of copies. The steps of a workflow > reference the workflow they belong to. Therefore, while it is possible to > modify a workflow, modifications do not impact running workflows, as the > steps of that workflow continue to reference the previous version. The model > suggests that it is ok to create a new version of a workflow but not to > modify existing workflows. > > > For now I would like to get a workflow running without modifying it > > > Sure. But again an interesting decision to have first. > > To me, what more interesting is to be able : > - to cancel a task (an activation actually), > - change dynamically the remaining workflow (to adapt)â¦ > - eventually suspend/resume (nice to time track but I also thin itâs not > hard to have) > > I know the second point seems too early but again this is important to > consider now. > > Designs decisions of Aare leaves some room to build more (and constrain its > use). > > > [â¦] > > DomBuilder is a small package for wrapping XML-Parser. I'll publish it so > you can use it. > > > Cedric did you got this package? > > > No but I didnât ask either. Itâs possible to ask Max. But I think first, as > you, we need to be able to run a process. > > > > The XML-Parser package has been significantly modified and > > is now named XMLParser (you can find it in the catalog). You should make the > changes necessary to use the current incarnation of XMLParser (decide for > yourself whether you still need DomBuilder or not). > > > But this is not really important. > > > > Yep. > > Cheers, > > CÃ©drick > >

Jan. 21, 2018

Re: [Pharo-users] Aare questions

by CÃ©drick BÃ©ler

> > HI cedrick > > >> I tried to start a booklet with Stephane but it is too complicated right >> now. Stephane started a simpler version. > > For now saving and loading is not important. :) Yes > > >> I put below a summary of the reflexion/discussion I had with Max. > > Thanks. > Now you should publish your code. > I would have preferred to work from a working code. Because now it is > like poking in the dark. > > Cedrick what did you get running? Actually, I got the workflow working and the tests as you. And then I was able to run some examples (as I tried to wrote in the booklet). I just dinât know yet how to publish on GitHub and friendsâ¦ I discussed with Max about thenâ¦ Iâm learned a bit after how to use these tools especially for the booklet as we chattedâ¦. Then end of the semesterâ¦. No timeâ¦. Should be better soon. So sorry for that :) I join the last pdf I hadâ¦. Fuzzy (especially since I tried to include automatically classes comments) but there are details of installation and what I could make work: >> - rethink persistence (process definition and orchestration, realization) >> => persistance is essential and was central to Aare. Beside removing >> Omnibase references (and implication of WfManagedObject), some of the >> application features were very dependant on the persistence (like logging, >> tracing process evolution). All of these features are to be thing again >> considering as much as possible a loosely coupled solution. A general >> purpose storage solution like Voyage could be used. At first, in image >> storage will be used to focus on the running aspects of the library. >> - rethink interaction >> => Designing a general interaction sub-system is probably the more >> challenging tasks. Aare was web based. We want workflow to be UI agnostic. >> Moreover, we want to associate , >> remove Magritte (replace UI or build an independant system based on >> Annoucement for instance) > > > Yes I agree. Now I would like to be able to > - define a super simple workflow: I picked sequence: start -> task1 -> task2 Done in WfWorkflowLibrary (with convenience method). An example in 2.4 > - execute it and script it resolution. See 2.5. My way of running them and where I stopped and is a bit stuck. To me we need now to design an interaction model (based on Annoucement ?) Running a workflow. Once a workflow is defined, to be executed, he calls the method #executeIn- newFrame. This method instanciate and populate the worklist (WfWorklist) that keep track of the state of the running workflow. workflow := WfWorkflowLibrary simpleBranch. frame := workflow executeInNewFrame. To see running activitions (activities that are started but not completed yet): frame worklist running. Once a activation is over, it has to be completed by sending the message #completed. For now, there are only manual completions but we could imag- ine in the future automatic or semi-atomatic completion based on extrenal interaction or if delegated to a program for instance. anActivation := frame worklist any. anActivation complete. "complete mannully one activation" "or" frame complete: anActivation. The workflow is running until there are no possible (accessible) activation left. This state is called implicit termination and can be checked with: frame isCompleted. Here is the code of the WfFrameÂ»>completeAll WfFrame>>>completeAll [self workList allRunning isEmpty] whileFalse: [self completeActivation: self workList allRunning first]. > > I would like to understand the difference between frame and activation. The frame is the container of the workflow resolution, the Â« manager Â» â¦ A workflow runs in a frame (subworkflows in subframes)â¦ Activations are when a step (one activity defined in a workflow) is activated (we are starting for real to do the activity). > > WfWorkflowManager managers workflow definitions >> (static) and activations (dynamic). >> WfFrame is also a part of the dynamic side, connecting activations to a >> workflow. >> Workflows are hierarchical, i.e. a step can have a sub workflow (see >> WfWorkflowLibrary>>simpleSubflow) > > Yes for now I do not want to understand this part. You have too to get the workflow running I think. > >> >> 3) >> >> Going back to activations, here is my current understanding. >> >> Once a step is activated (all condition on Edges leading to are true - to >> evaluate outgoing conditions of a step, the step execution has to be >> complete first) , we get an activation instance (Iâm not 100% sure how >> completion of an activity and outgoing conditions are managed). >> >> As far as I understand, a step can always be activated (e.g. manually). >> However, activating a step propagates the values of conditions on the edges >> to the next steps and their activations ("dead" or "alive"). Hence, an >> activation responds to #isAlive with true if at leat one incoming token was >> true ("alive") (see WfStep>>continueInFrame:fromStep:alive: and >> WfActivation>>isAlive). The conditions are evaluated once #complete is sent >> to the activation. >> Activation instances are created by two ways (slightly different for the >> start step), but generally they are created when a step receives tokens from >> the outgoing edges of an upstream activation (see >> WfStep>>continueInFrame:fromStep:alive:). Activations are central. >> >> >> On the exemple of BLActivationHistoryItem that you gave, Iâm not sure if >> itâs an activation of a history item stored in the history (subclasss of >> WfHistory?). >> >> My idea was that it should represent a record for an activation (there might >> be multiple records for a single activation). So "HistoryItem" would be the >> general description of a record, of which "ActivationHistoryItem" is a >> special case for activations (I hope that makes sense). >> >> >> 4) >> Moreover I donât see clearly the difference with a scheduler and a BP engine >> (they are at least really complementary). Do you see any ressemblance >> between Activation and ScheduledJob ? >> >> I actually would like to have a (simple) scheduler with the BP engine :) >> >> Well, it's certainly a matter of point of view. I would argue that an >> activation is something close to a "job". A "scheduled job" would be a more >> specific case of a "job", a job that is in a queue. An activation has no >> notion of scheduling but simply represents the idea of what happens when >> traversal between two nodes occurs. A scheduler would be one way of managing >> activations (WfWorklist seems pretty close to a scheduler, holding running >> and completed activations). > > > Too subtle for me. For now, the are no real workflow engine. More a state machine providing access to activable steps (and running oneâ¦ hence remaining ones). I/We will need a scheduler (even simple ones). Max explains below: > > >> To me the scheduler right now is not really existing besides having a list >> of simultaneous/parralelized steps to realize (activated or not). Activated >> means currently being done. >> >> You're right, I think. The application that Workflow was designed for >> required manual interaction, hence there was no need for other methods of >> scheduling (e.g. by time or event). >> >> >> >> This activation role is about logging and interacting with responsible >> users. But it is more than that. Itâs the actual job being done. >> >> Yes. >> >> >> >> 5) >> >> Concerning run time modification of a process. Is it true that we can modify >> a currently executed workflow (steps that are not yet activated ?) ? I think >> that is possible (an cool). When activated, it shouldnât. Would you think it >> would be interesting to allow activations to be suspended/resume (frozen), >> cancelled ? >> >> The history of workflows consists of copies. The steps of a workflow >> reference the workflow they belong to. Therefore, while it is possible to >> modify a workflow, modifications do not impact running workflows, as the >> steps of that workflow continue to reference the previous version. The model >> suggests that it is ok to create a new version of a workflow but not to >> modify existing workflows. > > For now I would like to get a workflow running without modifying it Sure. But again an interesting decision to have first. To me, what more interesting is to be able : - to cancel a task (an activation actually), - change dynamically the remaining workflow (to adapt)â¦ - eventually suspend/resume (nice to time track but I also thin itâs not hard to have) I know the second point seems too early but again this is important to consider now. Designs decisions of Aare leaves some room to build more (and constrain its use). [â¦] >> DomBuilder is a small package for wrapping XML-Parser. I'll publish it so >> you can use it. > > Cedric did you got this package? No but I didnât ask either. Itâs possible to ask Max. But I think first, as you, we need to be able to run a process. > > > The XML-Parser package has been significantly modified and >> is now named XMLParser (you can find it in the catalog). You should make the >> changes necessary to use the current incarnation of XMLParser (decide for >> yourself whether you still need DomBuilder or not). > > But this is not really important. > >> Yep. Cheers, CÃ©drick

Jan. 21, 2018

Re: [Pharo-users] looking for another iterator :)

by Stephane Ducasse

Now an iterator getting atMax: x elements could be better because we could them combined it with collect:, detect:... Stef On Sun, Jan 21, 2018 at 5:56 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I thought about something like that... > > SequenceableCollection >> atMax: numberOfItems do: aBlock > "Execute the iteration with at the maximum numberOfItems. If the > receiver contains less than numberOfItems iterate them all." > 1 to: (numberOfItems min: self size) do: [:index | aBlock value: > (self at: index)] > > This is an abstraction that we need to treat some samples. > > Stef > > On Sun, Jan 21, 2018 at 5:47 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Hi Ben and Clement >> >> I have a collection (a dictionary in my case) and I want to get >> maximum 5 bindings out of it and iterate on them. >> I want keysAndValuesDo: or do: but only up to 5 elements. >> >> aDict atMax: 5 do: [:each | ] >> >> So I learned from:to:do: >> >> aCollection atMax: 5 do: [:each | ] >> >> Does it make sense? >> >> Stef >> >> On Sun, Jan 21, 2018 at 1:16 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> I don't think we do. Do you need it on SequenceableCollection or >>> HashedCollection too ? >>> >>> Recently I was trying to iterate over the first N elements of a collection >>> and since there was no #first:do: I used #from:to:do:. I guess you could use >>> that too: >>> >>> aCollection from: 1 to: (aCollection size min: 1000) do: aBlock >>> >>> Which guarantees you iterate at max over 1000 elements. But that API is >>> SequenceableCollection specific. >>> >>> On Sun, Jan 21, 2018 at 11:44 AM, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> On 21 January 2018 at 18:36, Stephane Ducasse <stepharo.self(a)gmail.com> >>>> wrote: >>>> > Hi >>>> > >>>> > I would like to iterate at max on a certain amount of elements in a >>>> > collection. >>>> > And I was wondering if we have such iterator. >>>> >>>> I'm not clear what functionality your asking for. Could you present >>>> it as code & result if you assumed the iterator you want was >>>> available? >>>> >>>> cheers -ben >>>> >>> >>> >>> >>> -- >>> ClÃ©ment BÃ©ra >>> Pharo consortium engineer >>> https://clementbera.wordpress.com/ >>> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Jan. 21, 2018