Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
October 2010
- 130 participants
- 1604 messages
Re: [Pharo-project] [update 1.2] #12161 - #12172
by Igor Stasenko
2010/10/1 Levente Uzonyi <leves(a)elte.hu>:
> On Fri, 1 Oct 2010, Igor Stasenko wrote:
>
>> On 1 October 2010 12:06, Levente Uzonyi <leves(a)elte.hu> wrote:
>> On Fri, 1 Oct 2010, Marcus Denker wrote:
>>
>>> Issue 3002: Â Â A new finalization code ready for integration in Pharo
>>> Issue 3026: after 12172, sync with repository and reload
>>
>> If you didn't fix the migration code, then WeakFinalizationRegistry is
>> still
>> in the system. Details here:
>>
>>
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/15400…
>>
> You mean this not work:
> Â Â Â Â Smalltalk forgetClass: #WeakFinalizationRegistry logged: false.
>
> should be
> Â Â Â Â Smalltalk forgetClass: WeakFinalizationRegistry logged: false.
>
> right?
>
>
> Yes.
>
>
Thanks for noticing.
> Levente
>
>>
>> Levente
>>
>>>
>>> --
>>> Marcus Denker  -- http://www.marcusdenker.de
>>> INRIA Lille -- Nord Europe. Team RMoD.
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project(a)lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Best regards,
Igor Stasenko AKA sig.
Oct. 1, 2010
Re: [Pharo-project] [update 1.2] #12161 - #12172
by Levente Uzonyi
On Fri, 1 Oct 2010, Igor Stasenko wrote:
> On 1 October 2010 12:06, Levente Uzonyi <leves(a)elte.hu> wrote:
> On Fri, 1 Oct 2010, Marcus Denker wrote:
>
>> Issue 3002: Â Â A new finalization code ready for integration in Pharo
>> Issue 3026: after 12172, sync with repository and reload
>
> If you didn't fix the migration code, then WeakFinalizationRegistry is still
> in the system. Details here:
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/15400…
>
You mean this not work:
Smalltalk forgetClass: #WeakFinalizationRegistry logged: false.
should be
Smalltalk forgetClass: WeakFinalizationRegistry logged: false.
right?
Yes.
Levente
>
> Levente
>
>>
>> --
>> Marcus Denker  -- http://www.marcusdenker.de
>> INRIA Lille -- Nord Europe. Team RMoD.
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
Pharo-project(a)lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Oct. 1, 2010
[Pharo-project] [update 1.2] #12174
by Marcus Denker
12174
-----
Issue 2713: Changelist deserves some fixes
Issue 3030: Remove Explain... code (again)
Issue 3023: change the initial windows position strategy
Issue 3028: PluggableListMorphByItem >> getCurrentSelectionIndex access directly a non-initailized instance variable
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
Oct. 1, 2010
Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!
by Mariano Martinez Peck
On Fri, Oct 1, 2010 at 11:08 AM, Levente Uzonyi <leves(a)elte.hu> wrote:
> On Fri, 1 Oct 2010, Mariano Martinez Peck wrote:
>
> Thanks to everybody. I did what you say and now
>>
>> MessageTally time: [ECContextTest new testUntypedVarsOnly] -> 3023
>>
>> I've just commited OCompletion.
>>
>> And I didn't know TimeProfiler :)
>>
>
> If you download
> http://www.squeaksource.com/OCompletion/Ocompletion-ul.67.mcz you'll get
> better results:
>
> [ ECContextTest new testUntypedVarsOnly ] timeToRun "===> 815"
>
>
Excellent. Thanks Levente
>
> Levente
>
>
>
>> cheers
>>
>> Mariano
>>
>> On Tue, Sep 28, 2010 at 1:43 PM, Levente Uzonyi <leves(a)elte.hu> wrote:
>>
>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
>>>
>>> On 28.09.2010 01:43, Levente Uzonyi wrote:
>>>
>>>>
>>>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
>>>>>
>>>>> On 28.09.2010 00:41, Levente Uzonyi wrote:
>>>>>
>>>>>>
>>>>>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
>>>>>>>
>>>>>>> On 28.09.2010 00:07, Levente Uzonyi wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
>>>>>>>>>
>>>>>>>>> 2010/9/27 Levente Uzonyi <leves(a)elte.hu>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> IF you take a 1.1 core and just load OCompletion:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly]
>>>>>>>>>>>> 20907
>>>>>>>>>>>>
>>>>>>>>>>>> If you load OCompletion and the rest of the dev image:
>>>>>>>>>>>>
>>>>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly]
>>>>>>>>>>>> 100137
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> However, IN pharo dev 1.0 it is
>>>>>>>>>>>>
>>>>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> sooo.... ????
>>>>>>>>>>>>
>>>>>>>>>>>> something has changed?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> As I said, SortedCollection is not suitable for this kind of
>>>>>>>>>>> usage.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But in Pharo 1.0 OCompletion was doing the same....so? did
>>>>>>>>>> SortedCollection
>>>>>>>>>> chang between 1.0 and 1.1?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> No, something else changed. The same test is still 5x faster in 1.0
>>>>>>>>> dev with the new code.
>>>>>>>>>
>>>>>>>>> TimeProfiler to the rescue:
>>>>>>>> Preferences class >> ecompletionCaseSensitive
>>>>>>>> 1.0: (1725ms)
>>>>>>>> 1.1 (19724ms)
>>>>>>>>
>>>>>>>> Preference>>settingValue which is there for backwards-compatability
>>>>>>>> in
>>>>>>>> 1.1 does both symbol creation and respondsTo:, so yeah, it's much
>>>>>>>> slower
>>>>>>>> than the old dictionary lookup.
>>>>>>>>
>>>>>>>>
>>>>>>> Nice find. If you check my code, you'll find that I optimized that
>>>>>>> away. :)
>>>>>>>
>>>>>>>
>>>>>>> Levente
>>>>>>>
>>>>>>> Yes ,you moved it out of the actual sort loop :)
>>>>>> Rewrite the methods in ECPreferences to use the new syntax:
>>>>>> <preference: category: description: type:>, and you shouldn't even
>>>>>> have
>>>>>> to do that to get ok performance.
>>>>>>
>>>>>> IMHO, it's rather disturbing to see things like EC, where its
>>>>>> preferences are actually separated tucked away in an ECPreferences
>>>>>> class,
>>>>>> only to be delegated from there over to Preferences...
>>>>>>
>>>>>>
>>>>> The preferences should be updated, but sending a message once is still
>>>>> better than 2k-30k times.
>>>>>
>>>>>
>>>>> Levente
>>>>>
>>>>> Sure, on the order of a couple of milliseconds difference.
>>>> I keep forgetting the fact we generally have different definitions of
>>>> what
>>>> constitutes "ok performance" ;)
>>>>
>>>>
>>> 30k was a bit optimistic assumption. For example the Pharo 1.1 OneClick
>>> image has 3220 globals. The sortBlock asks for the preference twice per
>>> evaluation. SortedCollection uses a binary search during #add:. If we are
>>> optimistic, then the preference is asked 3220 * (3220 ln / 2 ln) * 2
>>> times
>>> which is ~75k.
>>>
>>> In the same image the "old" code asked for the preference 2282899 times
>>> during the tests, while the new code did it only 398 times. If the
>>> preference is changed to return the value of a variable, then the
>>> difference
>>> is only 80 ms, otherwise it's 36.6 seconds.
>>>
>>>
>>> Levente
>>>
>>>
>>>
>>> Cheers,
>>>> Henry
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> Pharo-project(a)lists.gforge.inria.fr
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project(a)lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
Oct. 1, 2010
Re: [Pharo-project] CodeMorph >> text should return an instance of Text but return a String
by Cyrille Delaunay
I just saw that there is propositions to remove CodeMorph:
http://code.google.com/p/pharo/issues/detail?id=2902&q=CodeMorph&colspec=ID…
So maybe the best fix will be to remove all the tests related ? :)
2010/10/1 Cyrille Delaunay <cy.delaunay(a)gmail.com>
> In pharo 1.2, NewTextMorphTests>>#testFullMethodName raise an error. This error happen when calling:
>
> CodeMorph >> defaultStyledText
> | text attribute |
> text := self text.
> text addAttribute: ( self newTextColorAttribute: Color black ).
> ^ text.
>
> text is a string, and therefore it does not understand 'addAttribute'. The value return by 'text' depends on the value of the instance variable 'adapter'. adapter can have different values according the way we initialize the CodeMorph. One of them is:
>
> beFullMethodName
> aspect := #selector.
> adapter := [:selector| target methodClass name , '.' , self selectorWithArguments ].
>
> The block return a String and I guess the right code should be
>
> beFullMethodName
> aspect := #selector.
> adapter := [:selector| (target methodClass name , '.' , self selectorWithArguments) asText ]
>
> ??.
>
>
> I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3031
>
>
Oct. 1, 2010
[Pharo-project] CodeMorph >> text should return an instance of Text but return a String
by Cyrille Delaunay
In pharo 1.2, NewTextMorphTests>>#testFullMethodName raise an error.
This error happen when calling:
CodeMorph >> defaultStyledText
| text attribute |
text := self text.
text addAttribute: ( self newTextColorAttribute: Color black ).
^ text.
text is a string, and therefore it does not understand 'addAttribute'.
The value return by 'text' depends on the value of the instance
variable 'adapter'. adapter can have different values according the
way we initialize the CodeMorph. One of them is:
beFullMethodName
aspect := #selector.
adapter := [:selector| target methodClass name , '.' , self
selectorWithArguments ].
The block return a String and I guess the right code should be
beFullMethodName
aspect := #selector.
adapter := [:selector| (target methodClass name , '.' , self
selectorWithArguments) asText ]
??.
I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3031
Oct. 1, 2010
[Pharo-project] [update 1.2] #12173
by Stéphane Ducasse
12173
-----
- Issue 3003: handleDisabledKey: is missing in Editor and subclasses
- Issue 2963: systemOrganizer fixes. Thanks German Leiva and James Foester
Stef
Oct. 1, 2010
Re: [Pharo-project] TextLint questions and feedback
by Jorge Ressia
Hi,
We did a change in the way the files are opened.
We could not reproduce the same issue but we could manage to reproduce
other encoding issues.
So, please try your file again and let us know.
Cheers,
2010/9/30 Mariano Martinez Peck <marianopeck(a)gmail.com>:
>
>
> On Thu, Sep 2, 2010 at 5:13 PM, Mariano Martinez Peck
> <marianopeck(a)gmail.com> wrote:
>>
>> Sorry, I forgot another bug. A piece of my latex is like this:
>>
>> \authorinfo{
>> Â Â Â Mariano Martinez Peck\affINRIA\affEMD \and
>> Â Â Â Â Noury Bouraqadi\affEMD \and
>> Â Â Â Â Marcus Denker\affINRIA \and
>> Â Â Â Â St\'ephane Ducasse\affINRIA \and
>> Â Â Â Â Luc Fabresse\affEMD
>> }{
>> Â Â Â $^1$RMoD Project-Team, Inria Lille--Nord Europe / Universit\'e Lille 1
>> \\
>> Â Â Â $^2$Universit\'e Lille Nord de France, Ecole des Mines de Douai
>> }{marianopeck(a)gmail.com,
>> \{stephane.ducasse,marcus.denker\}@inria.fr,\\\{noury.bouraqadi,luc.fabresse\}@mines-douai.fr}
>> \maketitle
>>
>>
>> I don't know why...but once I saved the file, the image "frezzed" for a
>> long time, and then, if finished and that part was replaced by this:
>>
>>
>> \authorinfo{
>> Â Â Â Mariano Martinez Peck\affINRIA\affEMD \and
>> Â Â Â Â Noury Bouraqadi\affEMD \and
>> Â Â Â Â Marcus Denker\affINRIA \and
>> Â Â Â Â St\'ephane Ducasse\affINRIA \and
>> Â Â Â Â Luc Fabresse\affEMD
>> }{
>> Â Â Â $^1$RMoD Project-Team, Inria Lille--Nord Europe /
>> UniversitâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâìÃâé
>> de Lille 1 \\
>> Â Â Â $^2$Universit\'e Lille Nord de France, Ecole des Mines de Douai
>> }{marianopeck(a)gmail.com,
>> \{stephane.ducasse,marcus.denker\}@inria.fr,\\\{noury.bouraqadi,luc.fabresse\}@mines-douai.fr}
>> \maketitle
>>
>
> Hi. TextLint is being used now even for non-smalltalkers :)
> Here my coworker is using it for his papers. THe problem he had, is the same
> as mine. Without trying to do it, we put accents characters like é or è or
> things like that in the TextLint pane. I don't know why but TextLint starts
> to loop and writes all those characters (for example Ãâì) a lot of times.
> For example, the file of my friend, went to 5MB!!!
>
> I know this is not TextLint fault, and probably Pharo, but avoiding this
> would be great.
>
> Cheers
>
> Mariano
>
>
>
>
>>
>> So...it seems something related to encoding...but no idea...
>>
>> thanks
>>
>> mariano
>>
>>
>> On Thu, Sep 2, 2010 at 3:42 PM, Mariano Martinez Peck
>> <marianopeck(a)gmail.com> wrote:
>>>
>>> Hi. First, please let me know if this is the correct place to talk about
>>> TextLint. I've just used for one paper I am writing and I have some
>>> questions/feedback. I am using the one click image.
>>>
>>> 1) The "An Rule" could be a little more smart and detects commands. For
>>> example, in my latex I have " an \emph{inner object}"Â and that was detected
>>> by the rule, althought I shouldn't. So...detecting the slash and ignore what
>>> it surrounded by {} would be nice for this rule.
>>>
>>> 2) When I edit the code inside TextLint and I save it, two bad things
>>> happens:
>>> Â Â Â Â 2.a)Â I lost focus of the text, as it moves when it finishing
>>> saving. The line I edited goes to the end of the text area. It would be
>>> great if nothing moves nor to loose focus when saving.
>>> Â Â Â Â 2.b) sometimes (I cannot reproduce) the order of the rules
>>> changes...and this is not good because I was going in order, one by one, and
>>> suddenly they are re-ordered. Maybe you are using a Set for that? using a
>>> simple OrderedCollection could help.
>>>
>>> 3) If you edit the text (and it differs in the amount of characters), and
>>> DO NOT save it, the following color highlighting are moved. It seems you
>>> keep the position in the file, and until it is saved, rules results are
>>> pointing to "unupdated" file. Of course, when I save the file, they are
>>> correct. I guess this is from a performance point of view, but maybe you
>>> have a little hack to do and make it better.
>>>
>>> 4) The rule "no white space before punctuation mark" showed me things I
>>> didn't understand. For example, it says this line there is a "," (comma) :
>>>
>>> \item[ Shared object ]Â Â In the case of the \emph{shared objects}, it is
>>> almost the same as in the \emph{inner objects}. An .....
>>>
>>> 5) Rules comments clearer. For example, when you say "Avoid using a lot,
>>> it weakens the sentence"Â It would be better to put "Avoid using "a lot", it
>>> weakens the sentence"
>>> or "Avoid using *a lot*, it weakens the sentence"
>>> or something to clearly mark the words not to use. Because sometimes the
>>> words are confused with the context. Or this one:
>>>
>>> "After an only words beginning with a vowel are allowed. "
>>> should be "After "an" only words beginning with a vowel are allowed."
>>>
>>> 6) For the rules of long sentences/paragraph it would be nice to ignore
>>> \fotenote{}
>>>
>>> 7) Maybe this link is of interest for you:
>>> http://matt.might.net/articles/shell-scripts-for-passive-voice-weasel-words…
>>>
>>> Apart from all these things, the tool is very useful and I like it.
>>>
>>> thanks
>>>
>>> Mariano
>>>
>>>
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Jorge Ressia
www.jorgeressia.com
Oct. 1, 2010
[Pharo-project] SystemVersionTest>>testDowngrade use a deprecated method
by Cyrille Delaunay
The test SystemVersionTest>>testDowngrade use SytemVersion >> version,
which is deprected. It raise a warning when running the tests in a
pharo 1.2 core image.
I opened an issue:
http://code.google.com/p/pharo/issues/detail?id=3025&colspec=ID%20Type%20St…
Oct. 1, 2010
[Pharo-project] PluggableListMorphByItem >> getCurrentSelectionIndex access directly a non-initailized instance variable
by Cyrille Delaunay
In pharo 1.2, MorphicToolBuilderTests >> testGetListSelection raise an
error. This error is caused by PluggableListMorphByItem >>
getCurrentSelectionIndex, which looks like that:
getCurrentSelectionIndex
"Answer the index of the current selection."
| item |
getIndexSelector == nil ifTrue: [^ 0].
item := model perform: getIndexSelector.
^ list findFirst: [ :x | x = item].
list is nil when runing the test. I guess that a better way is to use
the accessor 'getList'. This method seems to make the correct
initializations befor retrning the instance variable 'list'.
When replacing by:
getCurrentSelectionIndex
"Answer the index of the current selection."
| item |
getIndexSelector == nil ifTrue: [^ 0].
item := model perform: getIndexSelector.
^ self getList findFirst: [ :x | x = item].
The test pass.
I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3028
Oct. 1, 2010
Re: [Pharo-project] [update 1.2] #12161 - #12172
by Igor Stasenko
On 1 October 2010 12:06, Levente Uzonyi <leves(a)elte.hu> wrote:
> On Fri, 1 Oct 2010, Marcus Denker wrote:
>
>> Issue 3002: Â Â A new finalization code ready for integration in Pharo
>> Issue 3026: after 12172, sync with repository and reload
>
> If you didn't fix the migration code, then WeakFinalizationRegistry is still
> in the system. Details here:
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/15400…
>
You mean this not work:
Smalltalk forgetClass: #WeakFinalizationRegistry logged: false.
should be
Smalltalk forgetClass: WeakFinalizationRegistry logged: false.
right?
>
> Levente
>
>>
>> --
>> Marcus Denker  -- http://www.marcusdenker.de
>> INRIA Lille -- Nord Europe. Team RMoD.
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Best regards,
Igor Stasenko AKA sig.
Oct. 1, 2010
Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!
by Levente Uzonyi
On Fri, 1 Oct 2010, Mariano Martinez Peck wrote:
> Thanks to everybody. I did what you say and now
>
> MessageTally time: [ECContextTest new testUntypedVarsOnly] -> 3023
>
> I've just commited OCompletion.
>
> And I didn't know TimeProfiler :)
If you download
http://www.squeaksource.com/OCompletion/Ocompletion-ul.67.mcz you'll get
better results:
[ ECContextTest new testUntypedVarsOnly ] timeToRun "===> 815"
Levente
>
> cheers
>
> Mariano
>
> On Tue, Sep 28, 2010 at 1:43 PM, Levente Uzonyi <leves(a)elte.hu> wrote:
>
>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
>>
>> On 28.09.2010 01:43, Levente Uzonyi wrote:
>>>
>>>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
>>>>
>>>> On 28.09.2010 00:41, Levente Uzonyi wrote:
>>>>>
>>>>>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
>>>>>>
>>>>>> On 28.09.2010 00:07, Levente Uzonyi wrote:
>>>>>>>
>>>>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
>>>>>>>>
>>>>>>>> 2010/9/27 Levente Uzonyi <leves(a)elte.hu>
>>>>>>>>>
>>>>>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
>>>>>>>>>>
>>>>>>>>>> IF you take a 1.1 core and just load OCompletion:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
>>>>>>>>>>>
>>>>>>>>>>> If you load OCompletion and the rest of the dev image:
>>>>>>>>>>>
>>>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> However, IN pharo dev 1.0 it is
>>>>>>>>>>>
>>>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> sooo.... ????
>>>>>>>>>>>
>>>>>>>>>>> something has changed?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> As I said, SortedCollection is not suitable for this kind of usage.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But in Pharo 1.0 OCompletion was doing the same....so? did
>>>>>>>>> SortedCollection
>>>>>>>>> chang between 1.0 and 1.1?
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, something else changed. The same test is still 5x faster in 1.0
>>>>>>>> dev with the new code.
>>>>>>>>
>>>>>>> TimeProfiler to the rescue:
>>>>>>> Preferences class >> ecompletionCaseSensitive
>>>>>>> 1.0: (1725ms)
>>>>>>> 1.1 (19724ms)
>>>>>>>
>>>>>>> Preference>>settingValue which is there for backwards-compatability in
>>>>>>> 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower
>>>>>>> than the old dictionary lookup.
>>>>>>>
>>>>>>
>>>>>> Nice find. If you check my code, you'll find that I optimized that
>>>>>> away. :)
>>>>>>
>>>>>>
>>>>>> Levente
>>>>>>
>>>>> Yes ,you moved it out of the actual sort loop :)
>>>>> Rewrite the methods in ECPreferences to use the new syntax:
>>>>> <preference: category: description: type:>, and you shouldn't even have
>>>>> to do that to get ok performance.
>>>>>
>>>>> IMHO, it's rather disturbing to see things like EC, where its
>>>>> preferences are actually separated tucked away in an ECPreferences class,
>>>>> only to be delegated from there over to Preferences...
>>>>>
>>>>
>>>> The preferences should be updated, but sending a message once is still
>>>> better than 2k-30k times.
>>>>
>>>>
>>>> Levente
>>>>
>>> Sure, on the order of a couple of milliseconds difference.
>>> I keep forgetting the fact we generally have different definitions of what
>>> constitutes "ok performance" ;)
>>>
>>
>> 30k was a bit optimistic assumption. For example the Pharo 1.1 OneClick
>> image has 3220 globals. The sortBlock asks for the preference twice per
>> evaluation. SortedCollection uses a binary search during #add:. If we are
>> optimistic, then the preference is asked 3220 * (3220 ln / 2 ln) * 2 times
>> which is ~75k.
>>
>> In the same image the "old" code asked for the preference 2282899 times
>> during the tests, while the new code did it only 398 times. If the
>> preference is changed to return the value of a variable, then the difference
>> is only 80 ms, otherwise it's 36.6 seconds.
>>
>>
>> Levente
>>
>>
>>
>>> Cheers,
>>> Henry
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project(a)lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
Oct. 1, 2010
Re: [Pharo-project] [update 1.2] #12161 - #12172
by Levente Uzonyi
On Fri, 1 Oct 2010, Marcus Denker wrote:
> Issue 3002: A new finalization code ready for integration in Pharo
> Issue 3026: after 12172, sync with repository and reload
If you didn't fix the migration code, then WeakFinalizationRegistry is
still in the system. Details here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/15400…
Levente
>
> --
> Marcus Denker -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
Oct. 1, 2010
[Pharo-project] [ANN 1.2] new pre-built 1.2Core#1272
by Marcus Denker
https://gforge.inria.fr/frs/download.php/27544/PharoCore-1.2-12172.zip
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
Oct. 1, 2010
[Pharo-project] [update 1.2] #12161 - #12172
by Marcus Denker
Issue 3002: A new finalization code ready for integration in Pharo
Issue 3026: after 12172, sync with repository and reload
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
Oct. 1, 2010
Re: [Pharo-project] "A Mentoring Course on Smalltalk" Code License
by Julian Fitzell
I'm not a real license expert but I do play one on TV...
The license should be visible, easy to find, and clearly associated
with the code in question. Also, as Monty pointed out at ESUG, make
sure it is possible for people to comply with the terms of your
license. MIT license specifically requires the user to maintain the
copyright notice, so make sure you *have* a copyright notice!
I have no idea if this is relevant in this case--it's just a general
observation but I mention it here because it's one of my big concerns
with open source at the moment--but make sure the contributors (and
not their employers) all own the intellectual property. In many (even
most) jurisdictions, full-time employees may find that their employer
by default owns much of the code they write, even what is written in
their spare time. Contractors usually own their code by default but
most companies who are on the ball will try to assign the ownership to
them in the contract.
Whether you're a full-time employee or a contractor, check your
contracts before contributing to open-source. It is much easier to
request a written IP exclusion in advance than to try to transfer
ownership later. You're doing everyone a disservice if you pollute
open source projects with code that has questionable IP ownership; the
difficulty of defining derivative works makes it very hard to predict
the difficulty of fixing the problem.
Julian
On Fri, Oct 1, 2010 at 3:23 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote:
>
>
> Andres Valloud-4 wrote:
>>
>> Well, since this discussion is public now :)
>>
> hee hee
>
>
> Andres Valloud-4 wrote:
>>
>> ... exactly what seems to be
>> the problem? Â The book talks about code that is often in the public
>> Store repository. Â Is the problem that the code in the public Store
>> repository doesn't have an MIT license? Â Or is the problem that the book
>> that talks about the code in the public Store repository doesn't say
>> "and the code has an MIT license"?
>>
>
> Would a license expert weigh in here? Â Andres, would it be difficult to add
> a note to the book specifying that the code in it is MIT?
> --
> View this message in context: http://forum.world.st/A-Mentoring-Course-on-Smalltalk-Code-License-tp271425…
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
Oct. 1, 2010
Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!
by Mariano Martinez Peck
Thanks to everybody. I did what you say and now
MessageTally time: [ECContextTest new testUntypedVarsOnly] -> 3023
I've just commited OCompletion.
And I didn't know TimeProfiler :)
cheers
Mariano
On Tue, Sep 28, 2010 at 1:43 PM, Levente Uzonyi <leves(a)elte.hu> wrote:
> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
>
> On 28.09.2010 01:43, Levente Uzonyi wrote:
>>
>>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
>>>
>>> On 28.09.2010 00:41, Levente Uzonyi wrote:
>>>>
>>>>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote:
>>>>>
>>>>> On 28.09.2010 00:07, Levente Uzonyi wrote:
>>>>>>
>>>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
>>>>>>>
>>>>>>> 2010/9/27 Levente Uzonyi <leves(a)elte.hu>
>>>>>>>>
>>>>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote:
>>>>>>>>>
>>>>>>>>> IF you take a 1.1 core and just load OCompletion:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907
>>>>>>>>>>
>>>>>>>>>> If you load OCompletion and the rest of the dev image:
>>>>>>>>>>
>>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> However, IN pharo dev 1.0 it is
>>>>>>>>>>
>>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> sooo.... ????
>>>>>>>>>>
>>>>>>>>>> something has changed?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> As I said, SortedCollection is not suitable for this kind of usage.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> But in Pharo 1.0 OCompletion was doing the same....so? did
>>>>>>>> SortedCollection
>>>>>>>> chang between 1.0 and 1.1?
>>>>>>>>
>>>>>>>
>>>>>>> No, something else changed. The same test is still 5x faster in 1.0
>>>>>>> dev with the new code.
>>>>>>>
>>>>>> TimeProfiler to the rescue:
>>>>>> Preferences class >> ecompletionCaseSensitive
>>>>>> 1.0: (1725ms)
>>>>>> 1.1 (19724ms)
>>>>>>
>>>>>> Preference>>settingValue which is there for backwards-compatability in
>>>>>> 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower
>>>>>> than the old dictionary lookup.
>>>>>>
>>>>>
>>>>> Nice find. If you check my code, you'll find that I optimized that
>>>>> away. :)
>>>>>
>>>>>
>>>>> Levente
>>>>>
>>>> Yes ,you moved it out of the actual sort loop :)
>>>> Rewrite the methods in ECPreferences to use the new syntax:
>>>> <preference: category: description: type:>, and you shouldn't even have
>>>> to do that to get ok performance.
>>>>
>>>> IMHO, it's rather disturbing to see things like EC, where its
>>>> preferences are actually separated tucked away in an ECPreferences class,
>>>> only to be delegated from there over to Preferences...
>>>>
>>>
>>> The preferences should be updated, but sending a message once is still
>>> better than 2k-30k times.
>>>
>>>
>>> Levente
>>>
>> Sure, on the order of a couple of milliseconds difference.
>> I keep forgetting the fact we generally have different definitions of what
>> constitutes "ok performance" ;)
>>
>
> 30k was a bit optimistic assumption. For example the Pharo 1.1 OneClick
> image has 3220 globals. The sortBlock asks for the preference twice per
> evaluation. SortedCollection uses a binary search during #add:. If we are
> optimistic, then the preference is asked 3220 * (3220 ln / 2 ln) * 2 times
> which is ~75k.
>
> In the same image the "old" code asked for the preference 2282899 times
> during the tests, while the new code did it only 398 times. If the
> preference is changed to return the value of a variable, then the difference
> is only 80 ms, otherwise it's 36.6 seconds.
>
>
> Levente
>
>
>
>> Cheers,
>> Henry
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
Oct. 1, 2010
Re: [Pharo-project] NativeBoost and Cog. A working protype.
by Igor Stasenko
On 1 October 2010 10:33, Fernando olivero <fernando.olivero(a)usi.ch> wrote:
> Just a thought,
>
> I would say that Lukas Helvetia framework could be used here,  to cleanly embed C++, C or whatever you like  syntax into the existing Smalltalk ambient.
>
Yes, I like the idea of using Helvetia. I would be cool to invent some
kind of platform-neutral assembler language.
If one likes to write C or C++ , it would be cool too.
> So in the background NativeBoost would behave more uniformly, because everything in the end is smalltalk code.
>
> Fernando
>
>
> On Oct 1, 2010, at 8:39 AM, Schwab,Wilhelm K wrote:
>
>> Sig,
>>
>> I'm pointing out that "do it all in Smalltalk" has limits, both in syntax (C++ is generally a better formula translator than Smalltalk; Smalltalk is better at expressing just about anything else) and in performance, unless you can stop boxing/unboxing the floats, which it sounds like you can't.
>>
>> One performance penalty that I look forward to suffering is to have an external library calling into Pharo to do function evaluations. Â In most cases, the number of operations will be small and the convenience of having the code in the image will be most welcome.
>>
>> Bill
>>
>>>> ......
>
>
>
>>>> ________________________________________
>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen(a)pairhome.net]
>>>> Sent: Thursday, September 30, 2010 11:33 AM
>>>> To: Pharo-project(a)lists.gforge.inria.fr
>>>> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>>>>
>>>> On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote:
>>>> On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
>>>>> One really crazy idea: inline C. Â Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Â Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
>>>>>
>>>>> void LogOnePlus(double * data, unsigned long size)
>>>>> /*
>>>>> Â Â Â Add one and take log10() over the buffer; in-place transformation!
>>>>> */
>>>>> {
>>>>> Â Â Â for(unsigned long i=0; i<size; i++){
>>>>> Â Â Â data[i] = log10(data[i]+1);
>>>>> Â Â Â }
>>>>> }
>>>>>
>>>>> That's a simple calculation, but do it millions of times and it adds up. Â Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Â Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
>>>>>
>>>>
>>>> Of course its possible.
>>>> After porting C parser/compiler into smalltalk :)
>>>> Or perhaps some meta-language which looks like C, but which easier to
>>>> translate to native code.
>>>>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Best regards,
Igor Stasenko AKA sig.
Oct. 1, 2010
[Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1
by Sven Van Caekenberghe
Mariano,
On 01 Oct 2010, at 09:55, Mariano Martinez Peck wrote:
> Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo 1.1 but based on PharoCore 1.1.1. The versions of the external packages is the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has integrated some fixes and the support for CogVM. This means that Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For CogVM we recommend to use the last binaries that can be found in http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is http://www.mirandabanda.org/files/Cog/VM/VM.r2313/
>
> This CogVM version fixes the problem with "Objects as methods", and thus, all the #run:with:with are working. This means that tools like TestCoverage and AutoTest are working correctly with CogVM.
>
> The link to the image is: https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip
>
> Cheers
>
> Mariano
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Super!
Thanks a lot for all the effort (and the persistence).
Although I am already on 1.1.1 and Cog myself,
this version is a very important milestone for end users.
I will certainly check it out.
Sven
Oct. 1, 2010
[Pharo-project] [update 1.2] #12160
by Marcus Denker
12160
-----
Issue 3022: Custom help books should be able to define where subbooks should be placed/displayed
Issue 2980: dropping a text file into the host window raises an error
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
Oct. 1, 2010
[Pharo-project] [Progress Report] Zinc HTTP Components
by Sven Van Caekenberghe
Here is a quick progress report regarding the Zinc HTTP Components project.
Please check the SqueakSource history for a all the details.
The external documentation has not yet been updated ;-)
I am very pleased that Matt Kennedy joined the project as a developer and
is contributing lots of really important and interesting code - way to go Matt!
Some highights are:
- we now have cookie handling, authentication and credential objects
- there is a new ZnUserAgent client that can do advanced authentication
handles cookies, sessions and that can follow redirects
- there is a ZnFixedClient that can reuse a connection to the same host/port
- there is support for client side chunked and gzip decoding
- there is an experimental server that keeps connections alive (unfinised)
- support classes ZnUserAgentSession and ZnUserAgentSession
- lots of refactorings, fixes and portability improvements
- the number of unit tests has increased to 71
Sven
Oct. 1, 2010
[Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1
by Mariano Martinez Peck
Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo
1.1 but based on PharoCore 1.1.1. The versions of the external packages is
the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has
integrated some fixes and the support for CogVM. This means that
Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For
CogVM we recommend to use the last binaries that can be found in
http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is
http://www.mirandabanda.org/files/Cog/VM/VM.r2313/
This CogVM version fixes the problem with "Objects as methods", and thus,
all the #run:with:with are working. This means that tools like TestCoverage
and AutoTest are working correctly with CogVM.
The link to the image is:
https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip
Cheers
Mariano
Oct. 1, 2010
Re: [Pharo-project] Alien Plugin for Linux
by Fernando olivero
Thanks for the information Noury!
Now we can safely assume the the official Alien package is in the Alien repository.
I will look into the answer from Henrik, and try to have a cleaner Alien-Core package, with less overrides.
Fernando
On Sep 29, 2010, at 8:11 PM, Noury Bouraqadi wrote:
> HI Fernando,
>
> It was a bug fix. And we hadn't at that time access to the Alien repo for saving it.
> Currently, we have a metacello config and it refers the alien repo.
>
> Noury
> On 29 sept. 2010, at 15:20, Fernando olivero wrote:
>
>> A question to the Ocean developers, why do have a particular Alien-Core package in the ocean repo? ( Alien-Core-LucFabresse.64.mcz )
>>
>> Are there some fixes that could be included in the official package? Please let me know so i can integrate them.
>>
>> I'm asking because i'm cleaning a bit the Alien mess, ( see previous mail) , and would like to have a single working official Alien.
>>
>> Thanks,
>> Fernando
>>
>> On Sep 29, 2010, at 12:56 PM, Fernando olivero wrote:
>>
>>> This Error prevents from using Alien in the lastest Pharo image.
>>>
>>> I will try to fix this today.
>>>
>>> Also i will remove the ConfigurationOfAlien from the Alien repository, because the version in MetacelloRepository should be used instead.
>>> So there are no future misunderstandings
>>>
>>>
>>> Thanks to Eliot, and using his precompiled Vms for all platforms Alien would be available now!
>>> (if the mentioned bug were fixed).
>>>
>>>
>>> Fernando
>>>
>>>
>>> On Sep 28, 2010, at 12:05 PM, Igor Stasenko wrote:
>>>
>>>> On 28 September 2010 11:51, Henrik Johansen
>>>> <henrik.s.johansen(a)veloxit.no> wrote:
>>>>> On Sep 28, 2010, at 10:34 16AM, Alberto Bacchelli wrote:
>>>>>
>>>>>> On 9/27/10 8:13 PM, Eliot Miranda wrote:
>>>>>>>
>>>>>>>
>>>>>>> 2010/9/27 Fernando olivero<fernando.olivero(a)usi.ch<mailto:fernando.olivero@usi.ch>>
>>>>>>> Does the prebuilt CogVM for linux include Alien support?
>>>>>>> http://www.mirandabanda.org/files/Cog/VM/VM.r2313/
>>>>>>>
>>>>>>> Only of the data manipulation and callout parts, not the callback parts. I'm trying to find time to work on integrating the Alien callback machinery with the FFI.
>>>>>>>
>>>>>>> best
>>>>>>> Eliot
>>>>>>
>>>>>> We had a problem after installing Alien,
>>>>>> when running the tests.
>>>>>>
>>>>>> The following does not understand
>>>>>>
>>>>>> MessageNotUnderstood: Array>>createMethod:header:methodClass:
>>>>>>
>>>>>> sent by
>>>>>> CompileMethod class>>newBytes:trailerBytes:nArgs:nTemps:nStack:nLits:primitive:
>>>>>>
>>>>>> It appears to be cog related, is it?
>>>>>>
>>>>>> Thank you,
>>>>>> Alberto
>>>>>
>>>>> No, it's Method-trailer related.
>>>>>
>>>>> IIRC, the convention used to be to pass the empty trailer bytes #(0 0 0 0), find the offending sender and change it to pass CompiledMethodTrailer empty instead.
>>>>>
>>>>
>>>> Right. A more compatible way is to use SomeClass defaultMethodTrailer
>>>> Where SomeClass should be a class, where you installing this method.
>>>>
>>>>
>>>>> Cheers,
>>>>> Henry
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> Pharo-project(a)lists.gforge.inria.fr
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> Pharo-project(a)lists.gforge.inria.fr
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project(a)lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Oct. 1, 2010
Re: [Pharo-project] NativeBoost and Cog. A working protype.
by Fernando olivero
Just a thought,
I would say that Lukas Helvetia framework could be used here, to cleanly embed C++, C or whatever you like syntax into the existing Smalltalk ambient.
So in the background NativeBoost would behave more uniformly, because everything in the end is smalltalk code.
Fernando
On Oct 1, 2010, at 8:39 AM, Schwab,Wilhelm K wrote:
> Sig,
>
> I'm pointing out that "do it all in Smalltalk" has limits, both in syntax (C++ is generally a better formula translator than Smalltalk; Smalltalk is better at expressing just about anything else) and in performance, unless you can stop boxing/unboxing the floats, which it sounds like you can't.
>
> One performance penalty that I look forward to suffering is to have an external library calling into Pharo to do function evaluations. In most cases, the number of operations will be small and the convenience of having the code in the image will be most welcome.
>
> Bill
>
>>> ......
>>> ________________________________________
>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen(a)pairhome.net]
>>> Sent: Thursday, September 30, 2010 11:33 AM
>>> To: Pharo-project(a)lists.gforge.inria.fr
>>> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>>>
>>> On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote:
>>> On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
>>>> One really crazy idea: inline C. Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
>>>>
>>>> void LogOnePlus(double * data, unsigned long size)
>>>> /*
>>>> Add one and take log10() over the buffer; in-place transformation!
>>>> */
>>>> {
>>>> for(unsigned long i=0; i<size; i++){
>>>> data[i] = log10(data[i]+1);
>>>> }
>>>> }
>>>>
>>>> That's a simple calculation, but do it millions of times and it adds up. Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
>>>>
>>>
>>> Of course its possible.
>>> After porting C parser/compiler into smalltalk :)
>>> Or perhaps some meta-language which looks like C, but which easier to
>>> translate to native code.
>>>
Oct. 1, 2010
Re: [Pharo-project] NativeBoost and Cog. A working protype.
by Denis Kudriashov
Hello
2010/10/1 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>
> I'm pointing out that "do it all in Smalltalk" has limits, both in syntax
> (C++ is generally a better formula translator than Smalltalk; Smalltalk is
> better at expressing just about anything else)
I have many complex math stuff implemented in smalltalk and C in
university. And my experience that no matter C or smalltalk you use for
formula (equation) programming. In any case it will be not math formula like
on paper. And readability will be bad. Debugging is bad because of complex
calculations and diffirences in math formula and program language analogue.
Just see fast fourier transformation. Equations is not so complex. But
programme implementation...
Ideally programming math formula or equation should not exists for user. You
just put native math formula presentation to system and get results.
Maybe similar solution exists?
Oct. 1, 2010