[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] f9874f: 30640

[GitHub]

  Branch: refs/heads/3.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: f9874f20e39b4c7b91bb409d052753d24981e798
  
https://github.com/pharo-project/pharo-core/commit/f9874f20e39b4c7b91bb409d052753d24981e798
  Author: Jenkins Build Server 
  Date:   2013-12-13 (Fri, 13 Dec 2013)

  Changed paths:
A Deprecated30.package/extension/TBehavior/instance/methodDictionary.st
A Deprecated30.package/extension/TBehavior/instance/methodDictionary_.st
M 
KernelTests.package/AdditionalMethodStateTest.class/instance/running/setUp.st
M Nautilus.package/AbstractNautilusUI.class/instance/buttons 
behavior/instanceButtonLabel.st
A ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script295.st
A ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
updates/update30640.st
M 
ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A 
System-Platforms.package/MacOSPlatform.class/instance/accessing/lineEnding.st
A System-Platforms.package/OSPlatform.class/instance/accessing/lineEnding.st
A 
System-Platforms.package/UnixPlatform.class/instance/accessing/lineEnding.st
A 
System-Platforms.package/Win32Platform.class/instance/accessing/lineEnding.st
R Traits.package/TBehavior.class/instance/accessing method 
dictionary/methodDictionary.st
R Traits.package/TBehavior.class/instance/accessing method 
dictionary/methodDictionary_.st

  Log Message:
  ---
  30640
12417 Introduce lineEnding on OSPlatform
https://pharo.fogbugz.com/f/cases/12417

12371 Deprecated #methodDictionary and #methodDictionary:
https://pharo.fogbugz.com/f/cases/12371

http://files.pharo.org/image/30/30640.zip

Re: [Pharo-dev] Tell me about your workflow

[GOUBIER Thierry]

Bad news. Roassal package directory has 355 entries (343 classes + a few 
extensions) and I don't see much of a slow down (on 3.0). It's not 
instantaneous, but with a bit of feedback, it doesn't seems long.

I'll do some profiling.

Thierry

De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de GOUBIER Thierry
Date d'envoi : jeudi 12 décembre 2013 17:07
À : Pharo Development List
Objet : [PROVENANCE INTERNET] Re: [Pharo-dev] Tell me about your workflow

Thanks for the pointers.

I'll look at Seaside/Moose/Mondrian and Roassal, because I need code I can load 
and save in an image without destroying the very image I use to test  (which 
would happen if I load Pharo10 stuff in a 3.0 image ;) ).

Thierry


De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy Tymchuk 
[yuriy.tymc...@me.com]
Date d'envoi : jeudi 12 décembre 2013 16:24
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

So if you want something big and with a lot of commits you can use Pharo* in 
general. Pharo10 has the most versions and Pharo30Inbox is the largest one. If 
you want some other projects then you heve to take a look at Seaside30, 
Mondrian, Moose, Glamour or Roassal.

Uko

On 12 Dec 2013, at 16:20, Yuriy Tymchuk 
mailto:yuriy.tymc...@me.com>> wrote:

Pharo10 on SmalltalkHub is humongous. You can definitely do a stress test with 
it :)

Uko

On 12 Dec 2013, at 15:43, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

I would need a large project, composed of one or more packages, with more than 
150~200 classes, which triggers the slow read and writing times Sebastian 
experience. And, probably, to be complete, a long and complex commit history in 
git (> 100 commits).

I'll keep in mind the idea of creating one randomly ;)

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Yuriy Tymchuk [yuriy.tymc...@me.com]
Date d'envoi : jeudi 12 décembre 2013 15:37
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

Are you interested in a package or a project? I can provide you information 
based on size, etc…

Uko

On 12 Dec 2013, at 15:30, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

I gave up running gitfiletree on 1.4 :(

It's possible to use gitfiletree from a 2.0 or a 3.0 image to browse your git 
repository, but testing the writing will be an issue.

My best chance would be to find a large enough package I can use on 2.0 or 3.0 
to test and profile. Does anybody has a large enough package which could fit? 
Anything that doesn't require a NDA to read it, of course. Is Roassal large 
enough?

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Sebastian Sastre 
[sebast...@flowingconcept.com]
Date d'envoi : jeudi 12 décembre 2013 12:12
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

gee the big code package is airflowing which I have, quite conservatively, 
running on #14438 images

 I load filetree like this:

Gofer new
  url: 'http://ss3.gemstone.com/ss/FileTree';
  package: 'ConfigurationOfFileTree';
  load.
((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') load.

and it never complained

let me know





On Dec 12, 2013, at 3:53 AM, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

If you would be ready to profile a package save on your repository, it would be 
great. In the mean time, I'll make available a special gitfiletree package to 
test. Which version of Pharo you are using? 2.0 or 3.0?

Regards,

Thierry



De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Sebastian Sastre 
[sebast...@flowingconcept.com]
Date d'envoi : mercredi 11 décembre 2013 17:09
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

ok, if saving is dumping all, then 3 is confirmed? After the first commit, I'd 
say so.

about 2, I don't know. I'm available to make tests and measure results

have a nice trip, keep us tuned about any progress







On Dec 11, 2013, at 2:09 PM, Goubier Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

Yes, you're right in the general case.

But a solution to that general problem will take time to be implemented (time I 
lack at the moment, sadly) and if the main gain is a few % because it's writing 
the version file and the metadata for methods which are the "slow" factors, 
then we'll have worked hard for nothing.

If you want to help, I'd really like to see either 2- or 3- confirmed. I can 
produce a special gitfiletree to remove writing the metadata, that you can try 
on a lar

Re: [Pharo-dev] Tell me about your workflow

[GOUBIER Thierry]

However, for the fun, it seems browsing the Roassal git commit with gitg (coded 
with Gtk/C) is killing gitg :). gitk was Ok.

Roassal test: Pharo OK, Gitk OK (I believe it's coded in tcl/tk), Gitg(C) Fail 
(> 10 minutes at full power to get the file list in the commit). Use C, it's 
faster, mate :):):)

Thierry



De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de GOUBIER Thierry
Date d'envoi : vendredi 13 décembre 2013 10:00
À : Pharo Development List
Objet : [PROVENANCE INTERNET] Re: [Pharo-dev] Tell me about your workflow

Bad news. Roassal package directory has 355 entries (343 classes + a few 
extensions) and I don't see much of a slow down (on 3.0). It's not 
instantaneous, but with a bit of feedback, it doesn't seems long.

I'll do some profiling.

Thierry

De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de GOUBIER Thierry
Date d'envoi : jeudi 12 décembre 2013 17:07
À : Pharo Development List
Objet : [PROVENANCE INTERNET] Re: [Pharo-dev] Tell me about your workflow

Thanks for the pointers.

I'll look at Seaside/Moose/Mondrian and Roassal, because I need code I can load 
and save in an image without destroying the very image I use to test  (which 
would happen if I load Pharo10 stuff in a 3.0 image ;) ).

Thierry


De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy Tymchuk 
[yuriy.tymc...@me.com]
Date d'envoi : jeudi 12 décembre 2013 16:24
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

So if you want something big and with a lot of commits you can use Pharo* in 
general. Pharo10 has the most versions and Pharo30Inbox is the largest one. If 
you want some other projects then you heve to take a look at Seaside30, 
Mondrian, Moose, Glamour or Roassal.

Uko

On 12 Dec 2013, at 16:20, Yuriy Tymchuk 
mailto:yuriy.tymc...@me.com>> wrote:

Pharo10 on SmalltalkHub is humongous. You can definitely do a stress test with 
it :)

Uko

On 12 Dec 2013, at 15:43, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

I would need a large project, composed of one or more packages, with more than 
150~200 classes, which triggers the slow read and writing times Sebastian 
experience. And, probably, to be complete, a long and complex commit history in 
git (> 100 commits).

I'll keep in mind the idea of creating one randomly ;)

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Yuriy Tymchuk [yuriy.tymc...@me.com]
Date d'envoi : jeudi 12 décembre 2013 15:37
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

Are you interested in a package or a project? I can provide you information 
based on size, etc…

Uko

On 12 Dec 2013, at 15:30, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

