- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] endless loop again

by Sven Van Caekenberghe

> On 08 Jun 2016, at 10:40, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 04 Jun 2016, at 9:13 , stepharo <stepharo(a)free.fr> wrote: >> >> >> >> Le 3/6/16 Ã 19:16, Esteban A. Maringolo a Ã©crit : >>> Regarding the first part of your email, about UI lockups, it is almost >>> unavoidable, because in Pharo almost everything happens in the main >>> thread, as you pointed out. >> Yes. This is all my point. > > IMHO, all Pharo beginner tutorials should start by showing off Cmd - dot (or Alt - dot, on Win / Linux). > > Not just because it's cool, but because it's necessary :) > > Cheers, > Henry Very true. Yet, and I have already mentioned this years ago, it is technically totally possible to properly detect massive stack growth, before things get out of control. Sadly, VM people think this is not needed (or too costly). Consider the following in Common Lisp (LispWorks): CL-USER 1 > (defun fac (n) (if (< n 2) 1 (* n (fac (1- n))))) FAC CL-USER 2 > (fac 5) 120 CL-USER 3 > (fac 100) 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 CL-USER 4 > (fac 400) Stack overflow (stack size 31744). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 5 : 1 > :c 1 Stack overflow (stack size 48128). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 6 : 1 > :c 1 64034522846623895262347970319503005850702583026002959458684445942802397169186831436278478647463264676294350575035856810848298162883517435228961988646802997937341654150838162426461942352307046244325015114448670890662773914918117331955996440709549671345290477020322434911210797593280795101545372667251627877890009349763765710326350331533965349868386831339352024373788157786791506311858702618270169819740062983025308591298346162272304558339520759611505302236086810433297255194852674432232438669948422404232599805551610635942376961399231917134063858996537970147827206606320217379472010321356624613809077942304597360699567595836096158715129913822286578579549361617654480453222007825818400848436415591229454275384803558374518022675900061399560145595206127211192918105032491008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 CL-USER 7 > (defun infinite () (cons 'a (infinite))) INFINIT CL-USER 8 > (infinite) Stack overflow (stack size 80896). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 9 : 1 > :a CL-USER 10 > Just having an upper limit to the stack catches 99% of infinite loops - that would be nice to have. This has existed for 10s of years AFAIK. Sven PS: Of course, the stack size can be set larger to begin with, if necessary. I believe it is even per execution thread.

June 8, 2016

Story of one small fix

by Pavel Krivanek

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] endless loop again

by Henrik Johansen

> On 04 Jun 2016, at 9:13 , stepharo <stepharo(a)free.fr> wrote: > > > > Le 3/6/16 Ã 19:16, Esteban A. Maringolo a Ã©crit : >> Regarding the first part of your email, about UI lockups, it is almost >> unavoidable, because in Pharo almost everything happens in the main >> thread, as you pointed out. > Yes. This is all my point. IMHO, all Pharo beginner tutorials should start by showing off Cmd - dot (or Alt - dot, on Win / Linux). Not just because it's cool, but because it's necessary :) Cheers, Henry

June 8, 2016

Enterprise Pharo ePub: The Second Pass

by Thibault ARLOING

Hi, I reworked the Enterprise Pharo book as ePub taking into account feedbacks of the pass on first version. So, now the navigation menu is more developed and I added a cover for the book. It would be great to have new feedbacks on this version If some of you have electronic readers, it would be good to test the book on it too You can download the ePub here<http://files.pharo.org/books-ressources/entreprise-pharo/EnterprisePharo.ep…><http://files.pharo.org/books-ressources/entreprise-pharo/EnterprisePharo.ep…> Thanks, Thibault

June 8, 2016

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

by Guille Polito

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]] 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 <mailto:guillermopolito@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 > > > > >

June 8, 2016

Re: [Pharo-dev] Privacy sendDiagnosticsAndUsageData should be ternary, not binary

by stepharo

Le 7/6/16 Ã 12:00, Andrei Chis a Ã©crit : > Hi Peter, > > On Tue, Jun 7, 2016 at 12:05 AM, Peter Uhnak <i.uhnak(a)gmail.com > <mailto:i.uhnak@gmail.com>> wrote: > > Hi, > > Privacy>>sendDiagnosticsAndUsageData should be ternary, not binary. > > Because right now if I refuse sending the data I will be asked > again every single time. > > > Indeed right now, at least in Spotter, the notification is shown every > time it is opened in > a new image, even if the setting was explicitly set. It was done like > this as a reminder, > especially if you have the setting set to true. Andrei for the shortcut reporter we put a number of show. Like that the user will be reminder a number of times and the system will get calm. May be you could do the same > > > So the proper behavior (imho) should be: > > ask Privacy for the settingâ¦ if the setting is not defined, then > show a popup. > If the setting is defined then respect it and do not show another > popup. > > > The current behaviour with showing the notification in Spotter and > Nautilus should be a temporary one. > Ideally we just need a single uniform way of showing this notification > plus the option to control > and see the data that each tool wants to record at a fined-grained level. > > > Also it would be nice to know what happens with the data. > > > We store it on a server and use it for various analyses. what can you tell us on processor use in Spotter. > It is also publicly available: GTEventTool default download. > > I mean my projects are open source so "sendSourceCode" shouldn't > be an issueâ¦ but what you can possibly learn from it? > Why not just analyze the content of SmalltalkHub/GitHub? > > > Because if you have the setting enabled it does not always work to map > different actions that with the code that you are working on. > > Cheers, > Andrei > > > Peter > >

