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

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

by Serge Stinckwich

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. Yes this is the usual story .... software rots at the end. I guess you are using last version of mac os x and the VM provided on the web site does not work anymore. Give me 3 students and I will change this situation ;-) I want to continue this work but I have to find motivated students. >> 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? I know van der Aalst work but I don't know exactly what do you mean by workflow pattern. The one described here: http://www.workflowpatterns.com/patterns/control/index.php Regards, -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

May 11, 2017

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

by Norbert Hartl

> Am 11.05.2017 um 08:54 schrieb jtuchel(a)objektfabrik.de: > > Hi Norbert, > > thanks for your explanations. > So it seems liek I should start by using Pharo6 and load Iceberg and just take a look. > Yes, iceberg has still some issues but is usable and it will evolve quickly. If you are the brave type of guy you can start with pharo6 64bits ;) Norbert > Joachim > > > > Am 10.05.17 um 10:34 schrieb Norbert Hartl: >> Hi Joachim, >> >> I think your timing is quite good. We had some changes in the last years and it is getting better now. >> Before we had only monticello. Monticello is a zip container that contains a version number in the filename and prior version pointer inside the repository. Regarding dependencies there was nothing that was used widely. Then Metacello appeared and solved the problem by providing dependency management and versioning of dependencies. Dependency management works good, the integrated versioning has issues. Especially when you look at a system like git you can see that versioning is solved there. Filetree is needed because git and other vcs systems are file based so you need to layout your code in files (how quaint!) >> To make a long story short: The best thing to use is git with Metacello Baselines. Filetree is used to store code. Versioning you do with git tags that can be used in Baselines. Now we have a decent UI (iceberg) that supports the most needed workflow items. >> We have a UI for the dependency management as well (versionner) but it sadly targets ConfigurationOfs and not BaselineOfs. That needs to be changed. >> >> my 2 cents, >> >> Norbert >> >>> Am 10.05.2017 um 07:56 schrieb Joachim Tuchel <jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de>>: >>> >>> 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? >>> 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 >>> >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> > Fliederweg 1 http://www.objektfabrik.de <http://www.objektfabrik.de/> > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com <http://joachimtuchel.wordpress.com/> > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >

May 11, 2017

SourceCity

by phil＠highoctane.be

Where can I get a working SourceCity? Even in older Pharo/Moose. I've got a use case for metrics that would be a pretty good fit. Philippe

May 11, 2017

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

by Norbert Hartl

Hi Stef, > Am 10.05.2017 um 22:09 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > 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 I'm interested in workflow but came to petri nets as they are similar. But I don't know what is the real difference between those two. I've read a bit about van der Aalst workflow patterns and a revision of BrÃ¶ger for them. But I know too little of the topic. We have more projects where we choose a state machine in order to properly manage state changes in our applications. In some projects the transitions are simple and clear so that they can be described generically. And that brings me to workflow and petri nets. A more generic approach will lower the amount of code to be written and opens a way to serialize the flow, have a DSL for it or use it together with Roassal. Norbert > Stef > > On Wed, May 10, 2017 at 6:13 PM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > > > Am 10.05.2017 um 17:46 schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>>: > > > > On Wed, May 10, 2017 at 5:36 PM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@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/ <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 <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 <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 11, 2017

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

by jtuchel＠objektfabrik.de

Hi again, seems like I am too early. I just downloaded Pharo-60484 and loaded Iceberg from the Catalog Browser and I get a Walkbacks as answer to almost any click I perform ;-) So I'll better start with the docs suggested in this thread to be ready once Iceberg is ;-) Joachim Am 10.05.17 um 10:34 schrieb Norbert Hartl: > Hi Joachim, > > I think your timing is quite good. We had some changes in the last > years and it is getting better now. > Before we had only monticello. Monticello is a zip container that > contains a version number in the filename and prior version pointer > inside the repository. Regarding dependencies there was nothing that > was used widely. Then Metacello appeared and solved the problem by > providing dependency management and versioning of dependencies. > Dependency management works good, the integrated versioning has > issues. Especially when you look at a system like git you can see that > versioning is solved there. Filetree is needed because git and other > vcs systems are file based so you need to layout your code in files > (how quaint!) > To make a long story short: The best thing to use is git with > Metacello Baselines. Filetree is used to store code. Versioning you do > with git tags that can be used in Baselines. Now we have a decent UI > (iceberg) that supports the most needed workflow items. > We have a UI for the dependency management as well (versionner) but it > sadly targets ConfigurationOfs and not BaselineOfs. That needs to be > changed. > > my 2 cents, > > Norbert > >> Am 10.05.2017 um 07:56 schrieb Joachim Tuchel >> <jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de>>: >> >> 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? >> * 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 >> >> > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

