- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] ae307f: 60113
by GitHub June 26, 2016

June 26, 2016

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: ae307f5d7109a39c41558332012a5881046f8b18 https://github.com/pharo-project/pharo-core/commit/ae307f5d7109a39c41558332… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-26 (Sun, 26 Jun 2016) Changed paths: M CodeImportCommandLineHandlers.package/EvaluateCommandLineHandler.class/instance/commands/evaluate_.st A Kernel-Tests.package/CompiledMethodTest.class/instance/tests - testing/testSendsSelector.st M Kernel.package/CompiledMethod.class/instance/literals/sendsSelector_.st M Monticello.package/MCClassDefinition.class/instance/installing/sortedVariablesOfType_.st M Monticello.package/MCClassDefinition.class/instance/installing/variablesOfType_.st M OpalCompiler-Tests.package/OCCompilerTest.class/instance/literals/testScaledDecimalLiterals.st M Refactoring-Critics.package/RBBadMessageRule.class/instance/running/basicCheck_.st M Refactoring-Tests-Core.package/RBChildrenToSiblingsTest.class/instance/set up/setUp.st M Refactoring-Tests-Core.package/RBInlineMethodTest.class/instance/failure tests/testInlineMethodForSuperSendThatAlsoSendsSuper.st M Refactoring-Tests-Core.package/RBInlineMethodTest.class/instance/tests/testInlineMethodForSuperSend.st M Refactoring-Tests-Environment.package/RBBrowserEnvironmentTest.class/instance/private/storeStringFor_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60112.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60113.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60112.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60113.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Support.package/SmalltalkImage.class/instance/compiler/evaluate_.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/initializeActionToPerformOnTextModel.st Log Message: ----------- 60113 18599 use sendsAnySelectorOf: in RBBadMessageRule https://pharo.fogbugz.com/f/cases/18599 18593 Remove Pharo references to Smalltalk evaluate: https://pharo.fogbugz.com/f/cases/18593 http://files.pharo.org/image/60/60113.zip

1 0

ESUG 2016, 13th Innovation Technology Awards
by Jordi Delgado June 25, 2016

June 25, 2016

