- Pharo-dev - lists.pharo.org

Metacello and big Github repositories

by Pavel Krivanek

Hi, as already mentioned in GT Event Recorder help, current Pharo version does not support ZIP signature that is used for large files. That starts to be Metacello issue as soon as you need to work with some large Git repository because Metacello firstly downloads the repository working copy in the form of ZIP file. To reproduce try: Metacello new baseline: 'Moose'; repository: 'github://pavel-krivanek/Moose/repository'; load. or: ZnClient new url: 'https://github.com/pavel-krivanek/Moose/zipball/master'; downloadTo: 'archive.zip'. ZipArchive new readFrom: 'archive.zip' asFileReference. The workaround is to work with a local clone of the repository. Cherrs, -- Pavel

Feb. 17, 2017

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

by ClÃ©ment Bera

On Fri, Feb 17, 2017 at 1:48 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Le 17/02/2017 Ã 13:31, ClÃ©ment Bera a Ã©crit : > > > > > > It may solve part of the problem. > > > > Another problem is that tenure heuristics needs to be changed when > > allocating lots of long-lived objects. One needs to implement a GCPolicy > > object in the image and use it from the application code... > > > > > > What would be needed in order to make this work? I don't know the GC > enough to know what this imply. > Basically you need to have a look at the GC heuristics and analyse how they impact GC performance. Based on that, you can have a GCPolicy instance to which you can send messages such as #changePolicyForLargeHeap, #changePolicyForSmallHeaps or #growingPolicyDuring: aBlock. Internally the GCPolicy object changes GC heuristics. Some heuristics are already present in the vmParameter primitive (Smalltalk vm parameterAt: 46 for example), but some of them currently require the VM to be restarted. A first step would be to investigate those parameters. For example, the GCPolicy could read those parameters to know what is the current status: *2 size of young/new-space (read-only)* * 3 size of heap (read-only)* * 6 survivor count tenuring threshold (read-write)* * 7 full GCs since startup (read-only)* * 8 total milliseconds in full GCs since startup (read-only)* * 9 scavenges since startup (read-only)* * ...* * 55 ratio of growth and image size at or above which a GC will be performed post scavenge* * 63 total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil)* Based on this and the message sent to the GCPolicy, one can set new GC heuristics through those parameters: *6 survivor count tenuring threshold (read-write)* * ...* * 45 desired size of eden, in bytes (stored in image file header)* * 55 ratio of growth and image size at or above which a GC will be performed post scavenge* What has to be done is: - create a GCPolicy object with methods such as #changePolicyForLargeHeap, #changePolicyForSmallHeaps or #growingPolicyDuring: aBlock. - use the VM parameters in those methods to analyse the current state and define new heuristics - define a range in which the parameters can be changed without crashing the VM - add new parameters on heuristics that are important but not configurable right now - add the possibility to change several heuristics without restarting the image (for example change of Eden size or existing memory segment size) For example, let's say you grow your image from 30 Mb to 8Gb (I think one of our larger user in 64 bits use 8 Gb images right now and the default Pharo image is around 30 Mb). An uncommonly high rate of objects are promoted from young space to old space and the memory is expected to grow by 26667%. So you may want to: - decrease the survivor count for tenures. This way your objects are promoted earlier to old objects. - increase the ratio of growth. Instead of doing a full GC each time the image size grow by 33% you may want to do it each time the image size is increased by 900%. This way instead of having 20 fullGC while growing you have only 3. You switch back the policy at the end and trigger manually a fourth fullGC and everything's fine. Maybe we don't need a GCPolicy object, but more a VMPolicy object, so we can conveniently tweak the stack (number and size of stack page) and machine code zone. If somebody wants to have fun :-) > > > > > No one is working on this right now, but it's next step to improve the > GC. > > > > When the development starts on this feature I can give you more > > information. If a paying customer requests it, it should be done in a > > couple months. > > > > > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Feb. 17, 2017

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

by Cyril Ferlicot D.

Le 17/02/2017 Ã 13:31, ClÃ©ment Bera a Ã©crit : > > > It may solve part of the problem. > > Another problem is that tenure heuristics needs to be changed when > allocating lots of long-lived objects. One needs to implement a GCPolicy > object in the image and use it from the application code... > > What would be needed in order to make this work? I don't know the GC enough to know what this imply. > > No one is working on this right now, but it's next step to improve the GC. > > When the development starts on this feature I can give you more > information. If a paying customer requests it, it should be done in a > couple months. > > -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Feb. 17, 2017

Re: [Pharo-dev] 17240 Spur, when saving an image, it never shrinks

by ClÃ©ment Bera

On Fri, Feb 17, 2017 at 12:05 PM, Cyril Ferlicot D. < cyril.ferlicot(a)gmail.com> wrote: > Le 17/02/2017 Ã 07:17, ClÃ©ment Bera a Ã©crit : > > The full GC is indeed much faster as the previous compaction algorithm > > was very slow. But unless you were executing memory intensive code in > > very large heaps, you won't see much difference as full GC are uncommon. > > We still need to make the GC incremental to avoid pauses ... > > > > > > > > Can this fix the problem that MSE materialization takes 4 time longer > with spur memory management? It would be really cool :) > It may solve part of the problem. Another problem is that tenure heuristics needs to be changed when allocating lots of long-lived objects. One needs to implement a GCPolicy object in the image and use it from the application code... > > Do you have an idea of when the first incr GC without pause will be > available? (No rush, it's just for info to know if it's in months or > years :) ) > > No one is working on this right now, but it's next step to improve the GC. When the development starts on this feature I can give you more information. If a paying customer requests it, it should be done in a couple months. -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Feb. 17, 2017

