- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] CMD Shift B + N is not equal to CMD B + CMD Shift N

by stepharo

Thanks nicolai. I'm running a bit too much in this moment and I'm not sure that it will calm down. :) Stef Le 8/6/16 Ã 19:13, Nicolai Hess a Ã©crit : > > > 2016-06-08 11:34 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com > <mailto:nicolaihess@gmail.com>>: > > > > 2016-06-08 9:25 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi > > I was coding with a student on a french keyboard (argh) on > linux and I was > > teaching him to use shortcuts and we saw that the shortcut > reported is displaying > > Cmd shift B + N > > for class refs while it should be CMD B + CMD Shift N > > > I'll open a bug retpor. > > > https://pharo.fogbugz.com/f/cases/18454/drawing-menus-respect-order-of-uppe… > > > I do not know how to fix it but this is confusing for newcomers. > > > Stef > > > >

June 8, 2016

Re: [Pharo-dev] Story of one small fix

by stepharo

***THANKS*** Pavel. Yes it is the best way to make sure that nobody wants to work at this level. We discussed this problem during the last board meeting. This is why I proposed the following process. When the core Pharo developers are in need to change a package they should do it without updating the external package configurations. And the external developers should check and merge the changes from the Pharo repo and when they want release a new configuration that we will integrate. For me this is clear (for example for the icon: fix) I do not do anything if this is with the process you describe because it is insane. In fact fixing this process is part of the job description for your position. It was - republishing automatically changes and the configuration - working on package validation (making sure that the catalog does not get full of not working project) - bootstrap :) Stef Le 8/6/16 Ã 11:05, Pavel Krivanek a Ã©crit : > Hi, > > we had in the system circular package dependency between Catalog and > GTools and we decided to solve it by simple moving of one method from > one package to other one. However, these two packages are external > packages managed by configurations. That means that we needed move the > method, save dirty packages and fix both configurations. > > For the catalog we have very simple configuration because it manages > only one package (and dependency on STON). > ConfigurationOfGTInspectorCore was more complicated because the > repository already included newer development version of the modified > package so we needed to merge. But because we are not the maintainers, > we cannot know if the change in this package is not requiring changes > in other packages provided by the configuration. > Well, the new configurations were prepared and copied into inbox. We > needed to create next two issues for updating of the configuration in > the system. We did it and integrated all together in one update. But > that is not all... > ConfigurationOfGTInspectorCore is used by three other configurations > (ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and > ConfgurationOfGTDebugger) that specify number of > ConfigurationOfGTInspectorCore version. In ideal state you should > create new versions of the configurations but that means that you need > to modify configurations of all other configurations that use them. It > is simpler just modify current configuration and upgrade required > version number of GTInspectorCore. That means to create three next > issues, each for one configuration, create new configuration versions > (and check and merge the newer versions in the home repository if > needed), copy them to the inbox, wait for the review and hope that > during integration the Integrator will not create new versions of some > packages. If yes, you need to update configurations again. > > So at the end you have at least six issues because you wanted to > change package for one method that has still the same content and is > placed in the same class... And it can be worse. Both of these > external projects have public access to the repository and are managed > the same way (not mixing MC with GIT). > > As you see, it is crazy and unmaintainable. > > It is clear that we need to change the process. We need to discuss it > deeply and some of the results may touch maintainers of the external > projects integrated in Pharo but please keep in mind that the current > system is clearly bad. > > Cheers, > -- Pavel > >

June 8, 2016

Re: [Pharo-dev] Playground and text evaluation printing result default.

by Nicolai Hess

