On Thu, Jun 14, 2012 at 2:34 AM, Frank Shearar
<frank.shearar@gmail.com> wrote:
On 13 June 2012 23:15, Eliot Miranda <eliot.miranda@gmail.com> wrote:
>
>
> On Wed, Jun 13, 2012 at 7:35 AM, Frank Shearar <frank.shearar@gmail.com>
> wrote:
>>
>> On 2 June 2012 09:28, Stefan Marr <smalltalk@stefan-marr.de> wrote:
>> > Hi Sean:
>> >
>> > On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote:
>> >
>> >> During the process, I noticed that the Blue Book specifies that #fork
>> >> returns the block itself (pg. 252), while in Pharo it returns the
>> >> process
>> >> (see #testFork in the slice). Should our implementation be changed to
>> >> match�the Blue Book?
Sorry to reply so late. �I think the blue book definition is broken. �fork should answer the process. �It has been changed to do so in VisualWorks for a long time. �I think the blue book definition is simply a bug. �It can easily be implemented in the caller using yourself, i.e.
� � �[...] fork; yourself
answers the block if one needs it.
>> >
>> > Why would it be desirable to have the block?
>> > How would you obtain the process object after your change?
>> >
>> > Having the process directly is useful to do fork/join style operations.
>>
>> How do you #join Processes? I can't see anything in Process' protocol
>> for doing so. so what am I missing?
>
>
> Nothing. �Theres no support for join. �You have to roll your own.
OK, that's what I thought. Stefan's comment intrigued me.
It would be kind've handy to be able to say - even though we don't use
native threads - something like this:
(0..10).map {|i|
� �Thread.new { sleep(1); i }
}.map {|t| t.value}
only in a decent language:
((0 to: 10)
� �collect: [:i | [(Delay forSeconds: 1) wait. i] fork])
� � �collect: [:p | p value].
frank
>>
>>
>> frank
>>
>> > Best regards
>> > Stefan
>> >
>> > --
>> > Stefan Marr
>> > Software Languages Lab
>> > Vrije Universiteit Brussel
>> > Pleinlaan 2 / B-1050 Brussels / Belgium
>> > http://soft.vub.ac.be/~smarr
>> > Phone: +32 2 629 2974
>> > Fax: � +32 2 629 3525
>> >
>> >
>>
>
>
>
> --
> best,
> Eliot
>