- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Re: Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

by Eliot Miranda

Hi Ron, Hi All, On Thu, Sep 22, 2016 at 11:58 AM, Ron Teitelbaum <ron(a)usmedrec.com> wrote: > Hi All, > > > > Sorry Iâm joining this conversation late. > > > > We are using ImageSegment for transferring croquet island state. Is this > something covered in the changes from Bert or are we talking about dropping > ImageSegment altogether? > I suppose I should explain. At ESUG Bert and others announced support for Toys in Squeak 5.1. As part of this work, ImageSegment loading and saving was moved from the VM up into pure Smalltalk code. This allows Squeak 5.1 (Spur) to load image segments saved on pre-Spur VMs. Consequent;ly we no longer need VM support for ImageSegment. Instead we can use the pure image-level code Bert has kindly written. The question is then at what point can we nuke the Spur VM support, since it is now superfluous. Bert, am I jumping the gun? Do we still need to write image-level support for writing image segments? If this is the case, Igor Stasenko described a primitive for collecting the set of objects to be written out. It is the initial part of the segment-writing primitive that collects the transitive closure of objects reachable only from those root objects. > > > All the best, > > > > Ron Teitelbaum > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *Eliot Miranda > *Sent:* Thursday, September 22, 2016 2:47 PM > *To:* Squeak Virtual Machine Development Discussion > *Cc:* Pharo Development List; The general-purpose Squeak developers list > *Subject:* Re: [Pharo-dev] [Vm-dev] Re: Nuking VM ImageSegment support > (was Re: [squeak-dev] Daily Commit Log; System-bf.916) > > > > Hi Max, > > > > On Thu, Sep 22, 2016 at 11:42 AM, Max Leske <maxleske(a)gmail.com> wrote: > > > > > > On 22 Sep 2016, at 20:28, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Bert, Hi All, > > > > On Thu, Sep 15, 2016 at 2:55 PM, <commits(a)source.squeak.org> wrote: > > [snip] > > http://lists.squeakfoundation.org/pipermail/packages/2016- > September/068930.html > > Name: System-bf.916 > Ancestors: System-bf.915 > > Replace VM-level ImageSegment loading with a Smalltalk implementation for > old (interpreter-era) projects. > > Also removes support for writing segments. > > This overrides the Spur support introduced in System-eem.758. > > > > So one question is should we delete VM support for ImageSegment from the > Spur VM? There's at least 1.5k of generated source for the Spur > ImageSegment load and save support, some 2% of the interpreter/primitives > source code. That's a lot, and the code is complex and ugly. If it never > really worked before IMO we should nuke it asap. If it worked in some > fashion perhaps we can schedule its demise for the 6.0 release's VM. > > > > What do others think? > > > > As long as you donât remove it from the Cog VMâs until I no longer need it > Iâm fine with that. > > > > And when would that be? Do you mean that you use it in ways not covered > by Bert's modifications (which render the VM support superfluous), or do > you mean that you use ImageSegment as a naive consumer and are happy just > so long as it works? > > > > > > Max > > > > > > _,,,^..^,,,_ > > best, Eliot > > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > > > -- _,,,^..^,,,_ best, Eliot

Sept. 22, 2016

Re: [Pharo-dev] [Vm-dev] Re: Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

by Ron Teitelbaum