ESUG 2016, 13th Innovation Technology Awards Have you written innovative Smalltalk? The developers of any Smalltalk-based software can enter by submitting a 3-5min video of their software. Entrants demo their systems in a session at the end of Monday August 22, 2016, after which the conference attendees vote. (A vote consists in providing a sorted list of 3 preferred pieces of software.) The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros. The results are announced in the Awards ceremony that is held during the social event. Applicants should provide the following information on the conference registration server (registration.esug.org) Once you have registered your personal info, an 'Awards' menu allows submitting your software. You can provide this information when you first register, or login again later and update your details. Info to provide: Name of the software Licence information (free, shareware, or commercial) Name of the Smalltalk dialect used Name, Affiliation and Country of developers Besides, it would be great if the submission could include: URL for a video (3-5 min) showing a screencast / demo of the software URL for downloading the software or at least a runnable demo Deadline: August 21, 2016 Any Smalltalker can apply (students, companies, ...). The presented piece of code/software should be written in Smalltalk or directly support Smalltalk (e.g. Smalltalk VM). All Smalltalk dialects are accepted. The applicant should be "strongly related" to the presented code, be it as an author, as owner of the copyright/copyleft, or as an official representative of the copyright/copyleft owner. Bests, Jordi -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1 mQINBFWdFwMBEADubtkR8lTNVu1GRPD6ej9mlBnCIKDwEzx78yjR/MLjEumCe5bN x3dT3O1W3yxOxAJ/x3h0bGdXfCKuoA/tKIUMO97D2/5mPcOgXAVYALUafLv7y1V0 CFsAnHUBBh3XTpN30HrfOUaGVpxYsX9xlNOMlluEioZwSBHlL0/42g5VjCYxY21R BzKZROubQJK3cICsKVVexcX/2aU3cZu5dAgyt4q8wy0i9sC4pwNAEv/TnGBEShsH EKRcY7M3I7NYD5AKDjmbpOD7Vh9jC0B7BulcTwzY+lhY09ma/qJoqqnu/lfLPa02 ZDjEjy6xcXgoisTrSfQEwlq2F+gmf5ulr9mv7iCHuL0OB7QGxAuiRayZ2FklPST8 npe/71SRntptUfM/xETgnDw5PzmkBIX7htJS5e5lHXzAUQtnBP+vRlAeE5rDYF4M DZfDKnG/yVwyH16najx3R7dGBo5K7xZhuQZ9dPy+k/OcQFaWVGk0qgYY4ldS73i+ xgporBNYBwB29/FkQYfhVB2esqff/nXMPeTMfAsNjko6RKP4wUkBpfJbNLWY2SAr KW8yWOmWh6ptx8sABJdNXkM+OVQ7/B+ciicjMHg0A7ucFGnRf86/sAl5F4uDvKdP pvpOWIslMwymjucl9eraR+8cqoKZc21gd1DTBF7e0+2M/gYeoWsv1i3E8QARAQAB tCNKb3JkaSBEZWxnYWRvIDxqZGVsZ2Fkb0Bjcy51cGMuZWR1PokCPgQTAQIAKAUC VZ0XAwIbIwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ5nsSWl8H CWxzLRAAhZKieaCX+1lGJfgywuEBSkxsOIKxy1cIRFF5Ot9kFX42Ok/xNr4BJwwW R22F+rD4FvDK/w7tfqBxPcI6Q4X73McvgDHTZPnPEd0zIt3g0fz+j5z9l8V3o+H+ zKirEqsEhBtDveotv0ku4KSbEypBY8s1z39PabAg6gEKu5iBrZUXBnmHoyNfTUq5 3NQdI0zalmoCIzUXpLeOID4jHSUlNfpqs8f7/xzR4shAF0ISo5ARTbXVkcNjczys jlgfqOCbpI2TrjcazFdz5jQKqAP1AuYYj6QsL9NvUowrBwmLQd/bW0X8RDpcg1cV UZ4b3x+JBugxf21KzhspTgRqdthdfWG0oq+xU0TRJd82VAbHNfjRFElpCwj0ZgX+ C0i6KIk+e77u2Je5VfC9F/WRs7wnLKTc3/sHrD+87W/ijUSlSv6zjmaBixDjQidD XyT0ieKZyTAhuwNAYNPIk0lrZ48h0SNi6+tDvmiEfyrIjgHjJ1MmsW2Ysr7sazHN tElIJhdvPBl4B9pdH5n9gOpFNH2bOG1hITW0DFiBQcY/SsXgf/xpTrZEzFtfUELe +pAlnge+FgzlH3EMcIkbqLIfy7Fc6v/7neGnkgsekmaO8FpCvyJrFmiZ4UdXn6TH bJh9WDjIfWEWaPGjCEwg9lmtVB4C6DZmsqWYFFDmUb2RXsG+hha5Ag0EVZ0XAwEQ AN/BPO4wndcEliMRHeR8+OIK4M7rWCR216S8MxQ1GiFlVeEjtVAIktifIhOk0QMW EhajvUGEjhpMx+T0ZJRwt9+NPTRgPPThjAjc5gvhVOqznryfj6ZbIgHhb0sAXvBD WoEpd6afgoAfO1FdRjVF/jQ8HDlt9HQV4cqD045+fIKiB+6dz52FV3cmIWnvOwvm KkIlDimiLNA2BUpoNprMt+eP0zTQlui3I3YYYZ3XqfM4ra58HEsBKgnyzEaW3ohK Agy0qFTMDZDbr9LtzaY0yiJuxpihYKKozNCyJCprrIr4qFfVdIM3tPHk8d9mRThr hRGdtWdR1t7DJ7fJe+7fHlhrU0SiUF6QOnNSaCXhbZ6xQhgDtJ2EZRBEaV2fRteQ tv8eb52sdW7FZCrWiPg6/AoEFoUkZ/UJM1uk2lfHNEKDU5p9RKfm9kFZJdzo1YuV YcYmKc8AjstZB5WmassXxIAnlnwZRKdWXUbkG/BKkMOiJ3i0OhErrih7pbc2/XCF 75PXCh8ogtKHEEXhsXvJgsstWSG8JufEjKi6v/15gh0JlO6dAcCMKF0Obh4qW566 WfTzhUfar4X/73qVKfCY1cH9GtlaL0shcR7Mn8UNjnL+ObYZE03U1G/DF5wM/HxE FAOoZb+qQU4dMkkFVy+LhnYyqtQpRtATXQ2U/r9SZZcrABEBAAGJAiUEGAECAA8F AlWdFwMCGwwFCQlmAYAACgkQ5nsSWl8HCWx++g//TdA7tBFYeX3PGaTB7/79RHvl YMNnH8bUb2NWtgo84Azt95tK2+qIIsifCKDLxnnBrAjJKV1UDU6xXMZ3519FKKZ7 WnoL8P+8NYgVilQDaVvPaDoJKLI2m3qsH/sV7qmPXtvczAwXn4SoPCFC769uUQaz XEt9+AFzCA3wI/XCTSv2zxiujJrZkdYR3xsEc6AEHowEMO3qOXRJX0bu09wXX3UD 8HGOk+Fj5dP7T/fZtwAjkqwwf5CSEVLVAMCDQCiMm3ih/vxcxxyO/ieVWYXbjQWK i1VlicWMw2raaYDFMCFcPv1KDZLxh4154Y3/2i+2i96LPWrnz3fATjrQa6QQ7+Q0 wVYmD1gwKk2ZhDlB4nNo04VN7Ak1pHUsj+fZU+tZ6QyWlXBek/J+az5z8TcntYWw G1UEgefFvuHSIExbRqDQ0HQBcc2WfjGqorbx1i0yoKbnPZPphdV+gi4akdwkorcC k7TCWz6RMw0xH1qiTtWdRdDNF3ynu7FzSdOTUZHFXhv9Dv6g3vRnbPpNbG3CIw4/ eqtMyH4LbE1gsX7YCCV1o3jCvIvrwsr9t2PVbYgjpN9eVVMpUaaqcyrNL9Gny7sl t6wAmcwLLJBoXDPFbUEz2QzL0IZixw3Ttcyk7ATt6jDx4TiwPXX2ZD3aD2v3lHnq DwFjA9T1ONO5LR0iknc= =1gTk -----END PGP PUBLIC KEY BLOCK-----