2016-06-08 19:11 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Yes, we already agreed on that both for the debugger and for Spotter. We > just did not get the chance to do it yet. > Hey Doru, about your report https://pharo.fogbugz.com/f/cases/18455 Spotter shortcuts should be externalized as settings Please don't do this just for spotter. We really need a general solution for all tools shortcuts. I am alread about to clean up the shortcut definitions. In the tools and the PharoShortcuts class. But we still need a way to really define this in a customizable way. I already wrote about this and asked (ML or fogbugz, I don't remember). The current shortcut definitions (with pragmas for example). Can be browsed and in the Keymap browser (that is good), but they can not be changed of course, they are defined in the source. And, the current keymap definitions (KMKEyCombination) need a way to be able to read and write as a setting, that currently does not work (as I wrote). My proposition was, to define some kind of "Named-Keyaction" or "Named-Action", for example CopySelectionAction (name = CopySelection, shortcut Ctrl+C), it would act as a KMKeyCombination, but its own shortcut (Ctrl+C) would be configurable. Now, in PharoShortcuts instead of PharoShortcuts >>#copySelectionShortcut ^ $c meta we define PharoShortcuts >>#copySelectionShortcut ^ CopySelectionAction withShortcut: $c meta (maybe on unique Instance of CopySelectionAction, or one per category) And the keymap browser, or the settings browser could list these actions and provide a way to reset the keycombination: CopySelectionAction - | type some keycombination here | The current way with the PharoShortcuts class and how the keys are binded to the tools don't really work for customizable shortcut definitions (or keymaps) or I just don't see it. nicolai > > Doru > > > > On Jun 8, 2016, at 11:33 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > > >> On 08 Jun 2016, at 09:04, stepharo <stepharo(a)free.fr> wrote: > >> > >> the fact that I cannot access Spotter without hurting my hand it is > also probably why I do not try more. > > > > yeah, shortcut has to be configurable, for people with big hands :) > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Every now and then stop and ask yourself if the war you're fighting is > the right one." > > > > > >

June 8, 2016

Re: [Pharo-dev] CMD Shift B + N is not equal to CMD B + CMD Shift N

by Nicolai Hess

2016-06-08 11:34 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-06-08 9:25 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Hi >> >> I was coding with a student on a french keyboard (argh) on linux and I was >> >> teaching him to use shortcuts and we saw that the shortcut reported is >> displaying >> >> Cmd shift B + N >> >> for class refs while it should be CMD B + CMD Shift N >> > > I'll open a bug retpor. > https://pharo.fogbugz.com/f/cases/18454/drawing-menus-respect-order-of-uppe… > > >> >> I do not know how to fix it but this is confusing for newcomers. >> >> >> Stef >> >> >> >

June 8, 2016

Re: [Pharo-dev] Playground and text evaluation printing result default.

by Tudor Girba

Yes, we already agreed on that both for the debugger and for Spotter. We just did not get the chance to do it yet. Doru > On Jun 8, 2016, at 11:33 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 08 Jun 2016, at 09:04, stepharo <stepharo(a)free.fr> wrote: >> >> the fact that I cannot access Spotter without hurting my hand it is also probably why I do not try more. > > yeah, shortcut has to be configurable, for people with big hands :) > > -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

June 8, 2016

Re: [Pharo-dev] Playground and text evaluation printing result default.

by Tudor Girba

