November 2017 - Pharo-dev - lists.pharo.org

Publishing a book with Pillar

by Stephane Ducasse

Hi guys we are working on pillar and we will probably release a new alph version soon. I'm updating the doc. But I found that the doc I was writing can help some of you. Julien is written a nice booklet on USBdrivers and he told me that this doc works super well on mac. Stef

Nov. 13, 2017

Re: [Pharo-dev] Pharo6.1 World menu order

by Peter UhnÃ¡k

Placing it in the most used tools makes sense to me, because it really is used a lot. ... so maybe move it just above Monticello Browser :) > It breaks muscle memory. That's good, because you can finally liberate yourself from the bad memory and learn cmd+O+B instead. :-D Peter On Mon, Nov 13, 2017 at 8:37 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > I find world menu order in Pharo 6.1. with enable Iceberg a little bit > awkward :) > > [image: Inline images 1] > > Any thought on why Iceberg is the first? It breaks muscle memory. > > P.S. To fix the order remove `parent: #'MostUsedTools'` > from IceRepositoriesBrowser class>>#menuCommandOn: so that implementation > is: > > menuCommandOn: aBuilder > "Add a custom menu item to the world menu" > <worldMenu> > > (aBuilder item: #'Iceberg') > order: 0.8; > icon: self icon; > "parent: #'MostUsedTools'; <-- remove" > keyText: 'o, i'; > action: [ self open ]. > > > > Cheers, > Alex >

Nov. 13, 2017

Pharo6.1 World menu order

by Aliaksei Syrel

Hi, I find world menu order in Pharo 6.1. with enable Iceberg a little bit awkward :) [image: Inline images 1] Any thought on why Iceberg is the first? It breaks muscle memory. P.S. To fix the order remove `parent: #'MostUsedTools'` from IceRepositoriesBrowser class>>#menuCommandOn: so that implementation is: menuCommandOn: aBuilder "Add a custom menu item to the world menu" <worldMenu> (aBuilder item: #'Iceberg') order: 0.8; icon: self icon; "parent: #'MostUsedTools'; <-- remove" keyText: 'o, i'; action: [ self open ]. Cheers, Alex

Nov. 13, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Stephane Ducasse

