July 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Semantics of #resignalAs:

by jtuchel＠objektfabrik.de

Hi again, okay, trying in VAST didn't shed much light, because resignalAs: is implemented as ^self error: 'Not yet implemented'. ;-))) But here is an excerpt from the method's comment: Synopsis: Signal an alternative exception in place of the receiver. Definition: <signaledException> The active exception action is aborted and the exception environment and the evaluation context are restored to the same states that were in effect when the receiver was originally signaled. Restoring the evaluation context may result in the execution of #ensure: or #ifCurtailed: termination blocks. After the restoration, signal the replacementException and execute the exception action as determined by the restored exception environment. This message causes the replacementException to be treated as if it had been originally signaled instead of the receiver. If the replacementException is resumable and its exception action resumes, control will ultimately return from the message that signaled the original exception. Control does not return from this message to the currently active exception action. If I understand correctly, the [1/0] should only be run once and never again, and you should get a NotFound error. ....But: In VisualWorks, I also get a Halt instead of a MustBeBoolean (I had to Replace NotFound with something available in VW, so I used MustBeBoolen). So I am puzzled... Hoping for someone to shed some light on this... Joachim Am 24.07.15 um 08:25 schrieb jtuchel(a)objektfabrik.de: > Definitely looks wrong to me... The catching block shouldn't catch > exceptions in itself, and a resignal should never run the block again... > > I'll try this in VAST. > > > Am 23.07.15 um 20:05 schrieb Norbert Hartl: >> You get a debugger at the position if the halt in the code. Meaning >> the exception block run more than once. And it would run forever. >> >> Norbert >> >> >> >>> Am 23.07.2015 um 18:46 schrieb Joachim Tuchel >>> <jtuchel(a)objektfabrik.de>: >>> >>> Norbert, >>> >>> Sorry if this is a stupid question: what does the debugger say? >>> >>> I mean, assuming NotFound is an Exception, I'd expect a debugger >>> showing a NotFound Error... >>> >>> Joachim >>> >>> Am 23.07.2015 18:34 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>> >>>>> Am 23.07.2015 um 17:54 schrieb Joachim Tuchel >>>>> <jtuchel(a)objektfabrik.de>: >>>>> >>>>> Norbert, >>>>> >>>>> I'd say you get a NotFound Exception. >>>> In pharo you get a debugger. Meaning this piece of code is actively >>>> an endless loop. >>>> >>>> Norbert >>>> >>>>> Joachim >>>>> >>>>> >>>>> >>>>>> Am 23.07.2015 um 16:20 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>>>> >>>>>> What are the semantics of Exception>>#resignalAs: regarding >>>>>> active exception handler? Isn't the active exception handler >>>>>> excluded from being treated again? Taking the example >>>>>> >>>>>> | counter | >>>>>> counter := 0. >>>>>> [ 1/0 ] >>>>>> on: Error >>>>>> do: [ :e | >>>>>> counter := counter + 1. >>>>>> counter > 1 ifTrue: [ self halt ]. >>>>>> e resignalAs: NotFound new ]. >>>>>> >>>>>> should it just run and end? Or should the debugger pop up? >>>>>> >>>>>> thanks, >>>>>> >>>>>> Norbert >>>> >>>> > > -- ----------------------------------------------------------------------- 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

July 24, 2015

Re: [Pharo-users] Semantics of #resignalAs:

by jtuchel＠objektfabrik.de

