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

[pharo-project/pharo-core]

by GitHub

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

June 18, 2016

[pharo-project/pharo-core] 4fb354: 60095

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 4fb354e0d46b1acfc61183dccc94eb3bfeeb4348 https://github.com/pharo-project/pharo-core/commit/4fb354e0d46b1acfc61183dc… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-18 (Sat, 18 Jun 2016) Changed paths: M ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/tags/stable_.st A ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/version792p6_.st M Morphic-Widgets-Tabs.package/TabManager.class/instance/initialize/registerShortcuts.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60094.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60095.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60094.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60095.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-MorphicAdapters.package/MorphicDiffAdapter.class/instance/factory/buildWidget.st Log Message: ----------- 60095 18496 duplicate shortcut usage for window close and tab close https://pharo.fogbugz.com/f/cases/18496 18514 ConfigurationOfEpicea not in sync with Pharo https://pharo.fogbugz.com/f/cases/18514 18511 DNU MorphicDiffAdapter keyStroke:fromMorph: https://pharo.fogbugz.com/f/cases/18511 http://files.pharo.org/image/60/60095.zip

June 18, 2016

[pharo-project/pharo-core]

by GitHub

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

June 18, 2016

[pharo-project/pharo-core] 80fbbc: 60094

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 80fbbc02844a45677c751eb14226e99321363381 https://github.com/pharo-project/pharo-core/commit/80fbbc02844a45677c751eb1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-18 (Sat, 18 Jun 2016) Changed paths: M ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic versions/stable_.st M ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version015_.st A ConfigurationOfVersionner.package/ConfigurationOfVersionner.class/instance/as yet unclassified/version21316_.st M ConfigurationOfVersionner.package/ConfigurationOfVersionner.class/instance/symbolic versions/stable_.st M NECompletion.package/NECVarTypeGuesser.class/instance/bytecode decoding/pushLiteralVariable_.st A Random-Core.package/ManifestRandomCore.class/README.md A Random-Core.package/ManifestRandomCore.class/class/as yet unclassified/packageName.st A Random-Core.package/ManifestRandomCore.class/class/meta-data - dependency analyser/ignoredDependencies.st A Random-Core.package/ManifestRandomCore.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st A Random-Core.package/ManifestRandomCore.class/definition.st M Reflectivity-Tools.package/Breakpoint.class/instance/api/once.st A Reflectivity-Tools.package/HaltIconStyler.class/README.md A Reflectivity-Tools.package/HaltIconStyler.class/definition.st A Reflectivity-Tools.package/HaltIconStyler.class/instance/defaults/highlightColor.st A Reflectivity-Tools.package/HaltIconStyler.class/instance/defaults/iconFor_.st A Reflectivity-Tools.package/HaltIconStyler.class/instance/defaults/iconLabel_.st A Reflectivity-Tools.package/HaltIconStyler.class/instance/testing/shouldStyleNode_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60093.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60094.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60093.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60094.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60094 18517 ConfigurationOfVersionner needs update to be in sync with Pharo https://pharo.fogbugz.com/f/cases/18517 18522 Add icon styler for "self halt" https://pharo.fogbugz.com/f/cases/18522 18518 ConfigurationOfCatalog needs update to be in sync with Pharo https://pharo.fogbugz.com/f/cases/18518 18513 NEC fails to guess the type of non-class bindings https://pharo.fogbugz.com/f/cases/18513 18521 Add manifest for Random-Core https://pharo.fogbugz.com/f/cases/18521 http://files.pharo.org/image/60/60094.zip

June 18, 2016

Re: [Pharo-dev] Better #haltOnce: per haltOnce state, auto-enable

by Marcus Denker

> On 18 Jun 2016, at 05:29, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Marcus, > > > Marcus > > Yes, but using the byte code pc is a much much cheaper key, and just as unique. > But why would I care to make this efficient? Itâs a debug featureâ¦ And doing it on the AST is very nice for other reasons, e.g. as I next step I will add icons in the Editor for all the halt sends. For haltOnce, this will show the state and toggle the haltOnce to be âonâ again. The editor uses the AST for this, and therefore it can be done with just 5 lines of code. In general the question is: Am I willing to pay in terms of resources for abstraction? Marcus

June 18, 2016

Re: [Pharo-dev] Better #haltOnce: per haltOnce state, auto-enable

by Eliot Miranda

Marcus, On Fri, Jun 17, 2016 at 4:03 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 14 Jun 2016, at 09:47, marcus.denker(a)inria.fr wrote: > > > > Hi, > > > > Yesterday we improved #haltOnce to be more like a âonceâ BreakPoint: > > > > -> state per *each* haltOnce send > > (this means you can put two in one method and they are > independent) > > -> when putting a haltOnce, it is enabled by default > > -> The global menu entry just resets all haltOnce to be active > again. > > > > Interesting is how trivial this was to implementâ¦ in class Halt > > once > > | node | > > node := thisContext sender sender sourceNodeExecuted. > > (node hasProperty: #haltOnce) ifTrue: [^self]. > > node propertyAt: #haltOnce put: true. > > ^ self signal. > > > > > > This means, we get the AST node of the âhaltOnceâ message send. Then we > put an annotation there. > > haltOnCount: can be implemented using AST send-site per node state, too: > > onCount: anInteger > "Halt on the anInteger-th time through" > <debuggerCompleteToSender> > | node | > node := thisContext sender sender sourceNodeExecuted. > (node hasProperty: #haltCount) ifFalse: [ > node propertyAt: #haltCount put: 0. > ]. > node propertyAt: #haltCount put: (node propertyAt: > #haltCount) + 1. > ((node propertyAt: #haltCount) = anInteger) ifTrue: [ > ^self signal ]. > > > Marcus > Yes, but using the byte code pc is a much much cheaper key, and just as unique. _,,,^..^,,,_ best, Eliot

