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

Re: [Pharo-dev] SODD

by kilon alios

Its true at times SO goes into "crazy mode" and closes useful questions and downvotes good answer, its a known condition as "human condition" , but overall SO is very useful for getting answer to questions and definitely is good promotion of pharo. Please note also that a question can be turned into wiki which also useful. I closely follow SO pharo tag and I track this tag and smalltalk tag and I am notified for any new questions using these tags. Surprising the majority of smalltalk questions are pharo questions which is very nice indeed. I dont know how much work would be if the pharo website would offer an online forum. If pharo grows in popularity I am not a fan of managing my messages via a mailing list. Blender which has already an extremely popular forum here (with at least 1 million posts) http://blenderartists.org/forum/ , has also chose to move to Stack exchance and has its own domain there for questions about blender. Emacs also recently ported to stack exchange. So Stack Exchange is here to stay and will all its disadvantages still a very good deal for pharo. Stack exchange, with Stackoverflow a part of it, is actually huge and probably the most popular ? forum ? out there and it keeps growing.

Dec. 18, 2014

Re: [Pharo-dev] 14615 Change in Delay semantics when high priority timer event loop stopped

by Guillermo Polito

On Wed, Dec 17, 2014 at 4:51 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > I'm looking for some community feedback on Case 14615. When the high > priority Delay timer event loop is stopped, there are two basic choices: > > 1. Delays wait indefinitely, since their delaySemaphore is never signaled, > and so for example, the UI locks up. > > 2. Delays are ignored, proceeding immediately. This would let the UI > continue working, give you a chance to restart the timer event loop, or > change the DelayScheduler algorithm on-the-fly (e.g. mutex, semaphore, > spinlock). > > The system currently does (1.). This is impeding integration of > Case 14252 to change Delays from millisecond to microsecond clock, since > as a Preload the Delay timer event loop is stopped to load the slice. > Did you try to do the switch in another process? [ oldDelayLoop stop. newDelayLoop start. ] forkAt: Processor highestPriority. That should do that outside of the UI event loop, and so the new delay process installation will not be suspended forever. Also, is there any kind of migration from the old delays to the new delay process? Or they are shared and as soon as the new delay loop starts it handles the old delays? > > I'd like to change it to (2.), which can be done in a single line. > > Your thoughts ? > > > https://pharo.fogbugz.com/default.asp?14615 > > https://pharo.fogbugz.com/default.asp?14353 > >

Dec. 18, 2014

Re: [Pharo-dev] MultiByteFileStream #converter - what does it do?

by Guillermo Polito

On Wed, Dec 17, 2014 at 7:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 17 Dec 2014, at 19:42, sheridan(a)sheridan-mahoney.com wrote: > > > > > > Hi there, > > > > I am still working my way through MultiByteFileStream tests, and have > come across the messages #converter and #converter: . I would like to be > able to test these - could someone explain briefly how the converters are > used in this class? > > In order to convert from bytes to characters and vice versa, > MultiByteFileStream uses a TextConverter subclass instance as a helper. The > messages #nextFromStream: and #nextPut:onStream: are the main interface > between the two. > This guy is loudly crying for a decorator. I wonder when Xtreams could be pushed... > > The silly thing is that both MultiByteFileStream and TextConverter convert > from wrongly encoded strings to correctly encoded strings. So it corrects encodings? :P I didn't know that! They are flawless!!! > ZnCharacter[Read|Write]Stream and ZnCharacterEncoder do the correct thing. > > Sven >

Dec. 18, 2014

Re: [Pharo-dev] Epicea

by Martin Dias

