September 2016 - Pharo-dev - lists.pharo.org

Synectique is recruiting

by stepharo

Synectique provides comprehensive and sophisticated analysis tools to improve the quality of software, reduce maintenance costs, and thus enable easier software evolution. The company was created in 2013 and already got some renowned customers. To sustain our growth we are looking for a full-time Smalltalk (Pharo) developer with some additional non Smalltalk skills. 2+ years OO programming experience or equivalent, with strong skills in OO design, front-end JavaScript and back-end Seaside/Pharo. The ideal candidate should be comfortable with meta-model approaches, client-side web technologies (HTML, CSS, JavaScript), be familiar with code parsing and master different languages (Java, C++, C#, ADA, Smalltalk). The job is based in Lille, which is centrally located with good connections by train to everywhere (one hour from Paris, 1h20 from London, 35 min from Brussels). Duration: Permanent (CDI) Starting date: September 2016 Salary: depending on skill set/experience Ready to travel if needed. Additional Skills: Object-oriented design/programming Agile Methodologies Fluent in French and/or English Please send your applications to philippe.valenza(a)synectique.eu.

Sept. 21, 2016

PrimitiveFailed: primitive #elementsForwardIdentityTo: in Array failed

by HernÃ¡n Morales Durand

Hi I don't know if this was reported. Apparently there is a problem when migrating a large number of instances, I have aprox. 270,000 instances from which I simply pulled up an ivar in their class to a higher superclass, and a PrimitiveFailed raised. It can be reproduced by installing Territorial in Pharo 5.0 with Spur VM 5.0 from 4 May 2016 in Windows 8.1 (this is the standard image installed using wget command line in msys). Gofer it smalltalkhubUser: 'hernan' project: 'Territorial'; configuration; loadDevelopment. TCityOrganization addOpenGeoCode Then manually install Territorial-HernanMoralesDurand.163 from Monticello. Backwards (installing .163, populating, then .166) also reproduces the issue. Is there a fix for this? --- The full stack --- Array(Object)>>primitiveFailed: Array(Object)>>primitiveFailed Array>>elementsForwardIdentityTo: TerritorialCity class(ClassDescription)>>updateInstances:from:isMeta: TerritorialCity class(ClassDescription)>>updateInstancesFrom: PharoClassInstaller>>updateClass:to: [ 1 to: old size do: [ :index | self updateClass: (old at: index) to: (new at: index) ]. old elementsForwardIdentityTo: new. " Garbage collect away the zombie instances left behind in garbage memory in #updateInstancesFrom: " " If we don't clean up this garbage, a second update would revive them with a wrong layout! " " (newClass rather than oldClass, since they are now both newClass) " Smalltalk garbageCollect ] in PharoClassInstaller>>migrateClasses:to:using: BlockClosure>>ensure: BlockClosure>>valueUnpreemptively PharoClassInstaller>>migrateClasses:to:using: SlotClassBuilder>>migrateClasses: SlotClassBuilder>>apply: SlotClassBuilder>>build PharoClassInstaller class(AbstractClassInstaller class)>>make: [ PharoClassInstaller make: [ :builder | builder superclass: superClass; name: name; layoutClass: (ObjectLayout layoutForType: type); slots: self instanceVariables; sharedVariables: self classVariables; sharedPools: self sharedPoolsString; classSlots: self classInstanceVariables; traitComposition: self traitCompositionCompiled; classTraitComposition: self classTraitCompositionCompiled; comment: comment stamp: commentStamp; category: category; environment: superClass environment ] ] in MCClassDefinition>>createClass BlockClosure>>on:do: MCClassDefinition>>createClass MCClassDefinition>>load MCClassDefinition(MCDefinition)>>addMethodAdditionTo: [ :each | each addMethodAdditionTo: methodAdditions ] in MCPackageLoader>> basicLoadDefinitions [ :each | | newLabel | "Special handling for first and last element" (count = 0 or: [ count + 1 = size or: [ (Time millisecondsSince: lastUpdate) >= msecs ] ]) ifTrue: [ bar current: count. oldLabel = (newLabel := (labelBlock cull: each) ifNil: [ oldLabel ]) ifFalse: [ bar label: newLabel. oldLabel := newLabel ]. lastUpdate := Time millisecondClockValue ]. aBlock value: each. count := count + 1 ] in [ :bar | labelBlock := aStringOrBlock isString ifTrue: [ bar label: aStringOrBlock. [ :dummyItem | aStringOrBlock ] ] ifFalse: [ aStringOrBlock ]. self do: [ :each | | newLabel | "Special handling for first and last element" (count = 0 or: [ count + 1 = size or: [ (Time millisecondsSince: lastUpdate) >= msecs ] ]) ifTrue: [ bar current: count. oldLabel = (newLabel := (labelBlock cull: each) ifNil: [ oldLabel ]) ifFalse: [ bar label: newLabel. oldLabel := newLabel ]. lastUpdate := Time millisecondClockValue ]. aBlock value: each. count := count + 1 ] ] in OrderedCollection(Collection)> >do:displayingProgress:every: OrderedCollection>>do: [ :bar | labelBlock := aStringOrBlock isString ifTrue: [ bar label: aStringOrBlock. [ :dummyItem | aStringOrBlock ] ] ifFalse: [ aStringOrBlock ]. self do: [ :each | | newLabel | "Special handling for first and last element" (count = 0 or: [ count + 1 = size or: [ (Time millisecondsSince: lastUpdate) >= msecs ] ]) ifTrue: [ bar current: count. oldLabel = (newLabel := (labelBlock cull: each) ifNil: [ oldLabel ]) ifFalse: [ bar label: newLabel. oldLabel := newLabel ]. lastUpdate := Time millisecondClockValue ]. aBlock value: each. count := count + 1 ] ] in OrderedCollection(Collection)> >do:displayingProgress:every: BlockClosure>>cull: [ ^ block cull: self ] in [ self prepareForRunning. CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run [ p psValueAt: index put: anObject. aBlock value ] in CurrentJob(DynamicVariable)>>value:during: BlockClosure>>ensure: CurrentJob(DynamicVariable)>>value:during: CurrentJob class(DynamicVariable class)>>value:during: [ self prepareForRunning. CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run BlockClosure>>ensure: Job>>run MorphicUIManager(UIManager)>>displayProgress:from:to:during: ByteString(String)>>displayProgressFrom:to:during: OrderedCollection(Collection)>>do:displayingProgress:every: OrderedCollection(Collection)>>do:displayingProgress: MCPackageLoader>>basicLoadDefinitions [ self basicLoadDefinitions ] in [ self handleLoadErrorsDuring: [ self basicLoadDefinitions ] ] in MCPackageLoader>>basicLoad BlockClosure>>on:do: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ aBlock on: InMidstOfFileinNotification do: [ :notification | notification resume: true ] ] in MCPackageLoader>> handleLoadErrorsDuring: BlockClosure>>on:do: MCPackageLoader>>handleLoadErrorsDuring: [ self handleLoadErrorsDuring: [ self basicLoadDefinitions ] ] in MCPackageLoader>>basicLoad BlockClosure>>ensure: MCPackageLoader>>basicLoad [ self basicLoad ] in MCPackageLoader>>loadWithNameLike: BlockClosure>>ensure: MCPackageLoader>>useChangeSetNamed:during: MCPackageLoader>>useNewChangeSetNamedLike:during: MCPackageLoader>>loadWithNameLike: MCThreeWayMerger(MCMerger)>>loadWithNameLike: MCVersionMerger>>mergeWithNameLike: MCVersionMerger class>>mergeVersion: MCVersion>>merge MCFileRepositoryInspector(MCVersionInspector)>>merge MCFileRepositoryInspector>>merge MCFileRepositoryInspector(MCTool)>>performButtonAction:enabled: PluggableButtonMorph>>performAction: [ :m | (m containsPoint: evt cursorPoint) ifTrue: [ m enabled ifTrue: [ m performAction: evt ] ] ] in PluggableButtonMorph>>mouseUp: Array(SequenceableCollection)>>do: PluggableButtonMorph>>mouseUp: PluggableButtonMorph(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableButtonMorph(Morph)>>handleEvent: PluggableButtonMorph(Morph)>>handleFocusEvent: [ ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self)) ] in HandMorph>>sendFocusEvent:to:clear: BlockClosure>>on:do: WorldMorph(PasteUpMorph)>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [ :h | ActiveHand := h. h processEvents. ActiveHand := nil ] in WorldState>>doOneCycleNowFor: Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle [ [ World doOneCycle. Processor yield. false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess [ self value. Processor terminateActive ] in BlockClosure>>newProcess ------------------------------------------------------------ ------------------- HernÃ¡n

Sept. 21, 2016

Re: [Pharo-dev] How do recover change with epicea?

by Martin Dias

Hi Stef, âNo idea why Epicea didn't log your changes. About "monitor vs. log set"... the two new entries in World Menu > Tools > Epicea... I'd like user opinions to improve naming and UI. I can tell some things introduced in the latest integration. - The Log Set As you know, Epicea Monitor logs code changes (and some IDE events such as MC load/save and refactorings). Such data is placed in .ombu files in a local directory. Each time a Pharo image opens, Epicea Monitor logs code changes into a new ombu file. Those ombu files in the local directory is what is currently called "Log Set". - The Monitor UI shows the code changes since Epicea started to log. ===> This means it shows changes placed in potentially several ombu files. - The Log Set UI shows: -- all the logs in the local directory on the left panel, and -- the content of the selected log in the right panel. ===> This UI visually connects the logs to help user to understand how the ombu files are related. Note that the code changes displayed on the right panel belong to only one log (different than in the Monitor UI, that might show changes in several logs). Cheers, Martin On Tue, Sep 20, 2016 at 4:57 PM, stepharo <stepharo(a)free.fr> wrote: > even better > > Smalltalk tools changeList browseRecentLog > > does not show any changes :) > > So I redownloaded the latest version of tried > > - changes something > > - exist without saving > > - reopening the image > > And I could not reproduce the bug.... Shit. > > So I lost my time. > > Stef > > > > > > Hi >> >> i introduced a loop (yes totally stupid) in menu morph icon :) >> so I had to quit my image. >> I thought that epicea would show me all the changes and I could not find >> how to do it. >> I do not know how to invoke the old recover lost changes... so so far I >> lost 40 min of dev :( >> >> I have no idea what is monitor vs log set in Epicea. >> And log set is just with the changes I'm doing :( not the ones I lost :( >> >> In cutting alpha image it would be good to make sure that we cannot lose >> our work :( >> Stef >> >> >> >> > >

Sept. 21, 2016

Re: [Pharo-dev] EpSelection DNU (Pharo 60231)

by Martin Dias

Thanks Nicolai, both 1 and 2 are fixed in the new release <https://pharo.fogbugz.com/f/cases/19119/Integrate-Epicea-8-0-2>. Martin On Tue, Sep 20, 2016 at 4:25 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > There was a change for icons/iconnamed done on class EpSelection > > 1. this change needs to be done in epiceas repository as well (?) > 2. one call is wrong (EpSelection>>#populateMenu) : > > icon: (self iconNamed: #smallSaveAsIcon); > instead of > icon: (self icons iconNamed: #smallSaveAsIcon); >

Sept. 21, 2016

Re: [Pharo-dev] Version dependent Metacello Platform

by Dale Henrichs

On 9/20/16 11:12 AM, Torsten Bergmann wrote: > Hi, > > the expression > > MetacelloPlatform current defaultRepositoryDescription > > returns the meta repo for pharo 3 ('http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main') > even when run in Pharo 6. > > This is because MetacelloPharoCommonPlatform has a single subclass "MetacelloPharo30Platform". > > I guess this is because Metacello scripting API was integrated back in Pharo 3. Yes ... > Do we need to > update this to a MetacelloPharo60Platform in Pharo 6 ? > This _is_ a feature of Metacello in the sense that if a repository: is not included in a `Metacello new` expression, the default repository is used, but with that said, it is clearly not used very heavily:) I still think it would be useful to be able to write: Metacello new baseline: 'xxxx'; load and get the proper project loaded for the image, but I can't force folks to use this form --- especially if the default isn't correct;) It's still not clear whether folks have actually begun using the scripting API as much as they should --- the old way of sending load to a ConfigurationOf is at least 3 years out of date ... Dale

