- Pharo-dev - lists.pharo.org

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

[pharo-project/pharo-core]

by GitHub

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

Dec. 18, 2014

Re: [Pharo-dev] SODD

by Sean P. DeNigris

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 ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/SODD-tp4795593p4796283.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 18, 2014

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

by Ben Coman

phil(a)highoctane.be wrote: > > > On Wed, Dec 17, 2014 at 4:51 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@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. > > 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?14615> > > https://pharo.fogbugz.com/__default.asp?14353 > <https://pharo.fogbugz.com/default.asp?14353> > > > Which one is going to speed up the headless startup time? > > Phil > > Neither will affect it directly. However it might take my interest to look into that after I'm done with my Delay refactorings, so the quicker they get through... ;) (of course, answers should be on a technical basis, not horse trading) So what do you do to convert/run as a headless image? cheers -ben

Dec. 17, 2014

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

by Sven Van Caekenberghe

> 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. The silly thing is that both MultiByteFileStream and TextConverter convert from wrongly encoded strings to correctly encoded strings. ZnCharacter[Read|Write]Stream and ZnCharacterEncoder do the correct thing. Sven

Dec. 17, 2014

Epicea

by Martin Dias

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. 17, 2014