In this screenshot you can see an Epicea Log Browser where the item in the bottom (EpOracleRunner: baseDirectory ---> analysisDataSet) represents an instance variable rename, and that triggered a modification in 5 methods of EpOracleRunner. On Thu, Dec 18, 2014 at 1:37 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > On Thu, Dec 18, 2014 at 11:23 AM, Dennis Schetinin <chaetal(a)gmail.com> wrote: >> Is it possible log refactorings this way? > > Yes, it is possible. But this feature of recording refactorings (and > MC save/load, and test runs as well) belongs to an optional package, > because it overrides methods in system and I decided to have a core > package without that. > > MartÃn > >> >> >> -- >> >> Best regards, >> >> >> Dennis Schetinin >> >> >> 2014-12-17 22:50 GMT+04:00 Martin Dias <tinchodias(a)gmail.com>: >>> >>> Hi all, >>> >>> I would like to ask your opinion on Epicea, a tool that logs code >>> changes you do in your Pharo image. In a few words, its comparable to >>> the traditional "change sorter + .changes file mechanism ": >>> >>> - it's serializable to/from a textual format file, that you can file >>> in/file out. >>> - the changes are logged to file immediately after they are announced >>> by the system. >>> - there is a UI where you can browse/manipulate the changes >>> >>> The main difference is that in .changes/.cs, the history is modelled >>> as a sequence of chunks (DoIt's or just strings) that the tools *try* >>> to parse in order to know what happened. In Epicea, the history >>> elements are reified. For example, EpMethodModification models a >>> method that was modified from an old state to a new state, so it >>> answers to #oldMethod with a RGMethod holding the source code and the >>> protocol as it was before the code change. >>> >>> I have been working on it during last time, it has been used by >>> several users, and it's quite stable. The project is in a "work in >>> progress" state, but I think it can be useful. >>> >>> To install it in latest Pharo4: >>> >>> Gofer new >>> smalltalkhubUser: #MartinDias project: #Epicea; >>> configuration; >>> load. >>> (#ConfigurationOfEpicea asClass project version: '4.7') load. >>> >>> To try it: >>> >>> 1. Word Menu -> Tools -> Epicea -> Ensure logging >>> 2. Word Menu -> Tools -> Epicea -> Log >>> 3. Open Nautilus and perform some changes >>> 4. Check they are displayed in the log open in 2. >>> 5. You can undo, redo, comment and file out log entries. >>> >>> Cheers, >>> MartÃn >>> >>

Dec. 18, 2014

Re: [Pharo-dev] Epicea

by Martin Dias

On Thu, Dec 18, 2014 at 11:23 AM, Dennis Schetinin <chaetal(a)gmail.com> wrote: > Is it possible log refactorings this way? Yes, it is possible. But this feature of recording refactorings (and MC save/load, and test runs as well) belongs to an optional package, because it overrides methods in system and I decided to have a core package without that. MartÃn > > > -- > > Best regards, > > > Dennis Schetinin > > > 2014-12-17 22:50 GMT+04:00 Martin Dias <tinchodias(a)gmail.com>: >> >> Hi all, >> >> I would like to ask your opinion on Epicea, a tool that logs code >> changes you do in your Pharo image. In a few words, its comparable to >> the traditional "change sorter + .changes file mechanism ": >> >> - it's serializable to/from a textual format file, that you can file >> in/file out. >> - the changes are logged to file immediately after they are announced >> by the system. >> - there is a UI where you can browse/manipulate the changes >> >> The main difference is that in .changes/.cs, the history is modelled >> as a sequence of chunks (DoIt's or just strings) that the tools *try* >> to parse in order to know what happened. In Epicea, the history >> elements are reified. For example, EpMethodModification models a >> method that was modified from an old state to a new state, so it >> answers to #oldMethod with a RGMethod holding the source code and the >> protocol as it was before the code change. >> >> I have been working on it during last time, it has been used by >> several users, and it's quite stable. The project is in a "work in >> progress" state, but I think it can be useful. >> >> To install it in latest Pharo4: >> >> Gofer new >> smalltalkhubUser: #MartinDias project: #Epicea; >> configuration; >> load. >> (#ConfigurationOfEpicea asClass project version: '4.7') load. >> >> To try it: >> >> 1. Word Menu -> Tools -> Epicea -> Ensure logging >> 2. Word Menu -> Tools -> Epicea -> Log >> 3. Open Nautilus and perform some changes >> 4. Check they are displayed in the log open in 2. >> 5. You can undo, redo, comment and file out log entries. >> >> Cheers, >> MartÃn >> >

Dec. 18, 2014

Re: [Pharo-dev] SODD

by Mark Bestley

