March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] TreadSafeTranscript proposal

by Igor Stasenko

Oh, TrascriptStream already uses AccessSema.. So, it should wrap a #changed: with it: changed: param self semaphore critical: [ super changed: param ] 2009/3/29 Igor Stasenko <siguctua(a)gmail.com>: > 2009/3/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Igor >> your change is already in pharo :) >> since months :) > > Yes, but method i changes is not related in particular to Transcript. > The change applies to all users of PluggableTextMorph. > > But as for thread-safe transcript, you need to be careful when you > sending #changed message (each time you printing something - it sends > this message), because it using a notification mechanism to tell > listeners that there is something changed. > Maybe its worth adding #synchronousChanged method to Object > which guards from entry by multiple threads(processes) simueltaneously. > >> Stef >> On Mar 29, 2009, at 6:48 PM, Igor Stasenko wrote: >> >>> 2009/3/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> did you check what the semaphore critical section is protecting? >>>> Â Â Â Â cr, tab, nextPutAll: and more and not protected. >>>> >>>> then transcriptStream inherits from stream which is not threadsafe, >>>> so >>>> everything can happen. >>>> I think that having a real thread safe output is a must. >>>> >>> >>> as well as thread-safe updating. >>> Btw, take a look at the http://bugs.squeak.org/view.php?id=7033 >>> >>> The way how Transcript window updates itself is not safe. It should >>> use deferUIMessage to update itself using regular world cycle. >>> >>>> Stef >>>> >>>> On Mar 29, 2009, at 5:55 PM, Keith Hodges wrote: >>>> >>>>> StÃ©phane Ducasse wrote: >>>>>> Hi >>>>>> >>>>>> I would really like that we get a threadSafeTranscript so I coded >>>>>> one. >>>>>> If you can comment this would help me. >>>>>> >>>>>> Stef >>>>> What is the difference tot he exisitng one, it has an access >>>>> semaphore too. >>>>> >>>>> Keith >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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. > -- Best regards, Igor Stasenko AKA sig.

March 29, 2009

Re: [Pharo-project] TreadSafeTranscript proposal

by Igor Stasenko

2009/3/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Igor > your change is already in pharo :) > since months :) Yes, but method i changes is not related in particular to Transcript. The change applies to all users of PluggableTextMorph. But as for thread-safe transcript, you need to be careful when you sending #changed message (each time you printing something - it sends this message), because it using a notification mechanism to tell listeners that there is something changed. Maybe its worth adding #synchronousChanged method to Object which guards from entry by multiple threads(processes) simueltaneously. > Stef > On Mar 29, 2009, at 6:48 PM, Igor Stasenko wrote: > >> 2009/3/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> did you check what the semaphore critical section is protecting? >>> Â Â Â Â cr, tab, nextPutAll: and more and not protected. >>> >>> then transcriptStream inherits from stream which is not threadsafe, >>> so >>> everything can happen. >>> I think that having a real thread safe output is a must. >>> >> >> as well as thread-safe updating. >> Btw, take a look at the http://bugs.squeak.org/view.php?id=7033 >> >> The way how Transcript window updates itself is not safe. It should >> use deferUIMessage to update itself using regular world cycle. >> >>> Stef >>> >>> On Mar 29, 2009, at 5:55 PM, Keith Hodges wrote: >>> >>>> StÃ©phane Ducasse wrote: >>>>> Hi >>>>> >>>>> I would really like that we get a threadSafeTranscript so I coded >>>>> one. >>>>> If you can comment this would help me. >>>>> >>>>> Stef >>>> What is the difference tot he exisitng one, it has an access >>>> semaphore too. >>>> >>>> Keith >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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.

March 29, 2009

Re: [Pharo-project] TreadSafeTranscript proposal

by StÃ©phane Ducasse

Igor your change is already in pharo :) since months :) Stef On Mar 29, 2009, at 6:48 PM, Igor Stasenko wrote: > 2009/3/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> did you check what the semaphore critical section is protecting? >> cr, tab, nextPutAll: and more and not protected. >> >> then transcriptStream inherits from stream which is not threadsafe, >> so >> everything can happen. >> I think that having a real thread safe output is a must. >> > > as well as thread-safe updating. > Btw, take a look at the http://bugs.squeak.org/view.php?id=7033 > > The way how Transcript window updates itself is not safe. It should > use deferUIMessage to update itself using regular world cycle. > >> Stef >> >> On Mar 29, 2009, at 5:55 PM, Keith Hodges wrote: >> >>> StÃ©phane Ducasse wrote: >>>> Hi >>>> >>>> I would really like that we get a threadSafeTranscript so I coded >>>> one. >>>> If you can comment this would help me. >>>> >>>> Stef >>> What is the difference tot he exisitng one, it has an access >>> semaphore too. >>> >>> Keith >>> >>> >>> >>> _______________________________________________ >>> 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 >

