May 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by Ronie Salgado

Hi kilon, Some weeks ago I tried the C live programming technique for the Ludum Dare. It works very well. For that occasion I wrote this short article https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-worl… . The game ended pretty well in my opinion: https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world . Why C++ coders still endure long compile times when they could test code in > an instant through live coding ? Well in games C++ live coding is actually > very popular, so some are already aware of the huge advantages of live > coding. > I work for a video game company that is using Unreal Engine 4, we do not use the C++ live coding features. I do not like the way that they implemented live coding, and the bindings for their Blueprint visual language. We all hate the long compilation times of UE4, the fact that they use their own undocumented makefile system which is using a bunch C# files for building their project. We also do not like the fact that from time to time, we see that we are missing some #includes because of the unity builds that are done by the unreal build system (merging several .cpp before compiling them). > Another shock for me is how simple it is to implement an image file format > for other languages. The shock was that the OS already uses image files > like pharo image that calls them "memory mapped files" they are used for > sharing memory which in turn is what is used for DLLs. The advantage over > the pharo image is that it crash prone, because it is handled by the OS and > not the language or the VM. Which means that even if your app crashes the > image is still saved and you lose no live data which is not the case with > pharo image. The disadvantage is that of course they are not OOP friendly > as the pharo image is and they are not language specific as pharo image is. > The biggest problem of these other language language is the lack of reflection information at runtime. The second other problem, is the lack of #become:, for swapping objects when their data layout changes. Elf files, PE files (.exe, .dll) and other executable formats are process images with a symbol table and relocation metadata. If the operating system allowed to modify in an easy way the symbol table of the current loaded process, it could be even cooler. In Linux, dlopen is implemented in terms of open() and mmap(). Best regards, Ronie 2017-05-10 16:48 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Or BeanShell > > http://www.beanshell.org/ > > or Groovy > https://zeroturnaround.com/rebellabs/scripting-your-java- > application-with-groovy/ > > or Spring-Shell > https://projects.spring.io/spring-shell/ > > Example app I am using (and extending) for Hadoop work: > https://github.com/sequenceiq/ambari-shell > > When one looks inside a command, this is something easily achievable with > pragmas. > > https://github.com/sequenceiq/ambari-shell/blob/master/src/ > main/java/com/sequenceiq/ambari/shell/commands/BasicCommands.java > > There is nothing extraordinary in these pieces of tech ("pas de quoi > casser trois pattes Ã un canard" in French). > > But we need our own house in order on the CLI. GSoC time! > > Phil > > > > > On Wed, May 10, 2017 at 7:38 PM, blake watson <dsblakewatson(a)gmail.com> > wrote: > >> There is a Java REPL. You could Google that. >> >> There's also a some kind of commercial hot/live compiler tool called >> "JRebel". Haven't tried it (don't code Java). >> >> On Wed, May 10, 2017 at 4:29 AM, askoh <askoh(a)askoh.com> wrote: >> >>> Kilon: >>> >>> This is revelation to me. I am enduring 10 minute turnaround for every >>> edit I make in *.java, xml, jsp, js files. 4 minute compile and 6 minute >>> web server update. How can I get that shortened to 10 seconds say? What >>> links can help? What search terms to google? >>> >>> Thanks, >>> Aik-Siong Koh >>> >>> On May 10, 2017, at 3:20 AM, kilon.alios [via Smalltalk] <[hidden email] >>> <http:///user/SendEmail.jtp?type=node&node=4946427&i=0>> wrote: >>> >>> Just to remind people here that all languages with long compile times >>> can be avoided live coding style through the use of dynamically linked >>> libraries known as DLLs on windows, shared libraries on linux (*.so) and >>> macos (*.dylib) . Also Swift in particular comes with a live coding >>> environment called "Playgrounds" which is also very flexible. >>> >>> Haskell do not know if they have something similar to Playgrounds but I >>> will be surprise if they do not have something at least inferior. All >>> languages support DLLs including ours. >>> >>> Live coding is actually super easy to implement and believe me I was >>> sceptical about it at first and if I had read this post I am making now I >>> would call me crazy. But after implementing live coding in python, C and >>> C++ , now I am a believer. Of course the real question here is if its that >>> easy why people do not use it . From what I have found out, it has not >>> occurred to them as it did not occur to me. >>> >>> Why C++ coders still endure long compile times when they could test code >>> in an instant through live coding ? Well in games C++ live coding is >>> actually very popular, so some are already aware of the huge advantages of >>> live coding. >>> >>> I think this is an advantage of Pharo , that introduces to live coding, >>> a so simple idea yet so essential without you having to think about it >>> yourself or be already aware of it. >>> >>> With other language you will have to find a tutorial or article that >>> mentions this ability. >>> >>> Another shock for me is how simple it is to implement an image file >>> format for other languages. The shock was that the OS already uses image >>> files like pharo image that calls them "memory mapped files" they are used >>> for sharing memory which in turn is what is used for DLLs. The advantage >>> over the pharo image is that it crash prone, because it is handled by the >>> OS and not the language or the VM. Which means that even if your app >>> crashes the image is still saved and you lose no live data which is not the >>> case with pharo image. The disadvantage is that of course they are not OOP >>> friendly as the pharo image is and they are not language specific as pharo >>> image is. >>> >>> Again I would not have known any of this if I had not been playing with >>> shared memory as an IPC and I also see coders rarely if ever mentioning >>> them. >>> >>> >>> >>> On Wed, May 10, 2017 at 4:09 AM Pierce Ng <[hidden email] >>> <http:///user/SendEmail.jtp?type=node&node=4946404&i=0>> wrote: >>> >>>> On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote: >>>> > I don't know. I do know that I can't use something with the >>>> > ridiculous compile times of Haskell or Swift. That just kills flow >>>> > and productivity. >>>> >>>> You could hop onto an office chair and engage your colleague in sword >>>> fighting. >>>> That's a plus! :-) >>>> >>>> Pierce >>>> >>>> >>> >>> ------------------------------ >>> If you reply to this email, your message will be added to the discussion >>> below: >>> http://forum.world.st/Smalltalkers-will-eventually-win-So-sa >>> ys-this-old-C-programmer-tp4945895p4946404.html >>> To unsubscribe from Smalltalkers will, eventually, win. So says this old >>> C++ programmer., click here. >>> NAML >>> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> >>> >>> >>> ------------------------------ >>> View this message in context: Re: Smalltalkers will, eventually, win. >>> So says this old C++ programmer. >>> <http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-p…> >>> >>> Sent from the Pharo Smalltalk Users mailing list archive >>> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at >>> Nabble.com. >>> >> >> >