Sept. 21, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

by Henrik Sperre Johansen

Tudor Girba-2 wrote > Now, this is something cool, I think. Letâs investigate this further. One > issue is whether the Pragma class should be modified to take into account > the new semantics. > > Cheers, > Doru A major disadvantage is that in other Smalltalks supporting tags, block scoping isn't simply ignored/treated as a regular method tag, but a syntax error. So a change would benefit from some degree of coordination. With upcoming split between Clean/Other blocks you also have decide polymorphically the valid execution scope; context-free clean blocks can be executed as examples anywhere, non-clean ones will only be valid inspecting/debugging a live object. The same idea can, for the same reasons, also be applied to implement asserts that are entirely free when disabled; [<assert> param satisfiesSomeCondition] A change in global assert setting could recompile affected methods, adding/removing #value calls to the block in AST as appropriate. -- View this message in context: http://forum.world.st/pharo-project-pharo-core-edd9f3-60220-tp4915481p49163… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 20, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

by Tudor Girba

Now, this is something cool, I think. Letâs investigate this further. One issue is whether the Pragma class should be modified to take into account the new semantics. Cheers, Doru > On Sep 20, 2016, at 10:41 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-09-19 16:24 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > >> On 19 Sep 2016, at 4:03 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >>> >>> On 17 Sep 2016, at 4:17 , Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> >>>> 2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>> >>>>> Hi All, >>>>> >>>>> >>>>> >>>>> _,,,^..^,,,_ (phone) >>>>>> On Sep 14, 2016, at 10:50 PM, Marcus Denker <marcus.denker(a)inria.fr> >>>>>> wrote: >>>>>> >>>>>> >>>>>>>> >>>>>>>> We can change it back and maybe add support for the reformatter to not >>>>>>>> convert it to the literal array #(3 #+ 4) . >>>>>>> >>>>>>> I do not know in fact this is why I asked :) >>>>>>> Now may be my idea to use pragma to get something like pythondoctest is >>>>>>> a bad idea >>>>>>> but I really want to have literal programming. >>>>>>> What do you think? >>>>>> I like the idea to show examples/tests close to code, but pragmas are >>>>>> not really good... >>>>>> >>>>>>> If we have ' ' then it would be good that the syntax higlighter works >>>>>>> with a special mode inside the ' ' >>>>>> >>>>>> it is just a string. How do you know that it contains code? >>>>>> >>>>>> Would you highlight all string in all code as if it contained code? Or >>>>>> would you add this just for >>>>>> Pragmas? But even there, strings are string, not code. >>>>>> >>>>>> I think we can conclude that pragmas are not a good solution to the >>>>>> problem, as they are far >>>>>> too limited to express code. >>>>> >>>>> I think that's not a safe conclusion. We know from Igor's use of Kieran >>>>> arrays for C signatures in the UFFI, and can easily extrapolate here, that >>>>> arbitrary Smalltalk expressions /can/ be expressed in literal arrays. S >>>>> expressions work for lisp. >>>>> >>>>> In this particular case special casing pretty printing of literal arrays >>>>> in pragmas would be all that's needed to make the code look beautiful. Why >>>>> throw the baby out with the bath water? It would be so easy to make this >>>>> work well. >>>> >>>> >>>> We can try this as well. And it is far more easier to work with this >>>> expressions if they are pragma arguments, than to parse the comment to find >>>> some code within. >>>> On the other hand, it looks much nicer if we have the examples right in the >>>> method doc. you have some text describing the method, some code, some more >>>> text about the reslt. >>>> >>>> >>>>> >>>>> >>>>> The only thing I'd do would be to print like this to make it clear that >>>>> the argument t is a literal Array and not some magic form of code: >>>>> >>>>> <expr: #(3 + 4) result: 7> >>>>> >>>> >>>> Yes, I would like to change this anyway, even for literal arrays for ffi, >>>> calls like >>>> >>>> mouseStateX: x y: y >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >>>> errorCode> >>>> ^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) ) >>>> >>>> this will be reformatted to >>>> >>>> mouseStateX: x y: y >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >>>> 'errorCode'> >>>> ^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* #y)) >>> >>> errr, yuck! Thats not pretty at all. Is there some way to avoid >>> that? As I've been getting started with FFI its been really nice >>> visually to see a *direct* correspondence between the C header file >>> declaration and the in-Image method. >> >> +1, that's about the main thought behind it... >> As long as the only required use of a # inside of literal arrays is differentiating whether something is a literal string or symbol, changing to format *all* symbols using it seems somewhat overzealous. >> >> Personally, if a solution using method properties/+ browser improvements to show/create them in a good way is out of the question, >> I have a weakness for using empty blocks as method-local, syntax-highlighted code comments (at least compared to special comment syntax, or pragmas backed by a whole literal -> ST parser). >> Though lately, the code critic (rightly, and very usefully, in the cases where it's a user error) points out they are dead code, and the IR optimizes them out entirely, meaning they miss out on senders/implementors/refactorings functionality. (Full blocks would potentially let us change the IR to leave them alone, put them in the literal slot and be searchable, at no additional runtime-cost/use in bytecodes) >> >> Cheers, >> Henry > > Now imagine if tags were scoped, and you could do > > Number >> #+ aNumber > <prim ....> > [ <insertInlineExampleTagNameHere> 3 + 4 == 7 ]. > ^self fallbackAdd: aNumber > > And have the browser pick it up, and either > - collapse it > - display text with alpha < 1 > > Make the code critic aware as well, and no more warnings of unused blocks when used for examples! > > Cheers, > Henry > > Hm, dead blocks, nice idea. > > see attached cs, you can file it in and have to uncomment one line in RBParser>>#parseBlock (the parsePragmasInto: aNode line) > to activate pragmas in blocks, now you can add a "dead block" like > > [<example> 3+4] > > and the icon styler lets you execute (inspect) the code. > (Just a quick and dirty implementation) > > > > <exampmle_blocks.cs><example_blocks.png> -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Sept. 20, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