Hi, Thanks. Interesting. I do not yet see it yet, but there is something intriguing about it. It would be interesting to play with this in more details. Cheers, Tudor > On Jun 8, 2016, at 12:24 PM, Ben Coman <btc(a)openinworld.com> wrote: > > On Wed, Jun 8, 2016 at 2:01 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >>> On Jun 8, 2016, at 2:04 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> On Wed, Jun 8, 2016 at 5:39 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> Hi Sven, >>>> >>>> If I understand correctly, Stef talks about the case of building tests in the debugger. There he tries an expression and then wants to capture the result of the expression as an assertion in the code so he wants to paste the result directly. It is a different scenario than the one of capturing results that we store as comments for further reference. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Jun 7, 2016, at 4:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> The #printString of most objects is not valid Pharo syntax, it makes sense to put those into comments, so that the overall syntax of the workspace/playground is maintained and syntax highlighting can operate normally. >>> >>> This might be too much a corner case, but I wonder... >>> If the domain object provided a sufficiently distinguishing >>> printString, then a shortcut that appended the CTRL-P result.... >>> printString = 'aDomainObject(''identiferâ') >> >> I cannot quite picture what you mean. Could you elaborate. It sounds intriguing? > > Simple example (perhaps poor because its integers) is... > 3+4 > select it, <ctrl-p> <ctrl-enter> > ==> > 3 +4 printString = '7'. > > more involved... actually nothing like a concrete example to flesh out > ideas. The generated string should include "printString equals:" > rather than "printString =" , or even "equalsPrintString" > > Object subclass: #Person > instanceVariableNames: 'name age' > classVariableNames: '' > package: 'AAAAA' > > Person>>named: aString age: anInteger > name := aString. > age := anInteger > > Person>>printOn: aStream > super printOn: aStream. > aStream > nextPut: $( ; > nextPutAll: name; > nextPut: $). > > PersonTest>>setUp > people := { > Person new named: 'John' age: 5). > Person new named: 'Peter' age: 7) } > > PersonTest>>testAge > self assert: (people detect: [ :p | p age = 5 ]) > <ctrl-p><ctrl-enter> ==> equalsPrintString: 'a Person(John)'. > > Maybe using the printString is a bit fragile. If it changes you need > to edit all the tests. Although you could be able to just use > <ctrl-p><ctrl-enter> again and visually check the new and old results. > > Maybe some other magic could happen like look up the returned value in > instance variables and insert a code reference > <ctrl-p><ctrl-enter> ==> equals: (People at: 1) > > cheers -ben > >> >>> to the selected text might provide an interesting workflow for >>> developing tests in the debugger. >>> Maybe it could be CTRL-P + CTRL-T (for test) ? >> >> I proposed Cmd+p Cmd+v (from paste). >> >> Cheers, >> Doru >> >> >>> A video demo of such might provide a good example of programming in an >>> immersive environment. What other environment could do this? >>> cheers -ben >>> >>> >>> >>> >>> >>>>> >>>>> A result printed as a comment is also easy to select (by double-clicking next to the $" on the inside). >>>>> >>>>> All this makes sense for literal programming (assuming that is what you are after). >>>>> >>>>> What is the use case for not doing it like that ? Why do you want the comments gone ? >>>>> >>>>>> On 07 Jun 2016, at 13:03, Ben Coman <btc(a)openinworld.com> wrote: >>>>>> >>>>>> On Tue, Jun 7, 2016 at 2:09 PM, stepharo <stepharo(a)free.fr> wrote: >>>>>>> >>>>>>> >>>>>>> Le 5/6/16 Ã 23:00, Tudor Girba a Ã©crit : >>>>>>>> >>>>>>>> Hi Stef, >>>>>>>> >>>>>>>> The quotes appear only when you add the result in the playground. >>>>>>> >>>>>>> >>>>>>> No need to explain I'm not idiot and I know it. >>>>>>>> >>>>>>>> The typical use case for this is to keep track of several results. >>>>>>> >>>>>>> No need to explain I'm not idiot and I know it. >>>>>>>> >>>>>>>> In this situation you do not want to modify the code to not affect the >>>>>>>> highlighting and this is why it gets in a comment. >>>>>>> >>>>>>> This is fun because I never ever needed it. But this is probably what >>>>>>> everybody else is doing that since this is the default. >>>>>>> I just write simple code and tests. Indeed I'm not that smart. >>>>>>> >>>>>>> But your tools only embedd your scenario and let the other users forced to >>>>>>> adapt. >>>>>>> >>>>>>> Well you do not want but I do. >>>>>>> I spent my evening removing quotes while writing tests. >>>>>>> >>>>>>> What I hate with the GTTools is that you want to teach me how I should work. >>>>>>> Sorry but good tools do not do that. >>>>>>> Good tools empower the users and not constraint them. >>>>>>> >>>>>>> I work a lot faster when I do not have to remove the wonderful comments or >>>>>>> when I have to copy and paste. >>>>>>> This commenting is breaking the flow of efficient people. May be GT team do >>>>>>> not work write tests in the >>>>>>> debugger but I do most of the time and I'm forced by the environment to >>>>>>> remove quotes all over the places. >>>>>>>> >>>>>>>> If you want to copy the content without quotes, you can do: >>>>>>>> Cmd+p -> popup >>>>>>>> Cmd+c -> selects the current line and copies the text >>>>>>>> Esc >>>>>>>> Cmd+v >>>>>>> >>>>>>> Sorry but I do not want. >>>>>>> I just want to print and modify directly. >>>>>>> 7 keystrokes vs 2 >>>>>>>> >>>>>>>> Perhaps we can add another keybinding like Shift+Enter for adding the text >>>>>>>> without quotes. >>>>>> >>>>>> I just had a play with this, and another option might be <ctrl-enter>, >>>>>> since the <ctrl> key is still selection from doing <ctrl-P> so there >>>>>> is not much difference in hand movements between <enter> and >>>>>> <ctrl-enter> >>>>>> >>>>>> cheers -ben >>>>>> >>>>>>> >>>>>>> And why not the inverse. >>>>>>> By default printing is printing and if you want to do something else then >>>>>>> you have a special binding. >>>>>> >>>>>> >>>>>> >>>>>>> Now I'm upset with this general attitude (Oh I will teach how you can be a >>>>>>> nice user) that I will turn them off >>>>>>> or go and hack my own settings. Still I'm amazingly sad about this state of >>>>>>> affair. >>>>>>> All these story about GT is hurting me because of this attitude: we are so >>>>>>> smart and we thought a lot and we will teach you >>>>>>> how you should work... and at the end I the end-user has to adapt. >>>>>>> Look at the Spotter discussions: you looked for the graal and I was just >>>>>>> telling to you that I cannot find >>>>>>> simple information such as class refs! >>>>>>> >>>>>>> So what saddens me the most is that >>>>>>> - you pretend to have end-user trying your tools but I have impression >>>>>>> that they are not real power users >>>>>>> or this is yourself and it means that you are never exposed to other >>>>>>> people. >>>>>>> I can still not use Spotter because the way I put my hand on my >>>>>>> keyboard. So should change >>>>>>> - 1 my hands >>>>>>> - 2 my brain >>>>>>> - 3 my keyboard >>>>>>> - 4 do not use the tools? >>>>>>> - funnily enough if I would not have complain aggressively then it looks >>>>>>> like we would have the same than before. >>>>>>> >>>>>>> Your flow is not mine and I go faster my way but your tools force me to get >>>>>>> slow. >>>>>>> I do not have the time to produce a video but I would even if it would give >>>>>>> a bad press to Pharo. >>>>>>> I will do a presentation in the rmod team. Because people do not watch >>>>>>> themselves why acting. >>>>>>> >>>>>>> Good tools empower the users not constraint them. >>>>>>> >>>>>>> GTTools feel often like an overengineer guitar that would have hampered >>>>>>> Jimmy Hendrix to do crazy solos. >>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Doru >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Jun 5, 2016, at 10:20 PM, stepharo <stepharo(a)free.fr> wrote: >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> I would like to know if there is a setting to remove the "" when printing >>>>>>>>> the result of an expression. >>>>>>>>> >>>>>>>>> I know that playground has been thought to help me, but today I watched >>>>>>>>> myself removing the comments >>>>>>>>> >>>>>>>>> code so often that I would like to get a setting because such wrapping of >>>>>>>>> results is really boring for me. >>>>>>>>> >>>>>>>>> I'm spending my time removing them and I start to wonder why they are any >>>>>>>>> useful. >>>>>>>>> >>>>>>>>> I would help me to write fast tests for example in the debugger. >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> www.feenk.com >>>>>>>> >>>>>>>> "What we can governs what we wish." >>>>> >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "It's not what we do that matters most, it's how we do it." >>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "If you interrupt the barber while he is cutting your hair, >> you will end up with a messy haircut." -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