May 10, 2017

Re: [Pharo-users] Petri nets and workflow patterns

by Stephane Ducasse

Norbert I know petri nets and I was wondering if you were interested in worklow (as in microworkflow). because I think that a simple extensible workflow library is missing in Pharo Stef On Wed, May 10, 2017 at 6:13 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 10.05.2017 um 17:46 schrieb Serge Stinckwich < > serge.stinckwich(a)gmail.com>: > > > > On Wed, May 10, 2017 at 5:36 PM, Norbert Hartl <norbert(a)hartl.name> > wrote: > >> Are there any resources regarding petri nets or control flowâ¦/workflow > patterns in pharo or smalltalk? > > > > We have done some work with one student of Alexandre about BPMN: > > http://a4bp.com/ > > > I downloaded the app but it opens with a black screen on my Mac laptop. > > > and there is PNTalk also: > > https://github.com/SergeStinckwich/PNTalk > > > Thanks, that is what I was looking for. > > > Long time ago I was able to do process mining from logs and generate > Petri Nets: > > https://www.youtube.com/watch?v=wdf80t32v-0 > > That is really close to what I want to play with. Did you ever encounter > van der Aalst workflow pattern in that context. Do you know any material > comparing the approaches? > > thank you very much, > > Norbert > > >

May 10, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by phil＠highoctane.be