Hi All, Sorry Iâm joining this conversation late. We are using ImageSegment for transferring croquet island state. Is this something covered in the changes from Bert or are we talking about dropping ImageSegment altogether? All the best, Ron Teitelbaum From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Eliot Miranda Sent: Thursday, September 22, 2016 2:47 PM To: Squeak Virtual Machine Development Discussion Cc: Pharo Development List; The general-purpose Squeak developers list Subject: Re: [Pharo-dev] [Vm-dev] Re: Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916) Hi Max, On Thu, Sep 22, 2016 at 11:42 AM, Max Leske <maxleske(a)gmail.com> wrote: On 22 Sep 2016, at 20:28, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: Hi Bert, Hi All, On Thu, Sep 15, 2016 at 2:55 PM, <commits(a)source.squeak.org> wrote: [snip] http://lists.squeakfoundation.org/pipermail/packages/2016-September/068930.… Name: System-bf.916 Ancestors: System-bf.915 Replace VM-level ImageSegment loading with a Smalltalk implementation for old (interpreter-era) projects. Also removes support for writing segments. This overrides the Spur support introduced in System-eem.758. So one question is should we delete VM support for ImageSegment from the Spur VM? There's at least 1.5k of generated source for the Spur ImageSegment load and save support, some 2% of the interpreter/primitives source code. That's a lot, and the code is complex and ugly. If it never really worked before IMO we should nuke it asap. If it worked in some fashion perhaps we can schedule its demise for the 6.0 release's VM. What do others think? As long as you donât remove it from the Cog VMâs until I no longer need it Iâm fine with that. And when would that be? Do you mean that you use it in ways not covered by Bert's modifications (which render the VM support superfluous), or do you mean that you use ImageSegment as a naive consumer and are happy just so long as it works? Max _,,,^..^,,,_ best, Eliot -- _,,,^..^,,,_ best, Eliot

Sept. 22, 2016

Re: [Pharo-dev] ZnPortNotANumber exception when loading from local clone dir (following Metacello Guide)

by Dale Henrichs

On 09/22/2016 12:41 AM, Sven Van Caekenberghe wrote: >> On 22 Sep 2016, at 00:19, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> Hi Sven, >> >> thanks. Did not notice that I need three instead of two slashes. So no need >> to explicitly convert to ZnUrl. >> >> So for the records this is what works: >> >> >> pathToPackageDirectory := 'C:\ClonedRepo\packages'. >> Metacello new >> baseline: 'MyProject'; >> repository: ('gitfiletree:///', pathToPackageDirectory) ; >> load. > So mixing back & forward slashes works ? Pretty weird ;-) Yes that is interesting ... in Metacello for Pharo, `('/', pathToPackageDirectory ) asFileReference` (stripping the leading 'filetree://') is being used to create the FileTree repository from the repository description ... so apparently this is how FileSystem deals with windows pathnames ??? Oh wait, that is a gitfiletee url ... not sure how that is handles ... Dale > >> Thanks >> T. >> >>> Gesendet: Dienstag, 20. September 2016 um 20:41 Uhr >>> Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> >>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> Betreff: Re: [Pharo-dev] ZnPortNotANumber exception when loading from local clone dir (following Metacello Guide) >>> >>> Hi Torsten, >>> >>> Just for the ZnUrl part, have a look at >>> >>> ZnFileUrlTests>>#testWindowsDriveNamesInFileUrl >>> >>> AFAIK, your example should be written as: >>> >>> ('filetree:///' , 'C:/ClonedRepo/packages') asZnUrl. >>> >>> Or maybe, >>> >>> (FileLocator C / 'ClonedRepo' / 'packages') asZnUrl. >>> >>> Sven >>> >>>> On 20 Sep 2016, at 20:30, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> >>>> Hi, >>>> >>>> according to the Metacello quide on [1] in section "Prime Metacello registry" one can write >>>> >>>> | pathToPackageDirectory | >>>> "edit to match the path to your chosen package directory" >>>> pathToPackageDirectory := '/opt/git/Sample/packages'. >>>> Metacello new >>>> baseline: 'Sample'; >>>> repository: 'filetree://', pathToPackageDirectory; >>>> load. >>>> >>>> Adopting this for a Windows path I have: >>>> >>>> | pathToPackageDirectory | >>>> pathToPackageDirectory := 'C:\ClonedRepo\packages'. >>>> Metacello new >>>> baseline: 'MyProject'; >>>> repository: 'filetree://', pathToPackageDirectory; >>>> load. >>>> >>>> But I get a ZnPortNotANumber exception, even when I use a diffent protocol like "client://". >>>> Tried this in Pharo 6.0 Latest update: #60233 >>>> >>>> What I want to do (on Windows) is to load all project packages from a local cloned git >>>> directory (not a remote GitHub) using the dependencies given in the Baseline. >>>> >>>> Did I miss something, is it just broken or the docu not up to date? If so is this a parsing issue on the Zinc URLs >>>> or an issue of Metacello API? >>>> >>>> Thanks >>>> T. >>>> >>>> [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStart… >>>> >>> >>> >

