December 2018 - Pharo-dev - lists.pharo.org

[Pharo .0] Build #16: SUCCESS

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #16 was: SUCCESS. Could not extract further issue information from commit message: dix sources when converting to 64bit too Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 5, 2018

[Pharo 7.0-dev] Build #1436: Improving comment of class DebugSession

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1436 was: SUCCESS. The Pull Request #2040 was integrated: "Improving comment of class DebugSession" Pull request url: https://github.com/pharo-project/pharo/pull/2040 Issue Url: https://pharo.fogbugz.com/f/cases/development Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 5, 2018

[Pharo .0] Build #15: FAILURE

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #15 was: FAILURE. Could not extract further issue information from commit message: fix inclusion of sources suspend upload for the moment = Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 5, 2018

[Pharo .0] Build #14: SUCCESS

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #14 was: SUCCESS. Could not extract further issue information from commit message: groovy is zero based :( Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 4, 2018

[Pharo 7.0-dev] Build #1435: 22727-NonInteractiveTranscript-is-broken-with-files

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1435 was: SUCCESS. The Pull Request #2039 was integrated: "22727-NonInteractiveTranscript-is-broken-with-files" Pull request url: https://github.com/pharo-project/pharo/pull/2039 Issue Url: https://pharo.fogbugz.com/f/cases/22727 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 4, 2018

Re: [Pharo-dev] InterruptedContext vs suspendedContext

by Thomas Dupriez