Or BeanShell http://www.beanshell.org/ or Groovy https://zeroturnaround.com/rebellabs/scripting-your-java-application-with-g… or Spring-Shell https://projects.spring.io/spring-shell/ Example app I am using (and extending) for Hadoop work: https://github.com/sequenceiq/ambari-shell When one looks inside a command, this is something easily achievable with pragmas. https://github.com/sequenceiq/ambari-shell/blob/master/src/main/java/com/se… There is nothing extraordinary in these pieces of tech ("pas de quoi casser trois pattes Ã un canard" in French). But we need our own house in order on the CLI. GSoC time! Phil On Wed, May 10, 2017 at 7:38 PM, blake watson <dsblakewatson(a)gmail.com> wrote: > There is a Java REPL. You could Google that. > > There's also a some kind of commercial hot/live compiler tool called > "JRebel". Haven't tried it (don't code Java). > > On Wed, May 10, 2017 at 4:29 AM, askoh <askoh(a)askoh.com> wrote: > >> Kilon: >> >> This is revelation to me. I am enduring 10 minute turnaround for every >> edit I make in *.java, xml, jsp, js files. 4 minute compile and 6 minute >> web server update. How can I get that shortened to 10 seconds say? What >> links can help? What search terms to google? >> >> Thanks, >> Aik-Siong Koh >> >> On May 10, 2017, at 3:20 AM, kilon.alios [via Smalltalk] <[hidden email] >> <http:///user/SendEmail.jtp?type=node&node=4946427&i=0>> wrote: >> >> Just to remind people here that all languages with long compile times can >> be avoided live coding style through the use of dynamically linked >> libraries known as DLLs on windows, shared libraries on linux (*.so) and >> macos (*.dylib) . Also Swift in particular comes with a live coding >> environment called "Playgrounds" which is also very flexible. >> >> Haskell do not know if they have something similar to Playgrounds but I >> will be surprise if they do not have something at least inferior. All >> languages support DLLs including ours. >> >> Live coding is actually super easy to implement and believe me I was >> sceptical about it at first and if I had read this post I am making now I >> would call me crazy. But after implementing live coding in python, C and >> C++ , now I am a believer. Of course the real question here is if its that >> easy why people do not use it . From what I have found out, it has not >> occurred to them as it did not occur to me. >> >> Why C++ coders still endure long compile times when they could test code >> in an instant through live coding ? Well in games C++ live coding is >> actually very popular, so some are already aware of the huge advantages of >> live coding. >> >> I think this is an advantage of Pharo , that introduces to live coding, a >> so simple idea yet so essential without you having to think about it >> yourself or be already aware of it. >> >> With other language you will have to find a tutorial or article that >> mentions this ability. >> >> Another shock for me is how simple it is to implement an image file >> format for other languages. The shock was that the OS already uses image >> files like pharo image that calls them "memory mapped files" they are used >> for sharing memory which in turn is what is used for DLLs. The advantage >> over the pharo image is that it crash prone, because it is handled by the >> OS and not the language or the VM. Which means that even if your app >> crashes the image is still saved and you lose no live data which is not the >> case with pharo image. The disadvantage is that of course they are not OOP >> friendly as the pharo image is and they are not language specific as pharo >> image is. >> >> Again I would not have known any of this if I had not been playing with >> shared memory as an IPC and I also see coders rarely if ever mentioning >> them. >> >> >> >> On Wed, May 10, 2017 at 4:09 AM Pierce Ng <[hidden email] >> <http:///user/SendEmail.jtp?type=node&node=4946404&i=0>> wrote: >> >>> On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote: >>> > I don't know. I do know that I can't use something with the >>> > ridiculous compile times of Haskell or Swift. That just kills flow >>> > and productivity. >>> >>> You could hop onto an office chair and engage your colleague in sword >>> fighting. >>> That's a plus! :-) >>> >>> Pierce >>> >>> >> >> ------------------------------ >> If you reply to this email, your message will be added to the discussion >> below: >> http://forum.world.st/Smalltalkers-will-eventually-win-So- >> says-this-old-C-programmer-tp4945895p4946404.html >> To unsubscribe from Smalltalkers will, eventually, win. So says this old >> C++ programmer., click here. >> NAML >> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> >> >> >> ------------------------------ >> View this message in context: Re: Smalltalkers will, eventually, win. So >> says this old C++ programmer. >> <http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-p…> >> >> Sent from the Pharo Smalltalk Users mailing list archive >> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at >> Nabble.com. >> > >

