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

[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

MultiByteFileStream #converter - what does it do?

by sheridan＠sheridan-mahoney.com

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? Many thanks, Sheridan

Dec. 17, 2014

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

by phil＠highoctane.be

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. > > 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 > > Which one is going to speed up the headless startup time? Phil

Dec. 17, 2014

14615 Change in Delay semantics when high priority timer event loop stopped

by Ben Coman

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?14353

Dec. 17, 2014

Re: [Pharo-dev] trying to download Hapa'o in a fresh Pharo image (4.0)

by Guillermo Polito

On Tue, Dec 16, 2014 at 10:47 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > But whatâs happen if I load S2py if I have roassal loaded already. Will it > try to load it again? > Well, generally with metacello: - if S2py requires roassal2 version 1 and you have no roassal => it will load it - if S2py requires roassal2 version 1 and you have version 1 => it will not load it again - if S2py requires roassal2 version 2 and you have version 1 => it will update it Guille > Alexandre > > > > On Dec 16, 2014, at 10:35 PM, stepharo <stepharo(a)free.fr> wrote: > > > > > > Le 8/12/14 06:06, Alejandro Infante a Ã©crit : > >> Hello, > >> Actually that version of Hapao is really outdated, currently we are > using S2py, a brand new release of Spy that involve mayor changes in > performance and design using everything that we learnt developing Spy. > >> > >> Since it depends on Roassal2, you have to load it first. > > > > NONO the S2py configuration should load roassal2. To not let end-user > facing that dependency hell. > > I wrote several chapters and example, we wrote a tool to help people > manage dependencies. So it can take less > > then 10 min to respect your users! > > > > I will not ask our students to look at S2py if this is not loadable in > one expression! > > And it should be available in the configurationbrowser. > > > > Stef > >> > >> Gofer new smalltalkhubUser: 'ObjectProfile' > >> project: 'Roassal2'; > >> package: 'ConfigurationOfRoassal2'; > >> load. > >> (Smalltalk at: #ConfigurationOfRoassal2) load. > >> > >> And then we load Spy2. > >> > >> Gofer new smalltalkhubUser: 'ObjectProfile' > >> project: 'S2py'; > >> package: 'S2py'; > >> load. > >> > >> Hapao is already included on Spy2, so you donât have to do anything > else. > >> > >> To use Hapao you can do it from the WorldMenu or using a workspace like: > >> > >> (Hapao2 runTestsForClasses: RTObject withAllSubclasses , RTTest > withAllSubclasses) visualize > >> or > >> (Hapao2 runTestsForPackagesMatching: 'Nautilus*') visualize > >> > >> I have already tried this on today fresh 4.0 image so unless I mess up > on a commit tonight it should work. > >> > >> Let us know how was your experience! All the feedback is welcome. > >> > >> Cheers, > >> Alejandro > >> > >>> On Dec 7, 2014, at 7:56 PM, sheridan(a)sheridan-mahoney.com wrote: > >>> > >>> Hello, > >>> > >>> I am trying to get Hapa'o loaded in a fresh 4.0 image, using the > following command: > >>> > >>> Gofer new > >>> squeaksource: 'Spy'; > >>> package: 'ConfigurationOfSpy'; > >>> load. > >>> (Smalltalk at: #ConfigurationOfSpy) perform: #loadDefault > >>> > >>> and I run across this error: > >>> > >>> This package depends on the following classes: > >>> RBFormatter > >>> You must resolve these dependencies before you will be able to load > these definitions: > >>> HapaoLineCoverage > >>> acceptAssignmentNode: > >>> acceptBlockNode:startBlockString:endBlockString: > >>> acceptCascadeNode: > >>> acceptLiteralArrayNode: > >>> acceptLiteralNode: > >>> acceptMessageNode: > >>> acceptPragmaNode: > >>> acceptReturnNode: > >>> acceptSequenceNode: > >>> acceptVariableNode: > >>> addAllText: > >>> addCoverageAtribute:isCovered: > >>> addText: > >>> coveredCondition > >>> format: > >>> ... > >>> > >>> This isn't something I'm familiar with, can someone tell me how to > resolve it? > >>> > >>> Many thanks, > >>> > >>> Sheridan > >>> > >> > >> > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Dec. 17, 2014

Re: [Pharo-dev] showing all icons

by Peter UhnÃ¡k

Exactly what I needed, thank you! On Wed, Dec 17, 2014 at 3:57 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-12-17 14:41 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> >> Is there a way to show all available ThemeIcons? I think that I've seen >> something some time ago (maybe in Glamour?), but I can't find it now... so >> maybe just my imagination? >> >> Peter >> >> > with spec: > > (TreeModel new roots: (ThemeIcons selectors select: [:each | '*Icon' > match: each asString])); > iconBlock:[:item | Smalltalk ui icons perform:item]; > openWithSpec. > > >

Dec. 17, 2014