September 2019 - Pharo-users

Re: [Pharo-users] Loading Seaside and Voyage in Pharo 7.0 64bit

by Paul DeBruicker

Add a onConflict:[:ex | ex allow]; to your load instructions. e.g. Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:v3.4.0/repository'; onConflict:[:ex | ex allow]; load. Metacello new repository: 'github://pharo-nosql/voyage:1.6/mc'; baseline: 'Voyage'; onConflict:[:ex | ex allow]; load: 'mongo tests'. If you're always going to load Voyage after Seaside into a fresh image then you don't need the #onConflict: send in the Seaside load instructions. Having it in both allows you to load them in either order. Jan Äada-2 wrote > Hi, > > I am trying to load Seaside and Voyage to Pharo 7.0 64bit image using > following : > > Metacello new > baseline:'Seaside3'; > repository: 'github://SeasideSt/Seaside:v3.4.0/repository'; > load. > > Metacello new > repository: 'github://pharo-nosql/voyage:1.6/mc'; > baseline: 'Voyage'; > load: 'mongo tests'. > > > I am getting dependency error: > > Load Conflict between existing BaselineOfGrease [baseline] from > github://SeasideSt/Grease:v1.4.x/repository and BaselineOfGrease > [baseline] from github://SeasideSt/Grease:v1.4.3/repository > <github://SeasideSt/Grease:v1.4.3/repository> > > - to me it seems that both Grease versions are in the end same. I see > following in transcript: > Project: Grease Core Tests baseline > Fetched -> Grease-Tests-Core-CompatibleUserName.1554365153 --- > https://github.com/SeasideSt/Grease.git[v1.4.3, v1.4.x] --- > https://github.com/SeasideSt/Grease.git[v1.4.x] > Fetched -> Grease-Tests-Pharo-Core-CompatibleUserName.1554365153 --- > https://github.com/SeasideSt/Grease.git[v1.4.3, v1.4.x] --- > https://github.com/SeasideSt/Grease.git[v1.4.x] > > - I do not insist on Seaside or voyage versions - I just took the latest. > > Can you please help me with resolving this issue ? > > > Thanks, > > Jan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 30, 2019

Re: [Pharo-users] Workflows and possible usages

by Esteban Maringolo