I gave up running gitfiletree on 1.4 :(

It's possible to use gitfiletree from a 2.0 or a 3.0 image to browse your git 
repository, but testing the writing will be an issue.

My best chance would be to find a large enough package I can use on 2.0 or 3.0 
to test and profile. Does anybody has a large enough package which could fit? 
Anything that doesn't require a NDA to read it, of course. Is Roassal large 
enough?

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Sebastian Sastre 
[sebast...@flowingconcept.com]
Date d'envoi : jeudi 12 décembre 2013 12:12
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

gee the big code package is airflowing which I have, quite conservatively, 
running on #14438 images

 I load filetree like this:

Gofer new
  url: 'http://ss3.gemstone.com/ss/FileTree';
  package: 'ConfigurationOfFileTree';
  load.
((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') load.

and it never complained

let me know





On Dec 12, 2013, at 3:53 AM, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

If you would be ready to profile a package save on your repository, it would be 
great. In the mean time, I'll make available a special gitfiletree package to 
test. Which version of Pharo you are using? 2.0 or 3.0?

Regards,

Thierry



De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Sebastian Sastre 
[sebast...@flowingconcept.com]
Date d'envoi : mercredi 11 décembre 2013 17:09
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

ok, if saving is dumping all, then 3 is confirmed? After the first commit, I'd 
say so.

about 2, I don't know. I'm available to make tests and measure results

have a nice trip, keep us tuned about any progress

[Pharo-dev] MooseDay schedule

[Marcus Denker]

>> De : Anne Etien 
>> 
>> Hi,
>> 
>> Please find bellow the schedule of the MooseDay 
>>  http://www.lifl.fr/~etien/MooseDay.html
>> The idea is really to present works developed on top of (or around) Moose 
>> and to have fruitful discussions. So I planned 30 mn per topic, but the 
>> schedule is quite flexible. Lot of time is foreseen for discussions.
>> 
>> 10h: welcome 
>> 10h30: APIEvolutionMiner - Andre Hora
>> 11h: FamixDiff - Nicolas Anquetil
>> 11h30: Orion - Jannik Laval and Anne Etien
>> 
>> 12h: Lunch offered by ESUG. 
>> 
>> 14h:  First works on Version - Yuriy Tymchuk
>> 14h30: Roassal - Alexandre Bergel
>> 
>> 15h-15h30 break
>> 
>> 15h30: GraphET - Alexandre Bergel
>> 16h: Use of GraphET - Serge Stinckwich
>> 16h30: Around tests - Alain Plantec
>> 
>> Reminder, the MooseDay will take place in Inria B building room B31. 
>> Directions to come can be found there 
>> (http://www.inria.fr/en/centre/lille/overview/locations).
>> 
>> See you next week in Lille ;o)
>> 
>> Anne
>> 

Re: [Pharo-dev] Versionner Impressions

[Christophe Demarey]

Hi Sean,

I made some progress on the following points:

Le 3 déc. 2013 à 06:43, Sean P. DeNigris a écrit :
> Bugs:
>   •   I added BabyMock as a dependent project, Versionner showed 
> "(stable)" in
> the UI, but when it added it to the baseline, it was loading bleeding edge

Fixed

>   •   Added packages were a mixture of strings and symbols i.e. 
> 'FMOD',
> #FMODSpecification, 'BabyMock-Core'

For this one, I cannot reproduce. Can you give more information on what you did?

>   •   I added a main repository to Versionner, but it didn't appear 
> in baseline
> when clicked "update dev"
Fixed

>   •   If you accidentally navigate away from the version you're 
> viewing, e.g.
> by clicking on another version, all changes are lost without warning

Fixed. There is now a warning.

I don't forget the point about repository selection (still in the to do).

Cheers,
Christophe.

smime.p7s
Description: S/MIME cryptographic signature

[Pharo-dev] Version summary for FogBugz

[Pavel Krivanek]

Hi,

what about to add to the World menu - System an item that will display some
information about image version, platform, dirty packages list etc. Plus
some button that will copy this text to the clipboard.
The goal is to provide simple way how to get this standard information that
should contain most of the FogBugz issue reports and the reporter could
simply paste it there.

Cheers,
-- Pavel

Re: [Pharo-dev] Version summary for FogBugz

[Sven Van Caekenberghe]

We already have that, no ?

World Menu > System > System Reporter 

On 13 Dec 2013, at 11:10, Pavel Krivanek  wrote:

> Hi,
> 
> what about to add to the World menu - System an item that will display some 
> information about image version, platform, dirty packages list etc. Plus some 
> button that will copy this text to the clipboard. 
> The goal is to provide simple way how to get this standard information that 
> should contain most of the FogBugz issue reports and the reporter could 
> simply paste it there.
> 
> Cheers,
> -- Pavel

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] a368f5: 30641

[GitHub]

  Branch: refs/heads/3.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: a368f5d4e2a997dffaa4baf72fd752c7e1a733b3
  
https://github.com/pharo-project/pharo-core/commit/a368f5d4e2a997dffaa4baf72fd752c7e1a733b3
  Author: Jenkins Build Server 
  Date:   2013-12-13 (Fri, 13 Dec 2013)

  Changed paths:
M Slot.package/EmptyLayout.class/instance/extending/extend_.st
A Slot.package/FixedLayout.class/README.md
A Slot.package/FixedLayout.class/class/instance 
creation/extending_scope_host_.st
A Slot.package/FixedLayout.class/definition.st
A 
Slot.package/FixedLayout.class/instance/format/instanceSpecificationBase.st
R Slot.package/LayoutWithSlots.class/README.md
R Slot.package/LayoutWithSlots.class/definition.st
R Slot.package/LayoutWithSlots.class/instance/accessing/allSlots.st
R Slot.package/LayoutWithSlots.class/instance/accessing/allVisibleSlots.st
R Slot.package/LayoutWithSlots.class/instance/accessing/fieldSize.st
R Slot.package/LayoutWithSlots.class/instance/accessing/instanceVariables.st
R Slot.package/LayoutWithSlots.class/instance/accessing/resolveSlot_.st
R Slot.package/LayoutWithSlots.class/instance/accessing/slotAt_.st
R Slot.package/LayoutWithSlots.class/instance/accessing/slotScope.st
R Slot.package/LayoutWithSlots.class/instance/accessing/slotScope_.st
R Slot.package/LayoutWithSlots.class/instance/comparing/=.st
R Slot.package/LayoutWithSlots.class/instance/comparing/hash.st
R Slot.package/LayoutWithSlots.class/instance/compatibility/atName_.st
R 
Slot.package/LayoutWithSlots.class/instance/compatibility/atName_ifAbsent_.st
R Slot.package/LayoutWithSlots.class/instance/compatibility/includesName_.st
R Slot.package/LayoutWithSlots.class/instance/copying/postCopy.st
R Slot.package/LayoutWithSlots.class/instance/diff/computeChangesFrom_in_.st
R Slot.package/LayoutWithSlots.class/instance/diff/popSlot_from_.st
R Slot.package/LayoutWithSlots.class/instance/extending/extend.st
R Slot.package/LayoutWithSlots.class/instance/extending/extendVariable_.st
R Slot.package/LayoutWithSlots.class/instance/extending/extendWeak_.st
R Slot.package/LayoutWithSlots.class/instance/extending/extend_.st
R 
Slot.package/LayoutWithSlots.class/instance/format/instanceSpecification.st
R Slot.package/LayoutWithSlots.class/instance/instance 
initialization/initializeInstance_.st
R 
Slot.package/LayoutWithSlots.class/instance/printing/printSlotDefinitionOn_.st
R Slot.package/LayoutWithSlots.class/instance/reshaping/extendAgain_with_.st
R Slot.package/LayoutWithSlots.class/instance/reshaping/reshapeTo_.st
R Slot.package/LayoutWithSlots.class/instance/testing/hasFields.st
R Slot.package/LayoutWithSlots.class/instance/testing/hasSlots.st
R Slot.package/LayoutWithSlots.class/instance/testing/size.st
R 
Slot.package/LayoutWithSlots.class/instance/validation/checkInheritedSlots.st
R Slot.package/LayoutWithSlots.class/instance/validation/checkIntegrity.st
R 
Slot.package/LayoutWithSlots.class/instance/validation/checkParentScopes.st
R Slot.package/LayoutWithSlots.class/instance/validation/checkSanity.st
R Slot.package/LayoutWithSlots.class/instance/validation/checkSlotIndices.st
R Slot.package/LayoutWithSlots.class/instance/validation/checkSlotNames.st
M 
Slot.package/OldClassBuilderAdapter.class/instance/accessing/layoutForType_.st
M Slot.package/PointerLayout.class/README.md
R Slot.package/PointerLayout.class/class/instance 
creation/extending_scope_host_.st
M Slot.package/PointerLayout.class/definition.st
A Slot.package/PointerLayout.class/instance/accessing/allSlots.st
A Slot.package/PointerLayout.class/instance/accessing/allVisibleSlots.st
A Slot.package/PointerLayout.class/instance/accessing/fieldSize.st
A Slot.package/PointerLayout.class/instance/accessing/instanceVariables.st
A Slot.package/PointerLayout.class/instance/accessing/resolveSlot_.st
A Slot.package/PointerLayout.class/instance/accessing/slotAt_.st
A Slot.package/PointerLayout.class/instance/accessing/slotScope.st
A Slot.package/PointerLayout.class/instance/accessing/slotScope_.st
A Slot.package/PointerLayout.class/instance/comparing/=.st
A Slot.package/PointerLayout.class/instance/comparing/hash.st
A Slot.package/PointerLayout.class/instance/compatibility/atName_.st
A 
Slot.package/PointerLayout.class/instance/compatibility/atName_ifAbsent_.st
A Slot.package/PointerLayout.class/instance/compatibility/includesName_.st
A Slot.package/PointerLayout.class/instance/copying/postCopy.st
A Slot.package/PointerLayout.class/instance/diff/computeChangesFrom_in_.st
A Slot.package/PointerLayout.class/instance/diff/popSlot_from_.st
A Slot.package/PointerLayout.class/instance/extending/extend.st
A Slot.package/PointerLayout.class/instance/extending/extendVariable_.st
A Slot.package/PointerLayout.class/instance/ex

Re: [Pharo-dev] [pharo-project/pharo-core] a368f5: 30641

[Marcus Denker]

This is a hand-made .cs update (loading a cs)


https://pharo.fogbugz.com/f/cases/resolve/12113/Slot-fix-some-layout-class-names

an update related to Slots 

This is how the hierarchy of layouts currently looks:

AbstractLayout
  EmptyLayout 
  ObjectLayout 
  BitsLayout 
ByteLayout
WordLayout 
  CompiledMethodLayout 
  LayoutWithSlots 
PointerLayout
VariableLayout
WeakLayout 
  SmallIntegerLayout 

the change does the rename: 

PointerLayout->FixedLayout
LayoutWithSlots->PointerLayout


More information about Slots can be found in the paper:

http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLayouts.pdf

Or a intro about what this is about here:
http://www.slideshare.net/MarcusDenker/lecture-27685035

On 13 Dec 2013, at 11:29, GitHub  wrote:
> 
> 
>  Log Message:
>  ---
>  30641
> 
> http://files.pharo.org/image/30/30641.zip
> 
> 

Re: [Pharo-dev] Version summary for FogBugz

[Benjamin]

The goal is to have a tool in Pharo to report bug.

This information will be provided bu the tool seamlessly :P

Ben

On 13 Dec 2013, at 11:26, Sven Van Caekenberghe  wrote:

> We already have that, no ?
> 
> World Menu > System > System Reporter 
> 
> On 13 Dec 2013, at 11:10, Pavel Krivanek  wrote:
> 
>> Hi,
>> 
>> what about to add to the World menu - System an item that will display some 
>> information about image version, platform, dirty packages list etc. Plus 
>> some button that will copy this text to the clipboard. 
>> The goal is to provide simple way how to get this standard information that 
>> should contain most of the FogBugz issue reports and the reporter could 
>> simply paste it there.
>> 
>> Cheers,
>> -- Pavel
> 
> 

Re: [Pharo-dev] Tell me about your workflow

[Sebastian Sastre]

how many coreMethods?




On Dec 13, 2013, at 7:00 AM, GOUBIER Thierry  wrote:

> Bad news. Roassal package directory has 355 entries (343 classes + a few 
> extensions) and I don't see much of a slow down (on 3.0). It's not 
> instantaneous, but with a bit of feedback, it doesn't seems long.
> 
> I'll do some profiling.
> 
> Thierry
> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de GOUBIER 
> Thierry
> Date d'envoi : jeudi 12 décembre 2013 17:07
> À : Pharo Development List
> Objet : [PROVENANCE INTERNET] Re: [Pharo-dev] Tell me about your workflow
> 
> Thanks for the pointers.
> 
> I'll look at Seaside/Moose/Mondrian and Roassal, because I need code I can 
> load and save in an image without destroying the very image I use to test  
> (which would happen if I load Pharo10 stuff in a 3.0 image ;) ).
> 
> Thierry
> 
> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy 
> Tymchuk [yuriy.tymc...@me.com]
> Date d'envoi : jeudi 12 décembre 2013 16:24
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Tell me about your workflow
> 
> So if you want something big and with a lot of commits you can use Pharo* in 
> general. Pharo10 has the most versions and Pharo30Inbox is the largest one. 
> If you want some other projects then you heve to take a look at Seaside30, 
> Mondrian, Moose, Glamour or Roassal.
> 
> Uko
> 
> On 12 Dec 2013, at 16:20, Yuriy Tymchuk  wrote:
> 
>> Pharo10 on SmalltalkHub is humongous. You can definitely do a stress test 
>> with it :)
>> 
>> Uko
>> 
>> On 12 Dec 2013, at 15:43, GOUBIER Thierry  wrote:
>> 
>>> I would need a large project, composed of one or more packages, with more 
>>> than 150~200 classes, which triggers the slow read and writing times 
>>> Sebastian experience. And, probably, to be complete, a long and complex 
>>> commit history in git (> 100 commits).
>>> 
>>> I'll keep in mind the idea of creating one randomly ;)
>>> 
>>> Thierry
>>> 
>>> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy 
>>> Tymchuk [yuriy.tymc...@me.com]
>>> Date d'envoi : jeudi 12 décembre 2013 15:37
>>> À : Pharo Development List
>>> Objet : Re: [Pharo-dev] Tell me about your workflow
>>> 
>>> Are you interested in a package or a project? I can provide you information 
>>> based on size, etc…
>>> 
>>> Uko
>>> 
>>> On 12 Dec 2013, at 15:30, GOUBIER Thierry  wrote:
>>> 
 I gave up running gitfiletree on 1.4 :(
 
 It's possible to use gitfiletree from a 2.0 or a 3.0 image to browse your 
 git repository, but testing the writing will be an issue.
 
 My best chance would be to find a large enough package I can use on 2.0 or 
 3.0 to test and profile. Does anybody has a large enough package which 
 could fit? Anything that doesn't require a NDA to read it, of course. Is 
 Roassal large enough?
 
 Thierry
 
 De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sebastian 
 Sastre [sebast...@flowingconcept.com]
 Date d'envoi : jeudi 12 décembre 2013 12:12
 À : Pharo Development List
 Objet : Re: [Pharo-dev] Tell me about your workflow
 
 gee the big code package is airflowing which I have, quite conservatively, 
 running on #14438 images
 
  I load filetree like this:
 
 Gofer new
   url: 'http://ss3.gemstone.com/ss/FileTree';
   package: 'ConfigurationOfFileTree';
   load.
 ((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') load.
 
 and it never complained
 
 let me know 
 
  
 
 
 
 On Dec 12, 2013, at 3:53 AM, GOUBIER Thierry  
 wrote:
 
> If you would be ready to profile a package save on your repository, it 
> would be great. In the mean time, I'll make available a special 
> gitfiletree package to test. Which version of Pharo you are using? 2.0 or 
> 3.0?
> 
> Regards,
> 
> Thierry
> 
> 
> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de 
> Sebastian Sastre [sebast...@flowingconcept.com]
> Date d'envoi : mercredi 11 décembre 2013 17:09
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Tell me about your workflow
> 
> ok, if saving is dumping all, then 3 is confirmed? After the first 
> commit, I'd say so.
> 
> about 2, I don't know. I'm available to make tests and measure results
> 
> have a nice trip, keep us tuned about any progress
> 
> 
> 
> 
> 
> 
> 
> On Dec 11, 2013, at 2:09 PM, Goubier Thierry  
> wrote:
> 
>> Yes, you're right in the general case.
>> 
>> But a solution to that general problem will take time to be implemented 
>> (time I lack at the moment, sadly) and if the main gain is a few % 
>> because it's writing the version file and the metadata for methods which 
>> are the "slow" factors, then we'll have worked hard for nothing.
>> 
>> If you w

[Pharo-dev] Pharo 3 is moved to BETA :)

[Esteban Lorenzano]

Hi,

I forget to announce it to the list, but since last week code integrations
are frozen. There just versioner integration, and that is independent of
the rest (and it will be integrated soon, probably today).

So, from now and until release, we will just accept bugfixes :)

cheers,
Esteban

Re: [Pharo-dev] Tell me about your workflow

[GOUBIER Thierry]

Roassal: 3493

Number of versions in the package history: 733. Size of the version file: 
202796.

Is that a lot lower than your count?

Thierry


De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sebastian 
Sastre [sebast...@flowingconcept.com]
Date d'envoi : vendredi 13 décembre 2013 13:34
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

how many coreMethods?




On Dec 13, 2013, at 7:00 AM, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

Bad news. Roassal package directory has 355 entries (343 classes + a few 
extensions) and I don't see much of a slow down (on 3.0). It's not 
instantaneous, but with a bit of feedback, it doesn't seems long.

I'll do some profiling.

Thierry

De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de GOUBIER Thierry
Date d'envoi : jeudi 12 décembre 2013 17:07
À : Pharo Development List
Objet : [PROVENANCE INTERNET] Re: [Pharo-dev] Tell me about your workflow

Thanks for the pointers.

I'll look at Seaside/Moose/Mondrian and Roassal, because I need code I can load 
and save in an image without destroying the very image I use to test  (which 
would happen if I load Pharo10 stuff in a 3.0 image ;) ).

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Yuriy Tymchuk [yuriy.tymc...@me.com]
Date d'envoi : jeudi 12 décembre 2013 16:24
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