June 8, 2016

Re: [Pharo-dev] [Vm-dev] Re: [ANN] Ephemeron Support is Ready

by Eliot Miranda

Hi Guille, On Wed, Jun 8, 2016 at 12:36 AM, Guille Polito <guillermopolito(a)gmail.com> wrote: > Hi Eliot, > > Pharo does AFAIK the same with the source files when you're navigating > source code. > > Now, I remember that while adapting the finalization scheme that you sent > me to Pharo (because there are indeed subtle differences), I noticed that > there was a missing loop. > > [looking for the code... found!] > > finalizationProcess > "The finalization process arranges to send mourn to each element of > the VM's finalization queue, > which is accessed via primitiveFetchMourner. The VM signals > FinalizationSemaphore whenever > the queue is non-empty. This process loops, waiting on the > semaphore, fetches the first element > of the queue and then spawns a process at a higher priority to > acually send the mourn messages. > If an error occurs in the higher priority mourn loop process then > this process will simply spawn > another process, hence ensuring that errors in finalization methods > don't break finalization. > > In addition this process also runs the old finalization scheme, > supporting clients of the older, > WeakRegistry based scheme. Hopefully this will go away when all > cleints have moved over." > | throttle firstMourner | > throttle := Semaphore new. > [FinalizationSemaphore wait; initSignals. > "Support the old scheme until things have changed over..." > self doOldFinalization. > [firstMourner := self primitiveFetchMourner. > firstMourner notNil] whileTrue: > [[throttle signal. > self mournLoopWith: firstMourner] forkAt: Processor > activePriority + 1. > throttle wait]] > Doh! So I wrote a naked block, not a loop !! So it did nothing. Thank you!! I think the compiler should warn about naked blocks. At first I was using that code that you sent me and I noticed that the > finalization process in there is a loop that is never evaluated! So I > updated it to the following using a [true] whileTrue: > > > finalizationProcess > "The finalization process arranges to send mourn to each element of > the VM's finalization queue, > which is accessed via primitiveFetchMourner. The VM signals > FinalizationSemaphore whenever > the queue is non-empty. This process loops, waiting on the > semaphore, fetches the first element > of the queue and then spawns a process at a higher priority to > acually send the mourn messages. > If an error occurs in the higher priority mourn loop process then > this process will simply spawn > another process, hence ensuring that errors in finalization methods > don't break finalization. > > In addition this process also runs the old finalization scheme, > supporting clients of the older, > WeakRegistry based scheme. Hopefully this will go away when all > cleints have moved over." > | throttle firstMourner | > throttle := Semaphore new. > [true] whileTrue: [FinalizationSemaphore wait; initSignals. > "Support the old scheme until things have changed over..." > self doOldFinalization. > [firstMourner := self primitiveFetchMourner. > firstMourner notNil] whileTrue: > [[throttle signal. > self mournLoopWith: firstMourner] forkAt: Processor > activePriority + 1. > throttle wait]] > > Maybe that's the reason of weak arrays not being finalized in squeak? > > Guille > > > -------- Original Message -------- > > > > Hi Guille, > > good news! But I'm seeing something wrong with finalisation of weak > arrays using the new scheme. In Squeak method source access is done by > default by opening a new read-only file for each method's source read > (crazy, but that's not the issue). So by default something that accesses > lots of source ends up running out of file descriptors, which causes > primOpen:writable: to fail. The surrounding code then uses > retryWithGC:until:forFileNamed: to do a GC to try and reclaim non-longer > referenced files, close file descriptors and continue: > > StandardFileStream retryWithGC:[self primOpen: f writable: > writeMode] > until:[:id| id notNil] > forFileNamed: fileName. > > But in my tests I'm not seeing any files reclaimed. I wonder whether the > new finalisation code is failing to finalise weak arrays properly. I > wonder whether your weak tests work properly with the new scheme or not. > > Anyway, I think I can reproduce the pathology in the simulator if I modify > it to implement a small limit on the number of file descriptors. I'm going > to try that to shed light on the problem. I can't easily debug in a > running image because...I run out of file descriptors ;-) > > On Tue, Jun 7, 2016 at 2:32 AM, Guille Polito <guillermopolito(a)gmail.com> > wrote: > >> >> >> >> >> >> >> Hi All, >> >> >> >> Since this morning, in Pharo #60065, Ephemeron support is in the >> image. Most of the changes are infrastructural, so far transparent >> for the users. It is important to notice that even while the support >> is there, it is not enabled by default. Also, this required changes >> in the virtual machine that are not yet distributed everywhere. For >> the ones that would like more detail, I invite you to read the >> following :) >> >> >> >> * On the infrastructure side >> >> - There is support to create Ephemeric classes and load them from >> monticello >> >> - There is a new finalization mechanism (by default disabled) that >> will process Ephemerons using a finalization queue. This will avoid >> scanning collections in look for weak objects to finalize ,as it >> happens now with the WeakDependent mechanism in WeakArray. >> >> - System-Finalization features two new classes *Ephemeron* and >> *EphemeronRegistry*. For the ones that want more details on >> Ephemerons, you can read the associated paper [1], or the class >> comment of Ephemeron: >> >> >> >> I represent ephemeric key-value objects. Ephemerons are >> key-value objects (subclasses of Association) with special >> semantics during garbage collection. My special behavior can >> resumed as follows: >> >> >> >> - The garbage collection will iterate my instances only if the key >> is not referenced strongly by another object. >> >> - Then, if no strong references to the key are found, then the >> values of this ephemeron are hold weakly. >> >> - Otherwise, the values are hold strongly. >> >> >> >> In this implementation, an Ephemeron can hold more than one value, >> which are all treated in the same manner. This ephemeron instance >> knows its container, which allows the ephemeron to remove itself >> from a container (such as a Dictionary) upon finalization. >> >> >> >> !! Example usages >> >> >> >> In general terms, do not use myself directly. Use instead an >> Ephemeric container like EphemeronRegistry. An Ephemeron registry >> will guarantee the collection of keys and values of the object >> inside the Ephemeron. >> >> >> >> Otherwise, if you want to use it, you can create an Ephemeron as >> any association: >> >> >> >> ephemeron := Ephemeron key: aKey value: aValue. >> >> ephemeron container: aContainer. >> >> >> >> !! Ephemeron Finalization >> >> >> >> When an ephemeron's key is hold strongly just by the ephemeron >> itself, the Ephemeron will be mourned (finalized). That means that >> the VM will: >> >> - put the Ephemeron in the mourning queue waiting for the image to >> take care of mourning >> >> - make the Ephemeron non ephemeric. That is, the ephemeron >> instance cannot be reused. >> >> >> >> On the image side, the finalization process will send the message >> #mourn to an Ephemeron. #mourn will #finalize the Ephemeron's >> key, and remove the Ephemeron from it's container to allow its >> collection during a subsequent garbage collection. >> >> >> >> !! More Documentation >> >> >> >> You can read the associated paper to understand better the >> semantics of ephemerons: >> >> >> >> [1]Ephemerons: A New Finalization Mechanism. Barry Hayes. OOPSLA >> '97 >> >> >> >> >> >> >> - WARNING: to be able to use ephemerons, you need to use the >> *latestVm* that has several fixes for making ephemerons work, and >> you need to enable ephemerons on the image side by evaluating: >> >> >> >> Smalltalk supportsQueueingFinalization: true. >> >> >> >> - With latest vm and ephemerons enabled, tests should be green, >> otherwise they are skipped >> >> >> >> >> >> >> >> * From the user point of view: >> >> >> >> - The Weak registries were not yet migrated to the new >> finalization mechanism. >> >> - We expect nothing will change from the user point of view. Just >> less memory leaks. >> >> >> >> * Next steps (in order) >> >> 1) Bless the latest vm as stable >> >> 2) Enable queueing finalization by default >> >> 3) Replace Weak Registry by Ephemeron Registry. >> >> >> >> >> >> Informed by: Guille >> >> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > > > > > > > > -- _,,,^..^,,,_ best, Eliot