1 0

Re: [Pharo-dev] OS-Windows and UnifiedFFI
by Nicolai Hess June 25, 2016

June 25, 2016

2016-05-19 8:56 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-04-25 10:17 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2016-04-25 9:28 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> Hi Nicolai, >>> >>> On 25 Apr 2016, at 09:14, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> >>> 2016-04-24 15:26 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: >>> >>>> Hi Nicolai, >>>> >>>> missed this thread - sorry. To my knowledge there was a call in NB for >>>> CreateWindow >>>> but there was no example in opening a new window. For X-Windows there >>>> was an example >>>> if I remember correctly. >>>> >>> >>> Hi Torsten, >>> >>> yes there is an "example" in NBOpenGL. On Windows, it registers and >>> creates window for getting an opengl context. >>> The code and classes for registering and creating a window are similiar >>> to what is now in your os-windows. >>> I needed to define some more pool variables for some style attributes, >>> all that is working. >>> What did not work is storing the hInstance attribute in the WndClass >>> struct. >>> >>> >>> what and how it does not work? >>> can you paste the code? >>> >> >> >> Sure. >> Load stable version of Torstens OSWindows. >> Change WinProcess class>>getVMModuleHandle (it has to use HINSTANCE >> instead of HMODULE (or just define a new pool variable HMODULE in WinTypes)) >> >> getVMModuleHandle >> "The GetModuleHandle function retrieves a module handle for the >> specified module if the file has been mapped into the address space of the >> calling process." >> >> ^ self ffiCall: #( HINSTANCE GetModuleHandleA (0)) module: #Kernel32 >> >> >> Now create a new WinWndClassEx and set the hInstance field: >> >> |hInst wndClass| >> hInst := WinProcess getVMModuleHandle. >> wndClass := WinWndClassEx new. >> wndClass hInstance: hInst. >> >> >> -> Message not understood SmallInteger>>isExternalAddress >> >> >> The equivalent code with NB that was working: >> >> |hInst wndClass| >> hInst := NativeBoostWin32 getVMModuleHandle. >> wndClass := NBWndClassEx new. >> wndClass hInstance: hInst. >> wndClass >> >> > Any more ideas? > >From my observation, hInst := NativeBoostWin32 getVMModuleHandle. hInst is not considered an external object, or its handle is not an ExternalAddress, although the object is a WinHandle that is a subclass of FFIExernalReference :-( I am lost here, any help appreciated. > > >> >> >>> >>> cheers! >>> Esteban >>> >>> With NBOpenGL (and non-spur resp. NativeBoost) this works. >>> With the new UnifiedFFI this gives an error from: >>> >>> pointerAt: byteOffset put: value >>> "Store a pointer object at the given byte address" >>> value isExternalAddress >>> >>> >>> >>>> >>>> Basically I would like to add support for this into OS-Windows, yes. >>>> Some parts are there and UFFI now has easy callbacks. Havent looked >>>> at OSWindow yet - but I guess the goal is to create native windows as >>>> well. >>>> Also I would like to add more support in manipulating/quering other >>>> external windows (which can be done using the already built in support >>>> for process and window handles). >>>> >>>> In Win32 to create a window one has to register a window class first and >>>> use the window class name afterwards in the CreateWindow API function. >>>> >>>> No time to look into this this week ... but can give a try afterwards. >>>> The WNDCLASS/WNDCLASSEX structure needs to be wrapped, RegisterClass >>>> called and CreateWindowEx with a callback for a function to process >>>> window messages. >>>> >>>> Dont know how if this interferes with the VM's own processing loop ... >>>> but we should give a try. If you catch me on Slack next week we can >>>> try together. >>>> >>>> Bye >>>> Torsten >>>> >>>> >>>> Gesendet: Sonntag, 24. April 2016 um 12:17 Uhr >>>> Von: "Nicolai Hess" <nicolaihess(a)gmail.com> >>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>> Betreff: Re: [Pharo-dev] OS-Windows and UnifiedFFI >>>> >>>> >>>> >>>> 2016-04-15 21:58 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> >>>> Hi Torsten, Esteban, >>>> I try to use OS-Windows (not OSWindow :) ) with latest spur VM and >>>> UnifiedFFI.As far as I can see, you (Torsten) already ported some parts to >>>> UnifiedFFI - great, thanks! >>>> I now try to open a new window withWinWindow>>createWindowEx ....as I >>>> took this example originally from NBOpenGL, it seems I have to define >>>> a Window Class first, with >>>> WinWndClassEx >>>> This seems to work in the old NBOpenGL/NBWin32 code but not with >>>> OS-Windows >>>> WinWndClassEx >>>> first, NBOpenGL uses >>>> NativeBoostWin32 getVMModuleHandle for an HModule instance >>>> there is a similar call in OS-Windows, WinProcess getVMModuleHandle >>>> (I needed to define a missing type, HMODULE, but that works). >>>> >>>> What does not work is this part: >>>> >>>> | hInst wndClass | >>>> hInst := WinProcess getVMModuleHandle. >>>> wndClass := WinWndClassEx new. >>>> wndClass hInstance: hInst. >>>> >>>> FF complains about >>>> pointerAt: byteOffset put: value >>>> "Store a pointer object at the given byte address" >>>> value isExternalAddress >>>> >>>> here value is not a handle, but a small integer, and it does not define >>>> isExternalAddress >>>> >>>> I tried to put the handle instead of the handles value, but this does >>>> not work either. >>>> >>>> Any Idea what is missing here, I need a way to store the HMODULE handle >>>> in the structure of the WinWNdClassEx >>>> >>>> Thanks in advance. >>>> >>>> Anyone? >>>> >>>> >>> >>> >> >

