- Pharo-dev - lists.pharo.org

Re: [Pharo-project] strange == behavior

by ClÃ©ment Bera

I reported. I am doing the slice. 2012/12/9 Marcus Denker <marcus.denker(a)inria.fr> > Can you add a issue at > http://code.google.com/p/pharo/issues/list > ? > On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> > wrote: > > It seems that this issue can be fixed by modifying the = method in > Association. > > Association>>= anAssociation > ^ super = anAssociation > and: [ > value == anAssociation value > ifTrue: [ true ] > ifFalse: [ value = anAssociation value ] ] > > Cheers... > > On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > >> Same behavior in Squeak 4.2 btw >> >> ----------------- >> Benoit St-Jean >> Yahoo! Messenger: bstjean >> A standpoint is an intellectual horizon of radius zero. >> (Albert Einstein) >> >> ------------------------------ >> *From:* Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >> *To:* Pharo-project(a)lists.gforge.inria.fr >> *Sent:* Saturday, December 8, 2012 11:11:44 AM >> *Subject:* Re: [Pharo-project] strange == behavior >> >> by the way, we have the same thing in 1.0, 1.1, 1.3. >> >> On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov < >> ciprian.teodorov(a)gmail.com> wrote: >> >> Hi guys, >> >> Playing with some recursive data-structure I have found some strange >> piece of behavior in Pharo. >> >> If in an workspace we try to evaluate: >> >> a := Association new. >> a key: 3. >> a value: a. >> a == a value. >> >> the first time we get "true", the second we get an infinite loop... >> >> A simple workaround is to declare "a": >> >> |a| >> a := Association new. >> a key: 3. >> a value: a. >> a == a value. >> >> My question now is: Is this a bug or a feature ? >> By the way the same thing happens in 1.4 and 2.0 equally. >> >> By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the >> workspace replacing them by "." >> >> Cheers, >> -- >> Dr. Ciprian TEODOROV >> IngÃ©nieur DÃ©veloppement CAO >> >> tÃ©l : 06 08 54 73 48 >> mail : ciprian.teodorov(a)gmail.com >> www.teodorov.ro >> >> >> >> >> -- >> Dr. Ciprian TEODOROV >> IngÃ©nieur DÃ©veloppement CAO >> >> tÃ©l : 06 08 54 73 48 >> mail : ciprian.teodorov(a)gmail.com >> www.teodorov.ro >> >> >> > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > > >

Dec. 9, 2012

Re: [Pharo-project] strange == behavior

by Marcus Denker

Can you add a issue at http://code.google.com/p/pharo/issues/list ? On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > It seems that this issue can be fixed by modifying the = method in Association. > > Association>>= anAssociation > ^ super = anAssociation > and: [ > value == anAssociation value > ifTrue: [ true ] > ifFalse: [ value = anAssociation value ] ] > > Cheers... > > On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > Same behavior in Squeak 4.2 btw > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Saturday, December 8, 2012 11:11:44 AM > Subject: Re: [Pharo-project] strange == behavior > > by the way, we have the same thing in 1.0, 1.1, 1.3. > > On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > Hi guys, > > Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. > > If in an workspace we try to evaluate: > > a := Association new. > a key: 3. > a value: a. > a == a value. > > the first time we get "true", the second we get an infinite loop... > > A simple workaround is to declare "a": > > |a| > a := Association new. > a key: 3. > a value: a. > a == a value. > > My question now is: Is this a bug or a feature ? > By the way the same thing happens in 1.4 and 2.0 equally. > > By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." > > Cheers, > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > > > > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro

Dec. 9, 2012

Re: [Pharo-project] Errors after force quit on Windows

by Igor Stasenko

