January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Marcus Denker

On 09 Jan 2014, at 10:45, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 9 January 2014 10:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > The history hack did totally not work for end users, many people, including myself, lost code, often without noticing or understanding it at first. > > This 'warning, you did not accept' is/was important and solid, if you want to replace that the solution should be really good - it was not. > > Don't shoot on Nicolai, he tried to fix it, after asking around. > > i'm not shooting anyone, i just sad there is no progress :) > and instead even regress, because now i should also answer 'yes/no' when i press > cmd-L.. > > If some people will need to be asked are they really really really fucking sure they wanted to press a key they pressed, each time they pressing the key, why others, who don't need such stupidity should suffer? > These are two different issue: 1) CMD-L 2) Not asking in general and rely on history. Marcus

Jan. 9, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Igor Stasenko

On 9 January 2014 10:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > The history hack did totally not work for end users, many people, > including myself, lost code, often without noticing or understanding it at > first. > > This 'warning, you did not accept' is/was important and solid, if you want > to replace that the solution should be really good - it was not. > > Don't shoot on Nicolai, he tried to fix it, after asking around. > > i'm not shooting anyone, i just sad there is no progress :) and instead even regress, because now i should also answer 'yes/no' when i press cmd-L.. If some people will need to be asked are they really really really fucking sure they wanted to press a key they pressed, each time they pressing the key, why others, who don't need such stupidity should suffer? On 09 Jan 2014, at 10:27, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > > > > > On 9 January 2014 08:50, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2014/1/9 Igor Stasenko <siguctua(a)gmail.com> > > > > > > > > On 8 January 2014 22:04, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > > I don't like an app that does not ask for my confirmation , because I > tend to do a lot of stupid mistakes along the way and I want to be able to > fix everyone of them even before they happen. Please don't remove that, > that would be reason enough for me to stop using Pharo. > > > > for stupid mistakes, there's (or should be , if missing) - undo. > > > > Another recipe: just don't make mistakes :) > > > > Undo also wont do, because I dont always realise my mistakes until much > later on. > > > > sorry.. but then perhaps you should find different occupation? :) > > computers (and software systems we writing) will never be smart enough > to predict or prevent you from doing mistakes. putting 'are you really > really sure?' popups everywhere doesn't helps but just serves as a > distraction.. because at certain point, your reaction on these popups > become completely mechanical and just cost you extra time and no cognitive > load only a distraction. > > > > at the end, it is just silly: the point is that i am always sure about > things i do, when interacting with my computer. if i'm not, i simply don't > (or i save and then proceed with caution).. and in any case, i don't need > stupid UI asking me about things i already decided to do (yes i am sort of > man, who disables file deletion warning, if it provided). > > > > when you pushing gas pedal in your car, or brakes, are there also popups > which freezes your feet and asks to press yes or no before proceed? > > because wrong decision could cost you much more - your own life. > > > > And having to undo all my work to fix a stupid mistake is a nightmare. > The only thing that would make sense for removing confirmation dialogs is > editable action history. Take a look at Photoshop. Some 3d apps also have > something similar. Every action is recorded at a history ( a list) and > there is a gui that allow you to remove individual actions without deleting > or affecting other actions. Very cool stuff. > > > > that what we did with Ben: there is navigation history, where you can > find unsaved changes. but people prefer popping up red herrings instead. > > > > > > > > > > On Wednesday, 8 January 2014, 11:44, Igor Stasenko <siguctua(a)gmail.com> > wrote: > > i want to discard. discard this modal thingies altogether.. > > and we did that with Ben, but then people turned their nose against it > and rolled back the change. > > > > > > On 8 January 2014 17:02, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I still have these un-interact-able pop ups following me around endlessly > > when I have unaccepted edits in Nautilus. It seems intermittent. Not sure > > how exactly to reproduceâ¦ Anyone else? > > > > b.t.w. the secret seems to be to bring up halos on the pop-up and > clicking > > the (x) halo. Trying to click its buttons only makes it angry > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > I don't think we have to discuss what would be the better alternative. > People have different preferences and different workflows. > > Why don't we make a setting for this? Something like "Codepanes can > discard edits", and let Nautilus and other > > codepanes behave like the Workspace (I remember a time when workspaces > asked too before discarding edits) > > > > About the editing history, most people said it is a good idea. The > reason I reverted this back was not someone > > doesn't like it. It just didn't worked. > > As commented in the bug case: > > 1. not alll interactions created an editing history entry. > > 2. throwing away the history on window closing was at leas unexpected > for some users. > > 3. the history that was used for both, navigation and editing, is > limited to 15 entries > > > > .. and instead of fixing the above things was thrown away. > > We will never have good UI if we will use such strategy to develop it. > > > > Nicolai > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Jan. 9, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Sven Van Caekenberghe

