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

Send Pharo-dev mailing list submissions to
[hidden email]

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
[hidden email]

You can reach the person managing the list at
[hidden email]

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 <[hidden email]>
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] FastTableModel switched from default
single-select to multi
Message-ID:
<[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
To: Benoit St-Jean <[hidden email]>, Pharo Development List
<[hidden email]>
Cc: Cl?ment Bera <[hidden email]>, The General-purpose Squeak
Developers List <[hidden email]>
Subject: Re: [Pharo-dev] Integer arithmetic and bit counting
performance in Squeak and Pharo
Message-ID:
<CAC20JE3tVL0s4umX6QPG=+uz=[hidden email]>
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 <
[hidden email]> wrote:

>
>
> ---------- Forwarded message ----------
> From: Benoit St-Jean <[hidden email]>
> To: "Cl?ment Bera" <[hidden email]>, Pharo Development List <
> [hidden email]>
> Cc: The General-purpose Squeak Developers List <
> [hidden email]>
> 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 <[hidden email]>
> *To:* Benoit St-Jean <[hidden email]>; Pharo Development List <
> [hidden email]>
> *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 <
> [hidden email]> wrote:
>
>
>
> ---------- Forwarded message ----------
> From: Benoit St-Jean <[hidden email]>
> To: The General-purpose Squeak Developers List <squeak-dev@lists.
> squeakfoundation.org <[hidden email]>>, "
> [hidden email]" <[hidden email]>
> 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 <[hidden email]>
To: Any question about pharo is welcome <[hidden email]>
Cc: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] [ANN] Pharo Association: Join or Renew now!
Message-ID: <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
To: Pharo Development List <[hidden email]>
Subject: [Pharo-dev] CI down this morning for maintance
Message-ID: <[hidden email]>
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 <[hidden email]>
To: Any question about pharo is welcome <[hidden email]>
Cc: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Association: Join
or Renew now!
Message-ID: <[hidden email]>
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 <[hidden email]> 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" <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> 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 <[hidden email]>
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] CI down this morning for maintance
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii

Everything is online again!

> On 16 Feb 2017, at 10:22, Marcus Denker <[hidden email]> 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 <[hidden email]>
To: Pharo Development List <[hidden email]>
Subject: [Pharo-dev] [Pharo6][Issue Tracker] Please check older issues
Message-ID: <[hidden email]>
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 <[hidden email]>
To: [hidden email]
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 <[hidden email]>
To: [hidden email]
Subject: [Pharo-dev] [pharo-project/pharo-core] 03cd61: 60396
Message-ID:
<[hidden email]>

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/03cd61e0aae1f586d4890c320a7bd01e00fc78dc
Author: Jenkins Build Server <[hidden email]>
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/script60395.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60396.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60395.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60396.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 <[hidden email]>
To: [hidden email]
Subject: [Pharo-dev] [pharo-project/pharo-core]
Message-ID:
<[hidden email]>

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." <[hidden email]>
To: [hidden email]
Subject: Re: [Pharo-dev] [VM] Windows VM SurfacePlugin.dll LoadLibrary
failure
Message-ID: <[hidden email]>
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 <[hidden email]>
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] Code Completion in Pharo
Message-ID:
<[hidden email]>
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%20constraint-based%20type%20inference%20algorithm%20for%20object-oriented%20dynamic%20languages%20supporting%20blocks%20and%20generic%20types.pdf

Guille


On Tue, Feb 14, 2017 at 6:57 PM, <[hidden email]> 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 <[hidden email]>
To: Discusses Development of Pharo <[hidden email]>
Subject: [Pharo-dev] 2 seconds default time limit for tests
Message-ID:
<[hidden email]>
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 <[hidden email]>
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] 2 seconds default time limit for tests
Message-ID:
<[hidden email]>
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 <[hidden email]>
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 <[hidden email]>
To: Any question about pharo is welcome <[hidden email]>
Cc: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Association: Join
or Renew now!
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii


> On 16 Feb 2017, at 10:43, denker <[hidden email]> 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 <[hidden email]>
To: Discusses Development of Pharo <[hidden email]>
Subject: [Pharo-dev] blog post about Calypso navigation model
Message-ID:
<CAG0zXM7T-HG9aaYvFMkVtb0dW0e1j-RLD8+fDEhgwMZQkkd=[hidden email]>
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 <[hidden email]>
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] 2 seconds default time limit for tests
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="us-ascii"


> On 16 Feb 2017, at 13:49, Guillermo Polito <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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