March 29, 2009

Re: [Pharo-project] TreadSafeTranscript proposal

by Igor Stasenko

2009/3/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > did you check what the semaphore critical section is protecting? > Â Â Â Â cr, tab, nextPutAll: and more and not protected. > > then transcriptStream inherits from stream which is not threadsafe, so > everything can happen. > I think that having a real thread safe output is a must. > as well as thread-safe updating. Btw, take a look at the http://bugs.squeak.org/view.php?id=7033 The way how Transcript window updates itself is not safe. It should use deferUIMessage to update itself using regular world cycle. > Stef > > On Mar 29, 2009, at 5:55 PM, Keith Hodges wrote: > >> StÃ©phane Ducasse wrote: >>> Hi >>> >>> I would really like that we get a threadSafeTranscript so I coded >>> one. >>> If you can comment this would help me. >>> >>> Stef >> What is the difference tot he exisitng one, it has an access >> semaphore too. >> >> Keith >> >> >> >> _______________________________________________ >> 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.

March 29, 2009

Re: [Pharo-project] TreadSafeTranscript proposal

by StÃ©phane Ducasse

did you check what the semaphore critical section is protecting? cr, tab, nextPutAll: and more and not protected. then transcriptStream inherits from stream which is not threadsafe, so everything can happen. I think that having a real thread safe output is a must. Stef On Mar 29, 2009, at 5:55 PM, Keith Hodges wrote: > StÃ©phane Ducasse wrote: >> Hi >> >> I would really like that we get a threadSafeTranscript so I coded >> one. >> If you can comment this would help me. >> >> Stef > What is the difference tot he exisitng one, it has an access > semaphore too. > > Keith > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 29, 2009

Re: [Pharo-project] Thread problem

by StÃ©phane Ducasse

Igor I m not surprised of the order. I know that transcript is totally unsafe :) Now this is probably the unclosure stuff that bites me... :) ...stef jumping to pharo and trying ... stef back | tt | Smalltalk at: #STranscript ifAbsent: [self installThreadSafeAsSTranscript]. tt := (Smalltalk at: #STranscript). tt open. [1 to: 10 do: [:x | tt nextPutAll: x printString; nextPutAll: '*'. Processor yield ] fixTemps. tt flush ] fork. [100 to: 110 do: [:i | tt nextPutAll: i printString; nextPutAll: '-'. Processor yield ] fixTemps. tt flush ] fork. 1*100-2*101-3*102-4*103-5*104-6*105-7*106-8*107-9*108-10*109-110- So I want closure..... definitively. Stef On Mar 29, 2009, at 4:54 PM, Igor Stasenko wrote: > 2009/3/29 Igor Stasenko <siguctua(a)gmail.com>: >> 2009/3/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Hi all >>> >>> I'm working on a threadSafeTranscript and I could not understand why >>> the following code >>> does not print something else than >>> >>> 1*100-102-103-104-105-106-107-108-109-110- >>> >>> |tt| >>> tt := Transcript. >>> [1 to: 10 do: [:i | tt show: i printString; show: '*'. >>> Processor yield ]. >>> tt flush ] fork. >>> [100 to: 110 do: [:i | tt show: i printString; show: '-'. >>> Processor yield ]. >>> tt flush ] fork. >>> >> >> What you expecting from it? >> If you imagine that Processes running in parallel, then numbers can >> be >> in any order , as well as * and - characters. >> Or you mean, that it eating 2-10 numbers which should be printed? >> In this case, the source of inconsistency could be the #flush method. >> But its hard to say, without looking at source code. >> > > oh, and if you running it in image, without Eliot's closures, i'd > recommend to use separate iterator for cycles, because it might be the > case that parser using the same temp slot for 'i' temp in both blocks. > >>> Stef >>> >>> _______________________________________________ >>> 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. >> > > > > -- > 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 >

March 29, 2009

Re: [Pharo-project] TreadSafeTranscript proposal

by Keith Hodges

StÃ©phane Ducasse wrote: > Hi > > I would really like that we get a threadSafeTranscript so I coded one. > If you can comment this would help me. > > Stef What is the difference tot he exisitng one, it has an access semaphore too. Keith

