November 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] how to know if an image is resuming or not

by Igor Stasenko

On 9 November 2010 00:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi guys > > I'm too dead to think more but I want to do the following > > Â Â Â Â save the current image > Â Â Â Â Â Â Â Â (I used saveSession) > Â Â Â Â and only when not resuming I want to save another image. > > Is there a way to know if an image is resuming (if the pc pointer just go reactivated - that the image was closed and reopened). > > naively I was doing > > saveImageForRunningTests > > Â Â Â Â | comment commentQuoted st | > Â Â Â Â SmalltalkImage current saveSession. > Â Â Â Â Â Â Â Â "now you can reopen prior to publishing to fix :)" > Â Â Â Â self saveAsImageAsTestImage. > > Â Â Â Â self inform: 'Now you can use this image named ''Test'' to run the tests and come back to fix problems in the previous one and eventually freeze it by selecting the next step, in either one.' > > and of course when I reopened the save session I reperformed the "self saveAsImageAsTestImage." > Now I could use startUp:.... > Or I could simply change my process but I wanted to know... I'm too dead now. > what about using some variable, like: RunTests := true. self saveimage. RunTests := false. self saveImage. and then in startUp: startUp: resuming ( resuming and: [ RunTests] ) ifTrue: [ self runTests ] ? > Stef > > > -- Best regards, Igor Stasenko AKA sig.

Nov. 8, 2010

[Pharo-project] how to know if an image is resuming or not

by StÃ©phane Ducasse

hi guys I'm too dead to think more but I want to do the following save the current image (I used saveSession) and only when not resuming I want to save another image. Is there a way to know if an image is resuming (if the pc pointer just go reactivated - that the image was closed and reopened). naively I was doing saveImageForRunningTests | comment commentQuoted st | SmalltalkImage current saveSession. "now you can reopen prior to publishing to fix :)" self saveAsImageAsTestImage. self inform: 'Now you can use this image named ''Test'' to run the tests and come back to fix problems in the previous one and eventually freeze it by selecting the next step, in either one.' and of course when I reopened the save session I reperformed the "self saveAsImageAsTestImage." Now I could use startUp:.... Or I could simply change my process but I wanted to know... I'm too dead now. Stef

Nov. 8, 2010

Re: [Pharo-project] About SimpleMorphic

by Denis Kudriashov

2010/11/8 Igor Stasenko <siguctua(a)gmail.com> > On 7 November 2010 22:38, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > > Sig, > > > > I disagree; the layout policy should arrange the morphs it controls. To > do otherwise demands that the morphs be able to cope with any type of layout > one might want. The various algorithms have to go somewhere; they might as > well go in the layouts. > > > > Some layouts, like table, indeed requiring a cooperation between > container morph and its submorphs. > > But still, i think that it should be based on a simple things: > - morph should have a single layout command: lay within certain > bounds. It doesn't matters where these bounds came from or how they > are calculated. > > Then child morph could decide for itself how to lay within given > bounds (like fill whole area or align to botton or top etc etc), and > avoid querying parent morph or layout policy/whatever to determine own > bounds, unless, of course it also having submorphs and own layout > policy. > > So, if parent morph having no layout policy, it will simply pass its > own bounds to submoprhs. > And if parent having , say table layout policy, then it will calculate > table cells and pass each cell bounds to each submorph for given cell. and yes, implementing this stuff is always harder than just talking about it > :) > I remember interesting design for layout logic in newspeak Brazil framefork. http://blog.3plus4.org/2008/11/23/brazil-example-a-classic-smalltalk-browse… See part about "area" concept

Nov. 8, 2010

Re: [Pharo-project] about consistency between hex implementations

by StÃ©phane Ducasse

On Nov 8, 2010, at 10:39 PM, Eliot Miranda wrote: > > > On Mon, Nov 8, 2010 at 1:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> > >> > >> in pharo we have > >> hex that always returns 16rXX > >> > >> $A hex '16r41' > >> > >> 20 hex '16r14' > >> > >> Even if this is regular this is not really nice. In fact this ones should be fixed to return numbers and not strings. > >> I do not understand why hex should return a string. > > > > And how? Integer >> #hex would be ^self and Character >> #hex would be ^value ? > > It looks like I proposed something stupid :) you are right we cannot generate 16r41 as a number. I was sure that we could do that so that I do not even check. > This is strange that we cannot generate these numbers. This is strange to have things that we can only parse but not generate other than via strings. > We could have something like Integer value: 65 base: 16 that returns 16r41 and not 65 and not '16r41' > When I type 16r41 my mental perception is not that this is a string but this is a number I'm manipulating. > Like #foo, true,.... I do not think in terms of strings just objects. Now for true, #foo this is simpler because they only have one representation. > Now the fact that several objects denotes the same elementary element is just an accident. So this was fun that I could think that :). > > > Now my post had two topics and I would like at least to get the other fixed: consistency. > > $A hex '16r41' > > 20 hex '16r14' > > $A printStringHex > '41' > 20 printStringHex > '14' > > +1. The above definitions of hex are what VMMaker wants. Ok I will send you a cs for squeak! Now I'm fighting with MC on something else (instead of writing a nice letter for a Phd evaluation :) > > Stef >

Nov. 8, 2010

Re: [Pharo-project] about tracker activities

by StÃ©phane Ducasse