So if you want something big and with a lot of commits you can use Pharo* in 
general. Pharo10 has the most versions and Pharo30Inbox is the largest one. If 
you want some other projects then you heve to take a look at Seaside30, 
Mondrian, Moose, Glamour or Roassal.

Uko

On 12 Dec 2013, at 16:20, Yuriy Tymchuk 
mailto:yuriy.tymc...@me.com>> wrote:

Pharo10 on SmalltalkHub is humongous. You can definitely do a stress test with 
it :)

Uko

On 12 Dec 2013, at 15:43, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

I would need a large project, composed of one or more packages, with more than 
150~200 classes, which triggers the slow read and writing times Sebastian 
experience. And, probably, to be complete, a long and complex commit history in 
git (> 100 commits).

I'll keep in mind the idea of creating one randomly ;)

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Yuriy Tymchuk [yuriy.tymc...@me.com]
Date d'envoi : jeudi 12 décembre 2013 15:37
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

Are you interested in a package or a project? I can provide you information 
based on size, etc…

Uko

On 12 Dec 2013, at 15:30, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

I gave up running gitfiletree on 1.4 :(

It's possible to use gitfiletree from a 2.0 or a 3.0 image to browse your git 
repository, but testing the writing will be an issue.

My best chance would be to find a large enough package I can use on 2.0 or 3.0 
to test and profile. Does anybody has a large enough package which could fit? 
Anything that doesn't require a NDA to read it, of course. Is Roassal large 
enough?

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Sebastian Sastre 
[sebast...@flowingconcept.com]
Date d'envoi : jeudi 12 décembre 2013 12:12
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

gee the big code package is airflowing which I have, quite conservatively, 
running on #14438 images

 I load filetree like this:

Gofer new
  url: 'http://ss3.gemstone.com/ss/FileTree';
  package: 'ConfigurationOfFileTree';
  load.
((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') load.

and it never complained

let me know





On Dec 12, 2013, at 3:53 AM, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

If you would be ready to profile a package save on your repository, it would be 
great. In the mean time, I'll make available a special gitfiletree package to 
test. Which version of Pharo you are using? 2.0 or 3.0?

Regards,

Thierry



De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Sebastian Sastre 
[sebast...@flowingconcept.com]
Date d'envoi : mercredi 11 décembre 2013 17:09
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

ok, if saving is dumping all, then 3 is confirmed? After the first commit, I'd 
say so.

about 2, I don't know. I'm available to make tests and 

Re: [Pharo-dev] Tell me about your workflow

[Sebastian Sastre]

A bit.

This is from today's current version (and is not all, it's only the two biggest 
packages):

(MCPackage named: 'flow') workingCopy packageInfo classes size. 363.
(MCPackage named: 'flow') workingCopy packageInfo coreMethods size. 4585.

(MCPackage named: 'airflowing') workingCopy packageInfo classes size. 377.
(MCPackage named: 'airflowing') workingCopy packageInfo coreMethods size. 5818.







On Dec 13, 2013, at 11:25 AM, GOUBIER Thierry  wrote:

> Roassal: 3493
> 
> Number of versions in the package history: 733. Size of the version file: 
> 202796.
> 
> Is that a lot lower than your count?
> 
> Thierry
> 
> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sebastian 
> Sastre [sebast...@flowingconcept.com]
> Date d'envoi : vendredi 13 décembre 2013 13:34
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Tell me about your workflow
> 
> how many coreMethods?
> 
> 
> 
> 
> On Dec 13, 2013, at 7:00 AM, GOUBIER Thierry  wrote:
> 
>> Bad news. Roassal package directory has 355 entries (343 classes + a few 
>> extensions) and I don't see much of a slow down (on 3.0). It's not 
>> instantaneous, but with a bit of feedback, it doesn't seems long.
>> 
>> I'll do some profiling.
>> 
>> Thierry
>> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de GOUBIER 
>> Thierry
>> Date d'envoi : jeudi 12 décembre 2013 17:07
>> À : Pharo Development List
>> Objet : [PROVENANCE INTERNET] Re: [Pharo-dev] Tell me about your workflow
>> 
>> Thanks for the pointers.
>> 
>> I'll look at Seaside/Moose/Mondrian and Roassal, because I need code I can 
>> load and save in an image without destroying the very image I use to test  
>> (which would happen if I load Pharo10 stuff in a 3.0 image ;) ).
>> 
>> Thierry
>> 
>> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy 
>> Tymchuk [yuriy.tymc...@me.com]
>> Date d'envoi : jeudi 12 décembre 2013 16:24
>> À : Pharo Development List
>> Objet : Re: [Pharo-dev] Tell me about your workflow
>> 
>> So if you want something big and with a lot of commits you can use Pharo* in 
>> general. Pharo10 has the most versions and Pharo30Inbox is the largest one. 
>> If you want some other projects then you heve to take a look at Seaside30, 
>> Mondrian, Moose, Glamour or Roassal.
>> 
>> Uko
>> 
>> On 12 Dec 2013, at 16:20, Yuriy Tymchuk  wrote:
>> 
>>> Pharo10 on SmalltalkHub is humongous. You can definitely do a stress test 
>>> with it :)
>>> 
>>> Uko
>>> 
>>> On 12 Dec 2013, at 15:43, GOUBIER Thierry  wrote:
>>> 
 I would need a large project, composed of one or more packages, with more 
 than 150~200 classes, which triggers the slow read and writing times 
 Sebastian experience. And, probably, to be complete, a long and complex 
 commit history in git (> 100 commits).
 
 I'll keep in mind the idea of creating one randomly ;)
 
 Thierry
 
 De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy 
 Tymchuk [yuriy.tymc...@me.com]
 Date d'envoi : jeudi 12 décembre 2013 15:37
 À : Pharo Development List
 Objet : Re: [Pharo-dev] Tell me about your workflow
 
 Are you interested in a package or a project? I can provide you 
 information based on size, etc…
 
 Uko
 
 On 12 Dec 2013, at 15:30, GOUBIER Thierry  wrote:
 