June 18, 2016

PluggableTextFieldMorph Entry Completion Enhancement

by Sean P. DeNigris

I've run into a limitation a few times where PluggableTextFieldMorph accepts the text regardless of the outcome of the entryCompletion's chooseBlock. I've found that this is not always appropriate. As such, I propose that PluggableTextFieldMorph skip accepting if the chooseBlock returns false. Any thoughts? ----- Cheers, Sean -- View this message in context: http://forum.world.st/PluggableTextFieldMorph-Entry-Completion-Enhancement-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 17, 2016

Re: [Pharo-dev] Automatic deprecation refactoring

by stepharo

it is using #Refactoring asClassIfPresent: I would prefer self class environment atIfPresent: Because asClass is evil since it does not consider that we can have different namespaces. Stef Le 17/6/16 Ã 12:22, Guille Polito a Ã©crit : > Hi! > > How is this packaged? I don't want to introduce a dependency to the > refactoring browser into the kernel... > > Guille > > -------- Original Message -------- >> Hi, >> >> >> I have dusted off and improved the automatic refactoring of >> deprecations. >> >> - when the refactoring engine is not present, it falls back to a >> standard deprecation >> - It does not introduce any dependencies (can just be in the Kernel, >> the only cost is one method of 10 lines). >> - It sets the author so it does not require initials >> - It refactors â*only*â the sending (offending, deprecated) send >> site. So a second selector that is identical (which might be a >> different method and not deprecated) will not be affected. >> >> The way to use it is this: >> >> ifNotNilDo: aBlock >> self >> deprecated: 'Please use #ifNotNil: instead' >> transformWith: '`@receiver ifNotNilDo: `@statements' -> >> '`@receiver ifNotNil: `@statements'. >> ^ aBlock ifNotNil: aBlock >> >> >> As we try to provide already Lint rules for deprecations (or at least >> should have..) the amount of additional work is not much. >> >> This is the full implementation: >> >> deprecated: anExplanationString transformWith: aRule >> | rewriteRule method context node | >> context := thisContext sender sender. >> (Smalltalk globals hasClassNamed: #RBParseTreeRewriter) >> ifFalse: [ ^self deprecated: anExplanationString ]. >> method := context method. >> node := context sourceNodeExecuted. >> rewriteRule := (Smalltalk globals classNamed: >> #RBParseTreeRewriter) new replace: aRule key with: aRule value. >> (rewriteRule executeTree: node) >> ifFalse: [ ^ self ]. >> node replaceWith: rewriteRule tree. >> Author >> useAuthor: 'AutoDeprecationRefactoring' >> during: [method methodClass compile: method ast >> formattedCode classified: method protocol] >> >> https://pharo.fogbugz.com/f/cases/18507/ >> >> This is *with intention* the absolute âsimplest thing that can >> possibly workâ. There is no interactive tool to preview refactoring >> in interactive >> mode, or some way to opt in or out. >> >> The power of things like this comes from actually using them, not >> from being perfect... >> >> Marcus > > >

June 17, 2016

ReÂ : Re: [Pharo-users] Pharo Launcher

by Christophe Demarey

Yes. It was that. Thanks ----- Sean P. DeNigris <sean(a)clipperadams.com> a Ã©critÂ : > demarey wrote > > Now fixed > > Was that due to the #vm40Path being incorrectly set? I was going to report > that... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-Launcher-tp4901336p4901477.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 17, 2016

Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD]

by Petr Fischer

VM version (from https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/) 5.0 #1 Sun Jan 17 14:19:14 CET 2016 gcc 4.7.2 [Production Spur ITHB VM] CoInterpreter VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 https://github.com/estebanlm/pharo-vm.git Commit: 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 Linux swing-hudson-lin64 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux plugin path: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin [default: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin/] Image version (from official 5.0 download): [version] 5.0 #50723 pf > in fact, this is not related to FFIâ¦ but it should be fixedâ¦ > > along with the VM version, which version of Pharo are you using? > > Esteban > > > On 17 Jun 2016, at 14:04, Max Leske <maxleske(a)gmail.com> wrote: > > > > Hi Petr, > > > > That looks like a bug with FreeType with our FFI. It should actually have been fixed but I donât know if the VM for FreeBSD is up to date. Can you post the output of âSmalltalk vm versionâ? > > > > Cheers, > > Max > > > >> On 17 Jun 2016, at 13:26, Petr Fischer <petr.fischer(a)me.com> wrote: > >> > >> Hello, I got some random segfaults (while loading Seaside) with 32 bit spur vm on FreeBSD - can someone (with low level knowledge) decode attached log? > >> Is this some problem with stack size? Can I fix this? > >> > >> Log: > >> http://pastebin.com/raw/NpFUnjh0 > >> > >> There is "**StackOverflow**" lines n the log... > >> > >> Thanks! pf > >> > > > > > >

June 17, 2016