- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Generate accessors refactoring

by Yuriy Tymchuk

> On 7 Dec 2016, at 18:00, John Brant <brant(a)refactoryworkers.com> wrote: > > Since then, Iâve had several times that it has saved me from overriding a method that I didnât want to be overridden. Was this done by creating a method with a different name or by letting you know that the method already exists and asking what you want to do next? Uko

Dec. 8, 2016

Re: [Pharo-dev] :: Separator in class names

by Torsten Bergmann

Aliaksei Syrel >This thread has a huge discussion potential :) Â Yes - I know it has :) And it comes up from time to time ... mostly fading away. Nonetheless I like to trigger it again. So far we have not made much progress on that frontier and - even when we do not have a full, perfect or portable namespace solution changing the current restriction what a "valid global name" means (see method #isValidGlobalName) could help in exploring that area more deeply. Having at a minimum support for a scope like separator (I would suggest to use "::") would allow to experiment with it from Pharo 6.0 onwards. >*grabs popcorn* Why do you just want to be part of the audience instead of telling us what you think? Thanks T.

Dec. 8, 2016

Re: [Pharo-dev] Drastically improving the messageNotUnderstood title

by Sven Van Caekenberghe

> On 8 Dec 2016, at 00:42, Ben Coman <btc(a)openinworld.com> wrote: > > On Thu, Dec 8, 2016 at 5:54 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> Done: 19441. >> >> I also change nil case to "message was send to nil" (instead of "receiver of >> message is nil"). You can correct it as you wish :) > > send==>sent > >> >> 2016-12-07 21:44 GMT+01:00 stepharong <stepharong(a)free.fr>: >>> >>> Hi guys >>> >>> As I exposed newbies to our wonderfull debugger I think that we should >>> change >>> >>> MessageNotUnderstood: Class>>#message >>> >>> into >>> >>> an instance of Class did not understand message > > Perhaps(?) a short form can be put in brackets? > ==> an instance of Class did not understand #message sent to it (MNU > Class>>#message) +1 > cheers -ben > >>> >>> To me this simple change would have a HUGE impact on making the debugger >>> first contact a lot more friendly.

Dec. 8, 2016

Re: [Pharo-dev] :: Separator in class names

by Dale Henrichs

Torsten, Because of the obvious portability problems this would introduce, I would think that an attempt should be made to come up with a common namespace solution ... I do believe that some discussion about namespace alternatives has taken place between GemStone and Pharo --- not familiar with details or outcome of discussions, but I would like to think that at least an attempt was made to come up with a common solution before resorting to a unilateral solution that would only introduce more isolation between the various dialects --- something that a small community cannot really afford to do ... Dale On 12/07/2016 04:47 PM, Torsten Bergmann wrote: > Hi, > > due to the absence of a namespace solution we today often prefix classes with one, two or three letters. > You all know prefixes like "Zn", "Zdc", "GLM", "Tx", "WA", ... to avoid conflicting names. > > I would like to have a "::" separator within the class name to better distinguish > the class name from the prefix and increase readability at the same time. SmalltalkMT > had this solution in alignment with C++ and I really liked working with it. > So much that I would like to see it in Pharo too - maybe also as a base for future Namespace > additions. > > So I modified the #isValidGlobalName in Pharo 6.0 like mentioned below to allow and support > the :: notation for classes. After that I can create classes like: > > Seaside::Component > Core::Boolean > Model::Person > GLM::BrickListModel > Tx::FontAttribute > > so far without any problem. > > Do you think > - there will be places where this conflicts or creates hazzles (tools, metacello, ...) > - if it would be a good idea to add this to the default image? > > Thanks for feedback. > > Thx > T. > > -------------------------------------------------------------------------------------------------- > isValidGlobalName > > self ifEmpty: [ ^ false ]. > > "reserverd default names" > self = 'NameOfSubclass' ifTrue: [ ^ false ]. > self = 'TNameOfTrait' ifTrue: [ ^ false ]. > > (self occurrencesOf: $:) = 2 ifTrue: [ > ^(self splitOn: '::') allSatisfy: [: part | part isValidGlobalName ] > ]. > > ^ Character supportsNonASCII > ifTrue: [ > (self first isLetter > and: [self first isUppercase]) > and: [ self allSatisfy: [:character | > character isAlphaNumeric or: [ character = $_ ]]]] > ifFalse: [ > (self first between: $A and: $Z) and: [ > self allSatisfy: [:character | > (character between: $a and: $z) or: [ > (character between: $A and: $Z) or: [ > (character between: $0 and: $9) or: [ > character = $_]]]]]] >

Dec. 8, 2016

Re: [Pharo-dev] :: Separator in class names

by Aliaksei Syrel