> I gave up running gitfiletree on 1.4 :(
> 
> It's possible to use gitfiletree from a 2.0 or a 3.0 image to browse your 
> git repository, but testing the writing will be an issue.
> 
> My best chance would be to find a large enough package I can use on 2.0 
> or 3.0 to test and profile. Does anybody has a large enough package which 
> could fit? Anything that doesn't require a NDA to read it, of course. Is 
> Roassal large enough?
> 
> Thierry
> 
> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de 
> Sebastian Sastre [sebast...@flowingconcept.com]
> Date d'envoi : jeudi 12 décembre 2013 12:12
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Tell me about your workflow
> 
> gee the big code package is airflowing which I have, quite 
> conservatively, running on #14438 images
> 
>  I load filetree like this:
> 
> Gofer new
>   url: 'http://ss3.gemstone.com/ss/FileTree';
>   package: 'ConfigurationOfFileTree';
>   load.
> ((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') 
> load.
> 
> and it never complained
> 
> let me know 
> 
>  
> 
> 
> 
> On Dec 12, 2013, at 3:53 AM, GOUBIER Thierry  
> wrote:
> 
>> If you would be ready to profile a package save on your repository, it 
>> would be great. In the mean time, I'll make available a special 
>> gitfiletree package to test. Which version of Pharo you are using? 2.0 
>> or 3.0?
>> 
>> Regards,
>> 
>> Thierry
>> 
>> 
>> De : Pharo

Re: [Pharo-dev] Tell me about your workflow

[GOUBIER Thierry]

Ok. I'll try Roassal on a slow netbook to see. I don't see a factor of 10 
difference between yours and Roassal, so I'll have a look.

Thierry

De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sebastian 
Sastre [sebast...@flowingconcept.com]
Date d'envoi : vendredi 13 décembre 2013 14:32
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

A bit.

This is from today's current version (and is not all, it's only the two biggest 
packages):

(MCPackage named: 'flow') workingCopy packageInfo classes size. 363.
(MCPackage named: 'flow') workingCopy packageInfo coreMethods size. 4585.

(MCPackage named: 'airflowing') workingCopy packageInfo classes size. 377.
(MCPackage named: 'airflowing') workingCopy packageInfo coreMethods size. 5818.







On Dec 13, 2013, at 11:25 AM, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

Roassal: 3493

Number of versions in the package history: 733. Size of the version file: 
202796.

Is that a lot lower than your count?

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Sebastian Sastre 
[sebast...@flowingconcept.com]
Date d'envoi : vendredi 13 décembre 2013 13:34
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

how many coreMethods?




On Dec 13, 2013, at 7:00 AM, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

Bad news. Roassal package directory has 355 entries (343 classes + a few 
extensions) and I don't see much of a slow down (on 3.0). It's not 
instantaneous, but with a bit of feedback, it doesn't seems long.

I'll do some profiling.

Thierry

De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de GOUBIER Thierry
Date d'envoi : jeudi 12 décembre 2013 17:07
À : Pharo Development List
Objet : [PROVENANCE INTERNET] Re: [Pharo-dev] Tell me about your workflow

Thanks for the pointers.

I'll look at Seaside/Moose/Mondrian and Roassal, because I need code I can load 
and save in an image without destroying the very image I use to test  (which 
would happen if I load Pharo10 stuff in a 3.0 image ;) ).

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Yuriy Tymchuk [yuriy.tymc...@me.com]
Date d'envoi : jeudi 12 décembre 2013 16:24
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

So if you want something big and with a lot of commits you can use Pharo* in 
general. Pharo10 has the most versions and Pharo30Inbox is the largest one. If 
you want some other projects then you heve to take a look at Seaside30, 
Mondrian, Moose, Glamour or Roassal.

Uko

On 12 Dec 2013, at 16:20, Yuriy Tymchuk 
mailto:yuriy.tymc...@me.com>> wrote:

Pharo10 on SmalltalkHub is humongous. You can definitely do a stress test with 
it :)