Definitely looks wrong to me... The catching block shouldn't catch exceptions in itself, and a resignal should never run the block again... I'll try this in VAST. Am 23.07.15 um 20:05 schrieb Norbert Hartl: > You get a debugger at the position if the halt in the code. Meaning the exception block run more than once. And it would run forever. > > Norbert > > > >> Am 23.07.2015 um 18:46 schrieb Joachim Tuchel <jtuchel(a)objektfabrik.de>: >> >> Norbert, >> >> Sorry if this is a stupid question: what does the debugger say? >> >> I mean, assuming NotFound is an Exception, I'd expect a debugger showing a NotFound Error... >> >> Joachim >> >> Am 23.07.2015 18:34 schrieb Norbert Hartl <norbert(a)hartl.name>: >>> >>>> Am 23.07.2015 um 17:54 schrieb Joachim Tuchel <jtuchel(a)objektfabrik.de>: >>>> >>>> Norbert, >>>> >>>> I'd say you get a NotFound Exception. >>> In pharo you get a debugger. Meaning this piece of code is actively an endless loop. >>> >>> Norbert >>> >>>> Joachim >>>> >>>> >>>> >>>>> Am 23.07.2015 um 16:20 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>>> >>>>> What are the semantics of Exception>>#resignalAs: regarding active exception handler? Isn't the active exception handler excluded from being treated again? Taking the example >>>>> >>>>> | counter | >>>>> counter := 0. >>>>> [ 1/0 ] >>>>> on: Error >>>>> do: [ :e | >>>>> counter := counter + 1. >>>>> counter > 1 ifTrue: [ self halt ]. >>>>> e resignalAs: NotFound new ]. >>>>> >>>>> should it just run and end? Or should the debugger pop up? >>>>> >>>>> thanks, >>>>> >>>>> Norbert >>> >>> -- ----------------------------------------------------------------------- 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

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

Peter, is this the dynacase at https://github.com/dynacase/dynacase ? Thierry Le 24/07/2015 02:29, Peter UhnÃ¡k a Ã©crit : > > > On Fri, Jul 24, 2015 at 12:26 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Hi Peter, > > no, I don't think you fucked up your gitfiletree metadata. But the > explanation is a bit complex. > > First thing is that you are looking at a git generated metadata... > So what you're asking for (regenerating from git) is already what > you are looking at :) > > Second is that gitfiletree walks your git log to rebuilt the version > history. So, I guess that if you look at your git with something > like gitg, you will recognize all the versions coming along the > diagram lines. > > It is linked a bit in the way gitfiletree reads through the merges > in the git history. I was surprised by that effect, I had a look and > yes, there is a good reason for having this done in that way, even > if it is a bit surprising at first. Don't remember the exact > reasoning... but it was linked to the way git links commits to > directories and how merge points appear. > > If you want to explore that part of GitFileTree, it is in > GitFileTreePackageEntry>>buildInfoWith:startingAt:version:ancestry:. > > > Hmm, I'll look at that but still I think it shows way more than it should. > > > The ghost changes are something else, however. Can you elaborate? > > > Basically Pharo (Monticello Browser/Nautilus) shows that a package has > changes... so I look at the changes (to see what I'm committing) and I > see things that I've already committed. And if I commit it again, only > metadata will change (because it was already committed), but the dirty > flag will disappear. > > I have no idea under what circumstances this happens, I thought that > maybe I am in different commit... but monticello browser says that I am > at the latest one... > So I have yet to tell what is the cause. > > Peter

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Yuriy Tymchuk