The history hack did totally not work for end users, many people, including myself, lost code, often without noticing or understanding it at first. This 'warning, you did not accept' is/was important and solid, if you want to replace that the solution should be really good - it was not. Don't shoot on Nicolai, he tried to fix it, after asking around. On 09 Jan 2014, at 10:27, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 9 January 2014 08:50, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014/1/9 Igor Stasenko <siguctua(a)gmail.com> > > > > On 8 January 2014 22:04, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > I don't like an app that does not ask for my confirmation , because I tend to do a lot of stupid mistakes along the way and I want to be able to fix everyone of them even before they happen. Please don't remove that, that would be reason enough for me to stop using Pharo. > > for stupid mistakes, there's (or should be , if missing) - undo. > > Another recipe: just don't make mistakes :) > > Undo also wont do, because I dont always realise my mistakes until much later on. > > sorry.. but then perhaps you should find different occupation? :) > computers (and software systems we writing) will never be smart enough to predict or prevent you from doing mistakes. putting 'are you really really sure?' popups everywhere doesn't helps but just serves as a distraction.. because at certain point, your reaction on these popups become completely mechanical and just cost you extra time and no cognitive load only a distraction. > > at the end, it is just silly: the point is that i am always sure about things i do, when interacting with my computer. if i'm not, i simply don't (or i save and then proceed with caution).. and in any case, i don't need stupid UI asking me about things i already decided to do (yes i am sort of man, who disables file deletion warning, if it provided). > > when you pushing gas pedal in your car, or brakes, are there also popups which freezes your feet and asks to press yes or no before proceed? > because wrong decision could cost you much more - your own life. > > And having to undo all my work to fix a stupid mistake is a nightmare. The only thing that would make sense for removing confirmation dialogs is editable action history. Take a look at Photoshop. Some 3d apps also have something similar. Every action is recorded at a history ( a list) and there is a gui that allow you to remove individual actions without deleting or affecting other actions. Very cool stuff. > > that what we did with Ben: there is navigation history, where you can find unsaved changes. but people prefer popping up red herrings instead. > > > > > On Wednesday, 8 January 2014, 11:44, Igor Stasenko <siguctua(a)gmail.com> wrote: > i want to discard. discard this modal thingies altogether.. > and we did that with Ben, but then people turned their nose against it and rolled back the change. > > > On 8 January 2014 17:02, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I still have these un-interact-able pop ups following me around endlessly > when I have unaccepted edits in Nautilus. It seems intermittent. Not sure > how exactly to reproduceâ¦ Anyone else? > > b.t.w. the secret seems to be to bring up halos on the pop-up and clicking > the (x) halo. Trying to click its buttons only makes it angry > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > -- > Best regards, > Igor Stasenko. > > > > > > -- > Best regards, > Igor Stasenko. > > > I don't think we have to discuss what would be the better alternative. People have different preferences and different workflows. > Why don't we make a setting for this? Something like "Codepanes can discard edits", and let Nautilus and other > codepanes behave like the Workspace (I remember a time when workspaces asked too before discarding edits) > > About the editing history, most people said it is a good idea. The reason I reverted this back was not someone > doesn't like it. It just didn't worked. > As commented in the bug case: > 1. not alll interactions created an editing history entry. > 2. throwing away the history on window closing was at leas unexpected for some users. > 3. the history that was used for both, navigation and editing, is limited to 15 entries > > .. and instead of fixing the above things was thrown away. > We will never have good UI if we will use such strategy to develop it. > > Nicolai > > > > > -- > Best regards, > Igor Stasenko.