Uko

On 12 Dec 2013, at 15:43, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

I would need a large project, composed of one or more packages, with more than 
150~200 classes, which triggers the slow read and writing times Sebastian 
experience. And, probably, to be complete, a long and complex commit history in 
git (> 100 commits).

I'll keep in mind the idea of creating one randomly ;)

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Yuriy Tymchuk [yuriy.tymc...@me.com]
Date d'envoi : jeudi 12 décembre 2013 15:37
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

Are you interested in a package or a project? I can provide you information 
based on size, etc…

Uko

On 12 Dec 2013, at 15:30, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

I gave up running gitfiletree on 1.4 :(

It's possible to use gitfiletree from a 2.0 or a 3.0 image to browse your git 
repository, but testing the writing will be an issue.

My best chance would be to find a large enough package I can use on 2.0 or 3.0 
to test and profile. Does anybody has a large enough package which could fit? 
Anything that doesn't require a NDA to read it, of course. Is Roassal large 
enough?

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Sebastian Sastre 
[sebast...@flowingconcept.com]
Date d'envoi : jeudi 12 décembre 2013 12:12
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

gee the big code package is airflowing which I have, quite conservatively, 
running on #14438 images

 I load filetree like this:

Gofer new
  url: 'http://ss3.gemstone.com/ss/FileTree';
   

[Pharo-dev] Commit right to Pharo30Inbox

[wm]

Hi list. 
I want to submit a SLICE to the pharo inbox, can you grant me commit rights? 

username: MartinWalk 

thanks!

Re: [Pharo-dev] Tell me about your workflow

[Sebastian Sastre]

I can try a forced load on a 3.0 ignoring requisites for testing purposes

but I'm using this:
https://github.com/dalehenrich/filetree

I'm not sure what you're are using

can you clarify?



On Dec 13, 2013, at 11:43 AM, GOUBIER Thierry  wrote:

> Ok. I'll try Roassal on a slow netbook to see. I don't see a factor of 10 
> difference between yours and Roassal, so I'll have a look.
> 
> Thierry
> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sebastian 
> Sastre [sebast...@flowingconcept.com]
> Date d'envoi : vendredi 13 décembre 2013 14:32
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Tell me about your workflow
> 
> A bit.
> 
> This is from today's current version (and is not all, it's only the two 
> biggest packages):
> 
> (MCPackage named: 'flow') workingCopy packageInfo classes size. 363.
> (MCPackage named: 'flow') workingCopy packageInfo coreMethods size. 4585.
> 
> (MCPackage named: 'airflowing') workingCopy packageInfo classes size. 377.
> (MCPackage named: 'airflowing') workingCopy packageInfo coreMethods size. 
> 5818.
> 
> 
> 
> 
> 
> 
> 
> On Dec 13, 2013, at 11:25 AM, GOUBIER Thierry  wrote:
> 
>> Roassal: 3493
>> 
>> Number of versions in the package history: 733. Size of the version file: 
>> 202796.
>> 
>> Is that a lot lower than your count?
>> 
>> Thierry
>> 
>> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sebastian 
>> Sastre [sebast...@flowingconcept.com]
>> Date d'envoi : vendredi 13 décembre 2013 13:34
>> À : Pharo Development List
>> Objet : Re: [Pharo-dev] Tell me about your workflow
>> 
>> how many coreMethods?
>> 
>> 
>> 
>> 
>> On Dec 13, 2013, at 7:00 AM, GOUBIER Thierry  wrote:
>> 
>>> Bad news. Roassal package directory has 355 entries (343 classes + a few 
>>> extensions) and I don't see much of a slow down (on 3.0). It's not 
>>> instantaneous, but with a bit of feedback, it doesn't seems long.
>>> 
>>> I'll do some profiling.
>>> 
>>> Thierry
>>> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de GOUBIER 
>>> Thierry
>>> Date d'envoi : jeudi 12 décembre 2013 17:07
>>> À : Pharo Development List
>>> Objet : [PROVENANCE INTERNET] Re: [Pharo-dev] Tell me about your workflow
>>> 
>>> Thanks for the pointers.
>>> 
>>> I'll look at Seaside/Moose/Mondrian and Roassal, because I need code I can 
>>> load and save in an image without destroying the very image I use to test  
>>> (which would happen if I load Pharo10 stuff in a 3.0 image ;) ).
>>> 
>>> Thierry
>>> 
>>> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy 
>>> Tymchuk [yuriy.tymc...@me.com]
>>> Date d'envoi : jeudi 12 décembre 2013 16:24
>>> À : Pharo Development List
>>> Objet : Re: [Pharo-dev] Tell me about your workflow
>>> 
>>> So if you want something big and with a lot of commits you can use Pharo* 
>>> in general. Pharo10 has the most versions and Pharo30Inbox is the largest 
>>> one. If you want some other projects then you heve to take a look at 
>>> Seaside30, Mondrian, Moose, Glamour or Roassal.
>>> 
>>> Uko
>>> 
>>> On 12 Dec 2013, at 16:20, Yuriy Tymchuk  wrote:
>>> 
 Pharo10 on SmalltalkHub is humongous. You can definitely do a stress test 
 with it :)
 
 Uko
 
 On 12 Dec 2013, at 15:43, GOUBIER Thierry  wrote:
 
> I would need a large project, composed of one or more packages, with more 
> than 150~200 classes, which triggers the slow read and writing times 
> Sebastian experience. And, probably, to be complete, a long and complex 
> commit history in git (> 100 commits).
> 
> I'll keep in mind the idea of creating one randomly ;)
> 
> Thierry
> 
> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy 
> Tymchuk [yuriy.tymc...@me.com]
> Date d'envoi : jeudi 12 décembre 2013 15:37
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Tell me about your workflow
> 
> Are you interested in a package or a project? I can provide you 
> information based on size, etc…
> 
> Uko
> 
> On 12 Dec 2013, at 15:30, GOUBIER Thierry  wrote:
> 
>> I gave up running gitfiletree on 1.4 :(
>> 
>> It's possible to use gitfiletree from a 2.0 or a 3.0 image to browse 
>> your git repository, but testing the writing will be an issue.
>> 
>> My best chance would be to find a large enough package I can use on 2.0 
>> or 3.0 to test and profile. Does anybody has a large enough package 
>> which could fit? Anything that doesn't require a NDA to read it, of 
>> course. Is Roassal large enough?
>> 
>> Thierry
>> 
>> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de 
>> Sebastian Sastre [sebast...@flowingconcept.com]
>> Date d'envoi : jeudi 12 décembre 2013 12:12
>> À : Pharo Development List
>> Objet : Re: [Pharo-dev] Tell me about your workflow
>> 
>> gee the big code package is airflowing which I have, quite 
>> conservatively

Re: [Pharo-dev] Commit right to Pharo30Inbox

[Esteban Lorenzano]

done :)


On Fri, Dec 13, 2013 at 2:51 PM,  wrote:

> Hi list.
> I want to submit a SLICE to the pharo inbox, can you grant me commit
> rights?
>
> username: MartinWalk
>
> thanks!
>
>

Re: [Pharo-dev] Tell me about your workflow

[GOUBIER Thierry]

gitfiletree can be had this way (filetree is already in 3.0, gitfiletree is in 
the filetree configuration for Pharo 3.0 but is a bit hard to load).

pharo/pharo pharo/Pharo.image config 
http://smalltalkhub.com/Pharo/MetaRepoForPharo30/main/ ConfigurationOfOSProcess 
--install=stable
pharo/pharo pharo/Pharo.image eval --save Gofer new 
url:\'http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main\'\; package: 
\'MonticelloFileTree-Git\'\; load

Thierry


De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sebastian 
Sastre [sebast...@flowingconcept.com]
Date d'envoi : vendredi 13 décembre 2013 14:57
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

I can try a forced load on a 3.0 ignoring requisites for testing purposes

but I'm using this:
https://github.com/dalehenrich/filetree

I'm not sure what you're are using

can you clarify?



On Dec 13, 2013, at 11:43 AM, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

Ok. I'll try Roassal on a slow netbook to see. I don't see a factor of 10 
difference between yours and Roassal, so I'll have a look.

Thierry

De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Sebastian Sastre 
[sebast...@flowingconcept.com]
Date d'envoi : vendredi 13 décembre 2013 14:32
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

A bit.

This is from today's current version (and is not all, it's only the two biggest 
packages):

(MCPackage named: 'flow') workingCopy packageInfo classes size. 363.
(MCPackage named: 'flow') workingCopy packageInfo coreMethods size. 4585.

(MCPackage named: 'airflowing') workingCopy packageInfo classes size. 377.
(MCPackage named: 'airflowing') workingCopy packageInfo coreMethods size. 5818.







On Dec 13, 2013, at 11:25 AM, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

Roassal: 3493

Number of versions in the package history: 733. Size of the version file: 
202796.

Is that a lot lower than your count?

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Sebastian Sastre 
[sebast...@flowingconcept.com]
Date d'envoi : vendredi 13 décembre 2013 13:34
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

how many coreMethods?




On Dec 13, 2013, at 7:00 AM, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

