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

> On 8 Dec 2016, at 00:42, Ben Coman wrote: > > On Thu, Dec 8, 2016 at 5:54 AM, Denis Kudriashov 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

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

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

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

This thread has a huge discussion potential :) *grabs popcorn* On 8 December 2016 at 01:47, 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",

[Pharo-dev] :: Separator in class names

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

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

On Thu, Dec 8, 2016 at 5:54 AM, Denis Kudriashov 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

Re: [Pharo-dev] Generate accessors refactoring

2016-12-07 18:00 GMT+01:00 John Brant : > 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

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

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 :) 2016-12-07 21:44 GMT+01:00 stepharong : > Hi

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

Thanks clement for your steady push in that direction. On Wed, 07 Dec 2016 19:17:26 +0100, Clément Bera 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

Re: [Pharo-dev] Generate accessors refactoring

As for my “real experience”, I wrote the accessor refactoring over 22 years ago. Since then, I’ve had several times that it has saved me from overriding a method that I didn’t want to be overridden. As for saving me from destroying the system, it most likely has, but not in the way you

[Pharo-dev] Drastically improving the messageNotUnderstood title

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

[Pharo-dev] Drastically improving the messageNotUnderstood title

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

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

On Wed, Dec 7, 2016 at 11:26 AM, Jan Vrany wrote: > On Wed, 2016-12-07 at 11:10 -0800, Eliot Miranda wrote: > > > > > > On Wed, Dec 7, 2016 at 9:52 AM, Marcus Denker > > wrote: > > > Hello, > > > > > > The current bytecode limited the size of

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

On Wed, 2016-12-07 at 11:10 -0800, Eliot Miranda wrote: > > > On Wed, Dec 7, 2016 at 9:52 AM, Marcus Denker > wrote: > > Hello, > > > > The current bytecode limited the size of jumps. > > > > This means that you will get this error if your mehthods are so > > complex

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

On Wed, Dec 7, 2016 at 9:52 AM, Marcus Denker wrote: > Hello, > > The current bytecode limited the size of jumps. > > This means that you will get this error if your mehthods are so complex > that they > require a jump too large. > > Solution: refactor to simplify. > > We

Re: [Pharo-dev] Generate accessors refactoring

On Wed, Dec 7, 2016 at 9:00 AM, John Brant wrote: > > On Dec 7, 2016, at 3:44 AM, Denis Kudriashov > wrote: > > > > > > 2016-12-06 19:29 GMT+01:00 John Brant : > > > We could make it configurable. "Manually" accessors

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

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

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

Hello, The current bytecode limited the size of jumps. This means that you will get this error if your mehthods are so complex that they require a jump too large. Solution: refactor to simplify. We should improve the error message to explain that. (this will not happen anymore when the new

Re: [Pharo-dev] Generate accessors refactoring

> On Dec 7, 2016, at 3:44 AM, Denis Kudriashov wrote: > > > 2016-12-06 19:29 GMT+01:00 John Brant : > > We could make it configurable. "Manually" accessors will be generated in > > simplified mode and related refactorings will use intelligent

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

--- Begin Message --- 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

Re: [Pharo-dev] Fogbugz admin - please add Pharo 7 milestone

Hi, I added the new Milestone. (the dates for start and end are just made up… they might change) > On 7 Dec 2016, at 02:15, Ben Coman wrote: > > Just taking a browse through open tickets for Pharo 6, and maybe some > can be bumped to Pharo 7 (rather than just "Later").

Re: [Pharo-dev] Generate accessors refactoring

2016-12-07 10:44 GMT+01:00 Denis Kudriashov : > > 2016-12-06 19:29 GMT+01:00 John Brant : > >> > We could make it configurable. "Manually" accessors will be generated >> in simplified mode and related refactorings will use intelligent mode >> >>

[Pharo-dev] [pharo-project/pharo-core]

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

[Pharo-dev] [pharo-project/pharo-core] 44e997: 60319

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 44e9977b19d5e712cadefd4a3fcdfbf034f5cf9f https://github.com/pharo-project/pharo-core/commit/44e9977b19d5e712cadefd4a3fcdfbf034f5cf9f Author: Jenkins Build Server Date:

Re: [Pharo-dev] Generate accessors refactoring

2016-12-06 19:29 GMT+01:00 John Brant : > > We could make it configurable. "Manually" accessors will be generated in > simplified mode and related refactorings will use intelligent mode > > My personal preference would be to ask the user what to do when performing >