Hi Todd have a look at the Tips and Tricks booklet. Because there is a setup for preference that will help you. Stef On Sun, Nov 12, 2017 at 8:07 PM, Todd Blanchard <tblanchard(a)mac.com> wrote: > That did it! > > Seems like that should be enabled by default but...I'm able to proceed. > > On Nov 12, 2017, at 10:39 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > What about > > Iceberg enableMetacelloIntegration: true. > > before the metacello command? > > Esteban > > On 12 Nov 2017, at 14:39, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Still no joy. Five days trying to do this. Incredibly frustrated. > > I hunted down every single possible cache instance > > todd$ find . -name estebanlm > todd$ find /Applications -name estebanlm > > I downloaded the latest Pharo6.1-64 > > I configured the iceberg with my .ssh directory > > I executed your snippet. > > I get.... > > <Pharo6.1-64.image 2017-11-12 09-35-45.png> > > > todd$ find /Applications -name estebanlm > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm > > todd$ find > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/LICENSE > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/README.md > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/.filetree > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/.properties > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/BaselineOfLibClang > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/BaselineOfLibClang/BaselineOfLibClang.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/BaselineOfLibClang/package.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/CLDiagnostic.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/CLDiagnosticSet.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/CLExternalObject.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/CLFixIt.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/CLIndex.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/CLTranslationUnit.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/CXCursorStruct.extension.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/CXIndexH.extension.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/CXSourceLocationStruct.extension.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/CXSourceRangeStruct.extension.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/CXStringStruct.extension.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/CXTypeStruct.extension.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/package.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Core/TLibClang.trait.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Examples > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Examples/LibClangExample.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Examples/package.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Binding > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Binding/CXIndexH.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Binding/LibClang.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Binding/package.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXAvailabilityKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXCallingConvEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXChildVisitResultEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXCodeCompleteResultsStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXCompletionChunkKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXCompletionResultStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXCursorAndRangeVisitorStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXCursorKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXCursorStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXCursorVisitorCb.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXCXXAccessSpecifierEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXDiagnosticSeverityEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXExternalEnumeration.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXExternalStructure.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXFFICallback.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxAttrInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxAttrKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxBaseClassInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxContainerInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxCXXClassDeclInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxDeclInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxEntityCXXTemplateKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxEntityInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxEntityKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxEntityLanguageEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxEntityRefInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxEntityRefKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxIBOutletCollectionAttrInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxImportedASTFileInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxIncludedFileInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxLocStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxObjCCategoryDeclInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxObjCContainerDeclInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxObjCContainerKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxObjCInterfaceDeclInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxObjCPropertyDeclInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxObjCProtocolRefInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIdxObjCProtocolRefListInfoStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXInclusionVisitorCb.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexerCallbacksStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexHCb1.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexHCb10.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexHCb11.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexHCb12.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexHCb2.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexHCb3.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexHCb4.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexHCb5.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexHCb6.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexHCb7.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexHCb8.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXIndexHCb9.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXLanguageKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXLinkageKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXLoadDiagErrorEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXSourceLocationStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXSourceRangeStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXStringStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXTokenKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXTokenStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXTUResourceUsageEntryStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXTUResourceUsageKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXTUResourceUsageStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXTypeKindEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXTypeStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXUnsavedFileStruct.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/CXVisitorResultEnum.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-FFI-Types/package.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Tests > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Tests/CLDiagnosticSetTest.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Tests/CLDiagnosticTest.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Tests/CLIndexTest.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Tests/CLTranslationUnitTest.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Tests/CXIndexHTest.class.st > /Applications/Pharo6.1-64.app/Contents/Resources/github-cache/estebanlm/libclang-pharo-bindings/master/estebanlm-libclang-pharo-bindings-89739df/src/LibClang-Tests/package.st > > > > On Nov 12, 2017, at 4:29 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > On 12 Nov 2017, at 09:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > the only thing I can think now is you have a cache problem (older version of > sources, older version of image, I don't know). > this is *exactly* what I did and worked: > > $ wget -O- get.pharo.org/64/61+vm | bash > > ah, and Iâd execute this in an empty dir so Iâm sure there is no caching > stuff in the middle. > > $ ./pharo-ui Pharo.image --no-default-preferences > > open playground > > LGitExternalStructure allSubclassesDo: #compileFields. > Metacello new > repository: 'github://estebanlm/libclang-pharo-bindings/src'; > baseline: 'LibClang'; > load. > > that loaded correctly for me (macOS high sierra). > > Esteban > > > On 11 Nov 2017, at 17:43, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Executed that. Now tried to do: > > Metacello new > repository: 'github://estebanlm/libclang-pharo-bindings/src'; > baseline: 'LibClang'; > load. > > > And I'm back to "Could not resolve 'BaselineOfLibClang' > > <Pharo6.1-64.image 2017-11-11 12-41-07.png> > > Also tried the iceberg loader. I get... > > "No ssh-agent suitable credentials found". Why? Its a public repository. > > <Pharo6.1-64.image 2017-11-11 12-43-00.png> > > > > > On Nov 11, 2017, at 3:46 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > got it. > I was able to reproduce it. > > turns out there is a problem in the 32-64 bits conversion and libgit2 > bindings. > > you need to execute this: > > LGitExternalStructure allSubclassesDo: #compileFields. > > before execute this: > > Metacello new > repository: 'github://estebanlm/libclang-pharo-bindings/src'; > baseline: 'LibClang'; > load. > > Esteban > > On 11 Nov 2017, at 07:37, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Any help? > > On Nov 10, 2017, at 8:49 AM, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Yes, trying to install your libclang. > > Pharo is brand new download of whatever is on the website - 6.1-64 bit > version (yes I know its not tested - I was going to test it). > OSX Sierra. > I have Xcode and all that goes with it installed (my day job is IoT projects > with accompanying iPhone apps and occasionally web services development). > > Homebrew packages installed include... > > appledoc gmp nettle > autoconf gnutls nmap > aws-elasticbeanstalk gobject-introspection node > awscli graphite2 openssl > basset_ios harfbuzz openssl(a)1.1 > bazel icu4c p11-kit > boot2docker imagemagick pango > c-ares jpeg pcre > cairo libcroco pixman > cmake libffi pkg-config > coreutils libgcrypt python > cvs libgpg-error python3 > dfu-util libpng rbenv > docker librsvg readline > fontconfig libssh2 redis > freetype libtasn1 ruby-build > gdbm libtiff sqlite > gdk-pixbuf libtool unar > geoip libunistring wget > gettext libusb wireshark > ghostscript little-cms2 xz > glib lua > > > > On Nov 10, 2017, at 1:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > I would need a way to reproduce this. > > pharo version? (6.1?) > vm version? > operating system? > project you try to install? (I guess is libclang) > > anything I should know about your environment? (image is clean/new? are you > behind a proxy? whatever that can help) > > Esteban > > On 10 Nov 2017, at 00:08, Todd Blanchard <tblanchard(a)mac.com> wrote: > > #(0 25 1) > > On Nov 9, 2017, at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > (LGitLibrary uniqueInstance version) > > > > > > > > > > >

Nov. 13, 2017

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Stephane Ducasse

