- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.3] #13287

by Lukas Renggli

Great, thank you for the quick fix. On Monday, 18 July 2011, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > 13287 > ----- > > - Issue 4528: Â Exception on:fork: enhancement. Thanks Igor Stasenko and Lukas Renggli for the idea. > > - Issue 4529: Â Announcement delivery breaks if last subscriber is curtailed. Thanks Henrik Johanssen. > -- Lukas Renggli www.lukas-renggli.ch

July 18, 2011

Re: [Pharo-project] about privShrinking

by Pavel Krivanek

On Mon, Jul 18, 2011 at 7:54 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 18 July 2011 18:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On Jul 18, 2011, at 6:36 PM, Pavel Krivanek wrote: >> >>> ok, >>> >>> let me know if you will remove or add some package because it requires >>> manual modification of scripts. >>> >>> What is the current right way to create new Transcript object? :-) >> >> no idea :) >> > See > ThreadSafeTranscript install. Thank you, http://code.google.com/p/pharo/issues/detail?id=4533 -- Pavel > >>> >>> -- Pavel >>> >>> >>> On Mon, Jul 18, 2011 at 4:34 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Hi pavel >>>> >>>> I removed the ref to RecentMessageSet since we will remove it. >>>> And I noticed that there was a reference to TranscriptModel, so may be we should remove it since I'm not sure that we will keep it. Or may be this is a good >>>> idea of have a model :) >>>> >>>> Â Â Â Â Smalltalk globals at: #Transcript put: TranscriptModel new. >>>> >>>> Stef >>>> >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

July 18, 2011

Re: [Pharo-project] about privShrinking

by Igor Stasenko

On 18 July 2011 18:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jul 18, 2011, at 6:36 PM, Pavel Krivanek wrote: > >> ok, >> >> let me know if you will remove or add some package because it requires >> manual modification of scripts. >> >> What is the current right way to create new Transcript object? :-) > > no idea :) > See ThreadSafeTranscript install. >> >> -- Pavel >> >> >> On Mon, Jul 18, 2011 at 4:34 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Hi pavel >>> >>> I removed the ref to RecentMessageSet since we will remove it. >>> And I noticed that there was a reference to TranscriptModel, so may be we should remove it since I'm not sure that we will keep it. Or may be this is a good >>> idea of have a model :) >>> >>> Â Â Â Â Smalltalk globals at: #Transcript put: TranscriptModel new. >>> >>> Stef >>> >> > > > -- Best regards, Igor Stasenko AKA sig.

July 18, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by Igor Stasenko

On 18 July 2011 19:32, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > You could - however, unlike exception handling, process-local variables are not part of ANSI. > Which means it's a safer choice for Seaside from a portability POV. > Yes, but seaside using grease layer to deal with dialect-specific stuff. So it is perfectly reasonable to use more effective feature(s) if they are available. > Speaking of which, referring to my last post when Danie raised the issue, is there any reason we don't copy the process environment when forking? > as any feature it needs to have a real use case. Because if its not used by anything, we don't have feedback and it even makes little sense to support it or change it. Without real use case i cannot clearly say, if environment should be inherited when you forking or not. If we draw a parallel with OS process - then yes, in OSes (at least unix ones) they inherit environment and file handles etc , when forking. But if we draw a parallel to threads, the thread-specific storage is clean for new thread. So i really don't know which approach is better without looking at real use case. Unfortunately, we don't have anything which using it now :( > Cheers, > Henry > > On 18. juli 2011, at 16:47, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> For instance, in Seaside (if i remember correctly) it creates a >> separate process for handling request. >> And so, for dynamic variables you can use a process-specific storage , >> provided by >> Process>>environmentAt: and environmentAt:put:, rather than using >> exceptions to access dynamic variable values. >> Like that, you don't need to use exceptions and moreover it will work >> much faster, because unwinding stack each time you accessing the state >> is costly! >> > > -- Best regards, Igor Stasenko AKA sig.

July 18, 2011

Re: [Pharo-project] fun bug: fileouting method with a $!, produces $!!

by Levente Uzonyi

On Mon, 18 Jul 2011, StÃ©phane Ducasse wrote: > > >> Why do you say so ? >> I can fileOut, then fileIn without a problem. >> To me, this is not a bug. This is a feature. >> Source ! are doubled so as not to be confused with chunk separators, it's an escaping sequence like doubles quotes in String >> >> 'here''s another example which is not a bug' > > this is not because people were not using a decent syntax to fileout and that after they hacked the system that this is not a bug. > If you save a method and once it is saved you cannot load it back then what is the point to save it. > > Seriously this is not the same than with double quote. > > Else it means that you cannot/should not use $! in Smalltalk method. And I read most of the spec and books on smalltalk > and nobody ever mentioned that. Here this is just that this is doing the wrong behavior. You can use $! in methods, but you can't use them in preambles. Also you shouldn't use any non-ascii (charcode > 127) characters in the preamble if you want to read it back again. If you don't trust me, then just check your image, I'm sure it has a few hundred methods containing the ! character. Levente > > Imagine that we save the code using the coral syntax then what we would not use [] anymore in method? > > Stef > >> >> Nicolas >> >> 2011/7/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Yes I know. >> To me, saving a method should make sure that we can reload it and this is not the case. >> So to me this is a bug. >> >> try to fileout >> >> getPreambleFrom: aFileStream at: position >> | writeStream | >> writeStream := String new writeStream. >> position to: 0 by: -1 do: [ :p | >> | c | >> aFileStream position: p. >> c := aFileStream basicNext. >> c == $! >> ifTrue: [^ writeStream contents reversed] >> ifFalse: [writeStream nextPut: c]] >> >> >> :) >> >> I do not see why the system should not save it correctly even if !! is used as a chunk separator. >> >> Stef >> >> >> On Jul 18, 2011, at 4:55 PM, Lukas Renggli wrote: >> >>> !! Is the escaping of a single ! (like '' is the escaping of ' in a >>> string), because the ! Is used to separate junks. >>> >>> Lukas >>> >>> On Monday, 18 July 2011, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>>> Hi >>>> >>>> with veronica we found a fun bug. >>>> If you have a method with a $! and you file it out. you get $!! in the fileouted file. >>>> >>>> http://code.google.com/p/pharo/issues/detail?id=4531 >>>> >>>> Stef >>>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> > > >