by Nicolai Hess

2016-09-19 16:24 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 19 Sep 2016, at 4:03 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > > On 17 Sep 2016, at 4:17 , Ben Coman <btc(a)openInWorld.com > <btc(a)openinworld.com>> wrote: > > On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > 2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > Hi All, > > > > _,,,^..^,,,_ (phone) > > On Sep 14, 2016, at 10:50 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > > > We can change it back and maybe add support for the reformatter to not > convert it to the literal array #(3 #+ 4) . > > > I do not know in fact this is why I asked :) > Now may be my idea to use pragma to get something like pythondoctest is > a bad idea > but I really want to have literal programming. > What do you think? > > I like the idea to show examples/tests close to code, but pragmas are > not really good... > > If we have ' ' then it would be good that the syntax higlighter works > with a special mode inside the ' ' > > > it is just a string. How do you know that it contains code? > > Would you highlight all string in all code as if it contained code? Or > would you add this just for > Pragmas? But even there, strings are string, not code. > > I think we can conclude that pragmas are not a good solution to the > problem, as they are far > too limited to express code. > > > I think that's not a safe conclusion. We know from Igor's use of Kieran > arrays for C signatures in the UFFI, and can easily extrapolate here, that > arbitrary Smalltalk expressions /can/ be expressed in literal arrays. S > expressions work for lisp. > > In this particular case special casing pretty printing of literal arrays > in pragmas would be all that's needed to make the code look beautiful. Why > throw the baby out with the bath water? It would be so easy to make this > work well. > > > > We can try this as well. And it is far more easier to work with this > expressions if they are pragma arguments, than to parse the comment to find > some code within. > On the other hand, it looks much nicer if we have the examples right in the > method doc. you have some text describing the method, some code, some more > text about the reslt. > > > > > The only thing I'd do would be to print like this to make it clear that > the argument t is a literal Array and not some magic form of code: > > <expr: #(3 + 4) result: 7> > > > Yes, I would like to change this anyway, even for literal arrays for ffi, > calls like > > mouseStateX: x y: y > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode> > ^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) ) > > this will be reformatted to > > mouseStateX: x y: y > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > 'errorCode'> > ^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* #y)) > > > errr, yuck! Thats not pretty at all. Is there some way to avoid > that? As I've been getting started with FFI its been really nice > visually to see a *direct* correspondence between the C header file > declaration and the in-Image method. > > > +1, that's about the main thought behind it... > As long as the only required use of a # inside of literal arrays is > differentiating whether something is a literal string or symbol, changing > to format *all* symbols using it seems somewhat overzealous. > > Personally, if a solution using method properties/+ browser improvements > to show/create them in a good way is out of the question, > I have a weakness for using empty blocks as method-local, > syntax-highlighted code comments (at least compared to special comment > syntax, or pragmas backed by a whole literal -> ST parser). > Though lately, the code critic (rightly, and very usefully, in the cases > where it's a user error) points out they are dead code, and the IR > optimizes them out entirely, meaning they miss out on senders/implementors/refactorings > functionality. (Full blocks would potentially let us change the IR to leave > them alone, put them in the literal slot and be searchable, at no > additional runtime-cost/use in bytecodes) > > Cheers, > Henry > > > Now imagine if tags were scoped, and you could do > > Number >> #+ aNumber > <prim ....> > [ <insertInlineExampleTagNameHere> 3 + 4 == 7 ]. > ^self fallbackAdd: aNumber > > And have the browser pick it up, and either > - collapse it > - display text with alpha < 1 > > Make the code critic aware as well, and no more warnings of unused blocks > when used for examples! > > Cheers, > Henry > Hm, dead blocks, nice idea. see attached cs, you can file it in and have to uncomment one line in RBParser>>#parseBlock (the parsePragmasInto: aNode line) to activate pragmas in blocks, now you can add a "dead block" like [<example> 3+4] and the icon styler lets you execute (inspect) the code. (Just a quick and dirty implementation)