Thanks Thomas for this analysing. I will reread the thread carefully. I would love to see if pharoers have other ideas and wishes to improve our cool debugger Stef On Mon, Nov 13, 2017 at 5:23 PM, Thomas Dupriez <thomas.dupriez(a)ens-paris-saclay.fr> wrote: > > > Le 13/11/2017 Ã 15:56, Ben Coman a Ã©crit : > > > > On Mon, Nov 13, 2017 at 9:32 PM, Thomas Dupriez > <thomas.dupriez(a)ens-paris-saclay.fr> wrote: >> >> >> >> Le 13/11/2017 Ã 14:08, Ben Coman a Ã©crit : >> >> >> >> On Mon, Nov 13, 2017 at 8:40 PM, Thomas Dupriez >> <thomas.dupriez(a)ens-paris-saclay.fr> wrote: >>> >>> I dug a bit in this issue. Here are the results: >>> >>> >>> # Problem raised by Stephanne >>> Code like the following is open in the debugger: >>> >>> `myMethod >>> 1+1. <PROGRAMCOUNTER> >>> MyClass new myEvalBlock: [ >>> 2+2. <CURSOR> >>> ]. >>> 3+3.` >>> >>> The program counter is on the 1+1, the cursor is at the end of the 2+2 >>> line. >>> Right-click, "Run to here". >>> -> the program counter moves to the 3+3, and does not stop at the 2+2 >>> (where the cursor is). Even though the 2+2 does get evaluated (the >>> myEvalBlock method evaluates the blocks it receives). >>> If there was no code after the block, the debugger would jump back to the >>> caller of myMethod. >>> >>> # Why this happens >>> The implementation of RunToHere (source code below) is basically to >>> stepOver until the context is different or the source code position of the >>> program counter is higher or equal to the source code position of the >>> cursor/selection. >>> >>> Since the debugger uses stepOver, it executes myEvalBlock without >>> stopping, reaches the 3+3 and see it has gone further than the source code >>> position of the cursorm so it stops. >>> >>> Source code of DebugSession>>#runToSelection:inContext: >>> >>> `runToSelection: selectionInterval inContext: aContext >>> "Attempt to step over instructions in selectedContext until the >>> execution reaches the selected instruction. This happens when the >>> program counter passes the begining of selectionInterval. >>> >>> A not nill and valid interval is expected." >>> >>> (self pcRangeForContext: aContext) first >= selectionInterval >>> first >>> ifTrue: [ ^self ]. >>> self stepOver: aContext. >>> [ aContext == self interruptedContext and: [ (self >>> pcRangeForContext: aContext) first < selectionInterval first ] ] >>> whileTrue: [ self stepOver: aContext ]` >>> >>> # Observations and thoughts >>> - Replacing the stepOver with a stepInto -> This made the RunToHere stops >>> when resolving the 'new' message (because the context changes). >> >> >> Thanks for looking into this Thomas. >> What happens if you use stepThrough rather than stepInto? >> >> cheers -ben >> >> >> Using `stepThrough: aContext` instead of `stepInto: aContext`, the >> RunToHere in the block stops at the intended place: the 2+2. >> Printing the sequence of `self pcRangeForContext: aContext` yields the >> following. It doesn't show precisely the stop in the block, and instead >> shows an interval encompassing the whole block. That's what I was using to >> see where the execution was going during the RunToHere loop so I guess >> that's not a precise enough indicator for this situation... >> (21 to: 22)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60) >> >> I also tried the case where the block does not get evaluated (changing >> myEvalBlock so that it does nothing). In this situation, the RunToHere with >> a stepThrough ends up at the intended place, the 3+3. >> >> So... just use stepThrough for the RunToHere I guess? > > > Seems like expected behaviour. > Could you create an Issue/Pull Request to provide some concrete code to > review? > > Now the trick will be if you can devise some tests to go with this. > For examples perhaps look at senders of newDebugSessionNamed:startedAt: > including SpecDebugger>>testBasic. > > cheers -ben > > > > I opened an issue on FogBugz: https://pharo.fogbugz.com/f/cases/20687/ > > Attached are the file out of the test code (MyClass.st) and the fixed > runToSelection:inContext: (DebugSession-runToSelectioninContext). > I'll make a pull request tomorrow. > > For the test, I'm thinking about something like the following, that checks > the source code position of the pc after the runToSelection. (It's not > working yet) > Now that I think of it, the source code position of the pc will maybe be the > whole block (as experienced earlier) so this approach may end up not > working. > I'll come back to that tomorrow. > > Draft for a test: > `testRunToSelectionInContext > |context_ process_ session_| > "The variable names have an underscore to distinguish them from those > declared in the setUp method of this TestCase (DebuggerModelTest), which are > not suited for this test (because not making a debug session out of suitable > code)" > context_ := [1+1. > self evalBlock:[2+2]. > 3+3. > ] asContext. > process_ := Process > forContext: context_ > priority: Processor userInterruptPriority. > > session_:= process_ newDebugSessionNamed: 'test session' startedAt: > context_. > session_ runToSelection: (Interval from: 28 to: 27) inContext: context_. > self assert: ((session_ pcRangeForContext: context_) first == 3)` > > cheers - Thomas > > >> >> Thomas >> >> >> >>> >>> >>> - Replacing the stepOver with stepInto and removing the equal condition >>> on contexts -> The RunToHere goes to the 3+3. Looking at the source code >>> position of the program counter, it doesn't enter the block and seems to >>> resolve it in a single step. I don't really get why that is, considering >>> using the stepInto button of the debugger does enter the block. Here is the >>> series of source code positions of the program counter during the RunToHere: >>> (21 to: 22)(34 to: 36)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60)(65 to: >>> 66). >>> However, removing the equal condition on contexts means that if the >>> method call returns before reaching the cursor, it won't stop! >>> >>> - An idea could be to have the RunToHere place a metalink on the selected >>> node and let the execution run until it hits the metalink, which then >>> updates the debugger. Potential problems are that it implies installing a >>> metalink on a method that is already on the stack, which may not be that >>> easy to do properly (in particular, it affects the program counter since it >>> changes the bytecode), and there is the potential case where the metalink is >>> never reached (for example imagine the myEvalBlock: method of my example is >>> just storing the block and not evaluating it). >>> >>> >>> Cheers, >>> Thomas >>> >>> >>> >>> Le 09/11/2017 Ã 22:06, Stephane Ducasse a Ã©crit : >>>> >>>> Agreed. Thomas? It would be a good bone to ... (Un bon os a ronger) . >>>> >>>> Stef >>>> >>>> On Thu, Nov 9, 2017 at 4:32 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> The basic tools, such as debugger, are expected to work. If something >>>>> does not work, itâs a bug. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>>> On Nov 8, 2017, at 11:59 PM, Tim Mackinnon <tim(a)testit.works> wrote: >>>>>> >>>>>> I think it's broken in Pharo 6 too, as I often find it unreliable. >>>>>> >>>>>> It's hard to know what should work anymore - we really need a >>>>>> stabilisation release to let the dust settle. >>>>>> >>>>>> I'm always a bit reticent to report things as I'm not sure what you >>>>>> expect to work. >>>>>> >>>>>> Tim >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On 8 Nov 2017, at 20:40, Stephane Ducasse <stepharo.self(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>> I have the following method and I have my cursor -MY CURSOR HERE- >>>>>>> I select the menu run to here and .... I exit the method. >>>>>>> :( >>>>>>> >>>>>>> Is run to here working in Pharo 70? >>>>>>> I start to get worry about the number of bugs I get when using >>>>>>> Pharo70. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> fileOut >>>>>>> "File out the receiver, to a file whose name is a function of the >>>>>>> change-set name and a unique numeric tag." >>>>>>> >>>>>>> | nameToUse | >>>>>>> self halt. >>>>>>> self class promptForDefaultChangeSetDirectoryIfNecessary. >>>>>>> nameToUse := (self defaultChangeSetDirectory / self name , 'cs') >>>>>>> nextVersion basename. >>>>>>> UIManager default >>>>>>> showWaitCursorWhile: >>>>>>> [ >>>>>>> | internalStream | >>>>>>> internalStream := (String new: 10000) writeStream. >>>>>>> >>>>>>> -MY CURSOR HERE- >>>>>>> >>>>>>> internalStream >>>>>>> header; >>>>>>> timeStamp. >>>>>>> self fileOutPreambleOn: internalStream. >>>>>>> self fileOutOn: internalStream. >>>>>>> self fileOutPostscriptOn: internalStream. >>>>>>> CodeExporter >>>>>>> writeSourceCodeFrom: internalStream >>>>>>> baseName: (nameToUse copyFrom: 1 to: nameToUse size - 3) >>>>>>> isSt: false ] >>>>>>> >>>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "Value is always contextual." >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >> >> > >