3 15

Reordering working directory mess
by Esteban Lorenzano June 24, 2016

June 24, 2016

Hi, Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this: Pharo.image Pharo.changes PharoDebug.log pharo-cache now we have: Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory: Pharo.image Pharo.changes ./pharo â¦ and everything for âpharo working internallyâ here then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir). of course, this idea follows other developing spaces, where things are stored in same fashion wayâ¦ for example in eclipse for java they store all eclipse data under .workspace directory. so, please note that this is NOT user spaceâ¦ regular pharo users will store his files along with the image, for instance filetree repositoriesâ¦ something like: Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc. wellâ¦ I will commit a SLICE with the changes soon (is not a hard change at all). But then: is ./pharo a good name? will this work? Esteban

14 21

debuggerCompleteToSender (was Re: Having comments for pragma?)
by Ben Coman June 24, 2016

June 24, 2016

On Fri, Jun 24, 2016 at 9:54 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > A pragma may be very obscure. For example, I do: > Pragma allInstances anyOne > => <debuggerCompleteToSender> > > If I want to know more about this <debuggerCompleteToSender> is actually > quite challenging. > I see many methods having that pragma, but not idea what it is for. > I see that Halt>>signalerContext and Process>>complete: that use that > pragma somehow. But still, I have no idea when I should use that pragma in > my method. > > Sorry I don't know enough of Pragma architecture to form an opinion on your question, but I can give you some background on debuggerCompleteToSender. There are two cases where the debugger interacts with a halt statement. The first is when a halt is first encountered in running code. This could be "Halt now" or "self halt" which respectively invoke... Halt>>now self signal. Object>>halt Halt now. Now you don't want the debugger to open in those methods, but the method that sent the message. The problem with the implementation prior to <debuggerCompleteToSender> was that while it was okay for signalerContext to be search the context chain for a Halt object so the debugger could open in the sender of #now, that meant the debugger would open inside "self halt" since it sends #now. So there was an #or: to look for #halt being sent, and an #or: for #haltOnce beign sent, and the dozen other senders of Halt>>now were ignored, or otherwise you'd need a dozen #or: conditions. The second case is when you are stepping through code you come across another "self haltOnce" and previously when you <Step Over> the debugger would end up several methods "in" and it would take eight or so <Steps> to get back out to the method containing the "self halt". (and this really annoyed me enough to fix it). So DebuggSession>>stepOver: calls Process>>completeStep: which calls Process>>complete: Again (vaguely I remember) it originally only searched up the context chain for senders of #halt and the dozen others halt methods were ignored and so they failed to set the debugger to the correct location. >From from #complete: the call "self completeTo: aContext sender" moves up the context chain, and completeTo: recurses back to complete. This recursion only happens while the error class is Halt and while the context methods have the pragma, otherwise it falls through to return suspendedContext as it unwinds. So having written all that to remind myself, the short answer of the net effect is that a first method with <debuggerCompleteToSender> can call another method with <debuggerCompleteToSender> which can call another <debuggerCompleteToSender> methods etc to any depth, until eventually Halt>>now is called to signal the exception, then all calls get unwound up to the first method with <debuggerCompleteToSender>, and the debugger lands in its sender. I was not completely happy with the pragma's name, but I was really at a loss what to name it, and so... since I was fixing the debugger, and was all happening in the "completion" machinery, and it unwound to the sender... *shrugs* Now, where to add all that as a comment? HTH, cheers -ben