Sept. 22, 2016

Re: [Pharo-dev] [Vm-dev] Re: Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

by Eliot Miranda

Hi Max, On Thu, Sep 22, 2016 at 11:42 AM, Max Leske <maxleske(a)gmail.com> wrote: > > > On 22 Sep 2016, at 20:28, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Bert, Hi All, > > On Thu, Sep 15, 2016 at 2:55 PM, <commits(a)source.squeak.org> wrote: > [snip] > >> http://lists.squeakfoundation.org/pipermail/packages/2016-Se >> ptember/068930.html >> >> Name: System-bf.916 >> Ancestors: System-bf.915 >> >> Replace VM-level ImageSegment loading with a Smalltalk implementation for >> old (interpreter-era) projects. >> >> Also removes support for writing segments. >> >> This overrides the Spur support introduced in System-eem.758. >> > > So one question is should we delete VM support for ImageSegment from the > Spur VM? There's at least 1.5k of generated source for the Spur > ImageSegment load and save support, some 2% of the interpreter/primitives > source code. That's a lot, and the code is complex and ugly. If it never > really worked before IMO we should nuke it asap. If it worked in some > fashion perhaps we can schedule its demise for the 6.0 release's VM. > > What do others think? > > > As long as you donât remove it from the Cog VMâs until I no longer need it > Iâm fine with that. > And when would that be? Do you mean that you use it in ways not covered by Bert's modifications (which render the VM support superfluous), or do you mean that you use ImageSegment as a naive consumer and are happy just so long as it works? > > Max > > > _,,,^..^,,,_ > best, Eliot > > > > -- _,,,^..^,,,_ best, Eliot

Sept. 22, 2016

Re: [Pharo-dev] Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

by Max Leske

> On 22 Sep 2016, at 20:28, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Bert, Hi All, > > On Thu, Sep 15, 2016 at 2:55 PM, <commits(a)source.squeak.org <mailto:commits@source.squeak.org>> wrote: > [snip] > http://lists.squeakfoundation.org/pipermail/packages/2016-September/068930.… <http://lists.squeakfoundation.org/pipermail/packages/2016-September/068930.…> > > Name: System-bf.916 > Ancestors: System-bf.915 > > Replace VM-level ImageSegment loading with a Smalltalk implementation for old (interpreter-era) projects. > > Also removes support for writing segments. > > This overrides the Spur support introduced in System-eem.758. > > So one question is should we delete VM support for ImageSegment from the Spur VM? There's at least 1.5k of generated source for the Spur ImageSegment load and save support, some 2% of the interpreter/primitives source code. That's a lot, and the code is complex and ugly. If it never really worked before IMO we should nuke it asap. If it worked in some fashion perhaps we can schedule its demise for the 6.0 release's VM. > > What do others think? As long as you donât remove it from the Cog VMâs until I no longer need it Iâm fine with that. Max > > _,,,^..^,,,_ > best, Eliot

Sept. 22, 2016

Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

by Eliot Miranda

Hi Bert, Hi All, On Thu, Sep 15, 2016 at 2:55 PM, <commits(a)source.squeak.org> wrote: [snip] > http://lists.squeakfoundation.org/pipermail/packages/2016- > September/068930.html > > Name: System-bf.916 > Ancestors: System-bf.915 > > Replace VM-level ImageSegment loading with a Smalltalk implementation for > old (interpreter-era) projects. > > Also removes support for writing segments. > > This overrides the Spur support introduced in System-eem.758. > So one question is should we delete VM support for ImageSegment from the Spur VM? There's at least 1.5k of generated source for the Spur ImageSegment load and save support, some 2% of the interpreter/primitives source code. That's a lot, and the code is complex and ugly. If it never really worked before IMO we should nuke it asap. If it worked in some fashion perhaps we can schedule its demise for the 6.0 release's VM. What do others think? _,,,^..^,,,_ best, Eliot

