February 2017 - Pharo-dev - lists.pharo.org

Esteban's ChangeLog week of 13 February 2017
by estebanlm＠gmail.com Feb. 20, 2017

Feb. 20, 2017

Hello! This is my weekly ChangeLog, from 13 February 2017 to 19 February 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=13/2/2017&to=19/2/2017 ChangeLog ========= 17 February 2017: ----------------- * I spent sometime working on UFFI and 64bits. Sometime ago I started this and found a problem that I talked with Eliot, you can found the rational [here](http://forum.world.st/Support-for-LP64-amp-LLP64-in-FFI-Kernel-td4929946.html) (we need to model in some way the fact that longs have different sizes in different platforms, notably LP64 and LLP64). In that discussion, with Eliot we proposed to add a new FFI type, a +platformLong+ who will behave as expected. I started to implement but didn't have the time to finish it and I needed to jump to other stuff. In the mean time, Ronie found a different workaround: instead adding support in the VM, just map in image the type to correct size. This is how it will work: |=== |Platform |type |size |FFI type | |i386 |long |4 |long | |LP64 |long |8 |long long | |LLP64 |long |4 |long | |=== Ensuring this mappings happens when compiling an UFFI method (and a structure, etc.) we can workaround the plugin limitation. So I worked taking Ronie's work, extended it to structures and added my own work on mapping structures in a 'platform-agnostic' way: the idea is to take values by 'offset' instead the constant value as it was done up to now. On 'structure-compilation time' (it happens first time structure is used on a session), it calculates also the correct field access offsets and structure size. This is mostly working, it just lacks some testing and pushing it to image... then I can start prepare Athens, SDL2 and libgit2 bindings to work both in 32 and 64 bits :) 16 February 2017: ----------------- * I continue enhancing [iceberg](https://github.com/npasserini/iceberg/pull/277) as much as I can, waiting to +0.4 release+ (that should be very soon). I added a couple of new things: * capability of plugins to extend "remotes panel" of repositories browser (so we can have options there) * added a new GitHub option: remove old branches dialog. * and I started a refactor of GitHub plugin to use a command-pattern hierarchy instead polluting the plugin. Rationale of plugin action addition is simple: if we receive a lot of bugfixes in the form of a pull request, it means people will be spawning branches all over the place, those branches can stay there a lot of time but eventually, is good to clean up a bit. Now we can do this cleaning from Pharo :) This is not just useful but it shows the power we can achieve by extending iceberg with plugins for different purposes ;) 15 February 2017: ----------------- * I spent some time bringing back some functionality I implemented for [voyage](https://github.com/pharo-nosql/voyage) a lot of time ago (like 4 years) that went missing because of lack of use. This is a "dinamic singleton access strategy"... something like that, more or less... The idea of this is, sometimes you need to have more than one repository active in an image, but you still want to use the singleton strategy (because is a lot cooler doing something like +Person selectOne: [ ... ]+ instead of +myRepository selectOne: Person where: [...]+. Voyage always allowed different container strategies, even if in master implementation there is just one, +VOSingletonContainer+. Now I added another called +VODynamicContainer+ and this allow to take the repostory from a 'dynamic variable' called +VOCurrentRepository+. So, for instance, when you have a seaside application where each user works on his own database, you can create a filter of the way: ---- VoyageFilter>>handleFiltered: aRequestContext VOCurrentRepository value: self obtainUserRepository during: [ self next handleFiltered: aRequestContext ] VoyageFilter>>obtainUserRepository ^ self session propertyAt: #voyageRepository ifAbsentPut: [ VOMongoRepository database: (self session propertyAt: #username) ] ---- ... adn you will handle your application as if your repository would be a singleton. To make this work, the only thing you need is to configure your repository this way: ---- VORepository repositoryContainer: VODynamicContainer new ---- 14 February 2017: ----------------- * I lost all day digging the problem with +FFICallbackTests+ on windows platforms. The problem occurs when going back to the image from a callback context 'when calling the tests'. Is important to remark this because other systems using a lot of callbacks are working fine (notably iceberg, the libgit2 bindings use callbacks as an important part of his design). Also +Athens+ (who uses callbacks to provide some values cairo lib needs) is working correctly too. So, I'm tempted to think it may be a problem with +MinGW+ implementation of +qsort+ function, and we use it to test the callbacks... anyway, I will keep digging when I find some more time, for now is enough to constate it is not being a problem for windows users (unless, of course, they need to use qsort ;) ) 13 February 2017: ----------------- * I worked on a plugin for iceberg that will take the place of the old "create SLICE"... so far is a very simple plugin that does exactly wjat the slice creator did: takes an issue number and gets the title from it, to conform a branch name called +12345-issue-title-here+. With this change (pull request [here](https://github.com/npasserini/iceberg/pull/277)) all pieces to replace the old fix process are there: * adding remotes (so you can clone pharo and use your remote as temporal destination) * creating pull requests (so you can submit your changes in a fancy way) * creating branches that conforms to our convention (so you can create branches as we like them ;) ... all this in an easy way (at least for me, heh). It remains, of course, test everything and enhance it with user feedback, but we will be starting that next week. * I finally finished restoring testing phase to [VM building](https://github.com/pharo-project/pharo-vm). The purpose of this is, of course, to notice regressions on VMs as soon as we can, and of course, I found some regressions I needed to fix before being able to have a green build. Most of them were details but: * there was an important problem with +String+ primitives I needed to dealt with. * there is a problem on +FFICallback+ for windows who make the test crash (but callbacks works most of the time) There are, however, still some important problems to fix: * threaded VM linux cannot be tested because they requiere changing some linux configuration. * 64bits VMs still cannot be tested because I need to prepare a special image for it. I will try to fix some of this problems soon, but at least now we are "as we were before" :) cheers! Esteban

2 1

[pharo-project/pharo-core] c37833: 50769
by GitHub Feb. 20, 2017

Feb. 20, 2017

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c378335143a126714852fb8df52b7a78d4cdb6f7 https://github.com/pharo-project/pharo-core/commit/c378335143a126714852fb8d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-20 (Mon, 20 Feb 2017) Changed paths: M Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/initialize-release/initialize.st A Polymorph-Widgets.package/Pharo3Theme.class/instance/initialize-release/initialize.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50768.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50769.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50768.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50769.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50769 19310 Backport Pharo 5.0: Wrong border after dragging out of a window group (backport 19299) https://pharo.fogbugz.com/f/cases/19310 http://files.pharo.org/image/50/50769.zip

1 0

[pharo-project/pharo-core]
by GitHub Feb. 20, 2017

Feb. 20, 2017

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

1 0

confused about printString and printIt
by stepharong Feb. 19, 2017

Feb. 19, 2017

Hi guys I'm working on an introduction chapter for my future book and I do not like the behavior I see in latest pharo 60. And I do not understand the behavior of print-it (MFDirectory new name: 'comics') comics/ (MFDirectory new name: 'comics') printString >>> 'comics/' Why print it does not produce ''? Stef printIt "Treat the current text selection as an expression; evaluate it. Insert the description of the result of evaluation after the selection and then make this description the new text selection." | printString | self evaluateSelectionAndDo: [ :result | printString := [ result printString ] on: Error do: [ '<error in printString: try ''Inspect it'' to debug>' ]. self afterSelectionInsertAndSelect: printString ] -- Using Opera's mail client: http://www.opera.com/mail/

5 16

FileTree
by Jonathan Khalil Feb. 19, 2017

Feb. 19, 2017

Hi everyone, I'm Jonathan, student in master, from Dakar, SÃ©nÃ©gal and i will be working with stephane ducasse's team for my internship. I need some lectures on FileTree. Someone know how can i get it ? Thanks Jonathan

6 7

Seeking support: Vote for Jigyasa Grover for Red Hat International Women in Open Source Academic Awards 2017
by Jigyasa Grover Feb. 19, 2017

Feb. 19, 2017

Dear All It feels delighted to be nominated as finalist for *Red Hat International Women in Open Source Academic Awards 2017* owing to my significant contributions to the open source community spanning various organisations & projects viz FOSSASIA, Pharo/Smalltalk, European Smalltalk Users Group (ESUG), Hashkat, Women Who Code, Google Developers Group, Learn IT Girl!, various tech stints in Canada, Europe, Singapore & India, etc. and everyone's best wishes. After initial two rounds, final voting round is open now till March 6, 2017. I request and appeal all of you to kindly bless me with your valuable votes. Folks, Some love & maximum clicks please :wink: Details: https://www.redhat.com/en/about/women-in-open-source Vote here: https://engage.redhat.com/opensourceawards-winners-votingform-2017 -- View this message in context: http://forum.world.st/Seeking-support-Vote-for-Jigyasa-Grover-for-Red-Hat-I… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

3 4

Re: [Pharo-dev] Pharo-dev Digest, Vol 46, Issue 17
by komarlu2＠fit.cvut.cz Feb. 18, 2017

Feb. 18, 2017

"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=+uz=jCxDuwUXTOHc+6Wmv7BBniRSw(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+fDEhgwMZQkkd=ow(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"

2 1

[pharo-project/pharo-core]
by GitHub Feb. 17, 2017

Feb. 17, 2017

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

1 0

[pharo-project/pharo-core] 358123: 60400
by GitHub Feb. 17, 2017

Feb. 17, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 35812356035b31d7143acab90c36026291ed5976 https://github.com/pharo-project/pharo-core/commit/35812356035b31d7143acab9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-17 (Fri, 17 Feb 2017) Changed paths: R Collections-Abstract.package/SequenceableCollection.class/instance/private/checkedAt_.st R Collections-Abstract.package/SequenceableCollection.class/instance/private/errorFirstObject_.st R Collections-Abstract.package/SequenceableCollection.class/instance/private/errorLastObject_.st R Morphic-Widgets-FastTable.package/FTPluggableIconListMorphAdaptor.class/instance/accessing/setMultipleSelection_.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing/setMultipleSelection_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60399.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60400.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60399.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60400.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60400 19723 Nuke SequenceableCollection>>#checkedAt: https://pharo.fogbugz.com/f/cases/19723 19722 Move setMultipleSelection to FTTableMorph https://pharo.fogbugz.com/f/cases/19722 http://files.pharo.org/image/60/60400.zip

1 0

Metacello and big Github repositories
by Pavel Krivanek Feb. 17, 2017

Feb. 17, 2017

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

1 0