Nov. 13, 2017

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Thomas Dupriez

Le 13/11/2017 Ã 15:56, Ben Coman a Ã©critÂ : > > > On Mon, Nov 13, 2017 at 9:32 PM, Thomas Dupriez > <thomas.dupriez(a)ens-paris-saclay.fr > <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: > > > > Le 13/11/2017 Ã 14:08, Ben Coman a Ã©critÂ : >> >> >> On Mon, Nov 13, 2017 at 8:40 PM, Thomas Dupriez >> <thomas.dupriez(a)ens-paris-saclay.fr >> <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: >> >> I dug a bit in this issue. Here are the results: >> >> >> # Problem raised by Stephanne >> Code like the following is open in the debugger: >> >> Â Â Â `myMethod >> Â Â Â Â Â Â 1+1. <PROGRAMCOUNTER> >> Â Â Â Â Â Â MyClass new myEvalBlock: [ >> Â Â Â Â Â Â Â Â Â 2+2. <CURSOR> >> Â Â Â Â Â Â ]. >> Â Â Â Â Â Â 3+3.` >> >> The program counter is on the 1+1, the cursor is at the end >> of the 2+2 line. >> Right-click, "Run to here". >> -> the program counter moves to the 3+3, and does not stop at >> the 2+2 (where the cursor is). Even though the 2+2 does get >> evaluated (the myEvalBlock method evaluates the blocks it >> receives). >> If there was no code after the block, the debugger would jump >> back to the caller of myMethod. >> >> # Why this happens >> The implementation of RunToHere (source code below) is >> basically to stepOver until the context is different or the >> source code position of the program counter is higher or >> equal to the source code position of the cursor/selection. >> >> Since the debugger uses stepOver, it executes myEvalBlock >> without stopping, reaches the 3+3 and see it has gone further >> than the source code position of the cursorm so it stops. >> >> Source code of DebugSession>>#runToSelection:inContext: >> >> Â Â Â `runToSelection: selectionInterval inContext: aContext >> Â Â Â Â Â Â "Attempt to step over instructions in selectedContext >> until the >> Â Â Â Â Â Â execution reaches the selected instruction. This >> happens when the >> Â Â Â Â Â Â program counter passes the begining of selectionInterval. >> >> Â Â Â Â Â Â A not nill and valid interval is expected." >> >> Â Â Â Â Â Â (self pcRangeForContext: aContext) first >= >> selectionInterval first >> Â Â Â Â Â Â Â Â Â ifTrue: [ ^self ]. >> Â Â Â Â Â Â self stepOver: aContext. >> Â Â Â Â Â Â [ aContext == self interruptedContext and: [ (self >> pcRangeForContext: aContext) first < selectionInterval first ] ] >> Â Â Â Â Â Â Â Â Â whileTrue: [ self stepOver: aContext ]` >> >> # Observations and thoughts >> - Replacing the stepOver with a stepInto -> This made the >> RunToHere stops when resolving the 'new' message (because the >> context changes). >> >> >> Thanks for looking into this Thomas. >> What happens if you use stepThrough rather than stepInto? >> >> cheers -ben > > Using `stepThrough: aContext` instead of `stepInto: aContext`, the > RunToHere in the block stops at the intended place: the 2+2. > Printing the sequence of `self pcRangeForContext: aContext` yields > the following. It doesn't show precisely the stop in the block, > and instead shows an interval encompassing the whole block. That's > what I was using to see where the execution was going during the > RunToHere loop so I guess that's not a precise enough indicator > for this situation... > (21 to: 22)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60) > > I also tried the case where the block does not get evaluated > (changing myEvalBlock so that it does nothing). In this situation, > the RunToHere with a stepThrough ends up at the intended place, > the 3+3. > > So... just use stepThrough for the RunToHere I guess? > > > Seems like expected behaviour. > Could you create an Issue/Pull Request to provide some concrete code > to review? > > Now the trick will be if you can devise some tests to go with this. > For examples perhaps look at senders of newDebugSessionNamed:startedAt: > including SpecDebugger>>testBasic. > > cheers -ben > I opened an issue on FogBugz: https://pharo.fogbugz.com/f/cases/20687/ Attached are the file out of the test code (MyClass.st) and the fixed runToSelection:inContext: (DebugSession-runToSelectioninContext). I'll make a pull request tomorrow. For the test, I'm thinking about something like the following, that checks the source code position of the pc after the runToSelection. (It's not working yet) Now that I think of it, the source code position of the pc will maybe be the whole block (as experienced earlier) so this approach may end up not working. I'll come back to that tomorrow. Draft for a test: Â Â Â `testRunToSelectionInContext Â Â Â |context_ process_ session_| Â Â Â "The variable names have an underscore to distinguish them from those declared in the setUp method of this TestCase (DebuggerModelTest), which are not suited for this test (because not making a debug session out of suitable code)" Â Â Â context_ := [1+1. Â Â Â Â Â Â self evalBlock:[2+2]. Â Â Â Â Â Â 3+3. Â Â Â ] asContext. Â Â Â process_ := Process Â Â Â Â Â Â forContext: context_ Â Â Â Â Â Â priority: Processor userInterruptPriority. Â Â Â session_:= process_ newDebugSessionNamed: 'test session' startedAt: context_. Â Â Â session_ runToSelection: (Interval from: 28 to: 27) inContext: context_. Â Â Â self assert: ((session_ pcRangeForContext: context_) first == 3)` cheers - Thomas > > Thomas > > >> >> - Replacing the stepOver with stepInto and removing the equal >> condition on contexts -> The RunToHere goes to the 3+3. >> Looking at the source code position of the program counter, >> it doesn't enter the block and seems to resolve it in a >> single step. I don't really get why that is, considering >> using the stepInto button of the debugger does enter the >> block. Here is the series of source code positions of the >> program counter during the RunToHere: (21 to: 22)(34 to: >> 36)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60)(65 to: 66). >> However, removing the equal condition on contexts means that >> if the method call returns before reaching the cursor, it >> won't stop! >> >> - An idea could be to have the RunToHere place a metalink on >> the selected node and let the execution run until it hits the >> metalink, which then updates the debugger. Potential problems >> are that it implies installing a metalink on a method that is >> already on the stack, which may not be that easy to do >> properly (in particular, it affects the program counter since >> it changes the bytecode), and there is the potential case >> where the metalink is never reached (for example imagine the >> myEvalBlock: method of my example is just storing the block >> and not evaluating it). >> >> >> Cheers, >> Thomas >> >> >> >> Le 09/11/2017 Ã 22:06, Stephane Ducasse a Ã©critÂ : >> >> Agreed. Thomas? It would be a good bone to ... (Un bon os >> a ronger) . >> >> Stef >> >> On Thu, Nov 9, 2017 at 4:32 AM, Tudor Girba >> <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi, >> >> The basic tools, such as debugger, are expected to >> work. If something does not work, itâs a bug. >> >> Cheers, >> Doru >> >> >> On Nov 8, 2017, at 11:59 PM, Tim Mackinnon >> <tim(a)testit.works> <mailto:tim@testit.works> wrote: >> >> I think it's broken in Pharo 6 too, as I often >> find it unreliable. >> >> It's hard to know what should work anymore - we >> really need a stabilisation release to let the >> dust settle. >> >> I'm always a bit reticent to report things as I'm >> not sure what you expect to work. >> >> Tim >> >> Sent from my iPhone >> >> On 8 Nov 2017, at 20:40, Stephane Ducasse >> <stepharo.self(a)gmail.com >> <mailto:stepharo.self@gmail.com>> wrote: >> >> Hi >> >> I have the following method and I have my >> cursor -MY CURSOR HERE- >> I select the menu run to here and .... I exit >> the method. >> :( >> >> Is run to here working in Pharo 70? >> I start to get worry about the number of bugs >> I get when using Pharo70. >> >> Stef >> >> >> fileOut >> "File out the receiver, to a file whose name >> is a function of the >> change-set name and a unique numeric tag." >> >> | nameToUse | >> self halt. >> self class >> promptForDefaultChangeSetDirectoryIfNecessary. >> nameToUse := (self defaultChangeSetDirectory >> / self name , 'cs') >> nextVersion basename. >> UIManager default >> showWaitCursorWhile: >> [ >> | internalStream | >> internalStream := (String new: 10000) >> writeStream. >> >> -MY CURSOR HERE- >> >> internalStream >> header; >> timeStamp. >> self fileOutPreambleOn: internalStream. >> self fileOutOn: internalStream. >> self fileOutPostscriptOn: internalStream. >> CodeExporter >> writeSourceCodeFrom: internalStream >> baseName: (nameToUse copyFrom: 1 to: >> nameToUse size - 3) >> isSt: false ] >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> www.feenk.com <http://www.feenk.com> >> >> "Value is always contextual." >> >> >> >> >> >> >> >> > >