Thanks! On Nov 8, 2010, at 10:53 PM, Stefan Marr wrote: > Hi: > > On 08 Nov 2010, at 22:06, StÃ©phane Ducasse wrote: > >> I think that we are not looking to the issues because we do not know that they have been entered. > Bye the way, your issue reporting template needs an update. It contains outdated information, i.e., that you are currently working on Pharo 1.1. > > 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 > >

Nov. 8, 2010

Re: [Pharo-project] about consistency between hex implementations

by Dave Mason

On Nov 8, 2010, at 16:22, StÃ©phane Ducasse wrote: > This is strange that we cannot generate these numbers. This is strange to have things that we can only parse but not generate other than via strings. > We could have something like Integer value: 65 base: 16 that returns 16r41 and not 65 and not '16r41' > When I type 16r41 my mental perception is not that this is a string but this is a number I'm manipulating. 16r41 is a *representation* of a number, just as 10r65, 65, 2r1000001 are... and all representations of the same number. The convention is that when numbers are displayed to use, they are in decimal, but presumably that is just an artifact from the number of fingers we have. > Now the fact that several objects denotes the same elementary element is just an accident. So this was fun that I could think that :). No, they're all the same object: 10r65 > Now my post had two topics and I would like at least to get the other fixed: consistency. > > $A hex '16r41' > > 20 hex '16r14' > > $A printStringHex > '41' > 20 printStringHex > '14' I think those are exactly the right definitions. Use: '16r', 20 printStringHex if that's what you want.... otherwise, if you want to string multiple hex strings together you have to remove the 16r from each of them first. e.g. '16r', 20 printStringHex, $A printStringHex ../Dave

Nov. 8, 2010

Re: [Pharo-project] about tracker activities

by Stefan Marr

Hi: On 08 Nov 2010, at 22:06, StÃ©phane Ducasse wrote: > I think that we are not looking to the issues because we do not know that they have been entered. Bye the way, your issue reporting template needs an update. It contains outdated information, i.e., that you are currently working on Pharo 1.1. 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

Nov. 8, 2010

Re: [Pharo-project] about consistency between hex implementations

by Eliot Miranda

On Mon, Nov 8, 2010 at 1:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > >> > >> > >> in pharo we have > >> hex that always returns 16rXX > >> > >> $A hex '16r41' > >> > >> 20 hex '16r14' > >> > >> Even if this is regular this is not really nice. In fact this ones > should be fixed to return numbers and not strings. > >> I do not understand why hex should return a string. > > > > And how? Integer >> #hex would be ^self and Character >> #hex would be > ^value ? > > It looks like I proposed something stupid :) you are right we cannot > generate 16r41 as a number. I was sure that we could do that so that I do > not even check. > This is strange that we cannot generate these numbers. This is strange to > have things that we can only parse but not generate other than via strings. > We could have something like Integer value: 65 base: 16 that returns 16r41 > and not 65 and not '16r41' > When I type 16r41 my mental perception is not that this is a string but > this is a number I'm manipulating. > Like #foo, true,.... I do not think in terms of strings just objects. Now > for true, #foo this is simpler because they only have one representation. > Now the fact that several objects denotes the same elementary element is > just an accident. So this was fun that I could think that :). > > > Now my post had two topics and I would like at least to get the other > fixed: consistency. > > $A hex '16r41' > > 20 hex '16r14' > > $A printStringHex > '41' > 20 printStringHex > '14' > +1. The above definitions of hex are what VMMaker wants. > Stef >

Nov. 8, 2010

Re: [Pharo-project] about consistency between hex implementations

by StÃ©phane Ducasse

>> >> >> in pharo we have >> hex that always returns 16rXX >> >> $A hex '16r41' >> >> 20 hex '16r14' >> >> Even if this is regular this is not really nice. In fact this ones should be fixed to return numbers and not strings. >> I do not understand why hex should return a string. > > And how? Integer >> #hex would be ^self and Character >> #hex would be ^value ? It looks like I proposed something stupid :) you are right we cannot generate 16r41 as a number. I was sure that we could do that so that I do not even check. This is strange that we cannot generate these numbers. This is strange to have things that we can only parse but not generate other than via strings. We could have something like Integer value: 65 base: 16 that returns 16r41 and not 65 and not '16r41' When I type 16r41 my mental perception is not that this is a string but this is a number I'm manipulating. Like #foo, true,.... I do not think in terms of strings just objects. Now for true, #foo this is simpler because they only have one representation. Now the fact that several objects denotes the same elementary element is just an accident. So this was fun that I could think that :). Now my post had two topics and I would like at least to get the other fixed: consistency. $A hex '16r41' 20 hex '16r14' $A printStringHex '41' 20 printStringHex '14' Stef

Nov. 8, 2010

Re: [Pharo-project] about tracker activities

by Igor Stasenko

On 8 November 2010 23:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I think that we are not looking to the issues because we do not know that they have been entered. > In the google web site we can special a mailing-list > > Â Â Â Â Activity notifications > Â Â Â Â Email notifications of issue tracker activity will automatically be sent to the following email address. > > Â Â Â Â All issue changes: > > Â Â Â Â Notifications will be sent from: pharo(a)googlecode.com > Â Â Â Â You may need to add this address as an allowed poster to your mailing list. > Â Â Â Â If using Google Groups, add the address directly with no email delivery. > > And I would like to activate that. I hope that this is ok for you. People not interested can just add a filter to discard > those mails. Marcus do you have an idea how we can make sure that the mails sent are not blocked? > +1 > Stef > > > -- Best regards, Igor Stasenko AKA sig.

Nov. 8, 2010