Jan. 9, 2014

Re: [Pharo-dev] Athens SVG Import

by Igor Stasenko

On 9 January 2014 10:26, J.F. Rick <self(a)je77.com> wrote: > OK. I've made a little headway in diagnosing the problem. It seems that > one culprit is that the "self changed" thing works differently with Athens > than previously. Correct me if I'm wrong, but it seems like sending that > method immediately causes the canvas to draw. In contrast, before, it just > marked that area as needing to be redrawn and then, on an update cycle, it > would redraw the total area that changed. I was using a model-view pattern > that had 25 components to it. When each got the update command, it seems to > have launched the canvas to draw. When I changed it so that only one > changed command was given, the interface became immediately much snappier. > Adding a factor of 25 to rendering could cause even fast rendering to be > quite noticeable. So, it is not an inherent problem with drawing forms but > rather one with changing the programming paradigm. Forms are just > noticeably slower to draw than vector components and that exacerbated my > problem. > > Hmm.. Can you explain me, how Athens is related to that? :) 'self changed' logic and its handling is related to Morphic and used by it. there's no way how you can change it by changing something in Athens. > Cheers, > > Jeff > > > On Thu, Jan 9, 2014 at 8:18 AM, J.F. Rick <self(a)je77.com> wrote: > >> Hmm. Weird. Could it be a linux thing? Bit order or something? Could it >> be a transparency issue? Could it be a size of the form? I have forms of >> size around 200 x 200. At this point, I haven't numerically investigated >> it. I just notice a significant difference in rendering speed as I switch >> from forms to SVGs. Perhaps it is having to redraw the entire interface >> very often. I'll investigate a bit more when I have some time. >> >> Cheers, >> >> Jeff >> >> >> On Thu, Jan 9, 2014 at 2:08 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >>> >>> >>> On 8 January 2014 08:59, J.F. Rick <self(a)je77.com> wrote: >>> >>>> In good news, I was able to implement the S/s functionality and both of >>>> my SVGs now load properly. I'll try some more soon and commit the changes >>>> once I have tested it a bit more. >>>> >>>> In bad news, the cacheing was working properly, so I still suspect that >>>> rendering forms as a paint is too intensive to be practical for many >>>> applications. I'll try to evaluate it a bit more as I replace forms with >>>> SVGs. If the forms are causing the problem, then performance should >>>> noticeably increase. >>>> >>>> >>> I just did a little comparison: >>> >>> | surface time | >>> surface := AthensCairoSurface extent: 200@200. >>> >>> surface drawDuring: [ :canvas| >>> canvas setPaint: Color red. >>> canvas setShape: (0@0 extent: 100@100). >>> time := [ 10000 timesRepeat: [ canvas draw ] ] timeToRun. >>> ]. >>> time >>> 0:00:00:00.115 >>> ============= >>> >>> same as above but with: >>> canvas setPaint: (ThemeIcons current backIcon). >>> >>> time >>> 0:00:00:00.093 >>> =========== >>> >>> same as above but with: >>> (canvas setPaint: (ThemeIcons current backIcon)) repeat. >>> >>> time >>> 0:00:00:00.956 >>> >>> as you can see, even in slowest case, the throughput is: >>> >>> 100*100*10000 = 100'000'000 pixels (texels) per second. >>> >>> >>> >>>> Cheers, >>>> >>>> Jeff >>>> >>>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > -- Best regards, Igor Stasenko.

Jan. 9, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Igor Stasenko

