- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Recursion inside #doesNotUnderstand: method. Why?

by Aliaksei Syrel

Just a guess, maybe to allow method adding from debugger and then ability to continue execution? Cheers, Alex On Thu, Feb 25, 2016 at 5:56 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > Does anybody know why #doesNotUnderstand: is implemented with recursion at > the end? > > doesNotUnderstand: aMessage > | exception resumeValue | > (exception := MessageNotUnderstood new) > message: aMessage; > receiver: self. > resumeValue := exception signal. > * ^exception reachedDefaultHandler* > * ifTrue: [aMessage sentTo: self]* > ifFalse: [resumeValue]. > > > Best regards, > Denis >

Feb. 25, 2016

Re: [Pharo-dev] Recursion inside #doesNotUnderstand: method. Why?

by Blondeau Vincent

Hi, Because when you are receiving a DNU, you have the possibility to implement the method before resuming the exception. If you choose to implement the method, the message is sent again to the newly created method and the execution restarts. Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Denis Kudriashov EnvoyÃ© : jeudi 25 fÃ©vrier 2016 17:56 Ã : Discusses Development of Pharo Objet : [Pharo-dev] Recursion inside #doesNotUnderstand: method. Why? Hi. Does anybody know why #doesNotUnderstand: is implemented with recursion at the end? doesNotUnderstand: aMessage | exception resumeValue | (exception := MessageNotUnderstood new) message: aMessage; receiver: self. resumeValue := exception signal. ^exception reachedDefaultHandler ifTrue: [aMessage sentTo: self] ifFalse: [resumeValue]. Best regards, Denis !!!************************************************************************************* "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"

Feb. 25, 2016

Re: [Pharo-dev] Recursion inside #doesNotUnderstand: method. Why?

by Denis Kudriashov

Maybe in past it was used to create methods in debugger on the fly. But now it is not. I just check it. I removed recursion logic and methods creation continue working in debugger. Maybe we should remove this strange behaviour 2016-02-25 17:56 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi. > > Does anybody know why #doesNotUnderstand: is implemented with recursion at > the end? > > doesNotUnderstand: aMessage > | exception resumeValue | > (exception := MessageNotUnderstood new) > message: aMessage; > receiver: self. > resumeValue := exception signal. > * ^exception reachedDefaultHandler* > * ifTrue: [aMessage sentTo: self]* > ifFalse: [resumeValue]. > > > Best regards, > Denis >

Feb. 25, 2016

Recursion inside #doesNotUnderstand: method. Why?

by Denis Kudriashov

Hi. Does anybody know why #doesNotUnderstand: is implemented with recursion at the end? doesNotUnderstand: aMessage | exception resumeValue | (exception := MessageNotUnderstood new) message: aMessage; receiver: self. resumeValue := exception signal. * ^exception reachedDefaultHandler* * ifTrue: [aMessage sentTo: self]* ifFalse: [resumeValue]. Best regards, Denis

Feb. 25, 2016

Re: [Pharo-dev] debugger versus primitive 19 "simulation guard"

by Denis Kudriashov

I revert this case in 17698 <https://pharo.fogbugz.com/f/cases/17698/Debugger-step-through-proxies-is-no…> 2016-02-25 12:24 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Trying to debug step two times into... > [ 'a' ] newProcess > ...hangs the image. > > It works okay with... > Pharo5.0 update: #50495 > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > Unix built on Apr 2 2015 00:51:53 Compiler: 4.6.3 > > but not with... > Pharo5.0 update: #50496 > CoInterpreter VMMaker.oscog-eem.1630 uuid: > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016 > 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 > +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 > Unix built on Jan 14 2016 11:50:34 Compiler: 4.6.3 > > > btw, the same case on Squeak-4.6-All-In-one and Squeak-5-All-In-One > both produce "Code simulation error." > > Is it maybe related to... "another endless debugger loop" > https://pharo.fogbugz.com/default.asp?16877 > > cheers -ben > >

Feb. 25, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50613 Home: https://github.com/pharo-project/pharo-core

Feb. 25, 2016

[pharo-project/pharo-core] f90141: 50613

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: f9014105d5211bb4d78aabd1278956e126bb00c3 https://github.com/pharo-project/pharo-core/commit/f9014105d5211bb4d78aabd1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-25 (Thu, 25 Feb 2016) Changed paths: A Deprecated50.package/NBExternalAddress.class/README.md A Deprecated50.package/NBExternalAddress.class/definition.st A Deprecated50.package/NBExternalArray.class/README.md A Deprecated50.package/NBExternalArray.class/definition.st A Deprecated50.package/NBExternalEnumeration.class/README.md A Deprecated50.package/NBExternalEnumeration.class/definition.st A Deprecated50.package/NBExternalObject.class/README.md A Deprecated50.package/NBExternalObject.class/definition.st A Deprecated50.package/NBExternalStructure.class/README.md A Deprecated50.package/NBExternalStructure.class/definition.st A Deprecated50.package/NBExternalStructureFields.class/README.md A Deprecated50.package/NBExternalStructureFields.class/definition.st A Deprecated50.package/NBExternalTypeValue.class/README.md A Deprecated50.package/NBExternalTypeValue.class/definition.st A Deprecated50.package/NBExternalUnion.class/README.md A Deprecated50.package/NBExternalUnion.class/definition.st A Deprecated50.package/NBFFICallback.class/README.md A Deprecated50.package/NBFFICallback.class/definition.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50612.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50613.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50612.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50613.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50613 17700 add stub NB classes to easy migrations https://pharo.fogbugz.com/f/cases/17700 http://files.pharo.org/image/50/50613.zip

