- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Seaside] [Ann] Workflow

by Tudor Girba

Thanks a lot! Doru > On Aug 23, 2017, at 10:17 AM, Max Leske <maxleske(a)gmail.com> wrote: > > Hi everyone, > > Stef has asked me whether Netstyle would release our workflow engine to the public, so here goes: > > Workflow (originally called "Aare") was conceived as part of an application that Netstyle developed back in the day. We can't release all of that code but we can release the engine. I've published it on Github with an MIT license (loadable via baseline): https://github.com/Netstyle/Workflow. > > Please note: > - Workflow used to depend on OmniBase for storing objects (one of the main superclasses inherited from an OmniBase class for that). I've removed that dependency. > - As this only includes the engine, there's no UI and the things shown in the whitepaper (see repository) are technically correct but are missing the appropriate model (the UI was written with Magritte and Morphic). > - The code is from 2005 and we haven't touched it since then, so there might be a couple of hiccups. > - We can't provide full support for the code but I'll be happy to talk to anyone interested in maintaining or improving it. > > > We at Netstyle hope that Workflow may be useful to some of you. > > Cheers, > Max > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Aug. 23, 2017

Re: [Pharo-dev] [Vm-dev] Latest Debian, Ubuntu and CentOS packages of the pharo-vm

by Holger Freyther

> On 18. Aug 2017, at 23:56, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: Hi! > Are the packaging stuff in opensmalltalk too, or just in pharo-vm? > It would be great to move all to opensmalltalk. > What is specificity of pharo-vm repository now? the packaging bits are in the pharo-vm repository only. What is pharo specific from a technical point of view is that I re-generate the sources before building the source package. There is a Makefile[1] that drives building the source package and the actual compilation is here[2]. I don't want this to sound offensive but the non-technical part is that it seems easier to get changes into the PharoVM than into opensmalltalk-vm. One example could be the FilePlugin and my attempt to use inotify without periodic polling (wastes power, adds latency and increases your bill in cloud computing, etc). I am happy to answer questions about the packaging process or the OBS/travis-ci integration! holger [1] https://github.com/pharo-project/pharo-vm/blob/master/Makefile.debian [2] https://github.com/pharo-project/pharo-vm/blob/master/packaging/pharo6-vm-c…

Aug. 23, 2017

Re: [Pharo-dev] Latest Debian, Ubuntu and CentOS packages of the pharo-vm

by Holger Freyther

> On 20. Aug 2017, at 03:02, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: Hey! > Tx Holger!!!! > Really tx. appreciated but without Damien's initial Debian packaging, Estebans review, Norbert's drive to fix this for good and financial incentive by 2denker GmbH we wouldn't be here. holger

Aug. 23, 2017

Re: [Pharo-dev] [Ann] PharmIDE is renamed to TelePharo and moved to github

by philippe.back＠highoctane.be

Well I would just subclass the TlpRemoteIDE class with the other name and delegate a connectToRemote: to connect: Indeed there is material that would be better kept in line with the current code. I was demoed another approach to remote master/slave debugging at VUB this week and they were using Seamless + TaskIt2 (so there is actully a remote taskit worker implementation) + debug stack fuel. I recommended using Beacon as well. Interesting times! Phil On Aug 23, 2017 13:29, "Denis Kudriashov" <dionisiydk(a)gmail.com> wrote: > 2017-08-23 12:21 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> Hey Denis, >> >> That's a decent name. At least this is settled. >> >> Now code that reads: >> >> remotePharo := TlpRemoteIDE connectTo: (....) >> >> is annoying with the "Remote" because it somewhat implies that the IDE is >> remote. >> But the IDE is local and connects to a remote. >> >> Maybe >> >> remotePharo := TlpIDE connectToRemote: (...) >> >> is more intention revealing. >> > > Good point. But I made many videos where I show this name. So I don't want > to rename it in nearly future. > Maybe with auto deprecation of classes it can be not a problem. I want add > it in Pharo 7. > > >> >> A question: is it possible to connect an image to itself? >> >> Like in >> >> remotePharo := TlpIDE connectToLocal. >> >> Could have interesting side effects :-) >> > > Theoretically it can work. But right now debugger is not working is that > case. Errors lead to hanging image due to infinite recursion where remote > debugger requests local debugger which is remote debugger itself. > I don't think it is a practical case. > > >> >> Best, >> Phil >> >> >> >> On Wed, Aug 23, 2017 at 10:52 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> Hi. >>> >>> In the team we finally agreed on the end name for project. It is now >>> TelePharo. >>> Prefix "tele" means some action on or by distance. And this is what the >>> project is about: to work remotely with Pharo images. >>> Not all people like this name. But there are no name which was good for >>> everybody. So it was decision. And we now continue with it. >>> >>> With new name project was moved to github repository >>> https://github.com/dionisiydk/TelePharo with all dependencies. Feel >>> free to fork and report bugs. >>> >>> You can find more details in my blog http://dionisiydk.blogspot.fr/ >>> 2017/08/pharmide-is-renamed-to-telepharo-and.html. >>> >>> Best regards, >>> Denis >>> >> >> >

Aug. 23, 2017

Re: [Pharo-dev] [Seaside] [Ann] Workflow

by Max Leske