Sept. 20, 2016

Re: [Pharo-dev] glitches in text selection

by Nicolai Hess

Yes, see case 19113, fixed in 60233 2016-09-20 21:35 GMT+02:00 stepharo <stepharo(a)free.fr>: > Since I'm selecting a lot Smalltalk ui icons.... I noticed that there is a > bug in text selection. > > I thought it was me but no I select well the beginning of the expression > that I see the cursor jumping around....And missing > a couple of characters. > > > Stef > > >

Sept. 20, 2016

Re: [Pharo-dev] How do recover change with epicea?

by stepharo

even better Smalltalk tools changeList browseRecentLog does not show any changes :) So I redownloaded the latest version of tried - changes something - exist without saving - reopening the image And I could not reproduce the bug.... Shit. So I lost my time. Stef > Hi > > i introduced a loop (yes totally stupid) in menu morph icon :) > so I had to quit my image. > I thought that epicea would show me all the changes and I could not > find how to do it. > I do not know how to invoke the old recover lost changes... so so far > I lost 40 min of dev :( > > I have no idea what is monitor vs log set in Epicea. > And log set is just with the changes I'm doing :( not the ones I lost :( > > In cutting alpha image it would be good to make sure that we cannot > lose our work :( > Stef > > >

Sept. 20, 2016