Nov. 13, 2017

[Pharo 7.0-dev] Build #291: 20264-Date-gtInspectorDetailsIn-is-incorrectly-using-a-Block-for-the-title-so-selection-is-not-remembered

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #291 was: SUCCESS. The Pull Request #471 was integrated: "20264-Date-gtInspectorDetailsIn-is-incorrectly-using-a-Block-for-the-title-so-selection-is-not-remembered" Pull request url: https://github.com/pharo-project/pharo/pull/471 Issue Url: https://pharo.fogbugz.com/f/cases/20264 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2017

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Ben Coman

On Mon, Nov 13, 2017 at 9:32 PM, Thomas Dupriez < thomas.dupriez(a)ens-paris-saclay.fr> wrote: > > > Le 13/11/2017 Ã 14:08, Ben Coman a Ã©crit : > > > > On Mon, Nov 13, 2017 at 8:40 PM, Thomas Dupriez <thomas.dupriez@ens-paris- > saclay.fr> wrote: > >> I dug a bit in this issue. Here are the results: >> >> >> # Problem raised by Stephanne >> Code like the following is open in the debugger: >> >> `myMethod >> 1+1. <PROGRAMCOUNTER> >> MyClass new myEvalBlock: [ >> 2+2. <CURSOR> >> ]. >> 3+3.` >> >> The program counter is on the 1+1, the cursor is at the end of the 2+2 >> line. >> Right-click, "Run to here". >> -> the program counter moves to the 3+3, and does not stop at the 2+2 >> (where the cursor is). Even though the 2+2 does get evaluated (the >> myEvalBlock method evaluates the blocks it receives). >> If there was no code after the block, the debugger would jump back to the >> caller of myMethod. >> >> # Why this happens >> The implementation of RunToHere (source code below) is basically to >> stepOver until the context is different or the source code position of the >> program counter is higher or equal to the source code position of the >> cursor/selection. >> >> Since the debugger uses stepOver, it executes myEvalBlock without >> stopping, reaches the 3+3 and see it has gone further than the source code >> position of the cursorm so it stops. >> >> Source code of DebugSession>>#runToSelection:inContext: >> >> `runToSelection: selectionInterval inContext: aContext >> "Attempt to step over instructions in selectedContext until the >> execution reaches the selected instruction. This happens when the >> program counter passes the begining of selectionInterval. >> >> A not nill and valid interval is expected." >> >> (self pcRangeForContext: aContext) first >= selectionInterval >> first >> ifTrue: [ ^self ]. >> self stepOver: aContext. >> [ aContext == self interruptedContext and: [ (self >> pcRangeForContext: aContext) first < selectionInterval first ] ] >> whileTrue: [ self stepOver: aContext ]` >> >> # Observations and thoughts >> - Replacing the stepOver with a stepInto -> This made the RunToHere stops >> when resolving the 'new' message (because the context changes). >> > > Thanks for looking into this Thomas. > What happens if you use stepThrough rather than stepInto? > > cheers -ben > > > Using `stepThrough: aContext` instead of `stepInto: aContext`, the > RunToHere in the block stops at the intended place: the 2+2. > Printing the sequence of `self pcRangeForContext: aContext` yields the > following. It doesn't show precisely the stop in the block, and instead > shows an interval encompassing the whole block. That's what I was using to > see where the execution was going during the RunToHere loop so I guess > that's not a precise enough indicator for this situation... > (21 to: 22)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60) > > I also tried the case where the block does not get evaluated (changing > myEvalBlock so that it does nothing). In this situation, the RunToHere with > a stepThrough ends up at the intended place, the 3+3. > > So... just use stepThrough for the RunToHere I guess? > Seems like expected behaviour. Could you create an Issue/Pull Request to provide some concrete code to review? Now the trick will be if you can devise some tests to go with this. For examples perhaps look at senders of newDebugSessionNamed:startedAt: including SpecDebugger>>testBasic. cheers -ben > > > Thomas > > > > > >> - Replacing the stepOver with stepInto and removing the equal condition >> on contexts -> The RunToHere goes to the 3+3. Looking at the source code >> position of the program counter, it doesn't enter the block and seems to >> resolve it in a single step. I don't really get why that is, considering >> using the stepInto button of the debugger does enter the block. Here is the >> series of source code positions of the program counter during the >> RunToHere: (21 to: 22)(34 to: 36)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: >> 60)(65 to: 66). >> However, removing the equal condition on contexts means that if the >> method call returns before reaching the cursor, it won't stop! >> >> - An idea could be to have the RunToHere place a metalink on the selected >> node and let the execution run until it hits the metalink, which then >> updates the debugger. Potential problems are that it implies installing a >> metalink on a method that is already on the stack, which may not be that >> easy to do properly (in particular, it affects the program counter since it >> changes the bytecode), and there is the potential case where the metalink >> is never reached (for example imagine the myEvalBlock: method of my example >> is just storing the block and not evaluating it). >> >> >> Cheers, >> Thomas >> >> >> >> Le 09/11/2017 Ã 22:06, Stephane Ducasse a Ã©crit : >> >>> Agreed. Thomas? It would be a good bone to ... (Un bon os a ronger) . >>> >>> Stef >>> >>> On Thu, Nov 9, 2017 at 4:32 AM, Tudor Girba <tudor(a)tudorgirba.com> >>> wrote: >>> >>>> Hi, >>>> >>>> The basic tools, such as debugger, are expected to work. If something >>>> does not work, itâs a bug. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On Nov 8, 2017, at 11:59 PM, Tim Mackinnon <tim(a)testit.works> >>>>> <tim(a)testit.works> wrote: >>>>> >>>>> I think it's broken in Pharo 6 too, as I often find it unreliable. >>>>> >>>>> It's hard to know what should work anymore - we really need a >>>>> stabilisation release to let the dust settle. >>>>> >>>>> I'm always a bit reticent to report things as I'm not sure what you >>>>> expect to work. >>>>> >>>>> Tim >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 8 Nov 2017, at 20:40, Stephane Ducasse <stepharo.self(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> Hi >>>>>> >>>>>> I have the following method and I have my cursor -MY CURSOR HERE- >>>>>> I select the menu run to here and .... I exit the method. >>>>>> :( >>>>>> >>>>>> Is run to here working in Pharo 70? >>>>>> I start to get worry about the number of bugs I get when using >>>>>> Pharo70. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> fileOut >>>>>> "File out the receiver, to a file whose name is a function of the >>>>>> change-set name and a unique numeric tag." >>>>>> >>>>>> | nameToUse | >>>>>> self halt. >>>>>> self class promptForDefaultChangeSetDirectoryIfNecessary. >>>>>> nameToUse := (self defaultChangeSetDirectory / self name , 'cs') >>>>>> nextVersion basename. >>>>>> UIManager default >>>>>> showWaitCursorWhile: >>>>>> [ >>>>>> | internalStream | >>>>>> internalStream := (String new: 10000) writeStream. >>>>>> >>>>>> -MY CURSOR HERE- >>>>>> >>>>>> internalStream >>>>>> header; >>>>>> timeStamp. >>>>>> self fileOutPreambleOn: internalStream. >>>>>> self fileOutOn: internalStream. >>>>>> self fileOutPostscriptOn: internalStream. >>>>>> CodeExporter >>>>>> writeSourceCodeFrom: internalStream >>>>>> baseName: (nameToUse copyFrom: 1 to: nameToUse size - 3) >>>>>> isSt: false ] >>>>>> >>>>>> >>>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Value is always contextual." >>>> >>>> >>>> >>>> >>>> >>>> >> >> > >