On 23 August 2017 at 13:53:36, Norbert Hartl (norbert(a)hartl.name) wrote: Thank you very much. I was thinking about implementing van der Aalst pattern for quite some time now. So I try to free a bit of time to help bringing it to usable state in pharo6. Although my morphic skills do not really exist. thanks for releasing this, Norbert Cool! Let me know how it goes. Am 23.08.2017 um 10:17 schrieb Max Leske <maxleske(a)gmail.com>: Hi everyone, Stef has asked me whether Netstyle would release our workflow engine to the public, so here goes: Workflow (originally called "Aare") was conceived as part of an application that Netstyle developed back in the day. We can't release all of that code but we can release the engine. I've published it on Github with an MIT license (loadable via baseline): https://github.com/Netstyle/Workflow. Please note: - Workflow used to depend on OmniBase for storing objects (one of the main superclasses inherited from an OmniBase class for that). I've removed that dependency. - As this only includes the engine, there's no UI and the things shown in the whitepaper (see repository) are technically correct but are missing the appropriate model (the UI was written with Magritte and Morphic). - The code is from 2005 and we haven't touched it since then, so there might be a couple of hiccups. - We can't provide full support for the code but I'll be happy to talk to anyone interested in maintaining or improving it. We at Netstyle hope that Workflow may be useful to some of you. Cheers, Max _______________________________________________ seaside mailing list seaside(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Aug. 23, 2017

Re: [Pharo-dev] [Seaside] [Ann] Workflow

by Norbert Hartl

Thank you very much. I was thinking about implementing van der Aalst pattern for quite some time now. So I try to free a bit of time to help bringing it to usable state in pharo6. Although my morphic skills do not really exist. thanks for releasing this, Norbert > Am 23.08.2017 um 10:17 schrieb Max Leske <maxleske(a)gmail.com>: > > Hi everyone, > > Stef has asked me whether Netstyle would release our workflow engine to the public, so here goes: > > Workflow (originally called "Aare") was conceived as part of an application that Netstyle developed back in the day. We can't release all of that code but we can release the engine. I've published it on Github with an MIT license (loadable via baseline): https://github.com/Netstyle/Workflow <https://github.com/Netstyle/Workflow>. > > Please note: > - Workflow used to depend on OmniBase for storing objects (one of the main superclasses inherited from an OmniBase class for that). I've removed that dependency. > - As this only includes the engine, there's no UI and the things shown in the whitepaper (see repository) are technically correct but are missing the appropriate model (the UI was written with Magritte and Morphic). > - The code is from 2005 and we haven't touched it since then, so there might be a couple of hiccups. > - We can't provide full support for the code but I'll be happy to talk to anyone interested in maintaining or improving it. > > > We at Netstyle hope that Workflow may be useful to some of you. > > Cheers, > Max > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org <mailto:seaside@lists.squeakfoundation.org> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside <http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>

Aug. 23, 2017

Re: [Pharo-dev] [Pharo-users] new chapter on double dispatch for new book :)

by Dimitris Chloupis

I read it once without knowing what double dispatch is, after reading it , I did not know what double dispatch is. It took several reads to understand what double dispatch is. My suggestion is starting with explaining as a summary what double dispatch is , instead of leaving it for the conclusion, explain not how it works but why we need it. Its a good idea to give a general picture to the reader before a practical example as a map to follow the example more easily and not be lost in the code. The code is easy to understand but the intention is not. Also what is a "die handle" ? On Wed, Aug 23, 2017 at 1:54 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > feedback is welcome > Good reading >

Aug. 23, 2017

Re: [Pharo-dev] new chapter on double dispatch for new book :)

by Denis Kudriashov

Ah, it is singular and plural form of word :) I was just confusing that *Die*HandleTest uses *Dice*Handle class. Maybe this should be fixed 2017-08-23 13:33 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > I found little mistake: > > In a previous chapter you implemented a small DSL to add dice and manage > *die*Handle. > > > It should be *dice* I guess. > > 2017-08-23 12:53 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> feedback is welcome >> Good reading >> > >

Aug. 23, 2017

Re: [Pharo-dev] new chapter on double dispatch for new book :)

by Denis Kudriashov

I found little mistake: In a previous chapter you implemented a small DSL to add dice and manage *die*Handle. It should be *dice* I guess. 2017-08-23 12:53 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > feedback is welcome > Good reading >

Aug. 23, 2017

Re: [Pharo-dev] [Ann] PharmIDE is renamed to TelePharo and moved to github

by Denis Kudriashov

2017-08-23 12:21 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Hey Denis, > > That's a decent name. At least this is settled. > > Now code that reads: > > remotePharo := TlpRemoteIDE connectTo: (....) > > is annoying with the "Remote" because it somewhat implies that the IDE is > remote. > But the IDE is local and connects to a remote. > > Maybe > > remotePharo := TlpIDE connectToRemote: (...) > > is more intention revealing. > Good point. But I made many videos where I show this name. So I don't want to rename it in nearly future. Maybe with auto deprecation of classes it can be not a problem. I want add it in Pharo 7. > > A question: is it possible to connect an image to itself? > > Like in > > remotePharo := TlpIDE connectToLocal. > > Could have interesting side effects :-) > Theoretically it can work. But right now debugger is not working is that case. Errors lead to hanging image due to infinite recursion where remote debugger requests local debugger which is remote debugger itself. I don't think it is a practical case. > > Best, > Phil > > > > On Wed, Aug 23, 2017 at 10:52 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Hi. >> >> In the team we finally agreed on the end name for project. It is now >> TelePharo. >> Prefix "tele" means some action on or by distance. And this is what the >> project is about: to work remotely with Pharo images. >> Not all people like this name. But there are no name which was good for >> everybody. So it was decision. And we now continue with it. >> >> With new name project was moved to github repository >> https://github.com/dionisiydk/TelePharo with all dependencies. Feel free >> to fork and report bugs. >> >> You can find more details in my blog http://dionisiydk.blogspot.fr/ >> 2017/08/pharmide-is-renamed-to-telepharo-and.html. >> >> Best regards, >> Denis >> > >

Aug. 23, 2017