July 18, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by Henrik Johansen

You could - however, unlike exception handling, process-local variables are not part of ANSI. Which means it's a safer choice for Seaside from a portability POV. Speaking of which, referring to my last post when Danie raised the issue, is there any reason we don't copy the process environment when forking? Cheers, Henry On 18. juli 2011, at 16:47, Igor Stasenko <siguctua(a)gmail.com> wrote: > For instance, in Seaside (if i remember correctly) it creates a > separate process for handling request. > And so, for dynamic variables you can use a process-specific storage , > provided by > Process>>environmentAt: and environmentAt:put:, rather than using > exceptions to access dynamic variable values. > Like that, you don't need to use exceptions and moreover it will work > much faster, because unwinding stack each time you accessing the state > is costly! >

July 18, 2011

Re: [Pharo-project] Stubbing class-side methods

by Igor Stasenko

On 18 July 2011 18:52, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Carlo wrote: >> >> Personally when I come across cases like this I either break the (usually >> public) method into a public and internal method, the internal method >> contains the date so we can test the edge cases. >> > > The thing I don't like about this is that I often load a package I've never > used before and go to the tests, which I believe should be examples of how > to use the class, yet I find tests that are not from the POV of a user and > give me less direction than I'd like. With this method, the > sin-to-make-it-testable is on display in the action step of the test instead > of hidden away in the setup as it could be with a stub. > > > Carlo wrote: >> >> Another option which you've probably decided against is to delegate to >> your current class or a Registry to ask for the class with which to use >> for date related tasks, a kind of factory in a way. >> > Yes, this is the best way I can think of, but it feels like a hack. > > > Carlo wrote: >> >> I personally feel Pharo is moving into a more pluggable direction with the >> work on the environment (Smalltalk environment) where we can provide our >> own environment for a particular context >> > That would be awesome! > This looks like a relevant: http://code.google.com/p/pharo/issues/detail?id=4485 > Thanks. > Sean > > -- > View this message in context: http://forum.world.st/Stubbing-class-side-methods-tp3674065p3675843.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

July 18, 2011

Re: [Pharo-project] Stubbing class-side methods

by Sean P. DeNigris

Carlo wrote: > > Personally when I come across cases like this I either break the (usually > public) method into a public and internal method, the internal method > contains the date so we can test the edge cases. > The thing I don't like about this is that I often load a package I've never used before and go to the tests, which I believe should be examples of how to use the class, yet I find tests that are not from the POV of a user and give me less direction than I'd like. With this method, the sin-to-make-it-testable is on display in the action step of the test instead of hidden away in the setup as it could be with a stub. Carlo wrote: > > Another option which you've probably decided against is to delegate to > your current class or a Registry to ask for the class with which to use > for date related tasks, a kind of factory in a way. > Yes, this is the best way I can think of, but it feels like a hack. Carlo wrote: > > I personally feel Pharo is moving into a more pluggable direction with the > work on the environment (Smalltalk environment) where we can provide our > own environment for a particular context > That would be awesome! Thanks. Sean -- View this message in context: http://forum.world.st/Stubbing-class-side-methods-tp3674065p3675843.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 18, 2011

Re: [Pharo-project] Stubbing class-side methods

by Sean P. DeNigris

Michael Roberts-2 wrote: > > is MyClass a domain class > Yes -- View this message in context: http://forum.world.st/Stubbing-class-side-methods-tp3674065p3675827.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 18, 2011

Re: [Pharo-project] about privShrinking

by StÃ©phane Ducasse

On Jul 18, 2011, at 6:36 PM, Pavel Krivanek wrote: > ok, > > let me know if you will remove or add some package because it requires > manual modification of scripts. > > What is the current right way to create new Transcript object? :-) no idea :) > > -- Pavel > > > On Mon, Jul 18, 2011 at 4:34 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi pavel >> >> I removed the ref to RecentMessageSet since we will remove it. >> And I noticed that there was a reference to TranscriptModel, so may be we should remove it since I'm not sure that we will keep it. Or may be this is a good >> idea of have a model :) >> >> Smalltalk globals at: #Transcript put: TranscriptModel new. >> >> Stef >> >

July 18, 2011