Nov. 13, 2017

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Thomas Dupriez

Le 13/11/2017 Ã 14:08, Ben Coman a Ã©critÂ : > > > On Mon, Nov 13, 2017 at 8:40 PM, Thomas Dupriez > <thomas.dupriez(a)ens-paris-saclay.fr > <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: > > I dug a bit in this issue. Here are the results: > > > # Problem raised by Stephanne > Code like the following is open in the debugger: > > Â Â Â `myMethod > Â Â Â Â Â Â 1+1. <PROGRAMCOUNTER> > Â Â Â Â Â Â MyClass new myEvalBlock: [ > Â Â Â Â Â Â Â Â Â 2+2. <CURSOR> > Â Â Â Â Â Â ]. > Â Â Â Â Â Â 3+3.` > > The program counter is on the 1+1, the cursor is at the end of the > 2+2 line. > Right-click, "Run to here". > -> the program counter moves to the 3+3, and does not stop at the > 2+2 (where the cursor is). Even though the 2+2 does get evaluated > (the myEvalBlock method evaluates the blocks it receives). > If there was no code after the block, the debugger would jump back > to the caller of myMethod. > > # Why this happens > The implementation of RunToHere (source code below) is basically > to stepOver until the context is different or the source code > position of the program counter is higher or equal to the source > code position of the cursor/selection. > > Since the debugger uses stepOver, it executes myEvalBlock without > stopping, reaches the 3+3 and see it has gone further than the > source code position of the cursorm so it stops. > > Source code of DebugSession>>#runToSelection:inContext: > > Â Â Â `runToSelection: selectionInterval inContext: aContext > Â Â Â Â Â Â "Attempt to step over instructions in selectedContext > until the > Â Â Â Â Â Â execution reaches the selected instruction. This happens > when the > Â Â Â Â Â Â program counter passes the begining of selectionInterval. > > Â Â Â Â Â Â A not nill and valid interval is expected." > > Â Â Â Â Â Â (self pcRangeForContext: aContext) first >= > selectionInterval first > Â Â Â Â Â Â Â Â Â ifTrue: [ ^self ]. > Â Â Â Â Â Â self stepOver: aContext. > Â Â Â Â Â Â [ aContext == self interruptedContext and: [ (self > pcRangeForContext: aContext) first < selectionInterval first ] ] > Â Â Â Â Â Â Â Â Â whileTrue: [ self stepOver: aContext ]` > > # Observations and thoughts > - Replacing the stepOver with a stepInto -> This made the > RunToHere stops when resolving the 'new' message (because the > context changes). > > > Thanks for looking into this Thomas. > What happens if you use stepThrough rather than stepInto? > > cheers -ben Using `stepThrough: aContext` instead of `stepInto: aContext`, the RunToHere in the block stops at the intended place: the 2+2. Printing the sequence of `self pcRangeForContext: aContext` yields the following. It doesn't show precisely the stop in the block, and instead shows an interval encompassing the whole block. That's what I was using to see where the execution was going during the RunToHere loop so I guess that's not a precise enough indicator for this situation... (21 to: 22)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60) I also tried the case where the block does not get evaluated (changing myEvalBlock so that it does nothing). In this situation, the RunToHere with a stepThrough ends up at the intended place, the 3+3. So... just use stepThrough for the RunToHere I guess? Thomas > > - Replacing the stepOver with stepInto and removing the equal > condition on contexts -> The RunToHere goes to the 3+3. Looking at > the source code position of the program counter, it doesn't enter > the block and seems to resolve it in a single step. I don't really > get why that is, considering using the stepInto button of the > debugger does enter the block. Here is the series of source code > positions of the program counter during the RunToHere: (21 to: > 22)(34 to: 36)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60)(65 to: 66). > However, removing the equal condition on contexts means that if > the method call returns before reaching the cursor, it won't stop! > > - An idea could be to have the RunToHere place a metalink on the > selected node and let the execution run until it hits the > metalink, which then updates the debugger. Potential problems are > that it implies installing a metalink on a method that is already > on the stack, which may not be that easy to do properly (in > particular, it affects the program counter since it changes the > bytecode), and there is the potential case where the metalink is > never reached (for example imagine the myEvalBlock: method of my > example is just storing the block and not evaluating it). > > > Cheers, > Thomas > > > > Le 09/11/2017 Ã 22:06, Stephane Ducasse a Ã©critÂ : > > Agreed. Thomas? It would be a good bone to ... (Un bon os a > ronger) . > > Stef > > On Thu, Nov 9, 2017 at 4:32 AM, Tudor Girba > <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: > > Hi, > > The basic tools, such as debugger, are expected to work. > If something does not work, itâs a bug. > > Cheers, > Doru > > > On Nov 8, 2017, at 11:59 PM, Tim Mackinnon > <tim(a)testit.works> wrote: > > I think it's broken in Pharo 6 too, as I often find it > unreliable. > > It's hard to know what should work anymore - we really > need a stabilisation release to let the dust settle. > > I'm always a bit reticent to report things as I'm not > sure what you expect to work. > > Tim > > Sent from my iPhone > > On 8 Nov 2017, at 20:40, Stephane Ducasse > <stepharo.self(a)gmail.com > <mailto:stepharo.self@gmail.com>> wrote: > > Hi > > I have the following method and I have my cursor > -MY CURSOR HERE- > I select the menu run to here and .... I exit the > method. > :( > > Is run to here working in Pharo 70? > I start to get worry about the number of bugs I > get when using Pharo70. > > Stef > > > fileOut > "File out the receiver, to a file whose name is a > function of the > change-set name and a unique numeric tag." > > | nameToUse | > self halt. > self class > promptForDefaultChangeSetDirectoryIfNecessary. > nameToUse := (self defaultChangeSetDirectory / > self name , 'cs') > nextVersion basename. > UIManager default > showWaitCursorWhile: > [ > | internalStream | > internalStream := (String new: 10000) writeStream. > > -MY CURSOR HERE- > > internalStream > header; > timeStamp. > self fileOutPreambleOn: internalStream. > self fileOutOn: internalStream. > self fileOutPostscriptOn: internalStream. > CodeExporter > writeSourceCodeFrom: internalStream > baseName: (nameToUse copyFrom: 1 to: nameToUse > size - 3) > isSt: false ] > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com <http://www.feenk.com> > > "Value is always contextual." > > > > > > > >

Nov. 13, 2017

[Pharo 7.0-dev] Build #290: 20679-Reloading-of-OSWindow-SDL2-causes-Tonel-parsing-error

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #290 was: SUCCESS. The Pull Request #473 was integrated: "20679-Reloading-of-OSWindow-SDL2-causes-Tonel-parsing-error" Pull request url: https://github.com/pharo-project/pharo/pull/473 Issue Url: https://pharo.fogbugz.com/f/cases/20679 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2017