Sept. 22, 2016

[pharo-project/pharo-core]

by GitHub

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

Sept. 22, 2016

[pharo-project/pharo-core] d3c4dd: 60236

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: d3c4dd1986da6a82d3a646cce151c8ff44913bfb https://github.com/pharo-project/pharo-core/commit/d3c4dd1986da6a82d3a646cc… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-22 (Thu, 22 Sep 2016) Changed paths: M AST-Core.package/NumberParser.class/instance/parsing-private/readExponent.st R Compiler.package/Compiler.class/instance/public - opal compatibility/category_.st M Compiler.package/Compiler.class/instance/public - opal compatibility/compilationContext.st M ConfigurationOfTxText.package/ConfigurationOfTxText.class/instance/symbolic versions/stable_.st A ConfigurationOfTxText.package/ConfigurationOfTxText.class/instance/versions/version2126_.st M Kernel.package/Deprecation.class/definition.st M Kernel.package/Deprecation.class/instance/accessing/messageText.st A Kernel.package/Deprecation.class/instance/accessing/sendingMethodName.st A Kernel.package/Deprecation.class/instance/accessing/sendingMethodName_.st M Kernel.package/Object.class/instance/deprecation/deprecated_.st M Kernel.package/Object.class/instance/deprecation/deprecated_on_in_.st M Kernel.package/Object.class/instance/deprecation/deprecated_on_in_transformWith_.st M Kernel.package/Object.class/instance/deprecation/deprecated_transformWith_.st M Monticello.package/MethodAddition.class/instance/operations/createCompiledMethod.st M Nautilus.package/AbstractNautilusUI.class/instance/build ui text/buildNewCodeSourceAreaRubric.st M Nautilus.package/Nautilus.class/class/settings/nautilusSettingsOn_.st A Nautilus.package/Nautilus.class/class/settings/showSourceCodeAnnotation.st A Nautilus.package/Nautilus.class/class/settings/showSourceCodeAnnotation_.st R OpalCompiler-Core.package/AbstractCompiler.class/instance/accessing/category_.st M OpalCompiler-Core.package/AbstractCompiler.class/instance/old - public/compile_in_classified_notifying_ifFail_.st M OpalCompiler-Core.package/CCompilationContext.class/definition.st R OpalCompiler-Core.package/CCompilationContext.class/instance/accessing/category.st R OpalCompiler-Core.package/CCompilationContext.class/instance/accessing/category_.st M OpalCompiler-Core.package/CompilationContext.class/definition.st R OpalCompiler-Core.package/CompilationContext.class/instance/accessing/protocol.st R OpalCompiler-Core.package/CompilationContext.class/instance/accessing/protocol_.st R OpalCompiler-Core.package/CompilationContext.class/instance/backward compatibility/category.st R OpalCompiler-Core.package/CompilationContext.class/instance/backward compatibility/category_.st M OpalCompiler-Core.package/OCSemanticError.class/instance/error handling/notify_at_.st R OpalCompiler-Core.package/OpalCompiler.class/instance/accessing/category_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60235.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60236.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60235.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60236.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Traits.package/TClassDescription.class/instance/compiling/compile_classified_withStamp_notifying_logSource_.st R TxText-Athens.package/TxAthensLayout.class/instance/as yet unclassified/hideEmbeddedObject_.st A TxText-Athens.package/TxAthensLayout.class/instance/view notifications/hideEmbeddedObject_.st A TxText-Athens.package/TxAthensLayoutView.class/class/examples/example.st M TxText-Athens.package/TxAthensLayoutView.class/instance/rendering/renderOn_.st M TxText-Athens.package/TxBasicViewMorph.class/README.md M TxText-Athens.package/TxBasicViewMorph.class/definition.st A TxText-Athens.package/TxBasicViewMorph.class/instance/accessing/backgroundColor.st A TxText-Athens.package/TxBasicViewMorph.class/instance/accessing/backgroundColor_.st A TxText-Athens.package/TxBasicViewMorph.class/instance/visual properties/fillStyle.st R TxText-Athens.package/TxDeleteOperation.class/instance/as yet unclassified/do.st A TxText-Athens.package/TxDeleteOperation.class/instance/undo-undo/do.st A TxText-Athens.package/TxInsertOperation.class/instance/accessing/text_.st R TxText-Athens.package/TxInsertOperation.class/instance/as yet unclassified/text_.st R TxText-Athens.package/TxInsertOperation.class/instance/as yet unclassified/undo.st A TxText-Athens.package/TxInsertOperation.class/instance/do%2Fundo/undo.st A TxText-Athens.package/TxNewTextAnnouncement.class/README.md A TxText-Athens.package/TxNewTextAnnouncement.class/definition.st M TxText-Athens.package/TxSelectionChangeOperation.class/instance/do%2Fundo/redo.st M TxText-Athens.package/TxSelectionChangeOperation.class/instance/do%2Fundo/undo.st M TxText-Athens.package/TxTextEditor.class/instance/editing/backspace.st M TxText-Athens.package/TxTextEditor.class/instance/editing/delete.st M TxText-Athens.package/TxTextEditor.class/instance/editing/insert_.st M TxText-Athens.package/TxTextEditor.class/instance/initialization/text_.st A TxText-Athens.package/TxTextEditor.class/instance/private notifying/notifyDeleted.st A TxText-Athens.package/TxTextEditor.class/instance/private notifying/notifyInserted_.st A TxText-Athens.package/TxTextEditor.class/instance/private notifying/notifyNewText.st A TxText-Athens.package/TxTextEditor.class/instance/private notifying/notifySelectionChange_.st M TxText-Athens.package/TxTextEditor.class/instance/private/recordSelectionChange_.st A TxText-Athens.package/TxTextEditor.class/instance/selection/shiftSelectionTo_.st M TxText-Athens.package/TxTextEditorMorph.class/instance/drawing/drawKeyboardFocusOn_.st M TxText-Athens.package/TxTextEditorMorph.class/instance/drawing/drawOnAthensCanvas_.st M TxText-Athens.package/TxTextEditorMorph.class/instance/drawing/drawSelectionOn_.st A TxText-Athens.package/TxTextRenderer.class/instance/accessing/advance_.st A TxText-Athens.package/TxTextRenderer.class/instance/accessing/canvas.st A TxText-Athens.package/TxTextRenderer.class/instance/accessing/setColor_.st A TxText-Athens.package/TxTextRenderer.class/instance/accessing/setFont_.st R TxText-Athens.package/TxTextRenderer.class/instance/as yet unclassified/advance_.st R TxText-Athens.package/TxTextRenderer.class/instance/as yet unclassified/canvas.st R TxText-Athens.package/TxTextRenderer.class/instance/as yet unclassified/initialize.st R TxText-Athens.package/TxTextRenderer.class/instance/as yet unclassified/renderLines_on_.st R TxText-Athens.package/TxTextRenderer.class/instance/as yet unclassified/render_lines_on_.st A TxText-Athens.package/TxTextRenderer.class/instance/initialization/initialize.st A TxText-Athens.package/TxTextRenderer.class/instance/rendering/renderLines_on_.st A TxText-Athens.package/TxTextRenderer.class/instance/rendering/render_lines_on_.st R TxText-Athens.package/TxTextRenderer.class/instance/rendering/setColor_.st R TxText-Athens.package/TxTextRenderer.class/instance/rendering/setFont_.st M TxText-Model.package/TxBackColorAttribute.class/class/defaults/defaultValue.st A TxText-Model.package/TxEmbeddedObjectSpan.class/instance/as yet unclassified/initWithText_.st M TxText-Model.package/TxForeColorAttribute.class/class/defaults/defaultValue.st A TxText-Styler.package/TxTextStyler.class/instance/attributes/addAttribute_forNode_.st A TxText-Styler.package/TxTextStyler.class/instance/attributes/addAttribute_startPosition_stopPosition_.st A TxText-Styler.package/TxTextStyler.class/instance/attributes/addAttributes_forNode_.st A TxText-Styler.package/TxTextStyler.class/instance/attributes/addAttributes_startPosition_stopPosition_.st M TxText-Styler.package/TxTextStyler.class/instance/initialization/initialize.st A TxText-Styler.package/TxTextStyler.class/instance/styling/addStyle_forNode_.st A TxText-Styler.package/TxTextStyler.class/instance/styling/addStyle_startPosition_stopPosition_.st R TxText-Styler.package/TxTextStyler.class/instance/visiting/addAttribute_forNode_.st R TxText-Styler.package/TxTextStyler.class/instance/visiting/addAttribute_startPosition_stopPosition_.st R TxText-Styler.package/TxTextStyler.class/instance/visiting/addAttributes_forNode_.st R TxText-Styler.package/TxTextStyler.class/instance/visiting/addAttributes_startPosition_stopPosition_.st R TxText-Styler.package/TxTextStyler.class/instance/visiting/addStyle_forNode_.st R TxText-Styler.package/TxTextStyler.class/instance/visiting/addStyle_startPosition_stopPosition_.st M TxText-Styler.package/TxTextStyler.class/instance/visiting/visitAssignmentNode_.st M TxText-Styler.package/TxTextStyler.class/instance/visiting/visitBlockNode_.st A TxText-Styler.package/TxTextStyler.class/instance/visiting/visitCascadeNode_.st M TxText-Styler.package/TxTextStyler.class/instance/visiting/visitMethodNode_.st A TxText-Styler.package/TxTextStyler.class/instance/visiting/visitPragmaNode_.st M TxText-Styler.package/TxTextStyler.class/instance/visiting/visitReturnNode_.st A TxText-Styler.package/TxTextStyler.class/instance/visiting/visitSuperNode_.st A TxText-Styler.package/TxTextStyler.class/instance/visiting/visitThisContextNode_.st Log Message: ----------- 60236 19039 Optional source code annotation pane Nautilus https://pharo.fogbugz.com/f/cases/19039 18482 Typing a large number into a playground freezes the image https://pharo.fogbugz.com/f/cases/18482 19124 enhance Deprecation to log sending method https://pharo.fogbugz.com/f/cases/19124 19122 Remove category from Opal https://pharo.fogbugz.com/f/cases/19122 18788 TxTextStyler do not work https://pharo.fogbugz.com/f/cases/18788 http://files.pharo.org/image/60/60236.zip

