December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] strange == behavior

by Igor Stasenko

some years ago, its been a long discussion on squeak mailing list about that.. imo association should compare keys. not values. But self-referencing data structures is and will be a problem. And there is no easy solution: a := Array new: 1. a at:1 put: a. a = a On 9 December 2012 17:20, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I am not pro, see my comments in the issue tracker. > > For example, > > | a | > a := Association key: #foo. > (a value: (Array with: a)) = (a value: (Array with: a)). > > would still loop. > > Loops like that cannot be prevented locally. > > See my other mail about prevent stack overflow. > > On 09 Dec 2012, at 16:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi guys >> >> what is the impact on method =? >> Any ideas? >> >> Stef >> On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov 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 >> >> > > -- Best regards, Igor Stasenko.

Dec. 9, 2012

Re: [Pharo-project] strange == behavior

by Sven Van Caekenberghe

I am not pro, see my comments in the issue tracker. For example, | a | a := Association key: #foo. (a value: (Array with: a)) = (a value: (Array with: a)). would still loop. Loops like that cannot be prevented locally. See my other mail about prevent stack overflow. On 09 Dec 2012, at 16:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > what is the impact on method =? > Any ideas? > > Stef > On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov 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 Nicolas Cellier

The sole impact I can't think of is (#x -> Float nan) = (#x -> Float nan) Nicolas 2012/12/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > what is the impact on method =? > Any ideas? > > Stef > On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov 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 StÃ©phane Ducasse

Hi guys what is the impact on method =? Any ideas? Stef On Dec 8, 2012, at 5:57 PM, Ciprian Teodorov 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

[Pharo-project] Protecting against stack overflow ?

by Sven Van Caekenberghe

Hi, Would it be possible to build some kind of protection against stack overflow ? This is actually the most common situation for loop/cycle that either results in an unusable image or a crash. Interrupting with CMD-. is not always possible. A possible solution could be to just limit the stack size and throw an exception. For example, in LispWorks, it goes like this: CL-USER 5 > (defun foo () (cons (random 100) (foo))) FOO CL-USER 6 > (foo) Stack overflow (stack size 48128). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 7 : 1 > :bq ERROR <- RUNTIME:BAD-ARGS-OR-STACK <- LENGTH <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- FOO <- EVAL <- CAPI::CAPI-TOP-LEVEL-FUNCTION <- CAPI::INTERACTIVE-PANE-TOP-LOOP <- MP::PROCESS-SG-FUNCTION Obviously, this is possible, the question is, can it be done easily and without paying an unbearable performance price ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 9, 2012

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