May 11, 2017

Re: [Pharo-users] Glamour Fast List, double click action. Is it supported?

by Esteban Lorenzano

> On 10 May 2017, at 21:00, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > Hi! > > Does Glamour Fast List Presentation allow double click action on a item? > > I cannot find anything like that. it should be âstrongSelectionâ, isnât? Esteban > > Thanks! > Juraj > >

May 11, 2017

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

by jtuchel＠objektfabrik.de

Hi Norbert, thanks for your explanations. So it seems liek I should start by using Pharo6 and load Iceberg and just take a look. Joachim Am 10.05.17 um 10:34 schrieb Norbert Hartl: > Hi Joachim, > > I think your timing is quite good. We had some changes in the last > years and it is getting better now. > Before we had only monticello. Monticello is a zip container that > contains a version number in the filename and prior version pointer > inside the repository. Regarding dependencies there was nothing that > was used widely. Then Metacello appeared and solved the problem by > providing dependency management and versioning of dependencies. > Dependency management works good, the integrated versioning has > issues. Especially when you look at a system like git you can see that > versioning is solved there. Filetree is needed because git and other > vcs systems are file based so you need to layout your code in files > (how quaint!) > To make a long story short: The best thing to use is git with > Metacello Baselines. Filetree is used to store code. Versioning you do > with git tags that can be used in Baselines. Now we have a decent UI > (iceberg) that supports the most needed workflow items. > We have a UI for the dependency management as well (versionner) but it > sadly targets ConfigurationOfs and not BaselineOfs. That needs to be > changed. > > my 2 cents, > > Norbert > >> Am 10.05.2017 um 07:56 schrieb Joachim Tuchel >> <jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de>>: >> >> 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? >> * 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 >> >> > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

May 11, 2017

Re: [Pharo-users] Wandering Through Dependency Hell

by Tudor Girba

Hi, > On May 11, 2017, at 3:55 AM, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > Hi, > > I do not understand much you problem. But reading about your commit strategy, you can use Gofer object and its push method to sync properly local changes to a remote repository. Check Pharo books. There are examples. > > If you inspect a configuration object, there used to be a GT-Inspector extension with dependency visualization. Maybe this is present only in the Moose image. Indeed, this is available in the Moose image by default, but can also be loaded in plain Pharo if you load the complete version of GTInspector. Cheers, Doru > Cheers, > Juraj > > -- > Juraj Kubelka > >> El 09-05-2017, a las 22:42, Evan Donahue <emdonahu(a)gmail.com> escribiÃ³: >> >> Hello, >> >> I was wondering if there was a resource somewhere that laid out a best practice for how to manage version control in Pharo. I know *how* to use Monticello and Versionner, but something about the way I use them inevitably dooms my efforts to the darkest circles of dependency hell, where strange and gruesome partial versions of old and abandoned branches come back to haunt me like some kind of object oriented night of the living dead. >> >> In particular, I usually commit daily to a local repository on my disk, and only occasionally to a remote repository like smalltalkhub. It has come to my attention that this only commits recent changes, with the result that no single repository actually has the current working code that I see in my image. I am in that situation now, where loading the latest version revives some distant and broken code where good, currently working code should be. If anyone knows how to figure out how to force all the current good code in my image into one massive commit, so that other people can check out the current, working version, please do not hesitate to let me know. >> >> Thanks, >> Evan > -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

May 11, 2017

Re: [Pharo-users] Wandering Through Dependency Hell

by Juraj Kubelka