Sept. 22, 2016

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

by stepharo

:) I'm trying to remember if we have fly by help on menu item because this descriptions would fit nicely there. Martin the names proposed by Norbert are cool. Stef Le 21/9/16 Ã 13:00, Sven Van Caekenberghe a Ã©crit : > Thank you for this clear explanation, Martin. People will always have trouble using any tool/UI if they do not understand the underlying model. It helped me. Needless to say, such high level documentation needs to go somewhere. > >> On 21 Sep 2016, at 06:50, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> 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 >> >> >> >> >> >> >> <epiceaLogSet.jpg> >

Sept. 22, 2016

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

by stepharo

Hi norbert I like your names better than mine. It took me some times to understand the monitor and others. Stef Le 21/9/16 Ã 09:51, Norbert Hartl a Ã©crit : > > > Am 21.09.2016 um 08:02 schrieb stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > >> >> >> Le 21/9/16 Ã 06:50, Martin Dias a Ã©crit : >>> Hi Stef, âNo idea why Epicea didn't log your changes. >> >> Me neither I tried to reproduce it and I could not. >> Still I lost 40 min deep hacking. >>> >>> 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". >> >> Session Set > > Session changes > or > Last session changes > > It is in the text. It writes changes since image start (=session) >>> >>> - The Monitor UI shows the code changes since Epicea started to log. >>> ===> This means it shows changes placed in potentially several ombu >>> files. >> >> Full Log Set >> > All changes > > Why so complicated names? Why so different to before? > > Norbert >> >>> >>> - 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 >>> <mailto:stepharo@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. 22, 2016