Bruno, There was the MockGemstone package that created "compatible" reduced conflict classes (that provide name compatibility but no RC behavior) and other Gemstone globals (such as System) that you can use. The develop in Pharo deploy in Gemstone is used by a few projects that I'm aware of. As for storing the rules, I rather go with Fuel or GLORP+SQlite. I don't know how complex the object graph can get. But these two options are the most easy to setup, since they have no dependencies and are self contained. Regards, Esteban A. Maringolo On Mon, Sep 30, 2019 at 11:56 AM Smalltalk <smalltalk(a)adinet.com.uy> wrote: > Hi,* > "There was a gemstone workflow engine - itâs not ported, it looked interesting but used a Windows bpml tool and again wasnât sure if it wanted to own the world, and porting it would be more than I wanted to do." > > *I think you are talking about BpmFlow (https://github.com/brunobuzzi/BpmFlow) if not excuse me :) > > A couple of month ago a created an issue for the port (https://github.com/brunobuzzi/BpmFlow/issues/843) to annotate all information related to a possible port. > > The most challenging task is how to persist BpmProcess data within Pharo, use an ORM (GLORP) or use GemStone ? > This task is the most complex. > > But first there are some minor issue to tackle: > * Replace GS ReduceConflict classes with normal Pharo collections. > * GsQuery > - Replace GsQuery with normal blocks > - (or) Find out if GsQuery was ported (or it could be ported) to Pharo > * Replace GS Selection Block with normal Pharo blocks. {:each | each.address.state = 'OR'} > > Develop in Pharo and Deploy in GemStone strategy can be a very good source of information to solve the above issues. > > I use Jade client to directly develop on GemStone/S so a research is needed on "Develop in Pharo and Deploy in GemStone". > > Modeling tools: > The goal is to be able to import any XPDL file exported by any BPMN tool. > For now we use Bizagi but others tools that export to XPDL standard can be added. > This will require some effort but is possible (we do an extensive use of Bizagi extended attributes but if the BPMN tool to be added support some kind of mechanism to add custom attributes to tasks there will be no problem). > > regards, > bruno > >

Sept. 30, 2019

Re: [Pharo-users] Workflows and possible usages

by Smalltalk

Hi, /"There was a gemstone workflow engine - itâs not ported, it looked interesting but used a Windows bpml tool and again wasnât sure if it wanted to own the world, and porting it would be more than I wanted to do." /I think you are talking about BpmFlow (https://github.com/brunobuzzi/BpmFlow) if not excuse me :) A couple of month ago a created an issue for the port (https://github.com/brunobuzzi/BpmFlow/issues/843) to annotate all information related to a possible port. The most challenging task is how to persist BpmProcess data within Pharo, use an ORM (GLORP) or use GemStone ? This task is the most complex. But first there are some minor issue to tackle|: * Replace GS ReduceConflict classes with normal Pharo collections. * GsQuery - Replace GsQuery with normal blocks - |||(or)| Find out if GsQuery was ported (or it could be ported) to Pharo * Replace GS Selection Block with normal Pharo blocks. {:each | each.address.state = 'OR'} Develop in Pharo and Deploy in GemStone strategy can be a very good source of information to solve the above issues. I use Jade client to directly develop on GemStone/S so a research is needed on "|||Develop in Pharo and Deploy in GemStone|". Modeling tools: The goal is to be able to import any XPDL file exported by any BPMN tool. For now we use Bizagi but others tools that export to XPDL standard can be added. This will require some effort but is possible (we do an extensive use of Bizagi extended attributes but if the BPMN tool to be added support some kind of mechanism to add custom attributes to tasks there will be no problem). regards, bruno | //

Sept. 30, 2019

Loading Seaside and Voyage in Pharo 7.0 64bit

by Jan Äada

Hi, I am trying to load Seaside and Voyage to Pharo 7.0 64bit image using following : Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:v3.4.0/repository'; load. Metacello new repository: 'github://pharo-nosql/voyage:1.6/mc'; baseline: 'Voyage'; load: 'mongo tests'. I am getting dependency error: Load Conflict between existing BaselineOfGrease [baseline] from github://SeasideSt/Grease:v1.4.x/repository and BaselineOfGrease [baseline] from github://SeasideSt/Grease:v1.4.3/repository <github://SeasideSt/Grease:v1.4.3/repository> - to me it seems that both Grease versions are in the end same. I see following in transcript: Project: Grease Core Tests baseline Fetched -> Grease-Tests-Core-CompatibleUserName.1554365153 --- https://github.com/SeasideSt/Grease.git[v1.4.3, v1.4.x] --- https://github.com/SeasideSt/Grease.git[v1.4.x] Fetched -> Grease-Tests-Pharo-Core-CompatibleUserName.1554365153 --- https://github.com/SeasideSt/Grease.git[v1.4.3, v1.4.x] --- https://github.com/SeasideSt/Grease.git[v1.4.x] - I do not insist on Seaside or voyage versions - I just took the latest. Can you please help me with resolving this issue ? Thanks, Jan

Sept. 30, 2019

Re: [Pharo-users] Testing "Weekly Digest" for GitHub

by Marcus Denker

> On 23 Jul 2019, at 08:04, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 17 Jul 2019, at 07:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> This seems to have been caused by a faulty config (I really hate YAMLâ¦). >> >> I changed it *and* put the day to be saturday, as they seem to have run into rate limiting >> for the API on Sundays in the past. >> >> So hopefully this will work saturday again. >> > > I finally remove the config file and deinstalled/reinstalled the bot. > > https://github.com/pharo-project/pharo/issues/4024 > > "Last week, 64 pull requests were merged.â > Not very stable these botsâ¦ after some weeks, now we got a report: Weekly Digest (23 September, 2019 - 30 September, 2019) https://github.com/pharo-project/pharo/issues/4767 <https://github.com/pharo-project/pharo/issues/4767> I hope that it will work better the next weeks (it is configured to run modays). Marcus

Sept. 30, 2019

Re: [Pharo-users] Workflows and possible usages

by eftomi

Please see also http://www.workflowpatterns.com/. Historically, BPMN by itself was regarded difficult to automate. BPEL as a workflow language (Oracle SOA, Microsoft BizTalk server) can be interpreted easily by machine, but it is not so easy to learn by the people who have to model the process. There were some effors to make an automatic translation from BPMN to BPEL but it didn't succeed - it was a true challenge, and the platforms that I mentioned in previous email were already coming to the stage, so this idea went downhill. YAWL is another workflow language attempt, however it is not widely accepted, in my opinion from similar reasons as for BPEL. As I said, a possible direction is to go for BPMN. It can be based on Workflow Patterns "behind the scenes". Here's an example of this approach in Python https://github.com/knipknap/SpiffWorkflow. However, the platforms that I mentioned have "... an embeddable, lightweight process engine in Java, supporting native BPMN 2.0 execution ..." (https://en.wikipedia.org/wiki/JBPM) and similar, so a direct support for BPMN 2.0 shouldn't be too difficult after all. One of the advantages to build an engine in Pharo around BPMN is that it would be directly usable by a large community that works on processes digitalization. They understand the processes and the notation. Best wishes, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 30, 2019

Re: [Pharo-users] Workflows and possible usages

by Christopher Fuhrman

On Sun, 29 Sep 2019 at 11:01, Stephan Eggermont <stephan(a)stack.nl> wrote: > Christopher Fuhrman > <christopher.fuhrman(a)etsmtl.ca> wrote: > > On Thu, 26 Sep 2019 at 04:27, Tim Mackinnon > > <tim(a)testit.works> wrote: > >> Anyone have any thoughts or directions to explore? > > > My intuition says that most software projects don't last long enough to > > invest in a general solution to supporting workflows. > > So, is there a causal relationship? And in which direction? > Interesting question, for which I have no answer. At the risk of going off topic, here's more context for my "intuition": I'm talking about startups (or even companies such as Google who have many "beta" projects that will likely die because they're experiments). The goal is a Minimal Viable Product (MVP) first, because many projects (or features?) don't continue for reasons that are often not technical. So spending resources (especially time) on workflow frameworks to support change is possibly a waste until some other (bigger) risks are mitigated. It's a form of YAGNI. The MVP is usually a form of cowboy hacking (hard-coded workflow), and if the project makes it to the next round, the company will manage the technical debt if changes are needed. We as software architects/designers are put off by these kinds of things. Maybe this is the kind of scenario Tim describes in the first post? Technical debt due to brittle design could be a reason a project dies, but I think it's not really the common reason. I believe we as software engineers are biased, because software was less prevalent when the discipline of SE was created. It's still true today that it costs too much to maintain software that lasts a long time. But how many projects last long enough for it to be a problem? A related topic about traditional CS/SE curriculum not being adequate for the context of startups was discussed recently [1]. Cris [1] https://spectrum.ieee.org/the-institute/ieee-member-news/software-engineeri… > Stephan > > > > > > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

Sept. 29, 2019

Re: [Pharo-users] Workflows and possible usages

by eftomi

> Anyone have any thoughts or directions to explore? The main assumption about workflows is that they are easily understood by non-developers, and that non-developers can be involved in the development, within business environments. However, the workflows per-se were not accepted well. For instance, even Microsoft's Windows Workflow Foundation in .NET will not have any future in .NET Core, as it seems. The idea went on, but on a totally different "track" and by different people: today BPMN notation attracts most of the attention. It is being used in business process management, processes design and reingeneering, and it can be directly used in software development, together with use cases. It has it's own role in information architecture frameworks. There are many systems that support a direct SW automation in process-driven development (e. g. Bonita https://www.bonitasoft.com/, ProcessMaker https://www.processmaker.com/, Bizagi https://www.bizagi.com/, jBPM, Joget ... to list just a few). Most influential big players on this were Oracle with SOA & BPM Suite and IBM WebSphere Process Server. Most of these platforms are web based, they have various designers (like process, data, forms designer), and extensive authentication and authorization facilities. They use reliable technologies for database access. So, as for the workflow core engine, I would bet onto BPMN and a direct support for BPMN 2.0 XML standard (https://www.omg.org/oceb-2/documents/BPMN_Interchange.pdf) This would be the core. Just my two cents ... Best wishes, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 29, 2019

Re: Could not resolve: BaselineOfNeoJSON

by Davide Varvello

Hi Cyril, You are right, I updated Metacello and Tonel and everything is fine also on Pharo5. Thx. Davide CyrilFerlicot wrote > Le 29/09/2019 Ã 11:23, Davide Varvello via Pharo-users a Ã©critÂ : > > Hi, > > NoeJSON seems to be saved with the Tonel format. > > Tonel is by default in Pharo since Pharo 6.1. > > It should be possible to update Metacello and Tonel to be able to load > this project in Pharo 4+ > > Here is a pharo-wiki page explaining how to do it: > > https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/… > > Have a nice day! > > -- > Cyril Ferlicot > https://ferlicot.fr > > > > signature.asc (836 bytes) > <http://forum.world.st/attachment/5104639/0/signature.asc> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 29, 2019

Re: [Pharo-users] Workflows and possible usages

by Stephan Eggermont

Christopher Fuhrman <christopher.fuhrman(a)etsmtl.ca> wrote: > On Thu, 26 Sep 2019 at 04:27, Tim Mackinnon > <tim(a)testit.works> wrote: >> Anyone have any thoughts or directions to explore? > My intuition says that most software projects don't last long enough to > invest in a general solution to supporting workflows. So, is there a causal relationship? And in which direction? Stephan

Sept. 29, 2019