1 0

Impossible to delete a class
by Valentin Ryckewaert June 24, 2016

June 24, 2016

Hello everyone, I just downloaded the last Pharo version and I found a bug when I tried to delete a class. The last version deprecated a method "name" and it looks like SmalltalkImage>>errorReportOn: doesn't like this. When you try to delete a class there is an infinite loop everytime. Valentin

2 1

catalog will be down 1hr
by Esteban Lorenzano June 24, 2016

June 24, 2016

Hi, I will apply some updates to catalog (backend, they will not be visible) cheers, Esteban

4 4

[pharo-project/pharo-core] b637cf: 60112
by GitHub June 24, 2016

June 24, 2016

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b637cf9547873482910a1cf6159b60d220b6e0c9 https://github.com/pharo-project/pharo-core/commit/b637cf9547873482910a1cf6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-24 (Fri, 24 Jun 2016) Changed paths: A ConfigurationOfTxText.package/ConfigurationOfTxText.class/instance/versions/version2125_.st M Kernel.package/Halt.class/class/halting/once.st M Ring-Core-Kernel.package/RGElementDefinition.class/instance/accessing/package.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60111.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60112.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60111.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60112.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M TxText-Athens.package/TxAdapterBindings.class/instance/initialize/initializeBindings.st R TxText-Model.package/TxModel.class/instance/copying/postCopy.st Log Message: ----------- 60112 18597 fix haltOnce to open debugger in the right place https://pharo.fogbugz.com/f/cases/18597 18539 Can not browse methods for a change set that modified class comments https://pharo.fogbugz.com/f/cases/18539 18073 TxModel >>#postCopy sends #halt https://pharo.fogbugz.com/f/cases/18073 http://files.pharo.org/image/60/60112.zip

1 0

[pharo-project/pharo-core]
by GitHub June 24, 2016

June 24, 2016

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

1 0

[pharo-project/pharo-core] b67123: 60111
by GitHub June 24, 2016

June 24, 2016

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b67123481cfacd8b11c33802fdacc9fc7d182137 https://github.com/pharo-project/pharo-core/commit/b67123481cfacd8b11c33802… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-24 (Fri, 24 Jun 2016) Changed paths: R Kernel.package/CompiledMethod.class/instance/literals/symbolLiterals.st M Kernel.package/CompiledMethod.class/instance/testing/containsHalt.st M Kernel.package/CompiledMethod.class/instance/testing/isDeprecated.st A Kernel.package/CompiledMethod.class/instance/testing/sendsAnySelectorOf_.st M Manifest-Core.package/TheManifestBuilder.class/definition.st M Manifest-Core.package/TheManifestBuilder.class/instance/printing/printOn_.st M Nautilus.package/MethodContainsFlagsAction.class/instance/order/isActionHandled.st M Nautilus.package/MethodWidget.class/instance/private/methodWrapper_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60110.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60111.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60110.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60111.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeAbstractInspector.class/instance/menu/inspectionMenu_.st Log Message: ----------- 60111 18592 fix a #name deprecation in Manifest Builder https://pharo.fogbugz.com/f/cases/18592 18587 Show depreciated methods with strikethrough emphasis https://pharo.fogbugz.com/f/cases/18587 18584 DNU on showing menu in PointerExplorer https://pharo.fogbugz.com/f/cases/18584 http://files.pharo.org/image/60/60111.zip

1 0