Feb. 25, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by Nicolai Hess

2016-02-25 15:25 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > > 2016-02-23 18:03 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> >> On Tue, Feb 23, 2016 at 12:47 AM, stepharo <stepharo(a)free.fr> wrote: >> >>> Hi >>> >>> I saw that something <return: #Point> or <return: Point> >>> I do not know why but I have the impression that <return: #Point> is >>> better. >>> Because we may have code not present and still want to load the code. >>> >> >> Given the current semantics of pragmas only <return: #Point> is valid. >> > > Well, yes... > > In fact, Opal compiles <return: Point> as <return: #Point>. It does not > change the semantics. > > I think the real question is: "Do we allow, in the specific case of > pragma, symbols to by written without the # ?" > I am about to change this (with the exception for <primitive:...error:>) 17696 <https://pharo.fogbugz.com/f/cases/17696/RBParser-should-not-allow-variable-…> RBParser should not allow variable names for pragma arguments > > We already allow "[ nil ]" to be written as "[ ]", and the "^self" at the > end of each method to be omitted. We could have more specific cases so it > won't be too trivial for unaware people to understand the semantics. > > We can already see that the syntax colorer is not aware of this specific > case, so it colors Point in <return: Point> as a Literal Variable instead > of a symbol, which leaded many people here to confusion. > > *About renaming...* > > When renaming a class, it checks all the symbol references too, so, > assuming you have a class Banana and the following code: > > Coconut >> getSomething > <return: Banana> > <return: #Banana> > Banana new. > ^ #Banana > > When we rename the class Banana to Cauliflower, the method is > automatically changed to: > > Coconut >> getSomething > <return: #Cauliflower> > <return: #Cauliflower> > Cauliflower new. > ^ #Cauliflower > > Again, in this case, as for syntax coloring, the system is not aware that > it should rename <return: Banana> to <return: Cauliflower> and not > <return: #Cauliflower>, so as it uses standard symbol terminology > > > > >> _,,,^..^,,,_ >> best, Eliot >> > >

Feb. 25, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by ClÃ©ment Bera

2016-02-23 18:03 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Tue, Feb 23, 2016 at 12:47 AM, stepharo <stepharo(a)free.fr> wrote: > >> Hi >> >> I saw that something <return: #Point> or <return: Point> >> I do not know why but I have the impression that <return: #Point> is >> better. >> Because we may have code not present and still want to load the code. >> > > Given the current semantics of pragmas only <return: #Point> is valid. > Well, yes... In fact, Opal compiles <return: Point> as <return: #Point>. It does not change the semantics. I think the real question is: "Do we allow, in the specific case of pragma, symbols to by written without the # ?" We already allow "[ nil ]" to be written as "[ ]", and the "^self" at the end of each method to be omitted. We could have more specific cases so it won't be too trivial for unaware people to understand the semantics. We can already see that the syntax colorer is not aware of this specific case, so it colors Point in <return: Point> as a Literal Variable instead of a symbol, which leaded many people here to confusion. *About renaming...* When renaming a class, it checks all the symbol references too, so, assuming you have a class Banana and the following code: Coconut >> getSomething <return: Banana> <return: #Banana> Banana new. ^ #Banana When we rename the class Banana to Cauliflower, the method is automatically changed to: Coconut >> getSomething <return: #Cauliflower> <return: #Cauliflower> Cauliflower new. ^ #Cauliflower Again, in this case, as for syntax coloring, the system is not aware that it should rename <return: Banana> to <return: Cauliflower> and not <return: #Cauliflower>, so as it uses standard symbol terminology > _,,,^..^,,,_ > best, Eliot >

Feb. 25, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 93fd3c: 50612

by Esteban Lorenzano

not clear in the message, but this issue also makes SDL2 work (a first iteration, there will be problems probably) > On 25 Feb 2016, at 14:45, GitHub <noreply(a)github.com> wrote: > > 17236 unload NativeBoost (spur migration) > https://pharo.fogbugz.com/f/cases/17236 <https://pharo.fogbugz.com/f/cases/17236>

Feb. 25, 2016