On 8 December 2012 22:12, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > My image hung waiting on data from a socket, so I aborted via "End Task" in > Windows 7. When I restarted it, I got "CannotDeleteFileException: Could not > delete the old version of file > Z:\Pharo-2.0-one-click.app\Contents\Resources\stdout" > > Then, when I went to save the image, it was complaining about the changes > file: > MultiByteFileStream(Object)>>primitiveFailed: > MultiByteFileStream(Object)>>primitiveFailed > MultiByteFileStream(StandardFileStream)>>primSize: > MultiByteFileStream(StandardFileStream)>>size > MultiByteFileStream(StandardFileStream)>>setToEnd > ChangesLog>>assureStartupStampLogged > > Any ideas? > A well known windows issue that systems keeps lock on a file, when application which has ownership on it was terminated abruptly :) there are tools to find an offending process which keeps the file(s) locked. Also, unlike unix systems, an r/w permission to open single file can acquire only one process at a time. > Thanks, > Sean > -- Best regards, Igor Stasenko.

Dec. 8, 2012

Re: [Pharo-project] Errors after force quit on Windows

by Sean P. DeNigris

Sean P. DeNigris wrote > My image hung waiting on data from a socket... A little more info... The image resided on a mapped network drive. When I tried to open it on my Mac, it worked fine, and when I copied it to C:\, it worked fine in Windows. The weird thing is that I successfully saved it a few times before it stopped working. -- View this message in context: http://forum.world.st/Errors-after-force-quit-on-Windows-tp4658575p4658576.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 8, 2012

[Pharo-project] Errors after force quit on Windows

by Sean P. DeNigris

My image hung waiting on data from a socket, so I aborted via "End Task" in Windows 7. When I restarted it, I got "CannotDeleteFileException: Could not delete the old version of file Z:\Pharo-2.0-one-click.app\Contents\Resources\stdout" Then, when I went to save the image, it was complaining about the changes file: MultiByteFileStream(Object)>>primitiveFailed: MultiByteFileStream(Object)>>primitiveFailed MultiByteFileStream(StandardFileStream)>>primSize: MultiByteFileStream(StandardFileStream)>>size MultiByteFileStream(StandardFileStream)>>setToEnd ChangesLog>>assureStartupStampLogged Any ideas? Thanks, Sean -- View this message in context: http://forum.world.st/Errors-after-force-quit-on-Windows-tp4658575.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 8, 2012

Re: [Pharo-project] strange == behavior

by Ciprian Teodorov

It seems that this issue can be fixed by modifying the = method in Association. Association>>= anAssociation ^ super = anAssociation and: [ value == anAssociation value ifTrue: [ true ] ifFalse: [ value = anAssociation value ] ] Cheers... On Sat, Dec 8, 2012 at 5:35 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > Same behavior in Squeak 4.2 btw > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > ------------------------------ > *From:* Ciprian Teodorov <ciprian.teodorov(a)gmail.com> > *To:* Pharo-project(a)lists.gforge.inria.fr > *Sent:* Saturday, December 8, 2012 11:11:44 AM > *Subject:* Re: [Pharo-project] strange == behavior > > by the way, we have the same thing in 1.0, 1.1, 1.3. > > On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov < > ciprian.teodorov(a)gmail.com> wrote: > > Hi guys, > > Playing with some recursive data-structure I have found some strange piece > of behavior in Pharo. > > If in an workspace we try to evaluate: > > a := Association new. > a key: 3. > a value: a. > a == a value. > > the first time we get "true", the second we get an infinite loop... > > A simple workaround is to declare "a": > > |a| > a := Association new. > a key: 3. > a value: a. > a == a value. > > My question now is: Is this a bug or a feature ? > By the way the same thing happens in 1.4 and 2.0 equally. > > By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the > workspace replacing them by "." > > Cheers, > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > > > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Dec. 8, 2012

Re: [Pharo-project] strange == behavior

by Benoit St-Jean