Check which versions are bold when you open the package. Because when I use gitfiletree it usually shows me that the latest few versions are not loaded (they are in bold) but I am anyway on the latest one. Uko > On 24 Jul 2015, at 02:29, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > On Fri, Jul 24, 2015 at 12:26 AM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > Hi Peter, > > no, I don't think you fucked up your gitfiletree metadata. But the explanation is a bit complex. > > First thing is that you are looking at a git generated metadata... So what you're asking for (regenerating from git) is already what you are looking at :) > > Second is that gitfiletree walks your git log to rebuilt the version history. So, I guess that if you look at your git with something like gitg, you will recognize all the versions coming along the diagram lines. > > It is linked a bit in the way gitfiletree reads through the merges in the git history. I was surprised by that effect, I had a look and yes, there is a good reason for having this done in that way, even if it is a bit surprising at first. Don't remember the exact reasoning... but it was linked to the way git links commits to directories and how merge points appear. > > If you want to explore that part of GitFileTree, it is in GitFileTreePackageEntry>>buildInfoWith:startingAt:version:ancestry:. > > Hmm, I'll look at that but still I think it shows way more than it should. > > > The ghost changes are something else, however. Can you elaborate? > > Basically Pharo (Monticello Browser/Nautilus) shows that a package has changes... so I look at the changes (to see what I'm committing) and I see things that I've already committed. And if I commit it again, only metadata will change (because it was already committed), but the dirty flag will disappear. > > I have no idea under what circumstances this happens, I thought that maybe I am in different commit... but monticello browser says that I am at the latest one... > So I have yet to tell what is the cause. > > Peter > > > > > Thierry > > > Le 23/07/2015 23:49, Peter UhnÃ¡k a Ã©crit : > Hi, > > it seems that I managed to completely fuck up my gitfiletree metadata... > > e.g.: > Ancestors: DynaCASE-PeterUhnak.148, DynaCASE-PeterUhnak.93, > DynaCASE-PeterUhnak.144, DynaCASE-PeterUhnak.146, > DynaCASE-PeterUhnak.92, DynaCASE-PeterUhnak.142, > DynaCASE-PeterUhnak.140, DynaCASE-PeterUhnak.138, > DynaCASE-PeterUhnak.139, DynaCASE-bliznjan.127, DynaCASE-PeterUhnak.137, > DynaCASE-PeterUhnak.125, DynaCASE-PeterUhnak.126, DynaCASE-bliznjan.123, > DynaCASE-bliznjan.121, DynaCASE-bliznjan.120, DynaCASE-PeterUhnak.119, > DynaCASE-PeterUhnak.117, DynaCASE-PeterUhnak.115, DynaCASE-bliznjan.113, > DynaCASE-PeterUhnak.111, DynaCASE-PeterUhnak.110, > DynaCASE-PeterUhnak.108, DynaCASE-PeterUhnak.102, DynaCASE-bliznjan.95, > DynaCASE-bliznjan.98, DynaCASE-PeterUhnak.91 > > I am also starting to see a lot of ghost changes etc. > > Now, someone mentioned that it would be possible to delete all the > .version and methodProperties.json and whatnot and generate it directly > from git. > > So my question is, is this possible? If yes, how? If no, what would need > to be done (implemented) to make it so? > > Or at least is it possible to completely regenerate all the metadata > purely from git? (To clean up all the mess until.) > > Peter > > >

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Peter UhnÃ¡k

On Fri, Jul 24, 2015 at 12:26 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Hi Peter, > > no, I don't think you fucked up your gitfiletree metadata. But the > explanation is a bit complex. > > First thing is that you are looking at a git generated metadata... So what > you're asking for (regenerating from git) is already what you are looking > at :) > > Second is that gitfiletree walks your git log to rebuilt the version > history. So, I guess that if you look at your git with something like gitg, > you will recognize all the versions coming along the diagram lines. > > It is linked a bit in the way gitfiletree reads through the merges in the > git history. I was surprised by that effect, I had a look and yes, there is > a good reason for having this done in that way, even if it is a bit > surprising at first. Don't remember the exact reasoning... but it was > linked to the way git links commits to directories and how merge points > appear. > > If you want to explore that part of GitFileTree, it is in > GitFileTreePackageEntry>>buildInfoWith:startingAt:version:ancestry:. > Hmm, I'll look at that but still I think it shows way more than it should. > > The ghost changes are something else, however. Can you elaborate? Basically Pharo (Monticello Browser/Nautilus) shows that a package has changes... so I look at the changes (to see what I'm committing) and I see things that I've already committed. And if I commit it again, only metadata will change (because it was already committed), but the dirty flag will disappear. I have no idea under what circumstances this happens, I thought that maybe I am in different commit... but monticello browser says that I am at the latest one... So I have yet to tell what is the cause. Peter > > > Thierry > > > Le 23/07/2015 23:49, Peter UhnÃ¡k a Ã©crit : > >> Hi, >> >> it seems that I managed to completely fuck up my gitfiletree metadata... >> >> e.g.: >> Ancestors: DynaCASE-PeterUhnak.148, DynaCASE-PeterUhnak.93, >> DynaCASE-PeterUhnak.144, DynaCASE-PeterUhnak.146, >> DynaCASE-PeterUhnak.92, DynaCASE-PeterUhnak.142, >> DynaCASE-PeterUhnak.140, DynaCASE-PeterUhnak.138, >> DynaCASE-PeterUhnak.139, DynaCASE-bliznjan.127, DynaCASE-PeterUhnak.137, >> DynaCASE-PeterUhnak.125, DynaCASE-PeterUhnak.126, DynaCASE-bliznjan.123, >> DynaCASE-bliznjan.121, DynaCASE-bliznjan.120, DynaCASE-PeterUhnak.119, >> DynaCASE-PeterUhnak.117, DynaCASE-PeterUhnak.115, DynaCASE-bliznjan.113, >> DynaCASE-PeterUhnak.111, DynaCASE-PeterUhnak.110, >> DynaCASE-PeterUhnak.108, DynaCASE-PeterUhnak.102, DynaCASE-bliznjan.95, >> DynaCASE-bliznjan.98, DynaCASE-PeterUhnak.91 >> >> I am also starting to see a lot of ghost changes etc. >> >> Now, someone mentioned that it would be possible to delete all the >> .version and methodProperties.json and whatnot and generate it directly >> from git. >> >> So my question is, is this possible? If yes, how? If no, what would need >> to be done (implemented) to make it so? >> >> Or at least is it possible to completely regenerate all the metadata >> purely from git? (To clean up all the mess until.) >> >> Peter >> > > >

July 24, 2015

Re: [Pharo-users] gitfiletree metadata

by Thierry Goubier

Hi Peter, no, I don't think you fucked up your gitfiletree metadata. But the explanation is a bit complex. First thing is that you are looking at a git generated metadata... So what you're asking for (regenerating from git) is already what you are looking at :) Second is that gitfiletree walks your git log to rebuilt the version history. So, I guess that if you look at your git with something like gitg, you will recognize all the versions coming along the diagram lines. It is linked a bit in the way gitfiletree reads through the merges in the git history. I was surprised by that effect, I had a look and yes, there is a good reason for having this done in that way, even if it is a bit surprising at first. Don't remember the exact reasoning... but it was linked to the way git links commits to directories and how merge points appear. If you want to explore that part of GitFileTree, it is in GitFileTreePackageEntry>>buildInfoWith:startingAt:version:ancestry:. The ghost changes are something else, however. Can you elaborate? Thierry Le 23/07/2015 23:49, Peter UhnÃ¡k a Ã©crit : > Hi, > > it seems that I managed to completely fuck up my gitfiletree metadata... > > e.g.: > Ancestors: DynaCASE-PeterUhnak.148, DynaCASE-PeterUhnak.93, > DynaCASE-PeterUhnak.144, DynaCASE-PeterUhnak.146, > DynaCASE-PeterUhnak.92, DynaCASE-PeterUhnak.142, > DynaCASE-PeterUhnak.140, DynaCASE-PeterUhnak.138, > DynaCASE-PeterUhnak.139, DynaCASE-bliznjan.127, DynaCASE-PeterUhnak.137, > DynaCASE-PeterUhnak.125, DynaCASE-PeterUhnak.126, DynaCASE-bliznjan.123, > DynaCASE-bliznjan.121, DynaCASE-bliznjan.120, DynaCASE-PeterUhnak.119, > DynaCASE-PeterUhnak.117, DynaCASE-PeterUhnak.115, DynaCASE-bliznjan.113, > DynaCASE-PeterUhnak.111, DynaCASE-PeterUhnak.110, > DynaCASE-PeterUhnak.108, DynaCASE-PeterUhnak.102, DynaCASE-bliznjan.95, > DynaCASE-bliznjan.98, DynaCASE-PeterUhnak.91 > > I am also starting to see a lot of ghost changes etc. > > Now, someone mentioned that it would be possible to delete all the > .version and methodProperties.json and whatnot and generate it directly > from git. > > So my question is, is this possible? If yes, how? If no, what would need > to be done (implemented) to make it so? > > Or at least is it possible to completely regenerate all the metadata > purely from git? (To clean up all the mess until.) > > Peter