This thread has a huge discussion potential :) *grabs popcorn* On 8 December 2016 at 01:47, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > due to the absence of a namespace solution we today often prefix classes > with one, two or three letters. > You all know prefixes like "Zn", "Zdc", "GLM", "Tx", "WA", ... to avoid > conflicting names. > > I would like to have a "::" separator within the class name to better > distinguish > the class name from the prefix and increase readability at the same time. > SmalltalkMT > had this solution in alignment with C++ and I really liked working with it. > So much that I would like to see it in Pharo too - maybe also as a base > for future Namespace > additions. > > So I modified the #isValidGlobalName in Pharo 6.0 like mentioned below to > allow and support > the :: notation for classes. After that I can create classes like: > > Seaside::Component > Core::Boolean > Model::Person > GLM::BrickListModel > Tx::FontAttribute > > so far without any problem. > > Do you think > - there will be places where this conflicts or creates hazzles (tools, > metacello, ...) > - if it would be a good idea to add this to the default image? > > Thanks for feedback. > > Thx > T. > > ------------------------------------------------------------ > -------------------------------------- > isValidGlobalName > > self ifEmpty: [ ^ false ]. > > "reserverd default names" > self = 'NameOfSubclass' ifTrue: [ ^ false ]. > self = 'TNameOfTrait' ifTrue: [ ^ false ]. > > (self occurrencesOf: $:) = 2 ifTrue: [ > ^(self splitOn: '::') allSatisfy: [: part | part > isValidGlobalName ] > ]. > > ^ Character supportsNonASCII > ifTrue: [ > (self first isLetter > and: [self first isUppercase]) > and: [ self allSatisfy: [:character | > character isAlphaNumeric > or: [ character = $_ ]]]] > ifFalse: [ > (self first between: $A and: $Z) and: [ > self allSatisfy: [:character | > (character between: $a and: $z) > or: [ > (character between: $A and: $Z) > or: [ > (character between: $0 and: $9) > or: [ > character = $_]]]]]] > >

Dec. 8, 2016

:: Separator in class names

by Torsten Bergmann

Hi, due to the absence of a namespace solution we today often prefix classes with one, two or three letters. You all know prefixes like "Zn", "Zdc", "GLM", "Tx", "WA", ... to avoid conflicting names. I would like to have a "::" separator within the class name to better distinguish the class name from the prefix and increase readability at the same time. SmalltalkMT had this solution in alignment with C++ and I really liked working with it. So much that I would like to see it in Pharo too - maybe also as a base for future Namespace additions. So I modified the #isValidGlobalName in Pharo 6.0 like mentioned below to allow and support the :: notation for classes. After that I can create classes like: Seaside::Component Core::Boolean Model::Person GLM::BrickListModel Tx::FontAttribute so far without any problem. Do you think - there will be places where this conflicts or creates hazzles (tools, metacello, ...) - if it would be a good idea to add this to the default image? Thanks for feedback. Thx T. -------------------------------------------------------------------------------------------------- isValidGlobalName self ifEmpty: [ ^ false ]. "reserverd default names" self = 'NameOfSubclass' ifTrue: [ ^ false ]. self = 'TNameOfTrait' ifTrue: [ ^ false ]. (self occurrencesOf: $:) = 2 ifTrue: [ ^(self splitOn: '::') allSatisfy: [: part | part isValidGlobalName ] ]. ^ Character supportsNonASCII ifTrue: [ (self first isLetter and: [self first isUppercase]) and: [ self allSatisfy: [:character | character isAlphaNumeric or: [ character = $_ ]]]] ifFalse: [ (self first between: $A and: $Z) and: [ self allSatisfy: [:character | (character between: $a and: $z) or: [ (character between: $A and: $Z) or: [ (character between: $0 and: $9) or: [ character = $_]]]]]]

Dec. 8, 2016

Re: [Pharo-dev] Drastically improving the messageNotUnderstood title

by Ben Coman

On Thu, Dec 8, 2016 at 5:54 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Done: 19441. > > I also change nil case to "message was send to nil" (instead of "receiver of > message is nil"). You can correct it as you wish :) send==>sent > > 2016-12-07 21:44 GMT+01:00 stepharong <stepharong(a)free.fr>: >> >> Hi guys >> >> As I exposed newbies to our wonderfull debugger I think that we should >> change >> >> MessageNotUnderstood: Class>>#message >> >> into >> >> an instance of Class did not understand message Perhaps(?) a short form can be put in brackets? ==> an instance of Class did not understand #message sent to it (MNU Class>>#message) cheers -ben >> >> To me this simple change would have a HUGE impact on making the debugger >> first contact a lot more friendly.

Dec. 8, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Denis Kudriashov

2016-12-07 18:00 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > Which of these would you consider valid setter methods for foo? > I understand pretty well what you are trying to explain. I just think that generation of methods like #instVar1/#instVar1: is useless. It always break user control flow. Simple generator should just skip existing accessors according to "name definition" of accessors (methods with #instVar name). Besides skipping them not makes refactoring unsafe.

