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
August 2016
- 766 messages
Re: [Pharo-dev] About the non-use of Announcer in Bloc
by Thierry Goubier
2016-08-31 18:01 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>:
>
> On 31 Aug 2016, at 10:10 , Glenn Cavarlé <glenn.cavarle(a)gmail.com> wrote:
>
> In Bloc the constraint is to propagate more than 2000 events/second without
> to decrease fps
>
>
> That's only a small part of the picture though, how many listeners are
> there per each event?
> And how large do you think the overhead specific to delivery guards is
> compared to the constraint propagation handlers?
>
> On my machine (an old 2011 MBP), the following gives throughput on the
> order of 300k-600k deliveries per second (very variable, due to the amount
> of garbage generated from copying subs, I presume)
>
So close to 3 times the performance of entry-level celeron for laptops
today (if I take the lowest of the 15" MBP of early 2011).
>
> #(1 10 100 1000) collect: [ :listeners |
>
> a := Announcer new.
> b := Object new.
> "Single message send in handler"
> listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for:
> b.].
> "announcement creation overhead not included"
> ann := Announcement new.
> [a announce: ann] bench].
>
> Cheers,
> Henry
>
> And with a registry tuned for delivery, yet maintaining the guards
> (attached)/exception/error handling properties, 900k -> 2.5M
>
> #(1 10 100 1000) collect: [ :listeners |
>
> a := Announcer new.
> b := Object new.
> a instVarNamed: 'registry' put: DeliveringSubscriptionRegistry new.
> "Single message send in handler"
> listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for:
> b.].
> "announcement creation overhead not included"
> ann := Announcement new.
> [a announce: ann] bench.].
>
Thanks for the numbers. We need those to optimise what really matters :)
Thierry
Aug. 31, 2016
Re: [Pharo-dev] About the non-use of Announcer in Bloc
by Henrik Johansen
> On 31 Aug 2016, at 10:10 , Glenn Cavarlé <glenn.cavarle(a)gmail.com> wrote:
>
> In Bloc the constraint is to propagate more than 2000 events/second without
> to decrease fps
That's only a small part of the picture though, how many listeners are there per each event?
And how large do you think the overhead specific to delivery guards is compared to the constraint propagation handlers?
On my machine (an old 2011 MBP), the following gives throughput on the order of 300k-600k deliveries per second (very variable, due to the amount of garbage generated from copying subs, I presume)
#(1 10 100 1000) collect: [ :listeners |
a := Announcer new.
b := Object new.
"Single message send in handler"
listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for: b.].
"announcement creation overhead not included"
ann := Announcement new.
[a announce: ann] bench].
Cheers,
Henry
And with a registry tuned for delivery, yet maintaining the guards (attached)/exception/error handling properties, 900k -> 2.5M
#(1 10 100 1000) collect: [ :listeners |
a := Announcer new.
b := Object new.
a instVarNamed: 'registry' put: DeliveringSubscriptionRegistry new.
"Single message send in handler"
listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for: b.].
"announcement creation overhead not included"
ann := Announcement new.
[a announce: ann] bench.].
Aug. 31, 2016
Re: [Pharo-dev] Binary selector and special characters
by John Brant
On 08/31/2016 08:46 AM, Nicolai Hess wrote:
> Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner)
> explicit allowes
> "#($± $· $à $÷)" to be binary selector characters ?
I do -- I added them about 20 years ago :)...
> Is there any smalltalk dialect that uses these characters ?
VW allows them. When possible, we made the scanner/parser be a superset
of the VW & VA syntax.
John Brant
Aug. 31, 2016
Re: [Pharo-dev] Binary selector and special characters
by Nicolai Hess
2016-08-29 11:23 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>:
>
>
> 2016-08-28 13:41 GMT+02:00 monty <monty2(a)programmer.net>:
>
>> See RBParserTest>>#testBinarySelectors
>>
>> It's based on the draft ANSI Smalltalk-80 standard. You integrated it. It
>> tests the RBParser's parsing of binary method definitions and message sends
>> of all binary selectors from 1 char upto 3 chars. (The Blue Book is more
>> restrictive than ANSI, limiting them to 2 chars max IIRC.)
>>
>> I wrote the test because of issues I had with the OldCompiler's handling
>> of selectors containing "|" and issues on other platforms like GemStone, so
>> the behavior I need and think is correct won't get broken without warning.
>>
>>
> Hi Monty,
> yes, but I am just wondering why the scanner interprets some characters as
> binary selector token, whereas they are not allowed as binary selectors.
> In the old scanner, the initialization of the type table just sets "
> binary token" as the default for all characters and changes some of them
> explicit to for example
>
> ($0 asciiValue to: $9 asciiValue) -> digit tokens
> #(9 10 12 13 32 ) -> delimiter token
> ...
>
> But RBScanner on the other hand explicitly sets some non-ascii characters
> to be used as "binary tokens"
>
> classificationTable at: 177 put: #binary. "plus-or-minus"
> classificationTable at: 183 put: #binary. "centered dot"
> classificationTable at: 215 put: #binary. "times"
> classificationTable at: 247 put: #binary. "divide"
>
> It looks like someone ( or somewhere ) it should be allowed to use these
> characters as a binary selector
> "#($± $· $à $÷)"
> Although later at the parsing step, using this tokens for binary message
> selectors isn't allowed.
>
> I think I will exclude these characters as binary selector tokens.
>
>
Now back ontopic :)
Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner) explicit
allowes
"#($± $· $à $÷)" to be binary selector characters ?
Is there any smalltalk dialect that uses these characters ?
I think I 'll remove the support for this in Pharo (it actually isn't
really supported, althought the scanner scannes these characters
as binary selector tokens, the parser finally does not allow these
characters as binary selector symbols.
Aug. 31, 2016
Re: [Pharo-dev] Binary selector and special characters
by Nicolai Hess
2016-08-31 10:14 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>:
> Oops. No need to add a step method; the increment method already exists:
>
>
>
On Wed, Aug 31, 2016 at 9:12 AM, Eliot Miranda <eliot.miranda(a)gmail.com>
> wrote:
>
>>
>>
>> On Tue, Aug 30, 2016 at 8:14 AM, Nicolai Hess <nicolaihess(a)gmail.com>
>> wrote:
>>
>>>
>>>
>>> 2016-08-29 21:38 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>:
>>>
>>>> Le 29/08/2016 à 21:28, stepharo a écrit :
>>>>
>>>>>
>>>>>
>>>>> Le 29/8/16 à 17:45, Thierry Goubier a écrit :
>>>>>
>>>>>> Hi Stef,
>>>>>>
>>>>>> 2016-08-29 11:42 GMT+02:00 stepharo <stepharo(a)free.fr
>>>>>> <mailto:stepharo@free.fr>>:
>>>>>>
>>>>>> Thierry
>>>>>>
>>>>>> If you have a better editor control even better :)
>>>>>>
>>>>>>>
>>>>>>> Syntax wise, one could consider "" to be inside a comment (i.e.
>>>>>>> do not split into two comments if encountered inside a comment,
>>>>>>> as it is done now).
>>>>>>>
>>>>>> This one could be nice too :)
>>>>>>
>>>>>>
>>>>>> https://pharo.fogbugz.com/f/cases/19011/Integrate-two-doubl
>>>>>> e-quotes-inside-comments
>>>>>>
>>>>>> I'll have the slice ready soon. Any comments on what that would mean
>>>>>> regarding the Smalltalk commonly accepted syntax if that feature is
>>>>>> integrated?
>>>>>>
>>>>> It will break compatibility for people using it now we should raise the
>>>>> topic and lets a chance to people to discuss about it. We could check
>>>>> before publishing if code contain nested comments.
>>>>>
>>>>
>>>> Hum. The slice should parse anything legal Smalltalk; just that it may
>>>> show less comments intervals (because in fact it will coalesce adjacent
>>>> comments).
>>>>
>>>
>>> Yes, I think the change for RBScanner is fine, it does not changes what
>>> kind of comments are accepted, only how they are assigned to
>>> the AST nodes (one vs. multiple comments).
>>>
>>> (BTW. do we have a function that would do the coalescing of intervals:
>>>
>>> (1 to:99) (100 to: 199) -> (1 to:199)
>>>
>>> ? )
>>>
>>
>> Find attached something that works in Squeak 5
>>
>
Nice,
But actually I wasn't clear about the requirements :-)
The purpose was to merge source code intervals after parsing code comments.
The comments may be adjacent and could be merged into one comment. For this
I would like to merge an collection of intervals in a smaller number of
intervals with adjacent intervals merged into one:
{ (30 to: 35) . (36 to:40) . (50 to:100) }
-> { (30 to:40) . (50 to:100) }
But Thierry already changed the scanner to produce this smaller set of
intervals/comments :-)
>> For example, standard parse will say that:
>>>>
>>>> '"this ""test"' is a token with two comments, intervals 1 to: 7 and 8
>>>> to: 13.
>>>>
>>>> The slice makes that a single comment:
>>>>
>>>> '"this ""test"' is a token with one comment, interval 1 to: 13.
>>>>
>>>> Now, this has probably no impact on parsing smalltalk code. But it
>>>> changes a bit the language definition, so that's why I'd like comments on
>>>> it.
>>>>
>>>> I think that I would use them only when developing.
>>>>>
>>>>
>>>> Up to you :)
>>>>
>>>> The most interesting is to have the correct comment/uncomment behavior
>>>> in an editor... that one works independently and is quite cool.
>>>>
>>>> Thierry
>>>>
>>>> Stef
>>>>>
>>>>>
>>>>>> Thierry
>>>>>>
>>>>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
Aug. 31, 2016
[pharo-project/pharo-core] 36483e: 60196
by GitHub
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: 36483e309d746cb796ae363a3a5a1555c5c2883a
https://github.com/pharo-project/pharo-core/commit/36483e309d746cb796ae363a…
Author: Jenkins Build Server <board(a)pharo-project.org>
Date: 2016-08-31 (Wed, 31 Aug 2016)
Changed paths:
M AST-Core.package/RBScanner.class/instance/private-scanning/stripComment.st
A AST-Tests-Core.package/RBScannerTest.class/instance/next/testNextWithTwoDoubleQuotesInComment.st
A AST-Tests-Core.package/RBScannerTest.class/instance/next/testNextWithTwoDoubleQuotesInCommentGetError.st
R BlueInk-Extras.package/BIInspector.class/README.md
R BlueInk-Extras.package/BIInspector.class/class/build ui buttons/buildOpenBIInspectorButton.st
R BlueInk-Extras.package/BIInspector.class/class/button behavior/openBIInspectorButtonAction.st
R BlueInk-Extras.package/BIInspector.class/class/button behavior/openBIInspectorButtonLabel.st
R BlueInk-Extras.package/BIInspector.class/class/button behavior/openBIInspectorButtonState.st
R BlueInk-Extras.package/BIInspector.class/class/settings/dialogOpenBIInspector.st
R BlueInk-Extras.package/BIInspector.class/class/settings/settingsOn_.st
R BlueInk-Extras.package/BIInspector.class/class/specs/defaultSpec.st
R BlueInk-Extras.package/BIInspector.class/definition.st
R BlueInk-Extras.package/BIInspector.class/instance/accessing/classSearchField.st
R BlueInk-Extras.package/BIInspector.class/instance/accessing/compiledMethodFromSearchFields.st
R BlueInk-Extras.package/BIInspector.class/instance/accessing/formattedCheckBox.st
R BlueInk-Extras.package/BIInspector.class/instance/accessing/methodSearchField.st
R BlueInk-Extras.package/BIInspector.class/instance/accessing/settingsTree.st
R BlueInk-Extras.package/BIInspector.class/instance/accessing/sourceCodePane.st
R BlueInk-Extras.package/BIInspector.class/instance/api/formatSourceCode.st
R BlueInk-Extras.package/BIInspector.class/instance/api/initialExtent.st
R BlueInk-Extras.package/BIInspector.class/instance/api/title.st
R BlueInk-Extras.package/BIInspector.class/instance/event handling/whenASettingChanged.st
R BlueInk-Extras.package/BIInspector.class/instance/event handling/whenSelectorAccepted.st
R BlueInk-Extras.package/BIInspector.class/instance/initialization/initializeWidgets.st
R BlueInk-Extras.package/BIInspector.class/instance/item creation/buildClassSearchField.st
R BlueInk-Extras.package/BIInspector.class/instance/item creation/buildFormattedCheckBox.st
R BlueInk-Extras.package/BIInspector.class/instance/item creation/buildMethodSearchField.st
R BlueInk-Extras.package/BIInspector.class/instance/item creation/buildSettingsTreeModel.st
R BlueInk-Extras.package/BIInspector.class/instance/item creation/buildSourceCodePane.st
R BlueInk-Extras.package/BIInspector.class/instance/item creation/displayNodeFor_.st
R BlueInk-Extras.package/BIInspector.class/instance/testing/selectorAndClassAreCorrect.st
A BlueInk-Extras.package/BISettingPreviewer.class/README.md
A BlueInk-Extras.package/BISettingPreviewer.class/class/build ui buttons/buildOpenBIInspectorButton.st
A BlueInk-Extras.package/BISettingPreviewer.class/class/button behavior/openBIInspectorButtonAction.st
A BlueInk-Extras.package/BISettingPreviewer.class/class/button behavior/openBIInspectorButtonLabel.st
A BlueInk-Extras.package/BISettingPreviewer.class/class/button behavior/openBIInspectorButtonState.st
A BlueInk-Extras.package/BISettingPreviewer.class/class/settings/dialogOpenBIPreviewer.st
A BlueInk-Extras.package/BISettingPreviewer.class/class/settings/settingsOn_.st
A BlueInk-Extras.package/BISettingPreviewer.class/class/specs/defaultSpec.st
A BlueInk-Extras.package/BISettingPreviewer.class/definition.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/accessing/classSearchField.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/accessing/compiledMethodFromSearchFields.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/accessing/formattedCheckBox.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/accessing/methodSearchField.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/accessing/settingsTree.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/accessing/sourceCodePane.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/api/formatSourceCode.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/api/initialExtent.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/api/title.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/event handling/whenASettingChanged.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/event handling/whenSelectorAccepted.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/initialization/initializeWidgets.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/item creation/buildClassSearchField.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/item creation/buildFormattedCheckBox.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/item creation/buildMethodSearchField.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/item creation/buildSettingsTreeModel.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/item creation/buildSourceCodePane.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/item creation/displayNodeFor_.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/testing/selectorAndClassAreCorrect.st
R Nautilus-Tests.package/NautilusTest.class/instance/tests/testCorrespondingMethods.st
R Nautilus-Tests.package/NautilusTest.class/instance/tests/testCorrespondingTestClass.st
R Nautilus-Tests.package/NautilusTest.class/instance/tests/testCorrespondingTestMethod.st
A Nautilus-Tests.package/NautilusUtilsTest.class/README.md
A Nautilus-Tests.package/NautilusUtilsTest.class/definition.st
A Nautilus-Tests.package/NautilusUtilsTest.class/instance/accessing/stubClass.st
A Nautilus-Tests.package/NautilusUtilsTest.class/instance/accessing/stubTestClass.st
A Nautilus-Tests.package/NautilusUtilsTest.class/instance/tests/testCorrespondingTestCase.st
A Nautilus-Tests.package/NautilusUtilsTest.class/instance/tests/testCorrespondingTestMethod.st
A Nautilus-Tests.package/NautilusUtilsTest.class/instance/tests/testCorrespondingTestedMethods.st
A Nautilus-Tests.package/NautilusUtilsTest.class/instance/tests/testTransformSelectorForComparison.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/README.md
A Nautilus-Tests.package/NautilusUtilsTestStub.class/class/instance creation/one_two_.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/class/instance creation/untestedOne_two_.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/definition.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/instance/accessing/one.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/instance/accessing/oneTwo_.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/instance/accessing/one_.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/instance/accessing/one_two_.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/instance/accessing/two.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/instance/accessing/two_.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/instance/accessing/untestedOne.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/instance/accessing/untestedOneTwo_.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/instance/accessing/untestedOne_.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/instance/accessing/untestedOne_two_.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/instance/accessing/untestedTwo.st
A Nautilus-Tests.package/NautilusUtilsTestStub.class/instance/accessing/untestedTwo_.st
A Nautilus-Tests.package/NautilusUtilsTestStubTest.class/README.md
A Nautilus-Tests.package/NautilusUtilsTestStubTest.class/definition.st
A Nautilus-Tests.package/NautilusUtilsTestStubTest.class/instance/accessing/stubClass.st
A Nautilus-Tests.package/NautilusUtilsTestStubTest.class/instance/instance creation/newStub.st
A Nautilus-Tests.package/NautilusUtilsTestStubTest.class/instance/tests/testOne.st
A Nautilus-Tests.package/NautilusUtilsTestStubTest.class/instance/tests/testOneTwo.st
A Nautilus-Tests.package/NautilusUtilsTestStubTest.class/instance/tests/testTwo.st
A Nautilus-Tests.package/NautilusUtilsTestStubUntested.class/README.md
A Nautilus-Tests.package/NautilusUtilsTestStubUntested.class/definition.st
A Nautilus.package/AbstractMethodIconAction.class/instance/accessing/iconForTestResultOf_.st
M Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/registerToTestAnnouncements.st
M Nautilus.package/AbstractNautilusUI.class/instance/icon caches/removeFromMethodsIconsCache_.st
A Nautilus.package/AbstractNautilusUI.class/instance/system announcements/testRan_.st
R Nautilus.package/AbstractNautilusUI.class/instance/system announcements/testRunned_.st
A Nautilus.package/AbstractNautilusUI.class/instance/updating/updateCategoryAndMethodList.st
A Nautilus.package/AbstractNautilusUI.class/instance/updating/updateCategoryAndMethodList_.st
M Nautilus.package/MethodIsTestAction.class/instance/order/privateActionIcon.st
M Nautilus.package/MethodWithCorrespondingTestAction.class/instance/order/privateActionIcon.st
M Nautilus.package/NautilusUI.class/class/menus behavior/runTestForAMethod_notifying_.st
A NautilusCommon.package/NautilusUtils.class/README.md
A NautilusCommon.package/NautilusUtils.class/class/utilities/correspondingTestCaseOf_.st
A NautilusCommon.package/NautilusUtils.class/class/utilities/correspondingTestMethodOf_.st
A NautilusCommon.package/NautilusUtils.class/class/utilities/correspondingTestedMethodsOf_.st
A NautilusCommon.package/NautilusUtils.class/class/utilities/isErrorTest_.st
A NautilusCommon.package/NautilusUtils.class/class/utilities/isFailedTest_.st
A NautilusCommon.package/NautilusUtils.class/class/utilities/isPassedTest_.st
A NautilusCommon.package/NautilusUtils.class/class/utilities/isTestMethod_.st
A NautilusCommon.package/NautilusUtils.class/definition.st
R NautilusCommon.package/extension/CompiledMethod/instance/correspondingMethods.st
M NautilusCommon.package/extension/CompiledMethod/instance/correspondingTestMethod.st
A NautilusCommon.package/extension/CompiledMethod/instance/correspondingTestedMethods.st
R NautilusCommon.package/extension/CompiledMethod/instance/hasErrorTest.st
R NautilusCommon.package/extension/CompiledMethod/instance/hasFailedTest.st
R NautilusCommon.package/extension/CompiledMethod/instance/hasPassedTest.st
A NautilusCommon.package/extension/CompiledMethod/instance/isErrorTest.st
A NautilusCommon.package/extension/CompiledMethod/instance/isFailedTest.st
A NautilusCommon.package/extension/CompiledMethod/instance/isPassedTest.st
M NautilusCommon.package/extension/CompiledMethod/instance/isTestMethod.st
A NautilusCommon.package/extension/RGClassDescriptionDefinition/instance/correspondingTestCase.st
R NautilusCommon.package/extension/RGMethodDefinition/instance/correspondingMethods.st
M NautilusCommon.package/extension/RGMethodDefinition/instance/correspondingTestMethod.st
A NautilusCommon.package/extension/RGMethodDefinition/instance/correspondingTestedMethods.st
R NautilusCommon.package/extension/RGMethodDefinition/instance/hasErrorTest.st
R NautilusCommon.package/extension/RGMethodDefinition/instance/hasFailedTest.st
R NautilusCommon.package/extension/RGMethodDefinition/instance/hasPassedTest.st
A NautilusCommon.package/extension/RGMethodDefinition/instance/isErrorTest.st
A NautilusCommon.package/extension/RGMethodDefinition/instance/isFailedTest.st
A NautilusCommon.package/extension/RGMethodDefinition/instance/isPassedTest.st
M NautilusCommon.package/extension/RGMethodDefinition/instance/isTestMethod.st
R NautilusCommon.package/extension/RGMethodDefinition/instance/literals.st
R NautilusCommon.package/extension/RGMethodDefinition/instance/numArgs.st
M NautilusCommon.package/extension/String/instance/transformSelectorForComparison.st
R NautilusCommon.package/extension/TClassDescription/instance/correspondingForTest.st
A NautilusCommon.package/extension/TClassDescription/instance/correspondingTestCase.st
A NautilusCommon.package/extension/TestCase/class/clearResultOfTestMethod_.st
R NautilusCommon.package/extension/TestCase/class/correspondingClass.st
A NautilusCommon.package/extension/TestCase/class/correspondingClassTested.st
A NautilusCommon.package/extension/TestCase/class/correspondingTestCase.st
M RPackage-Tests.package/RPackageOrganizerTest.class/instance/utility/quadrangleClass.st
A Ring-Core-Kernel.package/RGMethodDefinition.class/instance/accessing/numArgs.st
A Ring-Core-Kernel.package/RGMethodDefinition.class/instance/literals/literals.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60195.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60196.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60195.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60196.st
M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
Log Message:
-----------
60196
18974 A Nautilus fix to support class method tests
https://pharo.fogbugz.com/f/cases/18974
18991 asClass in RPackageTest
https://pharo.fogbugz.com/f/cases/18991
18989 asClass in BlueInk
https://pharo.fogbugz.com/f/cases/18989
19011 Integrate two double quotes inside comments
https://pharo.fogbugz.com/f/cases/19011
http://files.pharo.org/image/60/60196.zip
Aug. 31, 2016
[pharo-project/pharo-core]
by GitHub
Branch: refs/tags/60196
Home: https://github.com/pharo-project/pharo-core
Aug. 31, 2016
SUnit improvements need review and feedback
by Denis Kudriashov
Hi.
I am working on SUnit improvements. I open issue 19015
<https://pharo.fogbugz.com/f/cases/19015/Tests-should-never-hang-and-leave-f…>.
Slice is inbox which waits your review and feedback.
I was trying to address three problems:
*1) Tests should never hang. They should be always executed within time
limit.*
I give them 10 minutes for now to not change existing behaviour of tests.
At next step it should be really reduced to ~100 milliseconds (?).
Any TestCase could redefine time limit by method #defaultTimeLimit.
Or it could be specified directly in test code by
self timeLimit: 10 seconds
(could be changed at any time of test execution).
To implement this logic special watch dog process is running for given test
suite to control execution time of tests. It is single process for full
test suite.
*2) When test completes all forked processes should be terminated.*
If your tested code produced zombie processes SUnit will take care about
destroying all such garbage.
(it not means that you don't need to clean table in #tearDown but any code
could be broken and running tests should not produce dirty system).
*3) Any failures inside forked processes should not spawn debugger while
running tests.*
Only when we debug tests we need debugger on forked failed processes.
During normal run SUnit should prevent such "background debuggers" and mark
such tests as failed.
To implement this behaviour SUnit will handle errors from forked processes
by suspending them and collecting them in special collection.
I introduce TestFailedByForkedProcess error to signal these kind of
problems at the end of tests. This error is resumable and resume will opens
debuggers of suspended failures (in fact it will resume suspended
processes).
So to debug background failures you will need extra Proceed action on
debugger when TestFailedByForkedProcess is signalled.
But in normal run such tests will be just failed by
TestFailedByForkedProcess error.
*Now details on how it is done:*
I introduce special process specific variable CurrentExecutionEnvironment.
It is not installed by default and as default value it returns
DefaultExecutionEnvironment instance.
This variable is inheritable. If your install concrete environment into
process it will be installed to any child process.
So value of variable is instance of ExecutionEnvironment subclasses and you
can install it by:
anYourExecutionEnvironment beActiveDuring: aBlock
When block completes previous environment is restored.
For default environment there is class side method:
DefaultExecutionEnvironment beActiveDuring: aBlock
And to reset current environment to default:
DefaultExecutionEnvironment beActive.
SUnit introduces TestExecutionEnvironment which implements all described
behaviour for time limits and forked processes.
To activate environment there is new method #runCaseManaged. And submitted
slice uses it instead of simple runCase.
TestCase>>runCaseManaged
CurrentExecutionEnvironment runTestCase: self
DefaultExecutionEnvironment will install new TestExecutionEnvironment and
delegate processing to it. And if TestExecutionEnvironment is already
active it will just process new test case.
Now monkey has problem in checking slice (annoying timeout for loading).
So I can't see real system impact. But it should not stop you from review
:))
I think it is very important features for all our tests. And environment
idea will lead to very interesting future.
Best regards,
Denis
Aug. 31, 2016
Re: [Pharo-dev] About the non-use of Announcer in Bloc
by Glenn Cavarlé
Hi Denis,
> Problem that concurrent modification of OrderedCollection could just fail.
> You will got debugger.
Yes, effectively, if there are multiple threads that try to add an handler
on the same element at the same time, this could just fail.
To me, it is not a problem, it is just a rule: the scene graph is not
thread-safe.
When a developper have to do this kind of specific stuff, he has to know
that it is really not recommended and that he has to manage concurrency by
hand.
But yes, he could use #runLater:.
Maybe, Bloc will have to provide kind of Task (using TaskIt?) with a
specific api to ease ui synchronization using concurrency (later).
> In that case what to do if I need to be sure that I really subscribe on
> event and only after this continue my business logic process?
Weird use case, you mean that sometime your business behavior declared after
a subscription needs that the subscription have to be called before
continue?
Please can you be more explicit? For what i understand, it look like a
workaround or a conception issue.
> Very simple example: I want one shot handler for MouseMove to highlight
> element once to see that my mouse was moved around.
> So my handler will highlight target element and unsubscribe it
> immediately.
> Problem that if you do it on OrderedCollection during iteration you could
> skip one of the handlers. And probably some failures are also possible
> (debugger again).
Yes, thanks for pointing this issue, i didn't remember that #select:thenDo:
uses the index at each iteration.
I will update that using (handlers select:[...]) do:[...] instead. Since
#select: create a new collection, there should not be any problem.
> But in practice we never share any announcer instance. We always hide it
> inside owner object. ValueHolder is not specific example.
> Also ValueHolder is kind of active model for UI application which could be
> shared between different views. And when it will be modified in one view
> another view will be updated automatically.
I know what is a ValueHolder and how data binding is usefull in GUI.
I didn't say that NewValueHolder and Announcer are not good and i don't
think that, i just asked myself about why the use of Announcer in
NewValueHolder make it 5x slower only to ensure that it is thread-safe while
in most cases, all stuff is done in one thread.
It is why i didn't use NewValueHolder in Bloc. (I commited tests between
NewValueHolder and BlObservableProperty in Bloc-Tests).
If performances was not a critical issue in Bloc, obviously i would have
used NewValueHolder and Announcer because there are well done and well
tested.
> I wondering what the source of this constraint? Does Morphic follows it? I
> guess not, but all Pharo works quite well with it.
Just move you mouse quickly on screen and think about how many
MouseMoveEvent are generated by the system.
Yes, Morphic follows it. Morphic doesn't use Announcer for UI events and
concurrent modifications of a morph seems to be not thread-safe.
-----
Glenn Cavarlé
--
View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p4913…
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Aug. 31, 2016
Re: [Pharo-dev] why is gt playground not saving the code
by Andrei Chis
On Wed, Aug 31, 2016 at 12:32 PM, Nicolai Hess <nicolaihess(a)gmail.com>
wrote:
>
>
> 2016-08-31 12:00 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>:
>
>> At this point Iâve lost cumulatively hours and hours of work due to
>> Playground not saving the code; so every time I crash I lose.
>>
>>
>>
>> In the picture below the code was demonstrably executed and yet itâs not
>> in the history and if I would crash (which happens several times a day in
>> âstableâ pharo 5) I would lose it. Not to mention that way too often I see
>> duplicate events in the history with identical codeâ¦
>>
>>
>>
>>
>>
>
> This was discussed a couple of time and we even had some bug-entries.
> But it is working that way "by-design".
> I don't understand why, but the current content is not shown in the
> history, only if you close the current playground window *withouth*
> deleteing the content.
>
I do not remember the previous discussion in details but I think we should
consider this a bug.
I'll open a bug report and try to dig the previous discussion about this
topic.
Cheers,
Andrei
> If the content is not shown in the history, it may be still in the
> play-cache folder.
>
>
>
>> Peter
>>
>
>
Aug. 31, 2016