May 10, 2017

Glamour Fast List, double click action. Is it supported?

by Juraj Kubelka

Hi! Does Glamour Fast List Presentation allow double click action on a item? I cannot find anything like that. Thanks! Juraj

May 10, 2017

Re: [Pharo-users] Issue with Pillar

by phil＠highoctane.be

Forget about that way which doesn't work. Use this: https://github.com/cdlm/docker-texlive Works nicely and removes 90% of the setup frustration (you'll need latest docker-ce for this to work). Phil On Wed, May 10, 2017 at 5:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > I am trying to get Pillar working on OS X. I followed the instruction > given on https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/ > lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html > > I did: > curl https://raw.githubusercontent.com/pillar-markup/pillar/ > master/download.sh | bash > ./pillar archetype welcome > make book-result/welcome.html > > The two first instruction do not seem to cause any trouble. Work as > expected. The make instruction produces: > -=-=-=-= > /tmp/pillar> make book-result/welcome.html > mkdir -p ./book-result > find . -type d -path ./book-result -prune -o -wholename "*/figures" -exec > cp {} --parents -r ./book-result \; > cp -r support/ ./book-result > ./pillar export --to=html --outputDirectory=./book-result > --outputFile=welcome.pillar welcome.pillar > MessageNotUnderstood: FileReference>>jsonWriteOn: > FileReference(Object)>>doesNotUnderstand: #jsonWriteOn: > [ :assoc | > needComma > ifTrue: [ aStream nextPut: $, ] > ifFalse: [ needComma := true ]. > assoc key jsonWriteOn: aStream. > aStream nextPut: $:. > assoc value jsonWriteOn: aStream ] in Dictionary>>jsonWriteOn: in Block: [ > :assoc | ... > [ :each | each ifNotNil: [ aBlock value: each ] ] in > Dictionary>>associationsDo: in Block: [ :each | each ifNotNil: [ aBlock > value: each ] ] > Array(SequenceableCollection)>>do: > Dictionary>>associationsDo: > Dictionary>>jsonWriteOn: > PRExportPhase>>asJson:withConfiguration: > [ :outStream | > self > writeOutput: (self asJson: output withConfiguration: cocoonConfiguration) > toStream: outStream ] in PRExportPhase>>write:using: in Block: [ > :outStream | ... > [ aBlock value: stream ] in FileReference(AbstractFileReference)>>writeStreamDo: > in Block: [ aBlock value: stream ] > BlockClosure>>ensure: > FileReference(AbstractFileReference)>>writeStreamDo: > FileReference(AbstractFileReference)>>pillarWriteDuring: > PRExportPhase>>outputStreamDuring: > PRExportPhase>>write:using: > PRExportPhase>>actionOn: > PRExportPhase class(PRPhase class)>>executeOn: > [ :input | self executeOn: input ] in PRExportPhase class(PRPhase > class)>>buildPipe: in Block: [ :input | self executeOn: input ] > LPPhase>>executeOn: > [ :subResult :next | next executeOn: subResult ] in LPPipeline>>executeOn: > in Block: [ :subResult :next | next executeOn: subResult ] > [ :each | nextValue := binaryBlock value: nextValue value: each ] in > OrderedCollection(Collection)>>inject:into: in Block: [ :each | nextValue > := binaryBlock value: nextValu...etc... > OrderedCollection>>do: > OrderedCollection(Collection)>>inject:into: > LPPipeline>>executeOn: > PRPillarConfiguration>>export > [ :exporter | (configuration getConfigurationNamed: exporter) export ] in > [ configuration defaultExporters > do: [ :exporter | (configuration getConfigurationNamed: exporter) export ] > ] in PRExportCommandLineHandler>>export in Block: [ :exporter | > (configuration getConfigurationNamed...etc... > Array(SequenceableCollection)>>do: > [ configuration defaultExporters > do: [ :exporter | (configuration getConfigurationNamed: exporter) export ] > ] in PRExportCommandLineHandler>>export in Block: [ configuration > defaultExporters... > BlockClosure>>on:do: > PRExportCommandLineHandler>>export > PRExportCommandLineHandler>>activate > make: *** [book-result/welcome.html.json] Error 1 > rm book-result/welcome.html.json > -=-=-=-= > > Any idea whatâs wrong? > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