July 23, 2015

Re: [Pharo-users] Trying to load ViDI in Pharo 4 gives an error

by Yuriy Tymchuk

Hi, I will take a look at that, but at the moment Iâm in the airport awaiting my flight, and itâs not very comfortable to debug configurations here. Please be patient :) Cheers Uko > On 23 Jul 2015, at 22:14, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > Hi - > > > When I run this: > > > Gofer new > smalltalkhubUser: 'YuriyTymchuk' > project: 'Configuration'; > configurationOf: 'Vidi'; > load. > #ConfigurationOfVidi asClass loadStable > > > I get a error that the 1.2.14 version of ConfigruationOfRubric cannot be found. The ConfigurationOfRubric is loaded from the > > MCSmalltalkhubRepository > owner: 'AlainPlantec' > project: 'Rubric' > user: '' > password: '' > > > repo. Is there another one it should be loading? > > > Thanks > > Paul

July 23, 2015

gitfiletree metadata

by Peter UhnÃ¡k

Hi, it seems that I managed to completely fuck up my gitfiletree metadata... e.g.: Ancestors: DynaCASE-PeterUhnak.148, DynaCASE-PeterUhnak.93, DynaCASE-PeterUhnak.144, DynaCASE-PeterUhnak.146, DynaCASE-PeterUhnak.92, DynaCASE-PeterUhnak.142, DynaCASE-PeterUhnak.140, DynaCASE-PeterUhnak.138, DynaCASE-PeterUhnak.139, DynaCASE-bliznjan.127, DynaCASE-PeterUhnak.137, DynaCASE-PeterUhnak.125, DynaCASE-PeterUhnak.126, DynaCASE-bliznjan.123, DynaCASE-bliznjan.121, DynaCASE-bliznjan.120, DynaCASE-PeterUhnak.119, DynaCASE-PeterUhnak.117, DynaCASE-PeterUhnak.115, DynaCASE-bliznjan.113, DynaCASE-PeterUhnak.111, DynaCASE-PeterUhnak.110, DynaCASE-PeterUhnak.108, DynaCASE-PeterUhnak.102, DynaCASE-bliznjan.95, DynaCASE-bliznjan.98, DynaCASE-PeterUhnak.91 I am also starting to see a lot of ghost changes etc. Now, someone mentioned that it would be possible to delete all the .version and methodProperties.json and whatnot and generate it directly from git. So my question is, is this possible? If yes, how? If no, what would need to be done (implemented) to make it so? Or at least is it possible to completely regenerate all the metadata purely from git? (To clean up all the mess until.) Peter

July 23, 2015

Screamer for Smalltalk?

by Paul DeBruicker

Hi Screamer (https://nikodemus.github.io/screamer/) is a Lisp library that: "Screamer provides a nondeterministic choice-point operator, a backtracking mechanism, and a forward propagation facility." Is there an equivalent library available in Smalltalk? Thanks Paul

July 23, 2015

Trying to load ViDI in Pharo 4 gives an error

by Paul DeBruicker

Hi - When I run this: Gofer new smalltalkhubUser: 'YuriyTymchuk' project: 'Configuration'; configurationOf: 'Vidi'; load. #ConfigurationOfVidi asClass loadStable I get a error that the 1.2.14 version of ConfigruationOfRubric cannot be found. The ConfigurationOfRubric is loaded from the MCSmalltalkhubRepository owner: 'AlainPlantec' project: 'Rubric' user: '' password: '' repo. Is there another one it should be loading? Thanks Paul

July 23, 2015