On 18/12/2014 02:21, Sean P. DeNigris wrote: > Uko2 wrote >> Yes, these questions are very poor > > The third time someone from that programming class asked the exact same > question about overriding #compile:, I answered that they should check the > answer to either of their classmates identical questions... I got down-voted > and the answer was deleted. Apparently, SO is a great way for the lazy to > get their homework done for them with 0 effort on their part, and it is > sacrilege to actively oppose that ;) > > There is a function designed for exactly this case - it is to mark (flag or vote) to close the question as duplicate. Adding an answer is adding to the noise which is likely why it got deleted. However SO does not provide as much help as it could to find duplicates -- Mark

Dec. 18, 2014

Re: [Pharo-dev] Epicea

by Dennis Schetinin

Yeah, that's I was asking about: it should be used (finally) for version control! -- Best regards, Dennis Schetinin 2014-12-18 14:42 GMT+04:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > > Hi Martin, > > I think this is the great effort and it should be, at some point, > integrated to Pharo â and replace the current *.changes format. Then I > believe it is worth to think how to change Pharo core the way, Epicea can > also log higher actions, e.g. class cloning, refactoring, renaming. > > Cheers, > Juraj > > > On 17. Dec 2014, at 19:50, Martin Dias <tinchodias(a)gmail.com> wrote: > > > > Hi all, > > > > I would like to ask your opinion on Epicea, a tool that logs code > > changes you do in your Pharo image. In a few words, its comparable to > > the traditional "change sorter + .changes file mechanism ": > > > > - it's serializable to/from a textual format file, that you can file > > in/file out. > > - the changes are logged to file immediately after they are announced > > by the system. > > - there is a UI where you can browse/manipulate the changes > > > > The main difference is that in .changes/.cs, the history is modelled > > as a sequence of chunks (DoIt's or just strings) that the tools *try* > > to parse in order to know what happened. In Epicea, the history > > elements are reified. For example, EpMethodModification models a > > method that was modified from an old state to a new state, so it > > answers to #oldMethod with a RGMethod holding the source code and the > > protocol as it was before the code change. > > > > I have been working on it during last time, it has been used by > > several users, and it's quite stable. The project is in a "work in > > progress" state, but I think it can be useful. > > > > To install it in latest Pharo4: > > > > Gofer new > > smalltalkhubUser: #MartinDias project: #Epicea; > > configuration; > > load. > > (#ConfigurationOfEpicea asClass project version: '4.7') load. > > > > To try it: > > > > 1. Word Menu -> Tools -> Epicea -> Ensure logging > > 2. Word Menu -> Tools -> Epicea -> Log > > 3. Open Nautilus and perform some changes > > 4. Check they are displayed in the log open in 2. > > 5. You can undo, redo, comment and file out log entries. > > > > Cheers, > > MartÃn > > > > >

Dec. 18, 2014

Re: [Pharo-dev] Epicea

by Juraj Kubelka

Hi Martin, I think this is the great effort and it should be, at some point, integrated to Pharo â and replace the current *.changes format. Then I believe it is worth to think how to change Pharo core the way, Epicea can also log higher actions, e.g. class cloning, refactoring, renaming. Cheers, Juraj > On 17. Dec 2014, at 19:50, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi all, > > I would like to ask your opinion on Epicea, a tool that logs code > changes you do in your Pharo image. In a few words, its comparable to > the traditional "change sorter + .changes file mechanism ": > > - it's serializable to/from a textual format file, that you can file > in/file out. > - the changes are logged to file immediately after they are announced > by the system. > - there is a UI where you can browse/manipulate the changes > > The main difference is that in .changes/.cs, the history is modelled > as a sequence of chunks (DoIt's or just strings) that the tools *try* > to parse in order to know what happened. In Epicea, the history > elements are reified. For example, EpMethodModification models a > method that was modified from an old state to a new state, so it > answers to #oldMethod with a RGMethod holding the source code and the > protocol as it was before the code change. > > I have been working on it during last time, it has been used by > several users, and it's quite stable. The project is in a "work in > progress" state, but I think it can be useful. > > To install it in latest Pharo4: > > Gofer new > smalltalkhubUser: #MartinDias project: #Epicea; > configuration; > load. > (#ConfigurationOfEpicea asClass project version: '4.7') load. > > To try it: > > 1. Word Menu -> Tools -> Epicea -> Ensure logging > 2. Word Menu -> Tools -> Epicea -> Log > 3. Open Nautilus and perform some changes > 4. Check they are displayed in the log open in 2. > 5. You can undo, redo, comment and file out log entries. > > Cheers, > MartÃn >