May 10, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by blake watson

There is a Java REPL. You could Google that. There's also a some kind of commercial hot/live compiler tool called "JRebel". Haven't tried it (don't code Java). On Wed, May 10, 2017 at 4:29 AM, askoh <askoh(a)askoh.com> wrote: > Kilon: > > This is revelation to me. I am enduring 10 minute turnaround for every > edit I make in *.java, xml, jsp, js files. 4 minute compile and 6 minute > web server update. How can I get that shortened to 10 seconds say? What > links can help? What search terms to google? > > Thanks, > Aik-Siong Koh > > On May 10, 2017, at 3:20 AM, kilon.alios [via Smalltalk] <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=4946427&i=0>> wrote: > > Just to remind people here that all languages with long compile times can > be avoided live coding style through the use of dynamically linked > libraries known as DLLs on windows, shared libraries on linux (*.so) and > macos (*.dylib) . Also Swift in particular comes with a live coding > environment called "Playgrounds" which is also very flexible. > > Haskell do not know if they have something similar to Playgrounds but I > will be surprise if they do not have something at least inferior. All > languages support DLLs including ours. > > Live coding is actually super easy to implement and believe me I was > sceptical about it at first and if I had read this post I am making now I > would call me crazy. But after implementing live coding in python, C and > C++ , now I am a believer. Of course the real question here is if its that > easy why people do not use it . From what I have found out, it has not > occurred to them as it did not occur to me. > > Why C++ coders still endure long compile times when they could test code > in an instant through live coding ? Well in games C++ live coding is > actually very popular, so some are already aware of the huge advantages of > live coding. > > I think this is an advantage of Pharo , that introduces to live coding, a > so simple idea yet so essential without you having to think about it > yourself or be already aware of it. > > With other language you will have to find a tutorial or article that > mentions this ability. > > Another shock for me is how simple it is to implement an image file format > for other languages. The shock was that the OS already uses image files > like pharo image that calls them "memory mapped files" they are used for > sharing memory which in turn is what is used for DLLs. The advantage over > the pharo image is that it crash prone, because it is handled by the OS and > not the language or the VM. Which means that even if your app crashes the > image is still saved and you lose no live data which is not the case with > pharo image. The disadvantage is that of course they are not OOP friendly > as the pharo image is and they are not language specific as pharo image is. > > Again I would not have known any of this if I had not been playing with > shared memory as an IPC and I also see coders rarely if ever mentioning > them. > > > > On Wed, May 10, 2017 at 4:09 AM Pierce Ng <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=4946404&i=0>> wrote: > >> On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote: >> > I don't know. I do know that I can't use something with the >> > ridiculous compile times of Haskell or Swift. That just kills flow >> > and productivity. >> >> You could hop onto an office chair and engage your colleague in sword >> fighting. >> That's a plus! :-) >> >> Pierce >> >> > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C- > programmer-tp4945895p4946404.html > To unsubscribe from Smalltalkers will, eventually, win. So says this old > C++ programmer., click here. > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > > > ------------------------------ > View this message in context: Re: Smalltalkers will, eventually, win. So > says this old C++ programmer. > <http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-p…> > > Sent from the Pharo Smalltalk Users mailing list archive > <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com. >

May 10, 2017

Re: [Pharo-users] Intro to git-only Pharo

by Ben Coman

