"Send Pharo-dev mailing list submissions to pharo-dev@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@lists.pharo.org You can reach the person managing the list at pharo-dev-owner@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@gmail.com> To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] FastTableModel switched from default single-select to multi Message-ID: <CAPm7VF13zQJ0VPHhZO3Og-6ZApHOivJHDsvuSYqrnT93gdxvcA@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@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@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@gmail.com> To: Benoit St-Jean <bstjean@yahoo.com>, Pharo Development List <pharo-dev@lists.pharo.org> Cc: Cl?ment Bera <bera.clement@gmail.com>, The General-purpose Squeak Developers List <squeak-dev@lists.squeakfoundation.org> Subject: Re: [Pharo-dev] Integer arithmetic and bit counting performance in Squeak and Pharo Message-ID: <CAC20JE3tVL0s4umX6QPG=+uz=jCxDuwUXTOHc+6Wmv7BBniRSw@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@lists.pharo.org> wrote:

---------- Forwarded message ---------- From: Benoit St-Jean <bstjean@yahoo.com> To: "Cl?ment Bera" <bera.clement@gmail.com>, Pharo Development List < pharo-dev@lists.pharo.org> Cc: The General-purpose Squeak Developers List < squeak-dev@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@gmail.com> *To:* Benoit St-Jean <bstjean@yahoo.com>; Pharo Development List < pharo-dev@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@lists.pharo.org> wrote:

---------- Forwarded message ---------- From: Benoit St-Jean <bstjean@yahoo.com> To: The General-purpose Squeak Developers List <squeak-dev@lists. squeakfoundation.org <squeak-dev@lists.squeakfoundation.org>>, " pharo-dev@lists.pharo.org" <pharo-dev@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@inria.fr> To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Cc: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] [ANN] Pharo Association: Join or Renew now! Message-ID: <0CDEDCF7-3470-4FB9-AC4E-8F9C6A6D9D5C@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@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@inria.fr> To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: [Pharo-dev] CI down this morning for maintance Message-ID: <9E208550-9EE2-4432-BE08-AEAD1A35267D@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@inria.fr> To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Cc: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Association: Join or Renew now! Message-ID: <0285BD52-B73D-41C2-B7DE-594074F02EE7@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@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@inria.fr <mailto: marcus.denker@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@inria.fr <mailto: marcus.denker@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@inria.fr> To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] CI down this morning for maintance Message-ID: <8680E50E-2AD6-493E-A4C5-97DBDDAA0463@inria.fr> Content-Type: text/plain; charset=us-ascii Everything is online again!

On 16 Feb 2017, at 10:22, Marcus Denker <marcus.denker@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@inria.fr> To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: [Pharo-dev] [Pharo6][Issue Tracker] Please check older issues Message-ID: <CB61592F-D422-475C-A7E5-2E389619B280@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@gmail.com> To: pharo-dev@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@github.com> To: pharo-dev@lists.pharo.org Subject: [Pharo-dev] [pharo-project/pharo-core] 03cd61: 60396 Message-ID: <58a57c2a613b4_19b33fcf7e66fc3c837c8@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@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@github.com> To: pharo-dev@lists.pharo.org Subject: [Pharo-dev] [pharo-project/pharo-core] Message-ID: <58a57c2af29f0_1e53ff749c0bc3412854@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@gmail.com> To: pharo-dev@lists.pharo.org Subject: Re: [Pharo-dev] [VM] Windows VM SurfacePlugin.dll LoadLibrary failure Message-ID: <9550efba-de74-3d88-5631-0419ffb02f72@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@gmail.com> To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] Code Completion in Pharo Message-ID: <CAOBmb51TLyahCBWfpjFVTLg8LSqgwJJCd_5JQzAM0aq2LnLRtA@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@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@gmail.com> To: Discusses Development of Pharo <pharo-dev@lists.pharo.org> Subject: [Pharo-dev] 2 seconds default time limit for tests Message-ID: <CAG0zXM7pdyre6qNd-52hCYJDUu5gMyEUX2KCY5P9MjhTdwUwhA@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@gmail.com> To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] 2 seconds default time limit for tests Message-ID: <CAOBmb52HAic0Cgv1aPYECyeXE_N_83QXN3nuxo6a3MH0FJosaQ@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@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@inria.fr> To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Cc: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Association: Join or Renew now! Message-ID: <A69B3689-4913-4199-AFF9-1E1BCB121E44@inria.fr> Content-Type: text/plain; charset=us-ascii

On 16 Feb 2017, at 10:43, denker <marcus.denker@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@gmail.com> To: Discusses Development of Pharo <pharo-dev@lists.pharo.org> Subject: [Pharo-dev] blog post about Calypso navigation model Message-ID: <CAG0zXM7T-HG9aaYvFMkVtb0dW0e1j-RLD8+fDEhgwMZQkkd=ow@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@gmail.com> To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] 2 seconds default time limit for tests Message-ID: <B947AED0-836B-442F-927C-349C29EF874B@gmail.com> Content-Type: text/plain; charset="us-ascii"

On 16 Feb 2017, at 13:49, Guillermo Polito <guillermopolito@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@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"