March 29, 2009

Re: [Pharo-project] Namespaces for Squeak

by Igor Stasenko

2009/3/29 Igor Stasenko <siguctua(a)gmail.com>: > 2009/3/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I think class GUID is orthogonal to namespace. >> I still would be able to argue really why GUID for classes are good (I >> mean really scientifically). >> > > Let argue then :) > A GUID , as for me, is a simple and logical extension of object > identity concept. > An object identity used heavily in many different scenarios in > smalltalk. A GUID also enables to identify objects not only for single > image, but also beyond it. > From 'scientific' point of view, there is no problems, as to me - for > computer its no difference what you using to identify objects - by > name or by GUID. > But for humans, this is a problem, because this no longer true, and > name losing its role as a way to identify objects. > This is where namespaces can get in play and help. > > P.S. i also thinking, that GUID could be made as a special subclass of > Symbol. GUIDs are unique and immutable - same characteristics for > defining a Symbol. > In Squeak its an UUID class. There are a certain set of applications who using them. And making them symbols would speedup indexing a lot, since as with symbols, you don't need to compare object contents, just use identity comparison #== >> Stef >> >> On Mar 28, 2009, at 9:14 PM, Markus Fritsche wrote: >> >>> StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> if you want to have a modular system then sharing a falt space is not >>>> ideal. >>> >>>>> Which walls? Ambiguity? >>> >>> I just think if the approach of Craig, using something like GUIDs >>> during >>> Class creation, and then referring to those GUIDs would be more >>> practical >>> than to use namespaces. >>> >>> Namespaces proved to be a pain in the ass with several >>> implementations, as >>> your "import *" example shows. We need to circumvent that... >>> >>> >>> >>> _______________________________________________ >>> 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. > -- Best regards, Igor Stasenko AKA sig.

March 29, 2009

Re: [Pharo-project] Namespaces for Squeak

by Igor Stasenko

2009/3/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I think class GUID is orthogonal to namespace. > I still would be able to argue really why GUID for classes are good (I > mean really scientifically). > Let argue then :) A GUID , as for me, is a simple and logical extension of object identity concept. An object identity used heavily in many different scenarios in smalltalk. A GUID also enables to identify objects not only for single image, but also beyond it. >From 'scientific' point of view, there is no problems, as to me - for computer its no difference what you using to identify objects - by name or by GUID. But for humans, this is a problem, because this no longer true, and name losing its role as a way to identify objects. This is where namespaces can get in play and help. P.S. i also thinking, that GUID could be made as a special subclass of Symbol. GUIDs are unique and immutable - same characteristics for defining a Symbol. > Stef > > On Mar 28, 2009, at 9:14 PM, Markus Fritsche wrote: > >> StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> if you want to have a modular system then sharing a falt space is not >>> ideal. >> >>>> Which walls? Ambiguity? >> >> I just think if the approach of Craig, using something like GUIDs >> during >> Class creation, and then referring to those GUIDs would be more >> practical >> than to use namespaces. >> >> Namespaces proved to be a pain in the ass with several >> implementations, as >> your "import *" example shows. We need to circumvent that... >> >> >> >> _______________________________________________ >> 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.

March 29, 2009

Re: [Pharo-project] Thread problem

by Igor Stasenko

2009/3/29 Igor Stasenko <siguctua(a)gmail.com>: > 2009/3/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi all >> >> I'm working on a threadSafeTranscript and I could not understand why >> the following code >> does not print something else than >> >> Â Â Â Â 1*100-102-103-104-105-106-107-108-109-110- >> >> |tt| >> tt := Transcript. >> [1 to: 10 do: [:i | tt show: i printString; show: '*'. >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Processor yield ]. >> Â Â Â Â tt flush Â Â Â Â ] Â fork. >> [100 to: 110 do: [:i | tt show: i printString; show: '-'. >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Processor yield Â ]. >> Â Â Â Â tt flush Â Â Â Â ] fork. >> > > What you expecting from it? > If you imagine that Processes running in parallel, then numbers can be > in any order , as well as * and - characters. > Or you mean, that it eating 2-10 numbers which should be printed? > In this case, the source of inconsistency could be the #flush method. > But its hard to say, without looking at source code. > oh, and if you running it in image, without Eliot's closures, i'd recommend to use separate iterator for cycles, because it might be the case that parser using the same temp slot for 'i' temp in both blocks. >> Stef >> >> _______________________________________________ >> 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. > -- Best regards, Igor Stasenko AKA sig.

March 29, 2009