Ok, thanks to you two for these nice answers. I made a pull-request to improve the comment of the DebugSession class based on your answers. Thomas On 01/12/2018 19:02, Eliot Miranda wrote: > Hi Andrei, Hi Thomas, > > Â Â Andrei, you are right; they are different and the difference is > important. Â As you say, suspendedContext is the top (âhotâ) context in > a processâs context chain, but interruptedContext is the context which > sent the signal message that eventually raised the exception that > invoked the debugger. Â suspendedContext is therefore where execution > is in the process, but interruptedContext is where the debugger should > show the stack. > > Thomas, because the exception system is implemented in Smalltalk the > handling of the initial signal (eg in Object>>#halt), all the way to > opening a debugger, is itself Smalltalk code, and exists as > activations from suspendedContext toÂ interruptedContext. Â The > debugger, with help from the exception system, carefully hides this > processing from the programmer. Â If it did not we would have to wade > through many activations before we found where the exception occurred. > > When a process is interrupted by control period things are different. > Â Here, another process handles opening the debugger and indeed > suspendedContext and interruptedContext are the same. > > So the difference between suspendedContext and interruptedContext is > vital to the debugger. Â Without it we would Â see the inner machinery > of the exception system when errors or exceptions are raised. > > HTH > > _,,,^..^,,,_ (phone) > > On Nov 30, 2018, at 7:42 AM, Andrei Chis <chisvasileandrei(a)gmail.com > <mailto:chisvasileandrei@gmail.com>> wrote: > >> Hi, >> >> From what I remember they are not always redundant, but I'm not 100% >> sure they are both needed. >> >> `suspendedContext` from Process is always the top context of a >> process. After execution actions like Step Into, Step Over, Step >> Through it will be the same as interruptedContext in the debugger. >> >> They will be different when opening the debugger as a result of an >> exception. >> Exception>>#debug triggers the workflow for opening a debugger. This >> uses `self signalerContext` as the context that is being debugged. >> This is the context where the exception was raised and this will be >> put in the interruptedContext. As this point the execution of the >> current process is not over and it will continue up to >> `MorphicUIManager>>#debugProcess:context:label:fullView:notification:Â ` >> where the current process is suspended. At that point the two will be >> different, as suspendedContext will be the context of the method >> MorphicUIManager>>#debugProcess:context:label:fullView:notification: >> and the interruptedContext the context that triggered the exception. >> >> But it might be that they are not both needed. OneÂ possible option >> might be to force the process to step to the context that raised the >> exception when the debugger is created. For example >> inÂ DebugSession>>process:context:. >> Apart from when opening the debugger I do not know if there is >> another situation where those two can diverge. >> >> Cheers, >> Andrei >> >> On Fri, Nov 30, 2018 at 11:54 AM Thomas Dupriez >> <tdupriez(a)ens-paris-saclay.fr <mailto:tdupriez@ens-paris-saclay.fr>> >> wrote: >> >> Hello, >> >> >> Instances of DebugSession have an "interruptedContext" and an >> "interruptedProcess" instance variable. >> >> Instances of Process have a "suspendedContext" instance variable. >> >> Does someone know if there is a relation between the >> interruptedContext of a DebugSession and the suspendedContext of >> its interruptedProcess? At first glance it seems like these two >> variables are redundant and store the same Context. >> >> Thomas Dupriez >>

Dec. 4, 2018

[Pharo 7.0-dev] Build #1434: 22687-Update-Tonel

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1434 was: SUCCESS. The Pull Request #2028 was integrated: "22687-Update-Tonel" Pull request url: https://github.com/pharo-project/pharo/pull/2028 Issue Url: https://pharo.fogbugz.com/f/cases/22687 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 3, 2018

Re: [Pharo-dev] [Moose-dev] Re: Migrate PetitParser (1) on GitHub under moosetechnology organisation?

by Andrei Chis

Super. I can also help if you need so. On Mon, Dec 3, 2018 at 3:59 PM Julien <julien.delplanque(a)inria.fr> wrote: > Sure, I will keep the history. > > I will see how much time it takes to migrate PetitParser. > > If it does not take too much time, maybe I will do it for the two others > repository. > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > > Le 3 dÃ©c. 2018 Ã 15:55, Andrei Chis <chisvasileandrei(a)gmail.com> a Ã©crit : > > Hi, > > That's definitely a good idea. > > Just would also be very nice to use Peter's migration tool to also capture > the history+authors. > (I can provide you with a lis of authors that for the migration tool that > should cover most authors from PetitParser). > > If you're at this, could also help to migrate the PetitSQLite and > PetitJava projects. > > Cheers, > Andrei > > > On Mon, Dec 3, 2018 at 3:41 PM Julien <julien.delplanque(a)inria.fr> wrote: > >> Hello, >> >> Iâd like to migrate PetitParser (1) on GitHub under moosetechnology >> organisation. >> >> I have a project depending on it and there are some stuff Iâd like to fix >> on PetitParser 1 ConfigurationOf (which will become a baseline on GitHub). >> >> Is it ok to migrate it? >> >> Cheers, >> >> Julien >> >> --- >> Julien Delplanque >> Doctorant Ã lâUniversitÃ© de Lille >> http://juliendelplanque.be/phd.html >> Equipe Rmod, Inria >> BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq >> NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Dec. 3, 2018

Re: [Pharo-dev] [Moose-dev] Re: Migrate PetitParser (1) on GitHub under moosetechnology organisation?

by Julien

Sure, I will keep the history. I will see how much time it takes to migrate PetitParser. If it does not take too much time, maybe I will do it for the two others repository. Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 3 dÃ©c. 2018 Ã 15:55, Andrei Chis <chisvasileandrei(a)gmail.com> a Ã©crit : > > Hi, > > That's definitely a good idea. > > Just would also be very nice to use Peter's migration tool to also capture the history+authors. > (I can provide you with a lis of authors that for the migration tool that should cover most authors from PetitParser). > > If you're at this, could also help to migrate the PetitSQLite and PetitJava projects. > > Cheers, > Andrei > > > On Mon, Dec 3, 2018 at 3:41 PM Julien <julien.delplanque(a)inria.fr <mailto:julien.delplanque@inria.fr>> wrote: > Hello, > > Iâd like to migrate PetitParser (1) on GitHub under moosetechnology organisation. > > I have a project depending on it and there are some stuff Iâd like to fix on PetitParser 1 ConfigurationOf (which will become a baseline on GitHub). > > Is it ok to migrate it? > > Cheers, > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html <http://juliendelplanque.be/phd.html> > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch> > https://www.list.inf.unibe.ch/listinfo/moose-dev <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

Dec. 3, 2018

Re: [Pharo-dev] [Moose-dev] Migrate PetitParser (1) on GitHub under moosetechnology organisation?

by Andrei Chis

Hi, That's definitely a good idea. Just would also be very nice to use Peter's migration tool to also capture the history+authors. (I can provide you with a lis of authors that for the migration tool that should cover most authors from PetitParser). If you're at this, could also help to migrate the PetitSQLite and PetitJava projects. Cheers, Andrei On Mon, Dec 3, 2018 at 3:41 PM Julien <julien.delplanque(a)inria.fr> wrote: > Hello, > > Iâd like to migrate PetitParser (1) on GitHub under moosetechnology > organisation. > > I have a project depending on it and there are some stuff Iâd like to fix > on PetitParser 1 ConfigurationOf (which will become a baseline on GitHub). > > Is it ok to migrate it? > > Cheers, > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Dec. 3, 2018