Bad news. Roassal package directory has 355 entries (343 classes + a few 
extensions) and I don't see much of a slow down (on 3.0). It's not 
instantaneous, but with a bit of feedback, it doesn't seems long.

I'll do some profiling.

Thierry

De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de GOUBIER Thierry
Date d'envoi : jeudi 12 décembre 2013 17:07
À : Pharo Development List
Objet : [PROVENANCE INTERNET] Re: [Pharo-dev] Tell me about your workflow

Thanks for the pointers.

I'll look at Seaside/Moose/Mondrian and Roassal, because I need code I can load 
and save in an image without destroying the very image I use to test  (which 
would happen if I load Pharo10 stuff in a 3.0 image ;) ).

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Yuriy Tymchuk [yuriy.tymc...@me.com]
Date d'envoi : jeudi 12 décembre 2013 16:24
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

So if you want something big and with a lot of commits you can use Pharo* in 
general. Pharo10 has the most versions and Pharo30Inbox is the largest one. If 
you want some other projects then you heve to take a look at Seaside30, 
Mondrian, Moose, Glamour or Roassal.

Uko

On 12 Dec 2013, at 16:20, Yuriy Tymchuk 
mailto:yuriy.tymc...@me.com>> wrote:

Pharo10 on SmalltalkHub is humongous. You can definitely do a stress test with 
it :)

Uko

On 12 Dec 2013, at 15:43, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

I would need a large project, composed of one or more packages, with more than 
150~200 classes, which triggers the slow read and writing times Sebastian 
experience. And, probably, to be complete, a long and complex commit history in 
git (> 100 commits).

I'll keep in mind the idea of creating one randomly ;)

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Yuriy Tymchuk [yuriy.tymc...@me.com]
Date d'envoi : jeudi 12 décembre 2013 15:37
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

Are you interested in a package or a project? I can provide you

Re: [Pharo-dev] Tell me about your workflow

[Stéphane Ducasse]

try with Moose.

Stef

On Dec 12, 2013, at 4:20 PM, Yuriy Tymchuk  wrote:

> Pharo10 on SmalltalkHub is humongous. You can definitely do a stress test 
> with it :)
> 
> Uko
> 
> On 12 Dec 2013, at 15:43, GOUBIER Thierry  wrote:
> 
>> I would need a large project, composed of one or more packages, with more 
>> than 150~200 classes, which triggers the slow read and writing times 
>> Sebastian experience. And, probably, to be complete, a long and complex 
>> commit history in git (> 100 commits).
>> 
>> I'll keep in mind the idea of creating one randomly ;)
>> 
>> Thierry
>> 
>> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy 
>> Tymchuk [yuriy.tymc...@me.com]
>> Date d'envoi : jeudi 12 décembre 2013 15:37
>> À : Pharo Development List
>> Objet : Re: [Pharo-dev] Tell me about your workflow
>> 
>> Are you interested in a package or a project? I can provide you information 
>> based on size, etc…
>> 
>> Uko
>> 
>> On 12 Dec 2013, at 15:30, GOUBIER Thierry  wrote:
>> 
>>> I gave up running gitfiletree on 1.4 :(
>>> 
>>> It's possible to use gitfiletree from a 2.0 or a 3.0 image to browse your 
>>> git repository, but testing the writing will be an issue.
>>> 
>>> My best chance would be to find a large enough package I can use on 2.0 or 
>>> 3.0 to test and profile. Does anybody has a large enough package which 
>>> could fit? Anything that doesn't require a NDA to read it, of course. Is 
>>> Roassal large enough?
>>> 
>>> Thierry
>>> 
>>> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sebastian 
>>> Sastre [sebast...@flowingconcept.com]
>>> Date d'envoi : jeudi 12 décembre 2013 12:12
>>> À : Pharo Development List
>>> Objet : Re: [Pharo-dev] Tell me about your workflow
>>> 
>>> gee the big code package is airflowing which I have, quite conservatively, 
>>> running on #14438 images
>>> 
>>>  I load filetree like this:
>>> 
>>> Gofer new
>>>   url: 'http://ss3.gemstone.com/ss/FileTree';
>>>   package: 'ConfigurationOfFileTree';
>>>   load.
>>> ((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') load.
>>> 
>>> and it never complained
>>> 
>>> let me know 
>>> 
>>>  
>>> 
>>> 
>>> 
>>> On Dec 12, 2013, at 3:53 AM, GOUBIER Thierry  wrote:
>>> 
 If you would be ready to profile a package save on your repository, it 
 would be great. In the mean time, I'll make available a special 
 gitfiletree package to test. Which version of Pharo you are using? 2.0 or 
 3.0?
 
 Regards,
 
 Thierry
 
 
 De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Sebastian 
 Sastre [sebast...@flowingconcept.com]
 Date d'envoi : mercredi 11 décembre 2013 17:09
 À : Pharo Development List
 Objet : Re: [Pharo-dev] Tell me about your workflow
 
 ok, if saving is dumping all, then 3 is confirmed? After the first commit, 
 I'd say so.
 
 about 2, I don't know. I'm available to make tests and measure results
 
 have a nice trip, keep us tuned about any progress
 
 
 
 
 
 
 
 On Dec 11, 2013, at 2:09 PM, Goubier Thierry  
 wrote:
 
> Yes, you're right in the general case.
> 
> But a solution to that general problem will take time to be implemented 
> (time I lack at the moment, sadly) and if the main gain is a few % 
> because it's writing the version file and the metadata for methods which 
> are the "slow" factors, then we'll have worked hard for nothing.
> 
> If you want to help, I'd really like to see either 2- or 3- confirmed. I 
> can produce a special gitfiletree to remove writing the metadata, that 
> you can try on a large project temporary copy; if the slow writing (and 
> reading) is confirmed, then this is 3-
> 
> (But I'm leaving on a trip tomorrow early, so I have no idea of when I'll 
> have the time to do that :( ).
> 
> Thierry
> 
> Le 11/12/2013 16:44, Sebastian Sastre a écrit :
>> Without entering in details, a cause for slow package write is dumping
>> all every time.
>> 
>> For that strategy, we already have the image save which is magically 
>> fast.
>> 
>> So, if we make something to scan the code and write only when it's
>> different from what's on disk, then we would be preventing tons of
>> redundant writes
>> 
>> sebastian 
>> 
>> o/
>> 
>> 
>> 
>> 
>> 
>> On Dec 11, 2013, at 1:43 PM, Goubier Thierry > > wrote:
>> 
>>> 
>>> 
>>> Le 11/12/2013 16:27, Esteban Lorenzano a écrit :
 ah, and IMHO the problem is not about reading... is about writing (if 
 it
 has to write the metadata each time...).
>>> 
>>> But, personnaly, I don't know if this is the reason for the lack of
>>> performance...
>>> 
>>> I have three hypothesis for Sebastian probl

Re: [Pharo-dev] Which tests should be run in CI?

[Stéphane Ducasse]

On Dec 12, 2013, at 7:21 PM, Chris Cunningham  wrote:

> If it is a compatibility layer, then now that Pharo has it's own #package, 
> shouldn't the Pharo version of Grease just not include it anymore?  Once the 
> various Smalltalks start to implement what it is claiming it wants, the 
> compatibility layer for that dialect should change, I would think.  So, 
> Seaside should still use #packages, but on Pharo, it gets the native 
> #packages results.

This is exactly the point.

> This assumes that what Grease wants out of package is what Pharo provides - 
> and it is possible that Grease will need different compatibility artifacts to 
> make the Pharo results match what Grease expects.
> 
> I would think from a Grease perspective, the ideal world is to have nothing 
> left in Grease at all because all of the dialects have implemented everything 
> they want, in at least the minimal way they wanted.  As a step towards that, 
> having one dialect removing the need for Grease would also be a big, happy 
> step forward.

Exactly

Re: [Pharo-dev] Is variable shadowing a feature or a bug?

[Stéphane Ducasse]

> 
> Ok, I will do it with the Preference
> 
> But in the long run, one can get rid of these things… e,g,
> 
> Step one: code critic rule to detect these cases
> two: deprecate the code 
> three: remove.

Great plan!!

Re: [Pharo-dev] Is it possible to load and display pdfs inside pharo ?

[Stéphane Ducasse]

So far I do not think so but I know that the open-source library of pdf 
developed by christian Haider on VW 
can do it.

Stef

> I was wondering if there is a library to load and display or at least parse 
> pdf files for pharo.
> 

Re: [Pharo-dev] about the Pharo Catalog

[Stéphane Ducasse]

> I'm now adding it for OpenDBX and glorp. We should create lint rules for it ;)

please!
I want to add support for catalogMainContact too


> 
> 
> On Thu, Dec 12, 2013 at 10:57 AM, Stéphane Ducasse 
>  wrote:
> Yes :)
> In the output of the catalog itself
> 
> https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/?
> 
> There is probably a typo in the generator catalogkeyClassesAndExample => 
> catalogKeyClassesAndExample
> 1. Aconcagua
> Please define a class method named catalogDescription returning a paragraph 
> of description in the configuration class.
> 
> 1.1. Keywords
> Please define a class method named catalogKeywords returning an array of 
> symbols in the configuration class.
> 
> 1.2. Key classes and Implementations Notes
> Please define a class method named catalogkeyClassesAndExample returning a 
> paragraph describing the most important classes of the project and relevant 
> information such as an example.
> 
> 1.3. Key change logs
> Please define a class method named catalogChangeLog returning a paragraph 
> describing the most important changes in the configuration class. We suggest 
> to use the following format:
> 
> Version number - Date - topics
> 
>   ConfigurationOfXXX project version: 'xx' ) load 
> 
> or simply
> 
> Version number - Date - topics
> Version number - Date - topics
> Version number - Date - topics
> 
> 
> On Dec 12, 2013, at 10:49 AM, Esteban Lorenzano  wrote:
> 
>> is there a place where I can see the metadata methods I need to implement?
>> 
>> Esteban
>> 
>> 
>> On Thu, Dec 12, 2013 at 9:59 AM, Stéphane Ducasse 
>>  wrote:
>> Hi guys
>> 
>> I really want to have an official catalog soon, so please add the missing 
>> metadata in your configurations.
>> In addition I was discussing with robert pergl from Prague and he told me 
>> that
>> when he has a problem with a package he does not know to whom he should 
>> report so
>> I would like to add a catalogContact section.
>> Any idea for improvement.
>> 
>> Stef
>> 
> 
> 

[Pharo-dev] [Moose-dev] #deepCollect:

[Chris Cunningham]

Hi.

I was reading with interest the blog post on Traversal-enabled objects (
http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects )
when I noticed the method #deepCollect: referenced.  Interestingly, I have
a method called #deepCollect: that is use (wtih related methods like
#deepDo: and #deepSelect:).  I suspect these uses may be compatible, with
the traveral versions being more generic.

My set of #deep methods allow arbitrary flattening of collections.  The
#flatCollect: suite in Pharo today flattens objects 1 level; the
#deepCollect: flattens the collections as many levels deep as they are
nested.  I found this to be a really useful ability when I work with
PetitParser parsings, which tend give back massively nested Arrays by
default.

If you are interested, it is published at:
http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .

-cbc

Re: [Pharo-dev] [Moose-dev] #deepCollect:

[Esteban A. Maringolo]

To avoid such kind of situations I would implement all the traversal methods as
a) Traits or
b) Class side methods of DeepTraversal (you choose the name) to which
you'll have to pass the collection and the block.