Same behavior in Squeak 4.2 btw Â ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) >________________________________ > From: Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >To: Pharo-project(a)lists.gforge.inria.fr >Sent: Saturday, December 8, 2012 11:11:44 AM >Subject: Re: [Pharo-project] strange == behavior > > >by the way, we have the same thing in 1.0, 1.1, 1.3. > > >On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > >Hi guys, >> >> >>Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. >> >> >>If in an workspace we try to evaluate: >> >> >>a := Association new. >>a key: 3. >>a value: a. >>a == a value. >> >> >>the first time we get "true", the second we get an infinite loop...Â >> >> >>A simple workaround is to declare "a": >> >> >>|a| >>a := Association new. >>a key: 3. >>a value: a. >>a == a value. >> >> >>My question now is: Is this a bug or a feature ? >>By the way the same thing happens in 1.4 and 2.0 equally. >> >> >>By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "."Â >> >> >>Cheers,-- >>Dr. Ciprian TEODOROV >>IngÃ©nieurÂ DÃ©veloppementÂ CAO >> >>tÃ©l : 06 08 54 73 48 >>mail :Â ciprian.teodorov(a)gmail.com >>www.teodorov.ro >> > > > >-- >Dr. Ciprian TEODOROV >IngÃ©nieurÂ DÃ©veloppementÂ CAO > >tÃ©l : 06 08 54 73 48 >mail :Â ciprian.teodorov(a)gmail.com >www.teodorov.ro > > >

Dec. 8, 2012

Re: [Pharo-project] strange == behavior

by Ciprian Teodorov

by the way, we have the same thing in 1.0, 1.1, 1.3. On Sat, Dec 8, 2012 at 5:10 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com > wrote: > Hi guys, > > Playing with some recursive data-structure I have found some strange piece > of behavior in Pharo. > > If in an workspace we try to evaluate: > > a := Association new. > a key: 3. > a value: a. > a == a value. > > the first time we get "true", the second we get an infinite loop... > > A simple workaround is to declare "a": > > |a| > a := Association new. > a key: 3. > a value: a. > a == a value. > > My question now is: Is this a bug or a feature ? > By the way the same thing happens in 1.4 and 2.0 equally. > > By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the > workspace replacing them by "." > > Cheers, > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Dec. 8, 2012

[Pharo-project] strange == behavior

by Ciprian Teodorov

Hi guys, Playing with some recursive data-structure I have found some strange piece of behavior in Pharo. If in an workspace we try to evaluate: a := Association new. a key: 3. a value: a. a == a value. the first time we get "true", the second we get an infinite loop... A simple workaround is to declare "a": |a| a := Association new. a key: 3. a value: a. a == a value. My question now is: Is this a bug or a feature ? By the way the same thing happens in 1.4 and 2.0 equally. By the way, in Pharo 2.0 doing cmd + . erases the lines selected in the workspace replacing them by "." Cheers, -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Dec. 8, 2012

Re: [Pharo-project] eating some obsolete dog food

by Ben Coman

Nicolas Cellier wrote: > This is a long time since I did not contribute to Pharo, so I tried > with something easy... > http://code.google.com/p/pharo/issues/detail?id=7108 > > I downloaded latest successful build, > Pharo2.0a > Latest update: #20433 > > Then I updated the 5 methods from a MC merge, and... > Err... I cannot type my initials ^H^H^H^H^H^H^H^H full name > The dialog insists on selecting any letter I type and next letter will > override the previous one. > I finally published anonymously, that does not matter... > > But you know the impact of a first bad UI impression... > It would ruin tons of efforts I know you spent cleaning the infrastructure. > I believe such cleaning is very ambitious and rarely rewarding in the > short term... > But I'd really like to be more supportive, it's so essential for > building the future. > > So before ranting loud, I digged a bit further: could it be this > warning I had at startup about obsolete VM, yes that was it! > So if you are episodic user like me : > > ******** DON'T FORGET TO DOWNLOAD A PHARO SPECIFIC VM ************* > > I already spent way more time on this than I wished, hope my mistake > helps someone else. > ( over-estimating pharo planned obsolescence period is indeed a > mistake ;) why would the VM be handled differently ? ) > > Last thing, maybe you should insist on the download page that 2.0 > REQUIRES a pharo specific VM. > Not sure I would have read it, but then it would be entirely my fault. > > Nicolas > > > Or... for 2.0 Beta and 2.0 Release provide only a one-click package. If anyone wants just the image, they can get it from the CI server.

Dec. 8, 2012