On 9 January 2014 08:50, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014/1/9 Igor Stasenko <siguctua(a)gmail.com> > >> >> >> >> On 8 January 2014 22:04, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >> >>> I don't like an app that does not ask for my confirmation , because I >>> tend to do a lot of stupid mistakes along the way and I want to be able to >>> fix everyone of them even before they happen. Please don't remove that, >>> that would be reason enough for me to stop using Pharo. >>> >>> for stupid mistakes, there's (or should be , if missing) - undo. >> >> Another recipe: just don't make mistakes :) >> >> >>> Undo also wont do, because I dont always realise my mistakes until >>> much later on. >>> >> >> sorry.. but then perhaps you should find different occupation? :) >> computers (and software systems we writing) will never be smart enough to >> predict or prevent you from doing mistakes. putting 'are you really really >> sure?' popups everywhere doesn't helps but just serves as a distraction.. >> because at certain point, your reaction on these popups become completely >> mechanical and just cost you extra time and no cognitive load only a >> distraction. >> >> at the end, it is just silly: the point is that i am always sure about >> things i do, when interacting with my computer. if i'm not, i simply don't >> (or i save and then proceed with caution).. and in any case, i don't need >> stupid UI asking me about things i already decided to do (yes i am sort of >> man, who disables file deletion warning, if it provided). >> >> when you pushing gas pedal in your car, or brakes, are there also popups >> which freezes your feet and asks to press yes or no before proceed? >> because wrong decision could cost you much more - your own life. >> >> And having to undo all my work to fix a stupid mistake is a nightmare. >>> The only thing that would make sense for removing confirmation dialogs is >>> editable action history. Take a look at Photoshop. Some 3d apps also have >>> something similar. Every action is recorded at a history ( a list) and >>> there is a gui that allow you to remove individual actions without deleting >>> or affecting other actions. Very cool stuff. >>> >>> that what we did with Ben: there is navigation history, where you can >> find unsaved changes. but people prefer popping up red herrings instead. >> >> >> >> >>> >>> On Wednesday, 8 January 2014, 11:44, Igor Stasenko <siguctua(a)gmail.com> >>> wrote: >>> i want to discard. discard this modal thingies altogether.. >>> and we did that with Ben, but then people turned their nose against it >>> and rolled back the change. >>> >>> >>> On 8 January 2014 17:02, Sean P. DeNigris <sean(a)clipperadams.com>wrote: >>> >>> I still have these un-interact-able pop ups following me around endlessly >>> when I have unaccepted edits in Nautilus. It seems intermittent. Not sure >>> how exactly to reproduceâ¦ Anyone else? >>> >>> b.t.w. the secret seems to be to bring up halos on the pop-up and >>> clicking >>> the (x) halo. Trying to click its buttons only makes it angry >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > I don't think we have to discuss what would be the better alternative. > People have different preferences and different workflows. > Why don't we make a setting for this? Something like "Codepanes can > discard edits", and let Nautilus and other > codepanes behave like the Workspace (I remember a time when workspaces > asked too before discarding edits) > > About the editing history, most people said it is a good idea. The reason > I reverted this back was not someone > doesn't like it. It just didn't worked. > As commented in the bug case: > 1. not alll interactions created an editing history entry. > 2. throwing away the history on window closing was at leas unexpected for > some users. > 3. the history that was used for both, navigation and editing, is limited > to 15 entries > > .. and instead of fixing the above things was thrown away. We will never have good UI if we will use such strategy to develop it. Nicolai > > -- Best regards, Igor Stasenko.

Jan. 9, 2014

Re: [Pharo-dev] Athens SVG Import

by J.F. Rick