Hi, I do not understand much you problem. But reading about your commit strategy, you can use Gofer object and its push method to sync properly local changes to a remote repository. Check Pharo books. There are examples. If you inspect a configuration object, there used to be a GT-Inspector extension with dependency visualization. Maybe this is present only in the Moose image. Cheers, Juraj -- Juraj Kubelka > El 09-05-2017, a las 22:42, Evan Donahue <emdonahu(a)gmail.com> escribiÃ³: > > Hello, > > I was wondering if there was a resource somewhere that laid out a best practice for how to manage version control in Pharo. I know *how* to use Monticello and Versionner, but something about the way I use them inevitably dooms my efforts to the darkest circles of dependency hell, where strange and gruesome partial versions of old and abandoned branches come back to haunt me like some kind of object oriented night of the living dead. > > In particular, I usually commit daily to a local repository on my disk, and only occasionally to a remote repository like smalltalkhub. It has come to my attention that this only commits recent changes, with the result that no single repository actually has the current working code that I see in my image. I am in that situation now, where loading the latest version revives some distant and broken code where good, currently working code should be. If anyone knows how to figure out how to force all the current good code in my image into one massive commit, so that other people can check out the current, working version, please do not hesitate to let me know. > > Thanks, > Evan

May 11, 2017

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

by Dimitris Chloupis

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? > 10 minutes o_O wow, I can feel your suffering I do not know Java, I know it but only the very bare bones. What you should be looking for is any way of dynamic linking. Usually that means the ability to reload code on runtime, thats what DLLs are doing. Generally dynamic languages do this out of the box, for example python can reload its modules on runtime so live coding in python is very simple. Only a single command. Dynamic linking is a very basic functionality because its used for supporting scripting , plugins, addons , in short anything dynamic. I just googled "java dynamic code loading" which is what live coding is and this article came up , enjoy http://www.javaworld.com/article/2071777/design-patterns/add-dynamic-java-c… "Kilion, In Haskell (a language that I love, just as Smalltalk) you have the REPL. The workflow is, while you are working on the project, you periodically load that file into the REPL and check. After that you compile. Haskell works with a strong type inference feature, however most Haskellers will say that the best practice is to annotate all functions. Also if you are on macOS you have: http://haskellformac.com/ which is awesome, really a great piece of software. There was even a project called Kronos that was essentially the same as IPython but with a Haskell kernel I don't know the status of that project as of today" Problem with a REPL is that it makes me feel disconnected. I prefer working inside my source code directly and in an instant , no delays , no compromises and multi steps. hence why I love to live code. Plus why bother with a REPL when you can just live code ? I see no advantage but you can enlighten me :) "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 ." Bookmarked to check when I log in my Windows (I use mainly macos) "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)." Yes the live coding feature of Unreal is far from impressive, do not know why they made it so limited and focused only for their editor. Also the inability to not be able to change blueprints run time is annoying too as is the build system. But I can still do my own way of live coding with C++ which is much more simple and much more flexible. "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" Reflection is indeed another beast and an area I have not touched yet. To be fair however, I rarely use reflection and I avoid meta programming. On the matter of symbol table its my understanding that DLLs come with their own symbol tables. It appears to me that you try to modify the executable , that's not my way of doing live coding with C++. Also to be clear about, my way of live coding is strictly Spartan. Which means that in the main loop the only thing that it should be in are: 1) the detection of changes to source code text files (usually checking the date and time format , plus size of the source code file should be enough) 2) the trigger of the relevant DLL compilation source code (simple commands passed to command line, this also means the compilation is automatic) 3) the reload of the DLL after compilation (again one command) 4) the capture of exception that will not allow the executable or the DLL to crash even if the DLL does something very bad ( a couple of lines of code) 5) and finally a singe pointer to a memory location that will be passed to DLLs (yeap a single one , it could be an array though if more flexibility is required for organisation puproses, again a couple of lines of code) In short only a dozen of lines of code will go in the executable that will be written once and never being changed. Coding will happen exclusively inside the source code of fhe DLLs and nowhere else. DLLs also will have to fully manage the memory. As you can imagine what we reload here is the entire DLL which means also that the DLL should be short if we do not want long compile times that defeats the purpose of live coding which turn it means big code will have to be broke down to many DLLs. But then we are Smalltalkers we love it brake down things to small stuff :D

May 10, 2017