E.g. DeepTraversal deep: aCollection do: aBlock
DeepTraversal flatten: aCollection thenDo: aBlock

I, personally, don't like adding methods to Object unless it's
unavoidable(*). And in those cases I choose to prefix them with
something that is separate from the semantic, usually the
package/framework prefix.

Regards,

(*)I did that for years and in the long term it hits you back.
Esteban A. Maringolo


2013/12/13 Chris Cunningham :
> Hi.
>
> I was reading with interest the blog post on Traversal-enabled objects (
> http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when
> I noticed the method #deepCollect: referenced.  Interestingly, I have a
> method called #deepCollect: that is use (wtih related methods like #deepDo:
> and #deepSelect:).  I suspect these uses may be compatible, with the
> traveral versions being more generic.
>
> My set of #deep methods allow arbitrary flattening of collections.  The
> #flatCollect: suite in Pharo today flattens objects 1 level; the
> #deepCollect: flattens the collections as many levels deep as they are
> nested.  I found this to be a really useful ability when I work with
> PetitParser parsings, which tend give back massively nested Arrays by
> default.
>
> If you are interested, it is published at:
> http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
>
> -cbc

Re: [Pharo-dev] [Moose-dev] #deepCollect:

[Yuriy Tymchuk]

Wow, this is really cool. I missed this while working with PP.

Thanks Chris!

Uko

On 13 Dec 2013, at 18:02, Chris Cunningham  wrote:

> Hi.
> 
> I was reading with interest the blog post on Traversal-enabled objects ( 
> http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when 
> I noticed the method #deepCollect: referenced.  Interestingly, I have a 
> method called #deepCollect: that is use (wtih related methods like #deepDo: 
> and #deepSelect:).  I suspect these uses may be compatible, with the traveral 
> versions being more generic.
> 
> My set of #deep methods allow arbitrary flattening of collections.  The 
> #flatCollect: suite in Pharo today flattens objects 1 level; the 
> #deepCollect: flattens the collections as many levels deep as they are 
> nested.  I found this to be a really useful ability when I work with 
> PetitParser parsings, which tend give back massively nested Arrays by default.
> 
> If you are interested, it is published at: 
> http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
> 
> -cbc

Re: [Pharo-dev] about the Pharo Catalog

[Guillermo Polito]

On Fri, Dec 13, 2013 at 1:51 PM, Stéphane Ducasse  wrote:

>
> I'm now adding it for OpenDBX and glorp. We should create lint rules for
> it ;)
>
>
> please!
> I want to add support for catalogMainContact too
>

I'll add it :) Can I ask for permissions to commit in the Catalog?


>
>
>
>
> On Thu, Dec 12, 2013 at 10:57 AM, Stéphane Ducasse <
> stephane.duca...@inria.fr> wrote:
>
>> Yes :)
>> In the output of the catalog itself
>>
>>
>> https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/?
>>
>> There is probably a typo in the generator catalogkeyClassesAndExample =>
>> catalogKeyClassesAndExample
>> 1. Aconcagua
>>
>> Please define a class method named catalogDescription returning a
>> paragraph of description in the configuration class.
>> 1.1. Keywords
>>
>> Please define a class method named catalogKeywords returning an array of
>> symbols in the configuration class.
>> 1.2. Key classes and Implementations Notes
>>
>> Please define a class method named catalogkeyClassesAndExample returning
>> a paragraph describing the most important classes of the project and
>> relevant information such as an example.
>> 1.3. Key change logs
>>
>> Please define a class method named catalogChangeLog returning a paragraph
>> describing the most important changes in the configuration class. We
>> suggest to use the following format:
>>
>>- Version number - Date - topics
>>
>>
>>  ConfigurationOfXXX project version: 'xx' ) load 
>> 
>>
>> or simply
>>
>>
>>- Version number - Date - topics
>>- Version number - Date - topics
>>- Version number - Date - topics
>>
>>
>>
>> On Dec 12, 2013, at 10:49 AM, Esteban Lorenzano 
>> wrote:
>>
>> is there a place where I can see the metadata methods I need to implement?
>>
>> Esteban
>>
>>
>> On Thu, Dec 12, 2013 at 9:59 AM, Stéphane Ducasse <
>> stephane.duca...@inria.fr> wrote:
>>
>>> Hi guys
>>>
>>> I really want to have an official catalog soon, so please add the
>>> missing metadata in your configurations.
>>> In addition I was discussing with robert pergl from Prague and he told
>>> me that
>>> when he has a problem with a package he does not know to whom he should
>>> report so
>>> I would like to add a catalogContact section.
>>> Any idea for improvement.
>>>
>>> Stef
>>>
>>
>>
>>
>
>

Re: [Pharo-dev] [Moose-dev] #deepCollect:

[Frank Shearar]

On 13 December 2013 17:02, Chris Cunningham  wrote:
> Hi.
>
> I was reading with interest the blog post on Traversal-enabled objects (
> http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when
> I noticed the method #deepCollect: referenced.  Interestingly, I have a
> method called #deepCollect: that is use (wtih related methods like #deepDo:
> and #deepSelect:).  I suspect these uses may be compatible, with the
> traveral versions being more generic.
>
> My set of #deep methods allow arbitrary flattening of collections.  The
> #flatCollect: suite in Pharo today flattens objects 1 level; the
> #deepCollect: flattens the collections as many levels deep as they are
> nested.  I found this to be a really useful ability when I work with
> PetitParser parsings, which tend give back massively nested Arrays by
> default.

What about flattening during the parse, with #flatten?

frank

> If you are interested, it is published at:
> http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
>
> -cbc

Re: [Pharo-dev] Tell me about your workflow

[GOUBIER Thierry]

Then I will :)

Thierry

De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Stéphane 
Ducasse [stephane.duca...@inria.fr]
Date d'envoi : vendredi 13 décembre 2013 13:47
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

try with Moose.

Stef

On Dec 12, 2013, at 4:20 PM, Yuriy Tymchuk 
mailto:yuriy.tymc...@me.com>> wrote:

Pharo10 on SmalltalkHub is humongous. You can definitely do a stress test with 
it :)

Uko

On 12 Dec 2013, at 15:43, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

I would need a large project, composed of one or more packages, with more than 
150~200 classes, which triggers the slow read and writing times Sebastian 
experience. And, probably, to be complete, a long and complex commit history in 
git (> 100 commits).

I'll keep in mind the idea of creating one randomly ;)

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Yuriy Tymchuk [yuriy.tymc...@me.com]
Date d'envoi : jeudi 12 décembre 2013 15:37
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

Are you interested in a package or a project? I can provide you information 
based on size, etc…

Uko

On 12 Dec 2013, at 15:30, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