OK. I've made a little headway in diagnosing the problem. It seems that one culprit is that the "self changed" thing works differently with Athens than previously. Correct me if I'm wrong, but it seems like sending that method immediately causes the canvas to draw. In contrast, before, it just marked that area as needing to be redrawn and then, on an update cycle, it would redraw the total area that changed. I was using a model-view pattern that had 25 components to it. When each got the update command, it seems to have launched the canvas to draw. When I changed it so that only one changed command was given, the interface became immediately much snappier. Adding a factor of 25 to rendering could cause even fast rendering to be quite noticeable. So, it is not an inherent problem with drawing forms but rather one with changing the programming paradigm. Forms are just noticeably slower to draw than vector components and that exacerbated my problem. Cheers, Jeff On Thu, Jan 9, 2014 at 8:18 AM, J.F. Rick <self(a)je77.com> wrote: > Hmm. Weird. Could it be a linux thing? Bit order or something? Could it be > a transparency issue? Could it be a size of the form? I have forms of size > around 200 x 200. At this point, I haven't numerically investigated it. I > just notice a significant difference in rendering speed as I switch from > forms to SVGs. Perhaps it is having to redraw the entire interface very > often. I'll investigate a bit more when I have some time. > > Cheers, > > Jeff > > > On Thu, Jan 9, 2014 at 2:08 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 8 January 2014 08:59, J.F. Rick <self(a)je77.com> wrote: >> >>> In good news, I was able to implement the S/s functionality and both of >>> my SVGs now load properly. I'll try some more soon and commit the changes >>> once I have tested it a bit more. >>> >>> In bad news, the cacheing was working properly, so I still suspect that >>> rendering forms as a paint is too intensive to be practical for many >>> applications. I'll try to evaluate it a bit more as I replace forms with >>> SVGs. If the forms are causing the problem, then performance should >>> noticeably increase. >>> >>> >> I just did a little comparison: >> >> | surface time | >> surface := AthensCairoSurface extent: 200@200. >> >> surface drawDuring: [ :canvas| >> canvas setPaint: Color red. >> canvas setShape: (0@0 extent: 100@100). >> time := [ 10000 timesRepeat: [ canvas draw ] ] timeToRun. >> ]. >> time >> 0:00:00:00.115 >> ============= >> >> same as above but with: >> canvas setPaint: (ThemeIcons current backIcon). >> >> time >> 0:00:00:00.093 >> =========== >> >> same as above but with: >> (canvas setPaint: (ThemeIcons current backIcon)) repeat. >> >> time >> 0:00:00:00.956 >> >> as you can see, even in slowest case, the throughput is: >> >> 100*100*10000 = 100'000'000 pixels (texels) per second. >> >> >> >>> Cheers, >>> >>> Jeff >>> >>> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Jan. 9, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30680 Home: https://github.com/pharo-project/pharo-core

Jan. 9, 2014