On Wed, May 10, 2017 at 1:56 PM, Joachim Tuchel <jtuchel(a)objektfabrik.de> wrote: > Hi guys, > > please forgive me if this mail is a sign of ignorance. I am not a regular > Pharo user and one of the reasons for this is that I didn't like most of the > source management tools around Monticello. Coming from an envy background, > it feels like not being ready for prime time. Of course you guys have been > proving you can work with these tools quite well, but still I'd be > interested in using Pharo in a pure git-based environment, as it most > closely resembles some of the most-beloved features of envy. > > Over the years there was a lot of work and discussion on filetree, > gitfiletree, iceberg, cypress and maybe quite a few other projects that > sounded promising and interesting. But I must admit I lost track of what was > really done and how far things went in the last years. > > So are there any pointers to info material that I could look at to see what > the current status of source control in Pharo 5 and Pharo 6 is and/or will > be soon? > > I am mostly interested in these topics: > > git only - no monticello meta info any more - possible? As mentioned in other responses, GitFileTree and Iceberg are operating without Monticello metadata. This has been the case for a while but personally, even to I love to use git for C code, I just haven't managed to make the leap for image-side Pharo. Monticello was "good enough". Probably a lot of people are the same. Now with the coming Pharo 7, Iceberg/git will be the only game in town for "pharo-core contributions". Everyone will be forced to use Iceberg (and personally I welcome this) and there'll be many more eyeballs to polish off any rough edges of the tools and workflow. So *now* in Pharo 7 is an ideal time to start paying attention and to help identify any gaps in requirements for Pharo git tools and workflow. cheers -ben > tools like merge/diff, committing from within the image > dependencies within my own project as well as dependencies on external code > in - possibly multiple - external repositories > what is the current "most official" source repository for open source code? > best practices for managing complex projects and keeping old versions > reproducible at any time > tutorial for git newbies in a Pharo context? (Like, how do I start with a > new packege - create folder first and do git init, or start in the image and > push into repo later? as I said: beginners' stuff) > > Thanks for pointers and help > > > Joachim > >

May 10, 2017

Re: [Pharo-users] Remote Debugger bugs ?

by Denis Kudriashov

2017-05-10 11:16 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > In the end i will embed the remote image in a raspberry pi and access it > remotely, so the ui will (absolutely) not be needed I am currently working on RPI support. I will present it next week. If you want to try: Metacello new smalltalkhubUser: 'Pharo' project: 'IoT'; configuration: 'IoT'; version: #stable; load: 'RemoteToolsServer'. Then from playground evaluate: lib := remotePharo evaluate: [ WiringPiLibrary uniqueInstance]. board := RpiBoardBRev1 driver: (RpiWiringPiDriver lib: lib). board inspect It requires wiringPi external library which I think should be installed by default. Anyway I will publish it next week with more details and demos.

May 10, 2017

Re: [Pharo-users] Petri nets and workflow patterns

by Norbert Hartl

> Am 10.05.2017 um 17:46 schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com>: > > On Wed, May 10, 2017 at 5:36 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> Are there any resources regarding petri nets or control flowâ¦/workflow patterns in pharo or smalltalk? > > We have done some work with one student of Alexandre about BPMN: > http://a4bp.com/ > I downloaded the app but it opens with a black screen on my Mac laptop. > and there is PNTalk also: > https://github.com/SergeStinckwich/PNTalk > Thanks, that is what I was looking for. > Long time ago I was able to do process mining from logs and generate Petri Nets: > https://www.youtube.com/watch?v=wdf80t32v-0 That is really close to what I want to play with. Did you ever encounter van der Aalst workflow pattern in that context. Do you know any material comparing the approaches? thank you very much, Norbert

May 10, 2017

Re: [Pharo-users] Petri nets and workflow patterns

by Serge Stinckwich

On Wed, May 10, 2017 at 5:36 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Are there any resources regarding petri nets or control flowâ¦/workflow patterns in pharo or smalltalk? We have done some work with one student of Alexandre about BPMN: http://a4bp.com/ and there is PNTalk also: https://github.com/SergeStinckwich/PNTalk Long time ago I was able to do process mining from logs and generate Petri Nets: https://www.youtube.com/watch?v=wdf80t32v-0 Regards, -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

May 10, 2017