June 8, 2016

[pharo-project/pharo-core]

by GitHub

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

June 8, 2016

[pharo-project/pharo-core] bb7382: 60072

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: bb73827748efad1f9fa06147e7c90c49149eec05 https://github.com/pharo-project/pharo-core/commit/bb73827748efad1f9fa06147… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-08 (Wed, 08 Jun 2016) Changed paths: M ConfigurationOfVersionner.package/ConfigurationOfVersionner.class/instance/symbolic versions/stable_.st A ConfigurationOfVersionner.package/ConfigurationOfVersionner.class/instance/versions/version21314_.st M FileSystem-Disk.package/FileHandle.class/instance/streams-compatibility/binaryReadStream.st M FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-methodcontext/tempNamed_.st M Jobs.package/Job.class/instance/private/prepareForRunning.st M Metacello-Core.package/MetacelloProjectRegistration.class/instance/accessing/currentVersionString.st M Metacello-Core.package/MetacelloProjectRegistration.class/instance/accessing/merge_.st M Monticello.package/MCPackage.class/instance/testing/isDirty.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60071.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60072.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60071.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60072.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot-Tests.package/SlotErrorsTest.class/instance/tests/testDangerousClassesConditions.st M Slot-Tests.package/SlotErrorsTest.class/instance/tests/testDangerousClassesEnabling.st M Slot.package/DangerousClassNotifier.class/class/accessing/shouldNotBeRedefined_.st M Slot.package/DangerousClassNotifier.class/class/accessing/tooDangerousClasses.st M Slot.package/DangerousClassNotifier.class/class/validation/check_.st Log Message: ----------- 60072 18451 Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, #ifNotNilDo: https://pharo.fogbugz.com/f/cases/18451 18443 update Versionner configuration to 2.13.14 https://pharo.fogbugz.com/f/cases/18443 18433 Simplify DangerousClassNotifier logic https://pharo.fogbugz.com/f/cases/18433 http://files.pharo.org/image/60/60072.zip

June 8, 2016

[pharo-project/pharo-core]

by GitHub

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

June 8, 2016