[pharo-project/pharo-core] 029520: 30680

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 0295202bf0788a4e83f5d6a69c7c85a7ff1ac719 https://github.com/pharo-project/pharo-core/commit/0295202bf0788a4e83f5d6a6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-09 (Thu, 09 Jan 2014) Changed paths: M Komitter.package/KomitterUI.class/instance/private/openRemoteManager.st A Komitter.package/PackageRemotesManager.class/README.md A Komitter.package/PackageRemotesManager.class/class/specs/defaultSpec.st A Komitter.package/PackageRemotesManager.class/definition.st A Komitter.package/PackageRemotesManager.class/instance/accessing/packages.st A Komitter.package/PackageRemotesManager.class/instance/accessing/remotes.st A Komitter.package/PackageRemotesManager.class/instance/accessing/remotesTree.st A Komitter.package/PackageRemotesManager.class/instance/initialization/initialize.st A Komitter.package/PackageRemotesManager.class/instance/initialization/initializeDialogWindow_.st A Komitter.package/PackageRemotesManager.class/instance/initialization/initializePresenter.st A Komitter.package/PackageRemotesManager.class/instance/initialization/initializeWidgets.st A Komitter.package/PackageRemotesManager.class/instance/private/change_forRemote_.st A Komitter.package/PackageRemotesManager.class/instance/private/doIfNotSilent_.st A Komitter.package/PackageRemotesManager.class/instance/private/selectedPackageRepositories.st A Komitter.package/PackageRemotesManager.class/instance/private/silentWhile_.st A Komitter.package/PackageRemotesManager.class/instance/private/updateRemoteSelectionFrom_.st A Komitter.package/PackageRemotesManager.class/instance/protocol/initialExtent.st A Komitter.package/PackageRemotesManager.class/instance/protocol/packages_.st A Komitter.package/PackageRemotesManager.class/instance/protocol/title.st M Komitter.package/RemotesManager.class/README.md M Komitter.package/RemotesManager.class/class/specs/defaultSpec.st M Komitter.package/RemotesManager.class/definition.st R Komitter.package/RemotesManager.class/instance/accessing/packages.st M Komitter.package/RemotesManager.class/instance/initialization/initialize.st M Komitter.package/RemotesManager.class/instance/initialization/initializePresenter.st M Komitter.package/RemotesManager.class/instance/initialization/initializeWidgets.st M Komitter.package/RemotesManager.class/instance/private/buildRoots.st R Komitter.package/RemotesManager.class/instance/private/change_forRemote_.st R Komitter.package/RemotesManager.class/instance/private/doIfNotSilent_.st A Komitter.package/RemotesManager.class/instance/private/selected_changed_.st R Komitter.package/RemotesManager.class/instance/private/silentWhile_.st R Komitter.package/RemotesManager.class/instance/private/updateRemoteSelectionFrom_.st M Komitter.package/RemotesManager.class/instance/protocol/initialExtent.st R Komitter.package/RemotesManager.class/instance/protocol/packages_.st A Komitter.package/RemotesManager.class/instance/protocol/selectedChangedBlock_.st A Komitter.package/RemotesManager.class/instance/protocol/selectedRemotes_.st M Morphic-Core.package/Morph.class/instance/announcements/announceDeleted.st M Morphic-Core.package/Morph.class/instance/announcements/announceKeyboardFocusChange_.st M Morphic-Core.package/Morph.class/instance/announcements/announceOpened.st A Morphic-Core.package/Morph.class/instance/announcements/doAnnounce_.st M Nautilus.package/Nautilus.class/class/accessing/groupsManagerFrom_.st M Nautilus.package/Nautilus.class/class/cleanup/cleanUp.st M Nautilus.package/Nautilus.class/class/private/buildGroupManagerFor_.st M RPackage-Core.package/RPackageOrganizer.class/instance/accessing/packageNamed_.st M RPackage-Core.package/RPackageOrganizer.class/instance/accessing/packageNamed_ifAbsent_.st A RPackage-Core.package/RPackageOrganizer.class/instance/private/packageNamedIgnoreCase_ifAbsent_.st M RPackage-Core.package/RPackageSet.class/instance/initialization/initialize_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script333.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30680.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30680 12456 Split Komitter RemotesManager in 2 parts https://pharo.fogbugz.com/f/cases/12456 12513 Big number of Announcer instances https://pharo.fogbugz.com/f/cases/12513 12580 RPackageSet should not work as old PackageInfo https://pharo.fogbugz.com/f/cases/12580/ http://files.pharo.org/image/30/30680.zip

Jan. 9, 2014

Re: [Pharo-dev] A question about AST

by Goubier Thierry

Le 09/01/2014 01:57, Nicolas Passerini a Ã©crit : > I am looking at the AST of a method like this: > > someMethod > ^ SomeClass new > > > It was a surprise to me that the note for 'SomeClass' is an > RBVariableNode instead of a RBClassReference. Which is the best way to > tell if an RBVariableNode represents a global reference or an instance > variable? You test the binding associated with the RBVariableNode self binding isInstance -> instance variable name self binding isLiteral or: [ self isGlobal] Class reference or a global reference (singleton) or a literal self binding isTemp -> temporary Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Jan. 9, 2014

Pharo3 build is green!

by Marcus Denker

FInallyâ¦ a lot of work went into this, and I thank everyone who helped! We are now running 34134 (together) for the 3 architectures...

Jan. 9, 2014