Dec. 7, 2016

Re: [Pharo-dev] Drastically improving the messageNotUnderstood title

by Denis Kudriashov

Done: 19441 <https://pharo.fogbugz.com/f/cases/19441/Better-description-for-MessageNotUn…> . I also change nil case to "message was send to nil" (instead of "receiver of message is nil"). You can correct it as you wish :) 2016-12-07 21:44 GMT+01:00 stepharong <stepharong(a)free.fr>: > Hi guys > > As I exposed newbies to our wonderfull debugger I think that we should > change > > MessageNotUnderstood: Class>>#message > > into > > an instance of Class did not understand message > > To me this simple change would have a HUGE impact on making the debugger > first contact a lot more friendly. > > Any taker? > I'm off with a company today. > > Stef > > -- > >

Dec. 7, 2016

Re: [Pharo-dev] genJumpLong: distance index 1043 is out of range -1024 to 1023

by stepharong

Thanks clement for your steady push in that direction. On Wed, 07 Dec 2016 19:17:26 +0100, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi, > > This will be fixed by using the alternative bytecode set, likely in the > next few weeks in Pharo 6 alpha/beta. Basically control flow messages > (ifTrue:, to:do:, etc.) cannot have too many >statements in their blocks > (ifTrue: argument, to:do: second arguments, etc) or the compiler can't > compile them due to bytecode set encoding limitation. The new bytecode > set is encoded >differently and allows such code to be compiled. > > As a temporary solution, you need to split your code in multiple methods > to lower the number of statements inside blocks inside control flow > messages. > Sorry for the annoyance. We're working on integrating a solution and we > believe that this will be integrated in Pharo 6 in the next few weeks. > > Regards, > > Clement > > On Wed, Dec 7, 2016 at 4:14 PM, Davide Varvello via Pharo-dev > <pharo-dev(a)lists.pharo.org> wrote: >> >> >> ---------- Forwarded message ---------- >> From: Davide Varvello <varvello(a)yahoo.com> >> To: pharo-dev(a)lists.pharo.org >> Cc:Date: Wed, 7 Dec 2016 07:14:35 -0800 (PST) >> Subject: genJumpLong: distance index 1043 is out of range -1024 to 1023 >> Hi, >> >> Sometimes (and also today) after formatting and saving a method, an >> Error is >> thrown. >> Following a chunk of PharoDebug.log >> >> TIA >> Davide >> >> >> --------------------- >> THERE_BE_DRAGONS_HERE >> Error: genJumpLong: distance index 1043 is out of range -1024 to 1023 >> 7 December 2016 4:21:53.0426 pm >> >> VM: Mac OS - intel - 1096 - CoInterpreter >> VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: >> 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016 >> StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 >> uuid: >> 16138eb3-2390-40f5-a6c8-15f0494936f8 Sep 30 2016 >> https://github.com/pharo-project/pharo-vm.git Commit: >> 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 >> +0200 By: >> GitHub <noreply(a)github.com> Jenkins build #603 >> >> Image: Pharo5.0 [Latest update: #50763] >> >> OpalEncoderForV3PlusClosures(Object)>>error: >> Receiver: an OpalEncoderForV3PlusClosures >> Arguments and temporary variables: >> aString: 'genJumpLong: distance index 1043 is out >> of range -1024 to 1023' >> Receiver's instance variables: >> stream: an IRBytecodeGenerator >> position: nil >> rootNode: nil >> blockExtentsToLocals: nil >> >> >> OpalEncoderForV3PlusClosures(OpalBytecodeEncoder)>>outOfRangeError:index:range:to: >> Receiver: an OpalEncoderForV3PlusClosures >> Arguments and temporary variables: >> string: 'distance' >> index: 1043 >> rangeStart: -1024 >> rangeEnd: 1023 >> Receiver's instance variables: >> stream: an IRBytecodeGenerator >> position: nil >> rootNode: nil >> blockExtentsToLocals: nil >> >> >> OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJumpLong: >> Receiver: an OpalEncoderForV3PlusClosures >> Arguments and temporary variables: >> distance: 1043 >> Receiver's instance variables: >> stream: an IRBytecodeGenerator >> position: nil >> rootNode: nil >> blockExtentsToLocals: nil >> >> >> OpalEncoderForV3PlusClosures(OpalEncoderForV3)>>genJump: >> Receiver: an OpalEncoderForV3PlusClosures >> Arguments and temporary variables: >> distance: 1043 >> Receiver's instance variables: >> stream: an IRBytecodeGenerator >> position: nil >> rootNode: nil >> blockExtentsToLocals: nil >> >> >> >> -- >> View this message in context: >> http://forum.world.st/genJumpLong-distance-index-1043-is-out-of-range-1024-… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 7, 2016