[Issue Tracker][Pharo5] Please check issues tagged Pharo5

by Marcus Denker

Hello, We have still 9 issues that are tagged with the Pharo5 Milestone. Please everyone who either submitted the issue or was involved in the discussions: - Is this issue still relevant? - Is it maybe fixed in Pharo6? - Is is important enough to require a backport to Pharo5? https://pharo.fogbugz.com/f/filters/125/5-0-All <https://pharo.fogbugz.com/f/filters/125/5-0-All> Marcus

Feb. 17, 2017

[pharo-project/pharo-core]

by GitHub

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

Feb. 17, 2017

[pharo-project/pharo-core] d87034: 60399

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: d8703419191596d77a5cfa4cc64817b128e508dd https://github.com/pharo-project/pharo-core/commit/d8703419191596d77a5cfa4c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-17 (Fri, 17 Feb 2017) Changed paths: R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60398.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60399.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60398.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60399.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot-Tests.package/ClassVariableTest.class/instance/tests - properties/testIsReadInMethod.st Log Message: ----------- 60399 19721 fix #name send in Slot tests https://pharo.fogbugz.com/f/cases/19721 http://files.pharo.org/image/60/60399.zip

Feb. 17, 2017

Re: [Pharo-dev] [Pharo6][Issue Tracker] Please check older issues

by Marcus Denker

Current Status: Open Issues: 625 For Pharo6: 125 > On 16 Feb 2017, at 11:02, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > The issue tracker is at 632 open issues. > > https://pharo.fogbugz.com/f/filters/57/All-newest-first > > Please check every issue that you either opened or were part > of the discussion. > - is this issue still relevant? > - if tagged for the Pharo 6 milestone: is it really a showstopper? > ==> if not, remove the milestone > - is there a question asked in the discussion? Maybe you can answer it? > > > We have right now 141 issues tagged with Pharo6 milestone. Sorted by priority: > > https://pharo.fogbugz.com/f/filters/1192/6-0-All > > Any help to get these numbers down would be great! > > Marcus

Feb. 17, 2017

Re: [Pharo-dev] Pharo-dev Digest, Vol 46, Issue 17

by komarlu2＠fit.cvut.cz