Dec. 18, 2014

Re: [Pharo-dev] Epicea

by Dennis Schetinin

Is it possible log refactorings this way? -- Best regards, Dennis Schetinin 2014-12-17 22:50 GMT+04:00 Martin Dias <tinchodias(a)gmail.com>: > > Hi all, > > I would like to ask your opinion on Epicea, a tool that logs code > changes you do in your Pharo image. In a few words, its comparable to > the traditional "change sorter + .changes file mechanism ": > > - it's serializable to/from a textual format file, that you can file > in/file out. > - the changes are logged to file immediately after they are announced > by the system. > - there is a UI where you can browse/manipulate the changes > > The main difference is that in .changes/.cs, the history is modelled > as a sequence of chunks (DoIt's or just strings) that the tools *try* > to parse in order to know what happened. In Epicea, the history > elements are reified. For example, EpMethodModification models a > method that was modified from an old state to a new state, so it > answers to #oldMethod with a RGMethod holding the source code and the > protocol as it was before the code change. > > I have been working on it during last time, it has been used by > several users, and it's quite stable. The project is in a "work in > progress" state, but I think it can be useful. > > To install it in latest Pharo4: > > Gofer new > smalltalkhubUser: #MartinDias project: #Epicea; > configuration; > load. > (#ConfigurationOfEpicea asClass project version: '4.7') load. > > To try it: > > 1. Word Menu -> Tools -> Epicea -> Ensure logging > 2. Word Menu -> Tools -> Epicea -> Log > 3. Open Nautilus and perform some changes > 4. Check they are displayed in the log open in 2. > 5. You can undo, redo, comment and file out log entries. > > Cheers, > MartÃn > >

Dec. 18, 2014

[pharo-project/pharo-core] 1b0488: 40418

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 1b04885e58f166b6f1fa413f22308273c703126d https://github.com/pharo-project/pharo-core/commit/1b04885e58f166b6f1fa413f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-18 (Thu, 18 Dec 2014) Changed paths: M ConfigurationOfShoreLineReporter.package/ConfigurationOfShoreLineReporter.class/instance/versions/stable_.st A ConfigurationOfShoreLineReporter.package/ConfigurationOfShoreLineReporter.class/instance/versions/version011_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script418.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40418.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M ShoreLine-Report-UI.package/SlReportWindow.class/class/specs/defaultSpec.st A ShoreLine-Report-UI.package/SlReportWindow.class/class/text/helpText.st A ShoreLine-Report-UI.package/SlReportWindow.class/class/text/popupText.st M ShoreLine-Report-UI.package/SlReportWindow.class/definition.st R ShoreLine-Report-UI.package/SlReportWindow.class/instance/accessing/displayReportContents.st R ShoreLine-Report-UI.package/SlReportWindow.class/instance/accessing/displayReportSummary.st A ShoreLine-Report-UI.package/SlReportWindow.class/instance/accessing/help.st A ShoreLine-Report-UI.package/SlReportWindow.class/instance/accessing/help_.st A ShoreLine-Report-UI.package/SlReportWindow.class/instance/accessing/reportSummary.st A ShoreLine-Report-UI.package/SlReportWindow.class/instance/actions/displayReportContents.st A ShoreLine-Report-UI.package/SlReportWindow.class/instance/actions/openHelp.st R ShoreLine-Report-UI.package/SlReportWindow.class/instance/initialization/initializeAutoSubmit.st A ShoreLine-Report-UI.package/SlReportWindow.class/instance/initialization/initializeControls.st M ShoreLine-Report-UI.package/SlReportWindow.class/instance/initialization/initializePresenter.st M ShoreLine-Report-UI.package/SlReportWindow.class/instance/initialization/initializeWidgets.st Log Message: ----------- 40418 14635 ShoreLine Reporter version 0.1.1 https://pharo.fogbugz.com/f/cases/14635 http://files.pharo.org/image/40/40418.zip

Dec. 18, 2014