Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- August
- 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
- 3 participants
- 144616 messages
Re: [Pharo-dev] a request to change the meaning of <example> pragma
by Tudor Girba
Hi,
> On Dec 19, 2016, at 5:49 PM, Ben Coman <btc(a)openinworld.com> wrote:
>
> On Mon, Dec 19, 2016 at 3:53 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote:
>>
>>
>> 2016-12-19 8:46 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>:
>>>
>>> Hi,
>>>
>>> I would prefer if this thread does not transform in a terminology debate
>>> too much.
>>>
>>
>> @Doru, but you asked "What do you think" and I think Bens response about
>> sampleScript is valid
>>
>> @Ben Did you check Dorus blog entry
>> (http://gtoolkit.org/doc/Examples/examples.html) I think this makes
>> it more clear why gttExamples are more than just methods producsing
>> "samples"
>
>
> I hadn't seen that before. Thanks for the tip.
> So I cede the point the aim is something more than just a sample.
Thank you!
But, if we are at it, please letâs continue and brainstorm. The existing implementation should be taken as a first fully working version. It would be great to have people play with it and find its weaknesses.
Cheers,
Doru
> cheers -ben
>
>>
>>
>>>
>>> Example is a term that fits both the code and the returning object.
>>> <gtExample> is applied on a method and it primarily describes that method.
>>> The term âexampleâ also describes the meta object that is wraps the concrete
>>> return value with the information from the method (for example, the label of
>>> the example, the link to the subject, or the dependencies to other
>>> examples). The example term is also important from the metaphor point of
>>> view: "we learn from examplesâ.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>>> On Dec 19, 2016, at 3:34 AM, Ben Coman <btc(a)openinworld.com> wrote:
>>>>
>>>> On Mon, Dec 19, 2016 at 5:49 AM, Tudor Girba <tudor(a)tudorgirba.com>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> As you might know, a while ago we created GTExamples, a framework that
>>>>> supports both example-based live documentation and testing:
>>>>> http://gtoolkit.org/doc/Examples/examples.html
>>>>>
>>>>> GTExamples was part of the GTInspector for a while, but as it evolved,
>>>>> we pulled it out in a separate project. This separate project is not in
>>>>> Pharo anymore but it is part of the full GToolkit configuration (Pharo only
>>>>> ships the core of GToolkit). The idea of taking GTExamples out was to allow
>>>>> the community to have a more elaborate discussion about the role of examples
>>>>> in our environment.
>>>>>
>>>>> I have invited you to join that conversation, but it did not take off.
>>>>> I understand that perhaps the topic does not look appealing at this moment.
>>>>>
>>>>> We will certainly continue to evolve GTExamples both on the semantics
>>>>> level of the dependency constructs and on the integration with tools. Our
>>>>> goal is to enable a new practice that I would like to call Example-Guilded
>>>>> Development (or Example-Driven Development), and position Pharo to be the
>>>>> only platform on which someone can do that. But, that is our goal, and does
>>>>> not have to be the same with other peopleâs goal.
>>>>>
>>>>> Right now, GTExamples relies on the <gtExample> pragma to denote a
>>>>> method that returns an object that exemplifies something.
>>>>
>>>>
>>>> I've previously not done a good job of promoting the use of <sample>
>>>> for this. I'll try spinning this wheel once more.
>>>>
>>>> There are two concepts to consider:
>>>> * The returned object.
>>>> * The method code that creates the returned object.
>>>>
>>>> The "returned object" is best considered a <sample>.
>>>> The "method code" is best considered an <example> that produces the
>>>> sample.
>>>>
>>>> http://www.differencebetween.com/difference-between-example-and-vs-sample/
>>>>
>>>> The term "exemplifies/exemplification" associates equally with both...
>>>> * http://www.thesaurus.com/browse/example
>>>> * http://www.thesaurus.com/browse/sample
>>>> but for example... from a draw full of cutlery you don't "take an
>>>> example spoon", you "take a sample spoon".
>>>>
>>>>
>>>> So it depends on where you want the focus to be.
>>>> * If the focus is on working with a sample object, then <sample> makes
>>>> a better pragma for the method creating it.
>>>> * If the focus is on the code producing the sample, then <example> is
>>>> a better choice.
>>>>
>>>> Maybe you are constrained by existing industry terminology,
>>>> but "Example-Driven Development" might be equally called
>>>> "Sample-Driven Development".
>>>> Without having read into the topic, intuitively the former broadly
>>>> encompasses copying static code
>>>> while the latter feels more limited to working with an object.
>>>>
>>>>
>>>> My proposal...
>>>> * <sample> provides a narrower sense of side-effect-free provision of
>>>> object to work with. "Samples are often tangible parts and can be
>>>> observed"
>>>> * <example> provides a broader sense of showing how things work
>>>> together, in ways that may or may-not include side effects that you
>>>> don't actually want to execute - just to refer to. "Examples are used
>>>> [to] illustrate something. [Its] expected that the example will be
>>>> imitated and replicated among its audience."
>>>> * <script> provides a sense of system management, of methods causing
>>>> significant side effects. You won't want to copy these methods, just
>>>> make use them.
>>>>
>>>> <sampleScript> feels awkward to apply to examples, since by my these
>>>> are neither samples nor scripts.
>>>>
>>>>
>>>> cheers -ben
>>>>
>>>>
>>>>> Executing this method as an example should have no side-effects (either
>>>>> because the method itself does not have a side-effect, or because the
>>>>> example method defines how the cleanup should happen using the mechanism
>>>>> provided by GTExamples).
>>>>>
>>>>> This meaning is different from the meaning of the <example> pragma used
>>>>> through Pharo. There are currently 55 places that use this pragma inside
>>>>> Pharo and most of them come from FastTable. As things will progress and more
>>>>> libraries might use GTExamples, the situation can become confusing.
>>>>>
>>>>> To make things less confusing in the future, I would like to define the
>>>>> meaning of the <example> to denote a method that returns an object without
>>>>> having side effects. Would you agree with this?
>>>>>
>>>>> If yes, I would suggest the name of the new pragma that would replace
>>>>> the existing one to include âscriptâ in the name. For example,
>>>>> <sampleScript>.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>> www.feenk.com
>>>>>
>>>>> "Reasonable is what we are accustomed with."
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> âSoftware has no shape. Actually, it has no one shape. It has many."
--
www.tudorgirba.com
www.feenk.com
"If you can't say why something is relevant,
it probably isn't."
Dec. 19, 2016
[pharo-project/pharo-core]
by GitHub
Branch: refs/tags/60330
Home: https://github.com/pharo-project/pharo-core
Dec. 19, 2016
[pharo-project/pharo-core] 458c6c: 60330
by GitHub
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: 458c6cef0678ceeedd886a7e8c952aa72ceddca0
https://github.com/pharo-project/pharo-core/commit/458c6cef0678ceeedd886a7e…
Author: Jenkins Build Server <board(a)pharo-project.org>
Date: 2016-12-19 (Mon, 19 Dec 2016)
Changed paths:
M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st
M Kernel-Tests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st
M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st
M Kernel-Tests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st
M Kernel.package/Delay.class/class/initialize-release/initialize.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60329.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60330.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60329.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60330.st
M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A SmartSuggestions.package/SugsAbstractContext.class/instance/accessing/model.st
A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectTheTextForTheNode.st
A SmartSuggestions.package/SugsGlamourCodeContext.class/instance/selection/selectedInterval.st
Log Message:
-----------
60330
18735 DNU on suggestions shortcut in GTDebugger
https://pharo.fogbugz.com/f/cases/18735
19432 Promote DelaySpinScheduler from experimental status (part 2)
https://pharo.fogbugz.com/f/cases/19432
19438 Widen tolerance for DelayScheduler timing tests
https://pharo.fogbugz.com/f/cases/19438
http://files.pharo.org/image/60/60330.zip
Dec. 19, 2016
Re: [Pharo-dev] [Vm-dev] Problem with OSSubprocess / signals / heartbeat ?
by Holger Freyther
> On 19 Dec 2016, at 14:41, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote:
>
> Hi guys,
>
> Guille Polito kept one of these images if someone can give us a hand. He also proposed the great idea of using `strace` to see what was going on. He (together with Pable Tesone) suspected that the heartbeat could be interrupting the `clone()` function which is (I think) called internally by the 'posix_spawn()' which is the one used by OSSubprocess.
>
> When these images are "hung" they found at a infinitive loop like this:
Okay, how many child processes do you have at that point? How many processes does the system have?
>
> [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
> [pid 17477] gettimeofday({1482152630, 593498}, NULL) = 0
> [pid 17477] sigreturn() (mask []) = 120
> [pid 17477] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted)
> [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
> [pid 17477] gettimeofday({1482152630, 600126}, NULL) = 0
> [pid 17477] sigreturn() (mask []) = 120
> [pid 17477] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted)
so above.. 7ms between the two gettimeofday calls? Nothing else? Set a breakpoint on clone/fork in gdb and look at the c-stack at this point? Could you strace with timestamps to see how much time is spent? Is the process suspicious in other ways?
So yes.. sounds like clone doesn't complete.. the question is why? Is it out of resources? Is something in the VM blocking longer than the heartbeat, is the heartbeat more frequent than expected?
> As you can see, there is a SIGALARM involved. It also looks like the `gettimeofday` is used by the heartbeat ? Could it be that someone the heartbeat is interrupting the `clone()` ?
>
> Guille also showed me the `strace` output with a regular / working image:
>
>
> [pid 18647] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
> [pid 18647] gettimeofday({1482152829, 481014}, NULL) = 0
> [pid 18647] sigreturn() (mask []) = -1 EINTR (Interrupted system call)
> [pid 18647] getitimer(ITIMER_REAL, {it_interval={0, 2000}, it_value={0, 1917}}) = 0
> [pid 18647] recvmsg(3, 0xff7b0734, 0) = -1 EAGAIN (Resource temporarily unavailable)
> [pid 18647] select(4, [3], [], [3], {0, 1000}) = 0 (Timeout)
> [pid 18647] getitimer(ITIMER_REAL, {it_interval={0, 2000}, it_value={0, 797}}) = 0
> [pid 18647] recvmsg(3, 0xff7b0734, 0) = -1 EAGAIN (Resource temporarily unavailable)
> [pid 18647] select(4, [3], [], [3], {0, 1000}) = ? ERESTARTNOHAND (To be restarted if no handler)
> [pid 18647] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
>
>
> Does anyone have any hint here?
Get timestamps in there. How long does it take to fail/end in this situation?
holger
Dec. 19, 2016
Re: [Pharo-dev] a request to change the meaning of <example> pragma
by Ben Coman
On Mon, Dec 19, 2016 at 3:53 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote:
>
>
> 2016-12-19 8:46 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>:
>>
>> Hi,
>>
>> I would prefer if this thread does not transform in a terminology debate
>> too much.
>>
>
> @Doru, but you asked "What do you think" and I think Bens response about
> sampleScript is valid
>
> @Ben Did you check Dorus blog entry
> (http://gtoolkit.org/doc/Examples/examples.html) I think this makes
> it more clear why gttExamples are more than just methods producsing
> "samples"
I hadn't seen that before. Thanks for the tip.
So I cede the point the aim is something more than just a sample.
cheers -ben
>
>
>>
>> Example is a term that fits both the code and the returning object.
>> <gtExample> is applied on a method and it primarily describes that method.
>> The term âexampleâ also describes the meta object that is wraps the concrete
>> return value with the information from the method (for example, the label of
>> the example, the link to the subject, or the dependencies to other
>> examples). The example term is also important from the metaphor point of
>> view: "we learn from examplesâ.
>>
>> Cheers,
>> Doru
>>
>>
>>
>> > On Dec 19, 2016, at 3:34 AM, Ben Coman <btc(a)openinworld.com> wrote:
>> >
>> > On Mon, Dec 19, 2016 at 5:49 AM, Tudor Girba <tudor(a)tudorgirba.com>
>> > wrote:
>> >> Hi,
>> >>
>> >> As you might know, a while ago we created GTExamples, a framework that
>> >> supports both example-based live documentation and testing:
>> >> http://gtoolkit.org/doc/Examples/examples.html
>> >>
>> >> GTExamples was part of the GTInspector for a while, but as it evolved,
>> >> we pulled it out in a separate project. This separate project is not in
>> >> Pharo anymore but it is part of the full GToolkit configuration (Pharo only
>> >> ships the core of GToolkit). The idea of taking GTExamples out was to allow
>> >> the community to have a more elaborate discussion about the role of examples
>> >> in our environment.
>> >>
>> >> I have invited you to join that conversation, but it did not take off.
>> >> I understand that perhaps the topic does not look appealing at this moment.
>> >>
>> >> We will certainly continue to evolve GTExamples both on the semantics
>> >> level of the dependency constructs and on the integration with tools. Our
>> >> goal is to enable a new practice that I would like to call Example-Guilded
>> >> Development (or Example-Driven Development), and position Pharo to be the
>> >> only platform on which someone can do that. But, that is our goal, and does
>> >> not have to be the same with other peopleâs goal.
>> >>
>> >> Right now, GTExamples relies on the <gtExample> pragma to denote a
>> >> method that returns an object that exemplifies something.
>> >
>> >
>> > I've previously not done a good job of promoting the use of <sample>
>> > for this. I'll try spinning this wheel once more.
>> >
>> > There are two concepts to consider:
>> > * The returned object.
>> > * The method code that creates the returned object.
>> >
>> > The "returned object" is best considered a <sample>.
>> > The "method code" is best considered an <example> that produces the
>> > sample.
>> >
>> > http://www.differencebetween.com/difference-between-example-and-vs-sample/
>> >
>> > The term "exemplifies/exemplification" associates equally with both...
>> > * http://www.thesaurus.com/browse/example
>> > * http://www.thesaurus.com/browse/sample
>> > but for example... from a draw full of cutlery you don't "take an
>> > example spoon", you "take a sample spoon".
>> >
>> >
>> > So it depends on where you want the focus to be.
>> > * If the focus is on working with a sample object, then <sample> makes
>> > a better pragma for the method creating it.
>> > * If the focus is on the code producing the sample, then <example> is
>> > a better choice.
>> >
>> > Maybe you are constrained by existing industry terminology,
>> > but "Example-Driven Development" might be equally called
>> > "Sample-Driven Development".
>> > Without having read into the topic, intuitively the former broadly
>> > encompasses copying static code
>> > while the latter feels more limited to working with an object.
>> >
>> >
>> > My proposal...
>> > * <sample> provides a narrower sense of side-effect-free provision of
>> > object to work with. "Samples are often tangible parts and can be
>> > observed"
>> > * <example> provides a broader sense of showing how things work
>> > together, in ways that may or may-not include side effects that you
>> > don't actually want to execute - just to refer to. "Examples are used
>> > [to] illustrate something. [Its] expected that the example will be
>> > imitated and replicated among its audience."
>> > * <script> provides a sense of system management, of methods causing
>> > significant side effects. You won't want to copy these methods, just
>> > make use them.
>> >
>> > <sampleScript> feels awkward to apply to examples, since by my these
>> > are neither samples nor scripts.
>> >
>> >
>> > cheers -ben
>> >
>> >
>> >> Executing this method as an example should have no side-effects (either
>> >> because the method itself does not have a side-effect, or because the
>> >> example method defines how the cleanup should happen using the mechanism
>> >> provided by GTExamples).
>> >>
>> >> This meaning is different from the meaning of the <example> pragma used
>> >> through Pharo. There are currently 55 places that use this pragma inside
>> >> Pharo and most of them come from FastTable. As things will progress and more
>> >> libraries might use GTExamples, the situation can become confusing.
>> >>
>> >> To make things less confusing in the future, I would like to define the
>> >> meaning of the <example> to denote a method that returns an object without
>> >> having side effects. Would you agree with this?
>> >>
>> >> If yes, I would suggest the name of the new pragma that would replace
>> >> the existing one to include âscriptâ in the name. For example,
>> >> <sampleScript>.
>> >>
>> >> What do you think?
>> >>
>> >> Cheers,
>> >> Doru
>> >>
>> >>
>> >> --
>> >> www.tudorgirba.com
>> >> www.feenk.com
>> >>
>> >> "Reasonable is what we are accustomed with."
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> âSoftware has no shape. Actually, it has no one shape. It has many."
>>
>>
>
Dec. 19, 2016
[pharo-project/pharo-core]
by GitHub
Branch: refs/tags/60329
Home: https://github.com/pharo-project/pharo-core
Dec. 19, 2016
[pharo-project/pharo-core] c82973: 60329
by GitHub
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: c829737640c1e624505302e7878a4804d5bdcd7c
https://github.com/pharo-project/pharo-core/commit/c829737640c1e624505302e7…
Author: Jenkins Build Server <board(a)pharo-project.org>
Date: 2016-12-19 (Mon, 19 Dec 2016)
Changed paths:
A Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testCounterRollover.st
M Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testTwoDifferentGenerator.st
M Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testTwoSameGenerator.st
M Network-UUID.package/NeoUUIDGenerator.class/README.md
R Network-UUID.package/NeoUUIDGenerator.class/instance/accessing/placeFields_.st
M Network-UUID.package/NeoUUIDGenerator.class/instance/private/nextCounter16.st
M Network-UUID.package/NeoUUIDGenerator.class/instance/private/nextRandom16.st
A Network-UUID.package/NeoUUIDGenerator.class/instance/private/placeFields_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60328.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60329.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60328.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60329.st
M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Spec-Core.package/LabelModel.class/instance/initialization/defaultColor.st
R Spec-SelectEntity.package/ManifestSpecSelectEntity.class/README.md
R Spec-SelectEntity.package/ManifestSpecSelectEntity.class/definition.st
A System-Announcements.package/MethodAnnouncement.class/instance/accessing/classAffected.st
Log Message:
-----------
60329
19476 LabelModel default color needs to be theme text color (not hardcoded black)
https://pharo.fogbugz.com/f/cases/19476
19473 empty package Spec-SelectEntity can be unloaded
https://pharo.fogbugz.com/f/cases/19473
19453 NeoUUIDGenerator>>testTwoSameGenerator - intermittent CI failure
https://pharo.fogbugz.com/f/cases/19453
19471 classAffected method for MethodAnnouncement to be polymorphic with other system changes
https://pharo.fogbugz.com/f/cases/19471
http://files.pharo.org/image/60/60329.zip
Dec. 19, 2016
[ANN] TechTalks Jan and Feb
by Marcus Denker
Hi,
We have fixed the next two tech talks:
- 24 Jan 2017. Topic "Bloc/Brickâ
https://association.pharo.org/event-2405619
- 28 Feb 2017. Topic: âRefelectivity"
https://association.pharo.org/event-2407465
We added these as âEventsâ to the association website. People registered
there will get the information how to participate via mail (and a mail pointing
to the recording afterwards). This is therefor especially interesting for those
not following the mailing lists.
The idea is to have one each months, if you have ideas for topics (or want to
do some yourself), send a mail.
Blog post: http://pharo.org/news/techtalks17
Dec. 19, 2016
Problem with OSSubprocess / signals / heartbeat ?
by Mariano Martinez Peck
Hi guys,
There is a bug happening in OSSubprocess since quite some time which we
were never able to fix. What happens is that at certain point (after having
used OSSubprocess for a while), a simple command like the following would
"hang" Pharo:
OSSUnixSubprocess new
command: 'ls';
arguments: #();
redirectStdout;
runAndWaitOnExitDo: [ :process :outString | outString ]
Once the image does that, it keeps doing it in a 80% of the cases (so it is
easy enough to debug).
Guille Polito kept one of these images if someone can give us a hand. He
also proposed the great idea of using `strace` to see what was going on. He
(together with Pable Tesone) suspected that the heartbeat could be
interrupting the `clone()` function which is (I think) called internally by
the 'posix_spawn()' which is the one used by OSSubprocess.
When these images are "hung" they found at a infinitive loop like this:
[pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 17477] gettimeofday({1482152630, 593498}, NULL) = 0
[pid 17477] sigreturn() (mask []) = 120
[pid 17477] clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted)
[pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 17477] gettimeofday({1482152630, 600126}, NULL) = 0
[pid 17477] sigreturn() (mask []) = 120
[pid 17477] clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted)
[pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 17477] gettimeofday({1482152630, 606282}, NULL) = 0
[pid 17477] sigreturn() (mask []) = 120
[pid 17477] clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted)
[pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 17477] gettimeofday({1482152630, 612528}, NULL) = 0
[pid 17477] sigreturn() (mask []) = 120
[pid 17477] clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted)
[pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 17477] gettimeofday({1482152630, 618689}, NULL) = 0
[pid 17477] sigreturn() (mask []) = 120
[pid 17477] clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted)
[pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 17477] gettimeofday({1482152630, 624922}, NULL) = 0
[pid 17477] sigreturn() (mask []) = 120
[pid 17477] clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted)
[pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 17477] gettimeofday({1482152630, 631145}, NULL) = 0
[pid 17477] sigreturn() (mask []) = 120
[pid 17477] clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted)
[pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 17477] gettimeofday({1482152630, 637241}, NULL) = 0
[pid 17477] sigreturn() (mask []) = 120
[pid 17477] clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted)
[pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 17477] gettimeofday({1482152630, 643578}, NULL) = 0
[pid 17477] sigreturn() (mask []) = 120
[pid 17477] clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted)
[pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 17477] gettimeofday({1482152630, 649974}, NULL) = 0
[pid 17477] sigreturn() (mask []) = 120
[pid 17477] clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted)
[pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
As you can see, there is a SIGALARM involved. It also looks like the
`gettimeofday` is used by the heartbeat ? Could it be that someone the
heartbeat is interrupting the `clone()` ?
Guille also showed me the `strace` output with a regular / working image:
[pid 18647] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 18647] gettimeofday({1482152829, 481014}, NULL) = 0
[pid 18647] sigreturn() (mask []) = -1 EINTR (Interrupted system call)
[pid 18647] getitimer(ITIMER_REAL, {it_interval={0, 2000}, it_value={0,
1917}}) = 0
[pid 18647] recvmsg(3, 0xff7b0734, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 18647] select(4, [3], [], [3], {0, 1000}) = 0 (Timeout)
[pid 18647] getitimer(ITIMER_REAL, {it_interval={0, 2000}, it_value={0,
797}}) = 0
[pid 18647] recvmsg(3, 0xff7b0734, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 18647] select(4, [3], [], [3], {0, 1000}) = ? ERESTARTNOHAND (To be
restarted if no handler)
[pid 18647] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
Does anyone have any hint here?
Thanks in advance,
--
Mariano
http://marianopeck.wordpress.com
Dec. 19, 2016
Re: [Pharo-dev] a request to change the meaning of <example> pragma
by Tudor Girba
Hi,
Thanks for the message. There are several points under discussion.
I am not arguing now for introduction of GTExamples in the Pharo distribution. This is a discussion for the future.
But, I would like to distinguish between the current implementation and the goal. I believe "Example-driven development" is an interesting possibility to raise awareness for Pharo especially if we double the technology with a practice or method that will be in line with the idea of live programming. It might sound far fetched, but I really believe we can deliver on that.
GTExamples is a full first version (not a prototype). It certainly will not be the last. Regarding composition, in its simplest form, there is no composition, and for that you only need unary methods with <gtExample>. But, you do get the possibility of adding assertions and of specifying cleanups. So, relying on plain <gtExample> does not force you to use dependencies but you get extra advantages.
Nevertheless, as I said before, composition is a point on which we want to work more. I believe it should be possible to use static analysis to recover example dependencies without the need of injecting arguments based on pragmas, but it is not yet clear how this would work.
Cheers,
Doru
> On Dec 19, 2016, at 1:32 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote:
>
> Hi all
>
> In nautilus in Pharo 60 when you use
> <sampleInstance> you can get an inspector on the object returned by the method
>
> Example
>
> Die class >> d6
> <sampleInstance>
> ^ self faces: 6
>
> I started to use this pragma in all my libraries and I chose it to avoid conflict with <example> and others.
>
> I can change another time to make everybody happy. But I would like to avoid to have to change everything again because this is the second time. :)
> So let me know.
>
> Now as I already said in the past, I will veto the integration of Examples based on pragmas to compose them.
> I do not want to need a special tools to get example working. But you know all that.
>
>
> Stef
>
>
>
>
>
>
>
>
>
> On Sun, Dec 18, 2016 at 10:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> Hi,
>
> As you might know, a while ago we created GTExamples, a framework that supports both example-based live documentation and testing:
> http://gtoolkit.org/doc/Examples/examples.html
>
> GTExamples was part of the GTInspector for a while, but as it evolved, we pulled it out in a separate project. This separate project is not in Pharo anymore but it is part of the full GToolkit configuration (Pharo only ships the core of GToolkit). The idea of taking GTExamples out was to allow the community to have a more elaborate discussion about the role of examples in our environment.
>
> I have invited you to join that conversation, but it did not take off. I understand that perhaps the topic does not look appealing at this moment.
>
> We will certainly continue to evolve GTExamples both on the semantics level of the dependency constructs and on the integration with tools. Our goal is to enable a new practice that I would like to call Example-Guilded Development (or Example-Driven Development), and position Pharo to be the only platform on which someone can do that. But, that is our goal, and does not have to be the same with other peopleâs goal.
>
> Right now, GTExamples relies on the <gtExample> pragma to denote a method that returns an object that exemplifies something. Executing this method as an example should have no side-effects (either because the method itself does not have a side-effect, or because the example method defines how the cleanup should happen using the mechanism provided by GTExamples).
>
> This meaning is different from the meaning of the <example> pragma used through Pharo. There are currently 55 places that use this pragma inside Pharo and most of them come from FastTable. As things will progress and more libraries might use GTExamples, the situation can become confusing.
>
> To make things less confusing in the future, I would like to define the meaning of the <example> to denote a method that returns an object without having side effects. Would you agree with this?
>
> If yes, I would suggest the name of the new pragma that would replace the existing one to include âscriptâ in the name. For example, <sampleScript>.
>
> What do you think?
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Reasonable is what we are accustomed with."
>
>
>
--
www.tudorgirba.com
www.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Dec. 19, 2016