June 8, 2016

CMD Shift B + N is not equal to CMD B + CMD Shift N

by stepharo

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 do not know how to fix it but this is confusing for newcomers. Stef

June 8, 2016

[pharo-project/pharo-core] 683d0e: 60069

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 683d0ec54cd9dba568b7238f446e366c07108a41 https://github.com/pharo-project/pharo-core/commit/683d0ec54cd9dba568b7238f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-08 (Wed, 08 Jun 2016) Changed paths: M Refactoring-Core.package/RBMoveVariableDefinitionRefactoring.class/instance/preconditions/preconditions.st M Refactoring-Core.package/RBRenameTemporaryRefactoring.class/instance/preconditions/preconditions.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60068.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60069.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60068.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60069.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-SelectEntity.package/SelectEntity.class/README.md A Spec-SelectEntity.package/SelectEntity.class/class/example/example.st A Spec-SelectEntity.package/SelectEntity.class/class/specs/defaultSpec.st A Spec-SelectEntity.package/SelectEntity.class/definition.st A Spec-SelectEntity.package/SelectEntity.class/instance/accessing/entityText.st A Spec-SelectEntity.package/SelectEntity.class/instance/accessing/entityText_.st A Spec-SelectEntity.package/SelectEntity.class/instance/accessing/selectEntity.st A Spec-SelectEntity.package/SelectEntity.class/instance/accessing/selectEntity_.st A Spec-SelectEntity.package/SelectEntity.class/instance/api-events/whenDisplaySymbolChanged_.st A Spec-SelectEntity.package/SelectEntity.class/instance/api-events/whenEntityChanged_.st A Spec-SelectEntity.package/SelectEntity.class/instance/api-events/whenGhostTextChanged_.st A Spec-SelectEntity.package/SelectEntity.class/instance/api-events/whenPossibleEntitiesChanged_.st A Spec-SelectEntity.package/SelectEntity.class/instance/api-events/whenSelectDialogChanged_.st A Spec-SelectEntity.package/SelectEntity.class/instance/api/displaySymbol.st A Spec-SelectEntity.package/SelectEntity.class/instance/api/displaySymbol_.st A Spec-SelectEntity.package/SelectEntity.class/instance/api/entity.st A Spec-SelectEntity.package/SelectEntity.class/instance/api/entity_.st A Spec-SelectEntity.package/SelectEntity.class/instance/api/ghostText.st A Spec-SelectEntity.package/SelectEntity.class/instance/api/ghostText_.st A Spec-SelectEntity.package/SelectEntity.class/instance/api/possibleEntities.st A Spec-SelectEntity.package/SelectEntity.class/instance/api/possibleEntities_.st A Spec-SelectEntity.package/SelectEntity.class/instance/api/selectDialog.st A Spec-SelectEntity.package/SelectEntity.class/instance/api/selectDialog_.st A Spec-SelectEntity.package/SelectEntity.class/instance/entryCompletion/entitiesEntryCompletion.st A Spec-SelectEntity.package/SelectEntity.class/instance/initialization/initialize.st A Spec-SelectEntity.package/SelectEntity.class/instance/initialization/initializePresenter.st A Spec-SelectEntity.package/SelectEntity.class/instance/initialization/initializeValueHolders.st A Spec-SelectEntity.package/SelectEntity.class/instance/initialization/initializeWidgets.st Log Message: ----------- 60069 18428 Add SelectEntity to Spec https://pharo.fogbugz.com/f/cases/18428 18421 Fix Zinc-HTTP extensions capitalization https://pharo.fogbugz.com/f/cases/18421 18438 confusing error for variable refactoring https://pharo.fogbugz.com/f/cases/18438 http://files.pharo.org/image/60/60069.zip

June 8, 2016

[pharo-project/pharo-core]

by GitHub

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

June 8, 2016

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

by stepharo

Le 8/6/16 Ã 09:04, stepharo a Ã©crit : > This is incorrect. If you would not complain aggressively, we would > simply have a smoother conversation about solutions. My final point: Aggressivity is often the result of not being heard. So now you can argue that you listen :) But I decided that I will not bother people about such little problems anymore. If people believe that I'm trolling then it is the time to do something else for me. And this is what I will do. Stef

June 8, 2016