"Send Pharo-dev mailing list submissions to pharo-dev(a)lists.pharo.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org or, via email, send a message with subject or body 'help' to pharo-dev-request(a)lists.pharo.org You can reach the person managing the list at pharo-dev-owner(a)lists.pharo.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Pharo-dev digest..." Today's Topics: 1. Re: FastTableModel switched from default single-select to multi (Martin Dias) 2. Re: Integer arithmetic and bit counting performance in Squeak and Pharo (Eliot Miranda) 3. Re: [ANN] Pharo Association: Join or Renew now! (Marcus Denker) 4. CI down this morning for maintance (Marcus Denker) 5. Re: [Pharo-users] [ANN] Pharo Association: Join or Renew now! (denker) 6. Re: CI down this morning for maintance (Marcus Denker) 7. [Pharo6][Issue Tracker] Please check older issues (Marcus Denker) 8. [VM] Windows VM SurfacePlugin.dll LoadLibrary failure (Peter Uhnak) 9. [pharo-project/pharo-core] 03cd61: 60396 (GitHub) 10. [pharo-project/pharo-core] (GitHub) 11. Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure (Cyril Ferlicot D.) 12. Re: Code Completion in Pharo (Guillermo Polito) 13. 2 seconds default time limit for tests (Denis Kudriashov) 14. Re: 2 seconds default time limit for tests (Guillermo Polito) 15. Re: [Pharo-users] [ANN] Pharo Association: Join or Renew now! (denker) 16. blog post about Calypso navigation model (Denis Kudriashov) 17. Re: 2 seconds default time limit for tests (Esteban Lorenzano) 18. Re: 2 seconds default time limit for tests (Sven Van Caekenberghe) 19. Pharo Papers (Ben Coman) 20. Re: 2 seconds default time limit for tests (Denis Kudriashov) 21. Re: 2 seconds default time limit for tests (Denis Kudriashov) 22. Re: 2 seconds default time limit for tests (Sven Van Caekenberghe) 23. Re: 2 seconds default time limit for tests (Denis Kudriashov) 24. Re: 2 seconds default time limit for tests (Guillermo Polito) 25. Re: 2 seconds default time limit for tests (Ben Coman) 26. Re: 2 seconds default time limit for tests (Denis Kudriashov) 27. Re: Pharo Papers (denker) 28. Re: 2 seconds default time limit for tests (Denis Kudriashov) 29. Re: [Pharo-users] [ANN] Pharo Association: Join or Renew now! (denker) 30. 17240 Spur, when saving an image, it never shrinks (Ben Coman) 31. Re: 17240 Spur, when saving an image, it never shrinks (denker) 32. Re: 17240 Spur, when saving an image, it never shrinks (Sven Van Caekenberghe) 33. Re: [Pharo-users] [ANN] Pharo Association: Join or Renew now! (Peter Uhnak) 34. Re: 17240 Spur, when saving an image, it never shrinks (denker) 35. Re: [Pharo-users] [ANN] Pharo Association: Join or Renew now! (denker) 36. Re: 17240 Spur, when saving an image, it never shrinks (Sven Van Caekenberghe) 37. Re: 17240 Spur, when saving an image, it never shrinks (denker) 38. Re: 17240 Spur, when saving an image, it never shrinks (Cl?ment Bera) 39. Re: 17240 Spur, when saving an image, it never shrinks (Ben Coman) ---------------------------------------------------------------------- Message: 1 Date: Wed, 15 Feb 2017 14:01:54 -0300 From: Martin Dias <tinchodias(a)gmail.com> To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] FastTableModel switched from default single-select to multi Message-ID: <CAPm7VF13zQJ0VPHhZO3Og-6ZApHOivJHDsvuSYqrnT93gdxvcA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Reported as https://pharo.fogbugz.com/f/cases/19715/ FastTableModel-Can-t-enable-multiple-selection I checked that multiple selection works with ListModel (the superclass of FastTableModel). Martin On Wed, Feb 15, 2017 at 1:56 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi, > > I can't reproduce in #60394. In fact I *want* multiple selection and only > get single selection: > > FastTableModel new beMultipleSelection; items: (1 to: 10) asArray; > openWithSpec. > > Martin > > > > On Mon, Feb 13, 2017 at 9:03 PM, Stephan Eggermont <stephan(a)stack.nl> > wrote: > >> On 13/02/17 12:52, Andrei Chis wrote: >> >>> Is this in the Glamour model or in the Spec one? >>> >> >> In the Spec one, so I might be a bit late in noticing. >> >> Stephan >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/ attachments/20170215/c7bddad8/attachment-0001.html> ------------------------------ Message: 2 Date: Wed, 15 Feb 2017 10:21:57 -0800 From: Eliot Miranda <eliot.miranda(a)gmail.com> To: Benoit St-Jean <bstjean(a)yahoo.com>, Pharo Development List <pharo-dev(a)lists.pharo.org> Cc: Cl?ment Bera <bera.clement(a)gmail.com>, The General-purpose Squeak Developers List <squeak-dev(a)lists.squeakfoundation.org> Subject: Re: [Pharo-dev] Integer arithmetic and bit counting performance in Squeak and Pharo Message-ID: <CAC20JE3tVL0s4umX6QPG%3D%2Buz%3DjCxDuwUXTOHc%2B6Wmv7BBniRSw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Benoit, the upshot is that in 32-bits one should probably model a chess board bit mask with three or four SmallIntegers, for example 16 squares per integer, but in 64-bits one can use two SmallIntegers, with 32 squares per integer. You could construct a family of class that hide the representational details. A ChessBoardBitMap abstract class with subclasses for the 4 32-bit SmallIntegers representation, the 2 64-bit SmallIntegers representation, and the polymorphic single integer that will be either a SmallInteger or a LargePositiveInteger, depending on the board and the word size of the system. You can then play with the representation as your program evolves and as e.g. the Sista optimizer evolves, which should be abel to optimize away some of the overhead of using this "boxed" ChessBoardBitMap approach. On Fri, Feb 10, 2017 at 4:21 AM, Benoit St-Jean via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: "Cl?ment Bera" <bera.clement(a)gmail.com>, Pharo Development List < > pharo-dev(a)lists.pharo.org> > Cc: The General-purpose Squeak Developers List < > squeak-dev(a)lists.squeakfoundation.org> > Date: Fri, 10 Feb 2017 12:21:33 +0000 (UTC) > Subject: Re: [Pharo-dev] Integer arithmetic and bit counting performance > in Squeak and Pharo > Oh! Many thanks for all the details! I thought about special selectors > and remembered that #bitAnd: and #bitOr: were those special kind of > "beasts" but I falsely assumed that #bitXor: was also a special selector... > :( I should have looked at the code! > > So that also explains the "strange" behavior of the 64bit image. Lots of > the tests in the 32bit image fell into the LargeInteger "range" and then, > executing the same code on the 64bit image, those numbers suddenly became > considered SmallInteger... That explains it all and why some operations > "suddenly" became so fast for no apparent reason !!! > > Now, just for my personal curiosity, what is going to be the impact of a > 64bit VM on such code? (Unfortunately, I am on Windows so I will have to > wait...) ? > > P.S. I should have persevered in my google searches as I just came across > this *excellent* post : Arithmetic, inlined and special selectors > <https://clementbera.wordpress.com/2014/08/12/arithmetic-inlined-and- special-selectors/> > > :) > > Thanks a lot! > > Arithmetic, inlined and special selectors > Today we are going to discuss how message sends are dispatched in the VM > and/or compiled in the image for arithm... > > <https://clementbera.wordpress.com/2014/08/12/arithmetic-inlined-and- special-selectors/> > > > ----------------- > Beno?t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > ------------------------------ > *From:* Cl?ment Bera <bera.clement(a)gmail.com> > *To:* Benoit St-Jean <bstjean(a)yahoo.com>; Pharo Development List < > pharo-dev(a)lists.pharo.org> > *Cc:* The General-purpose Squeak Developers List <squeak-dev@lists. > squeakfoundation.org> > *Sent:* Friday, February 10, 2017 5:14 AM > *Subject:* Re: [Pharo-dev] Integer arithmetic and bit counting > performance in Squeak and Pharo > > Hi, > > This is a lovely post. Thanks for posting about Smalltalk / Pharo / Squeak. > > > 1. Why *exactly* does the override work (in 32bit images)? > 2. What changed so that things are different in Squeak 5.1 64bit image > (overrides partially work)? > > If I am correct your questions are exclusively for bitOr: and bitAnd:. I > don't know what you are aware of and what you're not aware of, hence I am > going to give you some details on how bitAnd: is executed (bitOr: is done > exactly the same way), and hopefully there will be something you don't know > yet that should help you understand what's going on. > > *Execution of bitAnd:* > > bitAnd: a special selector. If you run Smalltalk specialSelectors you get > this array: #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 > #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 > #next 0 #nextPut: 1 #atEnd 0 #== 1 #class 0 #blockCopy: 1 #value 0 #value: > 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) which includes bitAnd: . > > Special selectors are encoded in the bytecode differently to save memory, > so they can be executed differently without inducing overhead. In Cog, > bitAnd: is executed differently using type-prediction. > > In the Stack Interpreter, the execution of bitAnd: is done as follows: > If both operands are SmallIntegers, > push the bitAnd: value of the 2 SmallIntegers > else > Try the primitive BitAnd for SmallIntegers (14) > on success > push the result > on failure > perform the send. > > In the JIT, bitAnd: sends are compiled differently that normal send, the > compilation logic is as follows: > If both operands are SmallInteger literals > compute the result during compilation and use this value > else > If one of the 2 operands is a SmallInteger literal > generate 2 paths, a quick inlined path testing at runtime that > the other operand is a SmallInteger, and if so, Ands the operands and use > that result, else use the slow path performing a send > else > generate a normal send > > *Primitives* > > primitive 14 -> Works for SmallIntegers and LargePositiveInteger fitting > in an unsigned machine word. (Slower than direct SmallInteger bitAnd > performed by the special selector) > primitive 34 -> Works for SmallIntegers and LargePositiveInteger fitting > in an unsigned int64. (Slower than primitive 14 in 32 bits but covering > more cases, equivalent in 64 bits) > primDigitBitAnd (in Integer) -> Works for any integer. (Slower than the > primitive 14 and 34) > > *SmallInteger encoding* > > In 32 bits, SmallIntegers are signed 31bits integer. > In 64 bits, SmallIntegers are signed 61 bits integer. > > *Discussion* > > Let's make some assertions based on previous information: > > 1) If you have the exact same bitAnd: implementation for #bitAnd: and > #bitAnd2:, #bitAnd2: is slower because it is not a special selector. > > 2) Still with the exact same bitAnd: implementation, using the JIT, things > like that: > 16r1 bitAnd: 1. "1 bits" > 16r2 bitAnd: 2. "2 bit" > 16r4 bitAnd: 4. "3 bit" > 16r8 bitAnd: 3. "4 bit" > Are bitAnd: operations between SmallInteger constants and the result is > unused. Hence this whole portion of code does not generate any native > instructions. > On the other hand, things like that: > 16r1 bitAnd2: 1. "1 bits" > 16r2 bitAnd2: 2. "2 bit" > 16r4 bitAnd2: 4. "3 bit" > 16r8 bitAnd2: 3. "4 bit" > Are sends, generating multiple native instructions including calls. > > 3) Because of the SmallInteger encoding, > 16r200000000000000 bitAnd: 98490667780264321. "58 bit" > is compiled by the JIT to nothing in 64 bits but to a send in 32 bits (the > JIT can't solve LargeInteger arithmetic at compilation time). > > 4) primitive 34 provides some speed-up over primitive 14 in 32 bits, > covering bitAnd: operations from unsigned 33 bits integer to unsigned 64 > bits integer, but makes no difference in 64 bits. In 64bits all the cases > covered by primitive 34 are covered by primitive 14, so it should even slow > down things. > > *So...* > > Does this answer your questions ? > Don't hesitate to ask further questions. > > If you want more details, I wrote something about special selectors a > while ago: https://clementbera.wordpress.com/2014/08/12/ > arithmetic-inlined-and-special-selectors/ . > > Best, > > Clement > > PS1: If I'm correct, you referenced my blog a couple times, thank you for > doing this, I really appreciate that. > PS2: I enjoy chess myself, so if you have an open-source/MIT working > algorithm at some point please send it to me, I will play against the AI > and look at the code. > > > On Fri, Feb 10, 2017 at 8:18 AM, Benoit St-Jean via Pharo-dev < > pharo-dev(a)lists.pharo.org> wrote: > > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: The General-purpose Squeak Developers List <squeak-dev@lists. > squeakfoundation.org <squeak-dev(a)lists.squeakfoundation.org>>, " > pharo-dev(a)lists.pharo.org" <pharo-dev(a)lists.pharo.org> > Cc: > Date: Fri, 10 Feb 2017 07:18:02 +0000 (UTC) > Subject: Integer arithmetic and bit counting performance in Squeak and > Pharo > For those interested in performance of bit operations and integer > arithmetic in Squeak and Pharo : > > Bit operations in general : https://endormitoire.wordpress > .com/2017/02/10/bits-and- pieces/ > <https://endormitoire.wordpress.com/2017/02/10/bits-and-pieces/> > > Bit counting algorithms : https://endormitoire.wordpress > .com/2017/02/10/1001001-sos/ > <https://endormitoire.wordpress.com/2017/02/10/1001001-sos/> > > Some questions, some results, some answers... > > ----------------- > Beno?t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/ attachments/20170215/1bff07ec/attachment-0001.html> ------------------------------ Message: 3 Date: Thu, 16 Feb 2017 10:15:34 +0100 From: Marcus Denker <marcus.denker(a)inria.fr> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Cc: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] [ANN] Pharo Association: Join or Renew now! Message-ID: <0CDEDCF7-3470-4FB9-AC4E-8F9C6A6D9D5C(a)inria.fr> Content-Type: text/plain; charset="utf-8" We would be very interesting in ideas/improvements wrt. to the Association/ Consortium. if you have any ideas ?> send me a mail. Marcus > On 14 Feb 2017, at 15:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > The new Pharo Association website is up and running for some month. > > If you are a member, it will bug you once a year to renew. > > If you were a member in the past and have not been bugged by the system to renew until now, > please subscribe now as a new member. > > (We added all active members, but as the old system was purely manual, people did not get > asked to renew very consistently and you might not be in the system anymore) > > See the website for more information: > > https://association.pharo.org <https://association.pharo.org/> > > > Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/ attachments/20170216/6ecfea87/attachment-0001.html> ------------------------------ Message: 4 Date: Thu, 16 Feb 2017 10:22:00 +0100 From: Marcus Denker <marcus.denker(a)inria.fr> To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] CI down this morning for maintance Message-ID: <9E208550-9EE2-4432-BE08-AEAD1A35267D(a)inria.fr> Content-Type: text/plain; charset=us-ascii Hi, The ci (pharo and pharo-contrib) has some maintenance this morning and can be down for some hours. Marcus ------------------------------ Message: 5 Date: Thu, 16 Feb 2017 10:43:42 +0100 From: denker <marcus.denker(a)inria.fr> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Cc: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Association: Join or Renew now! Message-ID: <0285BD52-B73D-41C2-B7DE-594074F02EE7(a)inria.fr> Content-Type: text/plain; charset="utf-8" Hi, Yes, we are planning to extend the profiles to have space for -> website -> short bio -> list of interests -> interested in listed as public pharo consultant? *and* we will then automatically generate http://consultants.pharo.org < http://consultants.pharo.org/> from that data, too. Marcus > On 16 Feb 2017, at 10:32, john pfersich <jpfersich(a)gmail.com> wrote: > > The old site allowed you to put a web site on your profile page. That would be nice to have back. > > > On Feb 16, 2017 01:17, "Marcus Denker" <marcus.denker(a)inria.fr <mailto: marcus.denker(a)inria.fr>> wrote: > We would be very interesting in ideas/improvements wrt. to the Association/Consortium. > > if you have any ideas ?> send me a mail. > > Marcus > >> On 14 Feb 2017, at 15:17, Marcus Denker <marcus.denker(a)inria.fr <mailto: marcus.denker(a)inria.fr>> wrote: >> >> Hi, >> >> The new Pharo Association website is up and running for some month. >> >> If you are a member, it will bug you once a year to renew. >> >> If you were a member in the past and have not been bugged by the system to renew until now, >> please subscribe now as a new member. >> >> (We added all active members, but as the old system was purely manual, people did not get >> asked to renew very consistently and you might not be in the system anymore) >> >> See the website for more information: >> >> https://association.pharo.org <https://association.pharo.org/> >> >> >> Marcus > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/ attachments/20170216/9912ebb6/attachment-0001.html> ------------------------------ Message: 6 Date: Thu, 16 Feb 2017 10:49:58 +0100 From: Marcus Denker <marcus.denker(a)inria.fr> To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] CI down this morning for maintance Message-ID: <8680E50E-2AD6-493E-A4C5-97DBDDAA0463(a)inria.fr> Content-Type: text/plain; charset=us-ascii Everything is online again! > On 16 Feb 2017, at 10:22, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > The ci (pharo and pharo-contrib) has some maintenance this morning and can be down for some > hours. > > Marcus ------------------------------ Message: 7 Date: Thu, 16 Feb 2017 11:02:11 +0100 From: Marcus Denker <marcus.denker(a)inria.fr> To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] [Pharo6][Issue Tracker] Please check older issues Message-ID: <CB61592F-D422-475C-A7E5-2E389619B280(a)inria.fr> Content-Type: text/plain; charset=us-ascii Hi, The issue tracker is at 632 open issues. https://pharo.fogbugz.com/f/filters/57/All-newest-first Please check every issue that you either opened or were part of the discussion. - is this issue still relevant? - if tagged for the Pharo 6 milestone: is it really a showstopper? ==> if not, remove the milestone - is there a question asked in the discussion? Maybe you can answer it? We have right now 141 issues tagged with Pharo6 milestone. Sorted by priority: https://pharo.fogbugz.com/f/filters/1192/6-0-All Any help to get these numbers down would be great! Marcus ------------------------------ Message: 8 Date: Thu, 16 Feb 2017 11:06:08 +0100 From: Peter Uhnak <i.uhnak(a)gmail.com> To: pharo-dev(a)lists.pharo.org Subject: [Pharo-dev] [VM] Windows VM SurfacePlugin.dll LoadLibrary failure Message-ID: <20170216100608.GA10@LOCAL> Content-Type: text/plain; charset=us-ascii Hi, recently (couple of days ago) sometimes when I start Pharo there's a box at the bottom "Debug console" with the following info ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Debug console # To close: F2 -> 'debug options' -> 'show output console' # To disable: F2 -> 'debug options' -> 'show console on errors' LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. ) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I have Windows 10 & VM Version: Cog Spur VM 5.0 (release) from Feb 3 2017 (downloaded from files.pharo.org) This error results in Athens (and Roassal) not working, although Pharo itself seems fine. Reopening the image has no effect, and the only resolution is to do a system reboot. There is also crash.dmp from Feb 12 (possibly the day it started) containing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sun Feb 12 23:10:24 2017 Exception code: C0000005 Exception addr: 0040BDD0 Access violation (write access) at 00AFF43C EAX:FFFFFFFF EBX:74329850 ECX:549D7EBE EDX:00AFF43C ESI:74315F70 EDI:00489DB9 EBP:0887FF94 ESP:0887FF54 EIP:0040BDD0 EFL:00010206 FP Control: 0000027F FP Status: 00000000 FP Tag: 0000FFFF Crashed in some other thread ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Makes me wonder whether the SurfacePlugin.dll didn't somehow get corrupted... but then again there's no modification date change on the dll file, nor would it explain why rebooting fixes it. Thanks, Peter ------------------------------ Message: 9 Date: Thu, 16 Feb 2017 02:17:14 -0800 From: GitHub <noreply(a)github.com> To: pharo-dev(a)lists.pharo.org Subject: [Pharo-dev] [pharo-project/pharo-core] 03cd61: 60396 Message-ID: <58a57c2a613b4_19b33fcf7e66fc3c837c8(a)hookshot-fe3-cp1-prd.iad.github.net. mail> Content-Type: text/plain; charset="utf-8" Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 03cd61e0aae1f586d4890c320a7bd01e00fc78dc https://github.com/pharo-project/pharo-core/commit/03cd61e0aae1f586d4890c320 a7bd01e00fc78dc Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-16 (Thu, 16 Feb 2017) Changed paths: M Kernel-Tests.package/ClassHierarchyTest.class/instance/tests/ testObjectFormatInstSize.st M Metacello-ToolBox.package/MetacelloToolBox.class/instance/api- configuration/updateVersionMethodForVersion_projectAttributes_updateProjects _updatePackages_versionSpecsDo_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script 60395.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script 60396.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update 60395.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update 60396.st M ScriptLoader60.package/ScriptLoader.class/instance/public/ commentForCurrentUpdate.st Log Message: ----------- 60396 19716 The method Pragma>>#selector called from MetacelloToolBox https://pharo.fogbugz.com/f/cases/19716 19713 improve #testObjectFormatInstSize https://pharo.fogbugz.com/f/cases/19713 http://files.pharo.org/image/60/60396.zip ------------------------------ Message: 10 Date: Thu, 16 Feb 2017 02:17:14 -0800 From: GitHub <noreply(a)github.com> To: pharo-dev(a)lists.pharo.org Subject: [Pharo-dev] [pharo-project/pharo-core] Message-ID: <58a57c2af29f0_1e53ff749c0bc3412854(a)hookshot-fe2-cp1-prd.iad.github.net.mail > Content-Type: text/plain; charset="utf-8" Branch: refs/tags/60396 Home: https://github.com/pharo-project/pharo-core ------------------------------ Message: 11 Date: Thu, 16 Feb 2017 12:19:00 +0100 From: "Cyril Ferlicot D." <cyril.ferlicot(a)gmail.com> To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] [VM] Windows VM SurfacePlugin.dll LoadLibrary failure Message-ID: <9550efba-de74-3d88-5631-0419ffb02f72(a)gmail.com> Content-Type: text/plain; charset="windows-1252" On 16/02/2017 11:06, Peter Uhnak wrote: > Hi, > > recently (couple of days ago) sometimes when I start Pharo there's a box at the bottom "Debug console" with the following info > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > # Debug console > # To close: F2 -> 'debug options' -> 'show output console' > # To disable: F2 -> 'debug options' -> 'show console on errors' > LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. > > ) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I have Windows 10 & VM Version: Cog Spur VM 5.0 (release) from Feb 3 2017 (downloaded from files.pharo.org) > > This error results in Athens (and Roassal) not working, although Pharo itself seems fine. > > Reopening the image has no effect, and the only resolution is to do a system reboot. > > > There is also crash.dmp from Feb 12 (possibly the day it started) containing > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Sun Feb 12 23:10:24 2017 > > Exception code: C0000005 > Exception addr: 0040BDD0 > Access violation (write access) at 00AFF43C > EAX:FFFFFFFF EBX:74329850 ECX:549D7EBE EDX:00AFF43C > ESI:74315F70 EDI:00489DB9 EBP:0887FF94 ESP:0887FF54 > EIP:0040BDD0 EFL:00010206 > FP Control: 0000027F > FP Status: 00000000 > FP Tag: 0000FFFF > > > Crashed in some other thread > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Makes me wonder whether the SurfacePlugin.dll didn't somehow get corrupted... but then again there's no modification date change on the dll file, nor would it explain why rebooting fixes it. > > Thanks, > Peter > Hi, I got the same problem with the latest vm some weeks ago on Windows 7. It vanished by downloading a new vm some days after. I did not try with the current latest. I'll maybe have the time to try this week end. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques Pr?vert 01, 59650 Villeneuve d'ascq France -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/ attachments/20170216/6d56c0fc/attachment-0001.asc> ------------------------------ Message: 12 Date: Thu, 16 Feb 2017 13:31:26 +0100 From: Guillermo Polito <guillermopolito(a)gmail.com> To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] Code Completion in Pharo Message-ID: <CAOBmb51TLyahCBWfpjFVTLg8LSqgwJJCd_5JQzAM0aq2LnLRtA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" " Hi Guille, thanks for the answer, it really helps that so many of you take such an interest in this. So many people responded to the survey with so many great ideas and issues, that I really have to prioritize and it's coming very clear now that I will just be able to satisfy a few of my correspondents with what I'll manage to finish. I think going so deep in whit the AST-based suggestion wouldn't be a good idea for me at this point simply because of the deadline and the complexity of it. So the thesis should be about making the most of changing the small stuff and mapping what could be done in the future. I should cover many things like what c. c. algorithm could be used or how the interface should change or how to remove the registration to Smalltalk tools and stuff like that, but in the end I don't think I'll have enough time to cover all the really interesting stuff in this thesis. I thought about the AST as well and that it could have a really huge impact, but at this point my priority is to make sure that I finish the thesis in time, that I'll implement as much as possible of the little things and that I map what could be done in the future. I still want to continue on this project after I have my Bachelor's degree, but I just worry that until then I cannot afford having too big expectations. Lukas Â " Hi Lukas, This is cool and an interesting topic. Something that I would like is to see wether we can merge the auto-completion with the AST-based suggestion mechanism (right click on a piece of code -> suggestions), that provides suggestions for refactorings and code browsing. I mean, you can see auto-completion as a particular suggestion to add a word where the current cursor is placed. A somehow related question is to apply type inference mechanisms to enhance the suggested completions. You can check the work done lately on type inferencers for Pharo in here: http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_An%20extensible%20 constraint-based%20type%20inference%20algorithm%20for%20object-oriented%20 dynamic%20languages%20supporting%20blocks%20and%20generic%20types.pdf Guille On Tue, Feb 14, 2017 at 6:57 PM, <komarlu2(a)fit.cvut.cz> wrote: > Hello to all, > > I am a student at the Faculty of Information Technology of the Czech > Technical University in Prague and I decided to make Code Completion in > Pharo the topic of my Bachelor's degree and try to improve it. > > If you have suggestions on what should change / how to change it so you > would be satisfied with it, I will appreciate any input on this topic. It > would mean a lot to me if you could find two minutes and take this survey > (there are only like 7 questions, so it won't take longer than those 2 > minutes): > > https://docs.google.com/forms/d/e/1FAIpQLSd7lx6gIN079-vMvMwRsnA_AX_e_ > 7sZEz2XJQ4059nk_-LV6w/viewform > > Regards > > > Lukas > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/ attachments/20170216/cdb8a1a5/attachment-0001.html> ------------------------------ Message: 13 Date: Thu, 16 Feb 2017 13:33:53 +0100 From: Denis Kudriashov <dionisiydk(a)gmail.com> To: Discusses Development of Pharo <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] 2 seconds default time limit for tests Message-ID: <CAG0zXM7pdyre6qNd-52hCYJDUu5gMyEUX2KCY5P9MjhTdwUwhA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi. In Pharo 6 we introduced time limit for tests. Currently it is set to 1 minute by default. And concrete test cases or single tests can redefine it with suitable value. There is also setting to change default limit globally which should help to not adopt external projects immediately if current limit is bad for them. There is issue 19105 <https://pharo.fogbugz.com/f/cases/19105/Default-time-limit-for-tests-should -be-really-small> to make limit really small. It will set default limit for 2 seconds. Slow tests are already marked with bigger value. So it is safe for integration Here I ask for your agreement with this change. Or disagreement if there are good reasons to not do this. I hope following story will convince you that default time limit should be small: I worked on tests for new project and I got hanging tests. These tests were waiting for some event which not happens because of bugs. They will be failed after 1 minutes due to timeout. But when you work on code you of course do not want to wait 1 minute. So it always forces manual interrupt of running tests. But then you could not run full test suite to see all problem tests. And also it is not really easy to detect current running test after interrupt. You need analyze stack in debugger and if you just close debugger information is lost. So to fix it I change default timeout in each of my test cases. If you will work on similar code you will need same approach to comfortably detect and fix "synchronization" bugs. So this was my story. I am sure default behaviour with small time limit will make SUnit much better. Common case is that unit tests are supposed to be fast. Users expect it by default. And if something is going wrong fast tests should fail fast. When user wrote slow test it is expected to know that test is slow. And for such rare cases user can mark slow tests explicitly. But SUnit should not expect tests to be slow by default. I think it is really good improvement for Pharo 6. It makes TDD in Pharo better. Best regards, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/ attachments/20170216/29c0581b/attachment-0001.html> ------------------------------ Message: 14 Date: Thu, 16 Feb 2017 13:49:58 +0100 From: Guillermo Polito <guillermopolito(a)gmail.com> To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] 2 seconds default time limit for tests Message-ID: <CAOBmb52HAic0Cgv1aPYECyeXE_N_83QXN3nuxo6a3MH0FJosaQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" I vote for not introducing during code-freeze. We can discuss it for Pharo 7, I'm not against actually. But I have some concerns: - How does it work when we are debugging? I mean, imagine I'm running a test, a debugger is open, and I start working on it. How do these timeout currently work in this scenario? I imagine that the test runner should detect you entered into a "I'm debugging" mode and should not kill your test, but this is not clear to me how this works right now. - Also, how can we better document these things? Because I was bitten a couple of times by this timeouts and the "I kill your process but I do not tell you", and it was not nice because it was completely silent or obscure. Guille On Thu, Feb 16, 2017 at 1:33 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > In Pharo 6 we introduced time limit for tests. Currently it is set to 1 > minute by default. And concrete test cases or single tests can redefine it > with suitable value. There is also setting to change default limit globally > which should help to not adopt external projects immediately if current > limit is bad for them. > > There is issue 19105 > <https://pharo.fogbugz.com/f/cases/19105/Default-time-limit-for-tests- should-be-really-small> to > make limit really small. It will set default limit for 2 seconds. Slow > tests are already marked with bigger value. So it is safe for integration > > Here I ask for your agreement with this change. Or disagreement if there > are good reasons to not do this. > > I hope following story will convince you that default time limit should be > small: > > I worked on tests for new project and I got hanging tests. These tests > were waiting for some event which not happens because of bugs. They will be > failed after 1 minutes due to timeout. > > But when you work on code you of course do not want to wait 1 minute. So > it always forces manual interrupt of running tests. But then you could not > run full test suite to see all problem tests. And also it is not really > easy to detect current running test after interrupt. You need analyze stack > in debugger and if you just close debugger information is lost. > > So to fix it I change default timeout in each of my test cases. > If you will work on similar code you will need same approach to > comfortably detect and fix "synchronization" bugs. > > So this was my story. I am sure default behaviour with small time limit > will make SUnit much better. > Common case is that unit tests are supposed to be fast. Users expect it by > default. And if something is going wrong fast tests should fail fast. > When user wrote slow test it is expected to know that test is slow. And > for such rare cases user can mark slow tests explicitly. But SUnit should > not expect tests to be slow by default. > > I think it is really good improvement for Pharo 6. It makes TDD in Pharo > better. > > Best regards, > Denis > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/ attachments/20170216/714c3b0f/attachment-0001.html> ------------------------------ Message: 15 Date: Thu, 16 Feb 2017 14:06:02 +0100 From: denker <marcus.denker(a)inria.fr> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Cc: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Association: Join or Renew now! Message-ID: <A69B3689-4913-4199-AFF9-1E1BCB121E44(a)inria.fr> Content-Type: text/plain; charset=us-ascii > On 16 Feb 2017, at 10:43, denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > Yes, we are planning to extend the profiles to have space for > -> website I have added a field for the website. Marcus ------------------------------ Message: 16 Date: Thu, 16 Feb 2017 14:10:06 +0100 From: Denis Kudriashov <dionisiydk(a)gmail.com> To: Discusses Development of Pharo <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] blog post about Calypso navigation model Message-ID: <CAG0zXM7T-HG9aaYvFMkVtb0dW0e1j-RLD8%2BfDEhgwMZQkkd%3Dow(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello. I wrote blog post about Calypso navigation model http://dionisiydk.blogspot.fr/2017/02/calypso-navigation-model.html. Questions and feedback are welcome. Best regards, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/ attachments/20170216/c7e68704/attachment-0001.html> ------------------------------ Message: 17 Date: Thu, 16 Feb 2017 14:23:35 +0100 From: Esteban Lorenzano <estebanlm(a)gmail.com> To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] 2 seconds default time limit for tests Message-ID: <B947AED0-836B-442F-927C-349C29EF874B(a)gmail.com> Content-Type: text/plain; charset="us-ascii" > On 16 Feb 2017, at 13:49, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > I vote for not introducing during code-freeze. +1: not in code freeze. > > We can discuss it for Pharo 7, I'm not against actually. But I have some concerns: > > - How does it work when we are debugging? > I mean, imagine I'm running a test, a debugger is open, and I start working on it. How do these timeout currently work in this scenario? I imagine that the test runner should detect you entered into a "I'm debugging" mode and should not kill your test, but this is not clear to me how this works right now. > > - Also, how can we better document these things? Because I was bitten a couple of times by this timeouts and the "I kill your process but I do not tell you", and it was not nice because it was completely silent or obscure. > > Guille > > On Thu, Feb 16, 2017 at 1:33 PM, Denis Kudriashov <dionisiydk(a)gmail.com < mailto:dionisiydk@gmail.com>> wrote: > Hi. > > In Pharo 6 we introduced time limit for tests. Currently it is set to 1 minute by default. And concrete test cases or single tests can redefine it with suitable value. There is also setting to change default limit globally which should help to not adopt external projects immediately if current limit is bad for them. > > There is issue 19105 <https://pharo.fogbugz.com/f/cases/19105/Default-time -limit-for-tests-should-be-really-small> to make limit really small. It will set default limit for 2 seconds. Slow tests are already marked with bigger value. So it is safe for integration > > Here I ask for your agreement with this change. Or disa"

Feb. 17, 2017

Re: [Pharo-dev] Code Completion in Pharo

by Torsten Bergmann

Beside regular Smalltalk completion I personally would like to see also support for custom templates in the code completion (similar to whatÂ Eclipse provides, see https://www.youtube.com/watch?v=zqm4CB1BX6Y)

Feb. 17, 2017