I gave up running gitfiletree on 1.4 :(

It's possible to use gitfiletree from a 2.0 or a 3.0 image to browse your git 
repository, but testing the writing will be an issue.

My best chance would be to find a large enough package I can use on 2.0 or 3.0 
to test and profile. Does anybody has a large enough package which could fit? 
Anything that doesn't require a NDA to read it, of course. Is Roassal large 
enough?

Thierry


De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Sebastian Sastre 
[sebast...@flowingconcept.com]
Date d'envoi : jeudi 12 décembre 2013 12:12
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

gee the big code package is airflowing which I have, quite conservatively, 
running on #14438 images

 I load filetree like this:

Gofer new
  url: 'http://ss3.gemstone.com/ss/FileTree';
  package: 'ConfigurationOfFileTree';
  load.
((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') load.

and it never complained

let me know





On Dec 12, 2013, at 3:53 AM, GOUBIER Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

If you would be ready to profile a package save on your repository, it would be 
great. In the mean time, I'll make available a special gitfiletree package to 
test. Which version of Pharo you are using? 2.0 or 3.0?

Regards,

Thierry



De : Pharo-dev 
[pharo-dev-boun...@lists.pharo.org] 
de la part de Sebastian Sastre 
[sebast...@flowingconcept.com]
Date d'envoi : mercredi 11 décembre 2013 17:09
À : Pharo Development List
Objet : Re: [Pharo-dev] Tell me about your workflow

ok, if saving is dumping all, then 3 is confirmed? After the first commit, I'd 
say so.

about 2, I don't know. I'm available to make tests and measure results

have a nice trip, keep us tuned about any progress







On Dec 11, 2013, at 2:09 PM, Goubier Thierry 
mailto:thierry.goub...@cea.fr>> wrote:

Yes, you're right in the general case.

But a solution to that general problem will take time to be implemented (time I 
lack at the moment, sadly) and if the main gain is a few % because it's writing 
the version file and the metadata for methods which are the "slow" factors, 
then we'll have worked hard for nothing.

If you want to help, I'd really like to see either 2- or 3- confirmed. I can 
produce a special gitfiletree to remove writing the metadata, that you can try 
on a large project temporary copy; if the slow writing (and reading) is 
confirmed, then this is 3-

(But I'm leaving on a trip tomorrow early, so I have no idea of when I'll have 
the time to do that :( ).

Thierry

Le 11/12/2013 16:44, Sebastian Sastre a écrit :
Without entering in details, a cause for slow package write is dumping
all every time.

For that strategy, we already have the image save which is magically fast.

So, if we make something to scan the code and write only when it's
different from what's on disk, then we would be preventing tons of
redundant writes

sebastian 

o/





On Dec 11, 2013, at 1:43 PM, Goubier Thierry 
mailto:thierry.goub...@cea.fr>
> wrote:



Le 11/12/2013 16:27, Esteban Lorenzano a écrit :
ah, and IMHO the problem is not about reading... is about writing (if it
has to write the metadata each time...).

But, personnaly, I don't know if this is the reason for 

Re: [Pharo-dev] [Moose-dev] #deepCollect:

[Tudor Girba]

Hi Chris,

This is funny :). I took a look at your code, and if you remove your
extensions on Collection, the code using deepCollect: and deep:do should
work pretty much the same way.

Cheers,
Doru


On Fri, Dec 13, 2013 at 6:02 PM, Chris Cunningham
wrote:

> Hi.
>
> I was reading with interest the blog post on Traversal-enabled objects (
> http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects )
> when I noticed the method #deepCollect: referenced.  Interestingly, I have
> a method called #deepCollect: that is use (wtih related methods like
> #deepDo: and #deepSelect:).  I suspect these uses may be compatible, with
> the traveral versions being more generic.
>
> My set of #deep methods allow arbitrary flattening of collections.  The
> #flatCollect: suite in Pharo today flattens objects 1 level; the
> #deepCollect: flattens the collections as many levels deep as they are
> nested.  I found this to be a really useful ability when I work with
> PetitParser parsings, which tend give back massively nested Arrays by
> default.
>
> If you are interested, it is published at:
> http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
>
> -cbc
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] [Moose-dev] #deepCollect:

[Tudor Girba]

Hi Esteban,

Indeed, I pondered on the issue of extending Object with the deep* methods.
In the end, I chose to extend it because traversals are not a cherry on
top, they are rather essential for significant analysis.

>From my point of view, Pharo has to become a platform in which
understanding and manipulating objects is an essential concern. The reason
is that in the long run, it is precisely assessment-related activities that
account for the largest development costs. I detailed a bit this idea here:
http://www.humane-assessment.com/blog/choose-your-technology-for-the-long-run/

For this we need a powerful toolkit that makes crafting custom analyses
cheap, and traversals has a prominent place in it.

Cheers,
Doru




On Fri, Dec 13, 2013 at 6:17 PM, Esteban A. Maringolo
wrote:

> To avoid such kind of situations I would implement all the traversal
> methods as
> a) Traits or
> b) Class side methods of DeepTraversal (you choose the name) to which
> you'll have to pass the collection and the block.
>
> E.g. DeepTraversal deep: aCollection do: aBlock
> DeepTraversal flatten: aCollection thenDo: aBlock
>
> I, personally, don't like adding methods to Object unless it's
> unavoidable(*). And in those cases I choose to prefix them with
> something that is separate from the semantic, usually the
> package/framework prefix.
>
> Regards,
>
> (*)I did that for years and in the long term it hits you back.
> Esteban A. Maringolo
>
>
> 2013/12/13 Chris Cunningham :
> > Hi.
> >
> > I was reading with interest the blog post on Traversal-enabled objects (
> > http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects )
> when
> > I noticed the method #deepCollect: referenced.  Interestingly, I have a
> > method called #deepCollect: that is use (wtih related methods like
> #deepDo:
> > and #deepSelect:).  I suspect these uses may be compatible, with the
> > traveral versions being more generic.
> >
> > My set of #deep methods allow arbitrary flattening of collections.  The
> > #flatCollect: suite in Pharo today flattens objects 1 level; the
> > #deepCollect: flattens the collections as many levels deep as they are
> > nested.  I found this to be a really useful ability when I work with
> > PetitParser parsings, which tend give back massively nested Arrays by
> > default.
> >
> > If you are interested, it is published at:
> > http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
> >
> > -cbc
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

[Pharo-dev] Another thought about globals

[Igor Stasenko]

As you may know, smalltalk global dictionary contain all symbols defined
globally,
so you can access them directly in any piece of code i.e. when you write:

Object new

it actually means 'send message #new to object, associated with #Object
name in globals dictionary.

Most of globals are classes, but some of them , like Transcript, World,
Display etc are not.
And i was always thinking there's something wrong with these globals
(actually there's multiple 'wrongs'), but finally, i think i can answer
myself, what is most basic wrong with them: they miss any form of
declaration.

Most of variables in smalltalk require declaration, such as temps, method
arguments, instance variables , class variables, pool variables,
but not globals.
Even classes, from formal point of view do not require declaration,
because actually the usual:

Object subclass: #Collection
instanceVariableNames: ''
classVariableNames: 'MutexForPicking RandomForPicking'
poolDictionaries: ''
category: 'Collections-Abstract'

is _definition_ but not declaration:

Collection definition =>

'Object subclass: #Collection
instanceVariableNames: 
classVariableNames: ''MutexForPicking RandomForPicking''
poolDictionaries: 
category: ''Collections-Abstract'''

in fact, it is just a message sent to 'Object' variable (at some moment in
the past) , and there's nothing
in language which enforces the rule that evaluating such expression must
declare new global, named Collection, except from environment we're working
in.

The absence of declaration for globals leads to following problems:
since declaration point is not defined, all tools (including compiler)
assume that given name always been there, and always accessible. Which
leads to bootstrap problems.
There's no way to determine if given piece of code (which uses some global)
will keep functioning properly, once you unload certain package. No way to
determine dependencies (and as consequence the order of code loading during
bootstrapping).
Also, it is hard to determine, to which package certain global belongs.
While it is easy to tell for classes since they having category, for
globals like Transcript, Display etc, there's no way to tell anything.
Piece of cake, you can say:  since Display is instance of DisplayScreen
class, then such variable must belong to same package as DisplayScreen,
right?
Wrong!
Just for example, imagine i create variable named MyWindowMousePosition,
which will contain an instance of Point. Does it means that such variable
should belong to same package as Point class? I guess not.

So, to sum up, i think we should really think how to introduce a way to
declare globals in package-based ecosystem, where each global belongs to
certain package, and then since packages form dependency hierarchy, you can
easily detect whether you allowed to use certain global in given context or
not,
to prevent forming dependency loops.
But even if we will weaken contract and allow having dependency loops, even
in such case declarations can help us to clearly tell which pieces of code
will stop functioning properly, if package which declares given variable
are not present in system.

The last aspect of bootstrapping problem is order of initialization,
because declaring variable doesn't means you can use it right away,
since it may be not properly initialized yet (otherwise we will be forced
to always use lazy initialization pattern).

>From this perspective, IMO package should not only have unordered list of
classes/symbols it declares/defines, but also contain information in which
order they must be initialized while loaded.
>From other side, i don't really like introducing too much formalism and
rules, and keep them as minimal as possible, following smalltalk spirit.

What  you think?

-- 
Best regards,
Igor Stasenko.