Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
April 2015
- 1555 messages
Re: [Pharo-dev] Problem with asClass usage
by phil@highoctane.be
Le 10 avr. 2015 08:10, "Peter Uhnák" <i.uhnak(a)gmail.com> a écrit :
>
> Why not add this to the critic browser?
>
> I'm quite guilty of doing this myself... because it is easier than
spending X amount of time of coming up with proper abstraction for
unimportant stuff instead of focusing on what I need....
Same. It is very useful to get code loading in a shorter way that Smalltalk
at: ...
#ConfigurationOfX asClass ...
is nicer than the other longer version.
For the GLM things, I guess it allows one to have code that works only if
an extra module is loaded.
We have asString and it is fine. Now asClass will not be. Duh?
aThing perform: #someAction is as complicated.
Yeah make a lint rule but do not disallow the usage.
Phil
>
> Peter
>
> On Fri, Apr 10, 2015 at 8:07 AM, stepharo <stepharo(a)free.fr> wrote:
>>
>>
>>
>> Le 10/4/15 06:09, Ben Coman a écrit :
>>>
>>> I believe #asClass itself was introduced for a use case to simplify
Workspace "user interactive" Gofer scripts to retrieve and load
Configurations. Since this is through away code its not covered by your
modularity concerns, and I'm not sure if it came before or after its
friends, but can we retain or substitute something to avoid needing
ugly "(Smalltalk at: #ConfigurationOfXXX) load" ?
>>
>>
>> For first time newbee they can also use the Configuration browser.
>> This is one click.
>>
>>>
>>> This is a "first impression" consideration for people dealing with
Configurations for the first time (even thought we now have Configuration
Browser). The use case is that newbies will copy-paste a script from a web
site to Playground and execute the whole script resulting in a error
"Unknown class ConfigurationOfXXX." They don't know to execute in two
separate steps, first "Gofer ... load" then "ConfigurationOfXXX load".
>>
>> Yes it would be much better.
>>
>>
>>>
>>> Alternatively, what if the Metacello package extended Gofer with a
method #configurationOf: so websites can show...
>>>
>>> config :=
>>> Gofer new
>>> url: 'http://smalltalkhub.com/mc/MyProject/main'
>>> package: 'MyXXXPackage';
>>> load;
>>> configurationOf: 'XXX' "return class ConfigurationOfXXX"
>>> config load.
>>>
>>> ...so the compiler is dealing with a variable "config" rather than
class 'ConfigurationOfXXX' that it doesn't know yet, or a further
altenative...
>>>
>>> Gofer new
>>> url: 'http://smalltalkhub.com/mc/MyProject/main'
>>> package: 'MyXXXPackage';
>>> load;
>>> configurationOf: 'XXX' do: [ :config | config load ];
>>> configurationOf: 'YYY' do: [ :config | config load ].
>>>
>>> cheers -ben
>>>
>>>
>>> On 10/04/2015 4:32 am, "stepharo" <stepharo(a)free.fr> wrote:
>>>>
>>>> Hi
>>>>
>>>> We want to raise a strong warning against the extension of the use of
asClass and friends.
>>>> asClass should not be used in Pharo distribution. I will propose to
deprecate it.
>>>>
>>>> We are working on dependency analysis, module system, remote debugging
and asClass introduces
>>>> lose class references and many related problems.
>>>>
>>>> I would like to remove this behavior because it is clear that it will
just grow up and lead to deadcode and ugly dependencies.
>>>>
>>>> First, most of the time you can avoid to query Smalltalk globals at:
and that BY CONSTRUCTION a software system should be built and it
should define its own customization.
>>>>
>>>>
>>>> Second, at least use self class environment at: #foo
>>>>
>>>> Why is it much much much better? because it does not rely on String
class resolution and as such
>>>> is much more modular. You do not want to have the resolution of a
symbol related to the place where String is defined but on where your code
is actually.
>>>>
>>>> Imagine that tomorrow your code is in its own module. Then you want to
know from your code point of you
>>>> if a binding exist not from the one of environment in which String is.
>>>>
>>>>
>>>>
>>>>
>>>> here are some examples:
>>>>
>>>> ==============================
>>>> quadrangleClass
>>>> ^ 'QuadrangleForTesting' asClass
>>>>
>>>> Strange it simply breaks. Of course it broke the smallLint rule.
>>>>
>>>> ==============================
>>>> Metacello should better define OSProcess as a dependent.Because it is
not clear what will happen
>>>> if if not there?
>>>>
>>>> extractRepositoryFrom: zipFile to: directory
>>>> "unzip <zipFile> into <directory>"
>>>>
>>>> | out err proc errorMessage |
>>>> out := FileStream forceNewFileNamed: '/tmp/zip.out'.
>>>> err := FileStream forceNewFileNamed: '/tmp/zip.err'.
>>>> errorMessage := ''.
>>>> [
>>>> proc := #OSProcess asClass thisOSProcess
>>>> forkJob: '/usr/bin/unzip'
>>>> arguments:
>>>> {'-u'.
>>>> zipFile.
>>>> '-d'.
>>>> directory}
>>>> environment: nil
>>>> descriptors: (Array with: nil with: out with: err).
>>>>
>>>> ==================
>>>>
>>>> I do not get why we need this funky logic.
>>>>
>>>> openInBrickWindowLabeled: aLabel
>>>>
>>>> #GLMSystemWindowBrick asClassIfAbsent: [
>>>> ^ self asMorph openInWindow ].
>>>>
>>>> ^ #GLMSystemWindowBrick asClass new
>>>> label: aLabel;
>>>> color: Color transparent;
>>>> addBrickBack: (
>>>> GLMBrick new
>>>> vSpaceFill
>>>>
>>>>
>>>> window
>>>> "Answer the receiver's window."
>>>> #GLMWindowBrick asClassIfAbsent: [
>>>> ^ self ownerThatIsA: SystemWindow ].
>>>>
>>>> ^ (self ownerThatIsA: #GLMWindowBrick asClass)
>>>> ifNil: [ self ownerThatIsA: SystemWindow ]
>>>>
>>>>
>>>>
>>>> sendUsageData: aBoolean
>>>> | settingsClass |
>>>> settingsClass := #GTSpotterEventRecorderSettings asClassIfAbsent:
[ ^ self ].
>>>> ^ settingsClass sendUsageData: aBoolean
>>>>
>>>>
>>>> sendUsageData
>>>> | settingsClass |
>>>> settingsClass := #GTSpotterEventRecorderSettings asClassIfAbsent:
[ ^ false ].
>>>> ^ settingsClass sendUsageData
>>>>
>>>>
>>
>
April 10, 2015
Re: [Pharo-dev] why we removed debugTest from nautilus?
by Esteban Lorenzano
> On 10 Apr 2015, at 02:37, Clément Bera <bera.clement(a)gmail.com> wrote:
>
> I was using it frequently too and I have never experienced any issuesâ¦
me too, and also never seen it.
but also never seen the issue⦠so I suppose is my fault not to talk in time :)
I will propose a replacement as soon as I can allocate some time to came up with something more or less well designed (bah⦠or designed âmy wayâ which is not always âwellâ :P).
Esteban
>
> 2015-04-09 14:58 GMT-07:00 Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>>:
>
> 2015-04-09 23:38 GMT+02:00 phil(a)highoctane.be <mailto:phil@highoctane.be> <phil(a)highoctane.be <mailto:phil@highoctane.be>>:
> No Debug Tests?
>
> Geez, I am using that all the time.
>
> And you're never encountered this issue 14689 <https://pharo.fogbugz.com/default.asp?14689>?
> Or did this work in older versions?
>
>
>
>
> Phil
>
>
> On Thu, Apr 9, 2015 at 10:21 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote:
>
> > On 09 Apr 2015, at 22:32, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote:
> >
> > Nicolai Hess wrote
> >> http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-… <http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-…>
> >
> > Ah, I miss that too! From that thread, it seems it was removed temporarily
> > until we have real breakpoints. Is there an issue for its return?
> >
>
> Not yet.
>
> Marcus
>
>
>
April 10, 2015
Re: [Pharo-dev] Problem with asClass usage
by Peter Uhnák
Why not add this to the critic browser?
I'm quite guilty of doing this myself... because it is easier than spending
X amount of time of coming up with proper abstraction for unimportant stuff
instead of focusing on what I need....
Peter
On Fri, Apr 10, 2015 at 8:07 AM, stepharo <stepharo(a)free.fr> wrote:
>
>
> Le 10/4/15 06:09, Ben Coman a écrit :
>
> I believe #asClass itself was introduced for a use case to simplify
> Workspace "user interactive" Gofer scripts to retrieve and load
> Configurations. Since this is through away code its not covered by your
> modularity concerns, and I'm not sure if it came before or after its
> friends, but can we retain or substitute something to avoid needing
> ugly "(Smalltalk at: #ConfigurationOfXXX) load" ?
>
>
> For first time newbee they can also use the Configuration browser.
> This is one click.
>
>
> This is a "first impression" consideration for people dealing with
> Configurations for the first time (even thought we now have Configuration
> Browser). The use case is that newbies will copy-paste a script from a web
> site to Playground and execute the whole script resulting in a error
> "Unknown class ConfigurationOfXXX." They don't know to execute in two
> separate steps, first "Gofer ... load" then "ConfigurationOfXXX load".
>
> Yes it would be much better.
>
>
>
> Alternatively, what if the Metacello package extended Gofer with a method
> #configurationOf: so websites can show...
>
> config :=
> Gofer new
> url: 'http://smalltalkhub.com/mc/MyProject/main'
> package: 'MyXXXPackage';
> load;
> configurationOf: 'XXX' "return class ConfigurationOfXXX"
> config load.
>
> ...so the compiler is dealing with a variable "config" rather than class
> 'ConfigurationOfXXX' that it doesn't know yet, or a further altenative...
>
> Gofer new
> url: 'http://smalltalkhub.com/mc/MyProject/main'
> package: 'MyXXXPackage';
> load;
> configurationOf: 'XXX' do: [ :config | config load ];
> configurationOf: 'YYY' do: [ :config | config load ].
>
> cheers -ben
>
>
> On 10/04/2015 4:32 am, "stepharo" <stepharo(a)free.fr> wrote:
>
>> Hi
>>
>> We want to raise a strong warning against the extension of the use of
>> asClass and friends.
>> asClass should not be used in Pharo distribution. I will propose to
>> deprecate it.
>>
>> We are working on dependency analysis, module system, remote debugging
>> and asClass introduces
>> lose class references and many related problems.
>>
>> I would like to remove this behavior because it is clear that it will
>> just grow up and lead to deadcode and ugly dependencies.
>>
>> First, most of the time you can avoid to query Smalltalk globals at: and
>> that BY CONSTRUCTION a software system should be built and it should
>> define its own customization.
>>
>>
>> Second, at least use self class environment at: #foo
>>
>> Why is it much much much better? because it does not rely on String class
>> resolution and as such
>> is much more modular. You do not want to have the resolution of a symbol
>> related to the place where String is defined but on where your code is
>> actually.
>>
>> Imagine that tomorrow your code is in its own module. Then you want to
>> know from your code point of you
>> if a binding exist not from the one of environment in which String is.
>>
>>
>>
>>
>> here are some examples:
>>
>> ==============================
>> quadrangleClass
>> ^ 'QuadrangleForTesting' asClass
>>
>> Strange it simply breaks. Of course it broke the smallLint rule.
>>
>> ==============================
>> Metacello should better define OSProcess as a dependent.Because it is not
>> clear what will happen
>> if if not there?
>>
>> extractRepositoryFrom: zipFile to: directory
>> "unzip <zipFile> into <directory>"
>>
>> | out err proc errorMessage |
>> out := FileStream forceNewFileNamed: '/tmp/zip.out'.
>> err := FileStream forceNewFileNamed: '/tmp/zip.err'.
>> errorMessage := ''.
>> [
>> proc := #OSProcess asClass thisOSProcess
>> forkJob: '/usr/bin/unzip'
>> arguments:
>> {'-u'.
>> zipFile.
>> '-d'.
>> directory}
>> environment: nil
>> descriptors: (Array with: nil with: out with: err).
>>
>> ==================
>>
>> I do not get why we need this funky logic.
>>
>> openInBrickWindowLabeled: aLabel
>>
>> #GLMSystemWindowBrick asClassIfAbsent: [
>> ^ self asMorph openInWindow ].
>>
>> ^ #GLMSystemWindowBrick asClass new
>> label: aLabel;
>> color: Color transparent;
>> addBrickBack: (
>> GLMBrick new
>> vSpaceFill
>>
>>
>> window
>> "Answer the receiver's window."
>> #GLMWindowBrick asClassIfAbsent: [
>> ^ self ownerThatIsA: SystemWindow ].
>>
>> ^ (self ownerThatIsA: #GLMWindowBrick asClass)
>> ifNil: [ self ownerThatIsA: SystemWindow ]
>>
>>
>>
>> sendUsageData: aBoolean
>> | settingsClass |
>> settingsClass := #GTSpotterEventRecorderSettings asClassIfAbsent: [ ^
>> self ].
>> ^ settingsClass sendUsageData: aBoolean
>>
>>
>> sendUsageData
>> | settingsClass |
>> settingsClass := #GTSpotterEventRecorderSettings asClassIfAbsent: [ ^
>> false ].
>> ^ settingsClass sendUsageData
>>
>>
>>
>
April 10, 2015
Re: [Pharo-dev] New Cog VMs available
by stepharo
There is no problem tobias
We love ci
Stef
Le 10/4/15 00:17, Tobias Pape a écrit :
> Sorry the noise, did not look on whereto I replied.
> :/
> Best
> -Tobias
>
>
> On 10.04.2015, at 00:16, Tobias Pape <Das.Linux(a)gmx.de> wrote:
>
>> Updated on the CI :)
>>
>> Best
>> -Tobias
>> On 09.04.2015, at 23:28, Eliot Miranda <eliot.miranda(a)gmail.com> wrote:
>>
>>> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3308/.
>>>
>>> CogVM binaries as per VMMaker.oscog-eem.1178/r3308
>>>
>>> Plugins:
>>> Integrate Nicolas' fixes that use positiveMachineIntegerFor: for pointers.
>>>
>>> Newspeak:
>>> Print a warning in the method shared under multiple selectors scenario.
>>>
>>> Implement outer sends as clean sends just like implicit receiver sends. Add
>>> ObjectRepresentation>>illegalClassTag and use it for initializing and unlinking
>>> implicit and outer sends.
>>>
>>> Newspeak & Sista:
>>> The multiple bytecode set block initial nil counters need
>>> to be specific to the bytecode set in effect.
>>>
>>> Spur:
>>> Implement Clement's much better solution for the stale supersend problem.
>>> Place code at the send site for super sends to follow stale forwarded
>>> receivers. This parallels the interpreter implementation.
>>>
>>> Beef up the post-become scan of send sites to
>>> unlink all send sites that link to an invalid class tag.
>>>
>>> Cogit:
>>> Optimize StackToRegisterMappingCogit>>genReturnReceiver
>>> to not load ReceiverResultReg if it already contains self.
>>>
>>> Revise method map generation to provide multiple send type annotations. Add
>>> an IsAnnotationExtension annotation type that implicitly has a zero displacement
>>> and uses its displacement bits to extend the preceeding IsSendCall annotation.
>>> This allows us to eliminate all the exotic entry-points and keep only the
>>> checked and unchecked entries.
>>>
>>> Change IA32's genPushRegisterArgsForNumArgs: to not smash TempReg now that it
>>> is used in directed super send trampolines.
>>>
>>> Use PushCq to pass small integer constants in the trampolines instead of
>>> smashing TempReg, which is now used to hold the directed supersend argument.
>>> Add support for PushCq. Could use PushCw but on x86 PushCq is a lot shorter.
>>>
>>> Mac builds: Use UTC as the timezone for the build timestamp. Using the local
>>> timezone doesn't work :(.
>
>
>
April 10, 2015
Re: [Pharo-dev] Problem with asClass usage
by stepharo
Le 10/4/15 06:09, Ben Coman a écrit :
> I believe #asClass itself was introduced for a use case to simplify
> Workspace "user interactive" Gofer scripts to retrieve and load
> Configurations. Since this is through away code its not covered by
> your modularity concerns, and I'm not sure if it came before or after
> its friends, but can we retain or substitute something to avoid
> needing ugly "(Smalltalk at: #ConfigurationOfXXX) load" ?
For first time newbee they can also use the Configuration browser.
This is one click.
> This is a "first impression" consideration for people dealing with
> Configurations for the first time (even thought we now have
> Configuration Browser). The use case is that newbies will copy-paste
> a script from a web site to Playground and execute the whole script
> resulting in a error "Unknown class ConfigurationOfXXX." They don't
> know to execute in two separate steps, first "Gofer ... load"
> then "ConfigurationOfXXX load".
Yes it would be much better.
> Alternatively, what if the Metacello package extended Gofer with a
> method #configurationOf: so websites can show...
> config :=
> Gofer new
> url: 'http://smalltalkhub.com/mc/MyProject/main'
> package: 'MyXXXPackage';
> load;
> configurationOf: 'XXX' "return class ConfigurationOfXXX"
> config load.
> ...so the compiler is dealing with a variable "config" rather than
> class 'ConfigurationOfXXX' that it doesn't know yet, or a further
> altenative...
> Gofer new
> url: 'http://smalltalkhub.com/mc/MyProject/main'
> package: 'MyXXXPackage';
> load;
> configurationOf: 'XXX' do: [ :config | config load ];
> configurationOf: 'YYY' do: [ :config | config load ].
> cheers -ben
> On 10/04/2015 4:32 am, "stepharo" <stepharo(a)free.fr
> <mailto:stepharo@free.fr>> wrote:
>
> Hi
>
> We want to raise a strong warning against the extension of the use
> of asClass and friends.
> asClass should not be used in Pharo distribution. I will propose
> to deprecate it.
>
> We are working on dependency analysis, module system, remote
> debugging and asClass introduces
> lose class references and many related problems.
>
> I would like to remove this behavior because it is clear that it
> will just grow up and lead to deadcode and ugly dependencies.
>
> First, most of the time you can avoid to query Smalltalk globals
> at: and that BY CONSTRUCTION a software system should be built
> and it should define its own customization.
>
>
> Second, at least use self class environment at: #foo
>
> Why is it much much much better? because it does not rely on
> String class resolution and as such
> is much more modular. You do not want to have the resolution of a
> symbol related to the place where String is defined but on where
> your code is actually.
>
> Imagine that tomorrow your code is in its own module. Then you
> want to know from your code point of you
> if a binding exist not from the one of environment in which String is.
>
>
>
>
> here are some examples:
>
> ==============================
> quadrangleClass
> ^ 'QuadrangleForTesting' asClass
>
> Strange it simply breaks. Of course it broke the smallLint rule.
>
> ==============================
> Metacello should better define OSProcess as a dependent.Because it
> is not clear what will happen
> if if not there?
>
> extractRepositoryFrom: zipFile to: directory
> "unzip <zipFile> into <directory>"
>
> | out err proc errorMessage |
> out := FileStream forceNewFileNamed: '/tmp/zip.out'.
> err := FileStream forceNewFileNamed: '/tmp/zip.err'.
> errorMessage := ''.
> [
> proc := #OSProcess asClass thisOSProcess
> forkJob: '/usr/bin/unzip'
> arguments:
> {'-u'.
> zipFile.
> '-d'.
> directory}
> environment: nil
> descriptors: (Array with: nil with: out with: err).
>
> ==================
>
> I do not get why we need this funky logic.
>
> openInBrickWindowLabeled: aLabel
>
> #GLMSystemWindowBrick asClassIfAbsent: [
> ^ self asMorph openInWindow ].
>
> ^ #GLMSystemWindowBrick asClass new
> label: aLabel;
> color: Color transparent;
> addBrickBack: (
> GLMBrick new
> vSpaceFill
>
>
> window
> "Answer the receiver's window."
> #GLMWindowBrick asClassIfAbsent: [
> ^ self ownerThatIsA: SystemWindow ].
>
> ^ (self ownerThatIsA: #GLMWindowBrick asClass)
> ifNil: [ self ownerThatIsA: SystemWindow ]
>
>
>
> sendUsageData: aBoolean
> | settingsClass |
> settingsClass := #GTSpotterEventRecorderSettings
> asClassIfAbsent: [ ^ self ].
> ^ settingsClass sendUsageData: aBoolean
>
>
> sendUsageData
> | settingsClass |
> settingsClass := #GTSpotterEventRecorderSettings
> asClassIfAbsent: [ ^ false ].
> ^ settingsClass sendUsageData
>
>
April 10, 2015
Re: [Pharo-dev] Problem with asClass usage
by Ben Coman
I believe #asClass itself was introduced for a use case to simplify
Workspace "user interactive" Gofer scripts to retrieve and load
Configurations. Since this is through away code its not covered by your
modularity concerns, and I'm not sure if it came before or after its
friends, but can we retain or substitute something to avoid needing
ugly "(Smalltalk at: #ConfigurationOfXXX) load" ?
This is a "first impression" consideration for people dealing with
Configurations for the first time (even thought we now have Configuration
Browser). The use case is that newbies will copy-paste a script from a web
site to Playground and execute the whole script resulting in a error
"Unknown class ConfigurationOfXXX." They don't know to execute in two
separate steps, first "Gofer ... load" then "ConfigurationOfXXX load".
Alternatively, what if the Metacello package extended Gofer with a method
#configurationOf: so websites can show...
config :=
Gofer new
url: 'http://smalltalkhub.com/mc/MyProject/main'
package: 'MyXXXPackage';
load;
configurationOf: 'XXX' "return class ConfigurationOfXXX"
config load.
...so the compiler is dealing with a variable "config" rather than class
'ConfigurationOfXXX' that it doesn't know yet, or a further altenative...
Gofer new
url: 'http://smalltalkhub.com/mc/MyProject/main'
package: 'MyXXXPackage';
load;
configurationOf: 'XXX' do: [ :config | config load ];
configurationOf: 'YYY' do: [ :config | config load ].
cheers -ben
On 10/04/2015 4:32 am, "stepharo" <stepharo(a)free.fr> wrote:
> Hi
>
> We want to raise a strong warning against the extension of the use of
> asClass and friends.
> asClass should not be used in Pharo distribution. I will propose to
> deprecate it.
>
> We are working on dependency analysis, module system, remote debugging and
> asClass introduces
> lose class references and many related problems.
>
> I would like to remove this behavior because it is clear that it will just
> grow up and lead to deadcode and ugly dependencies.
>
> First, most of the time you can avoid to query Smalltalk globals at: and
> that BY CONSTRUCTION a software system should be built and it should
> define its own customization.
>
>
> Second, at least use self class environment at: #foo
>
> Why is it much much much better? because it does not rely on String class
> resolution and as such
> is much more modular. You do not want to have the resolution of a symbol
> related to the place where String is defined but on where your code is
> actually.
>
> Imagine that tomorrow your code is in its own module. Then you want to
> know from your code point of you
> if a binding exist not from the one of environment in which String is.
>
>
>
>
> here are some examples:
>
> ==============================
> quadrangleClass
> ^ 'QuadrangleForTesting' asClass
>
> Strange it simply breaks. Of course it broke the smallLint rule.
>
> ==============================
> Metacello should better define OSProcess as a dependent.Because it is not
> clear what will happen
> if if not there?
>
> extractRepositoryFrom: zipFile to: directory
> "unzip <zipFile> into <directory>"
>
> | out err proc errorMessage |
> out := FileStream forceNewFileNamed: '/tmp/zip.out'.
> err := FileStream forceNewFileNamed: '/tmp/zip.err'.
> errorMessage := ''.
> [
> proc := #OSProcess asClass thisOSProcess
> forkJob: '/usr/bin/unzip'
> arguments:
> {'-u'.
> zipFile.
> '-d'.
> directory}
> environment: nil
> descriptors: (Array with: nil with: out with: err).
>
> ==================
>
> I do not get why we need this funky logic.
>
> openInBrickWindowLabeled: aLabel
>
> #GLMSystemWindowBrick asClassIfAbsent: [
> ^ self asMorph openInWindow ].
>
> ^ #GLMSystemWindowBrick asClass new
> label: aLabel;
> color: Color transparent;
> addBrickBack: (
> GLMBrick new
> vSpaceFill
>
>
> window
> "Answer the receiver's window."
> #GLMWindowBrick asClassIfAbsent: [
> ^ self ownerThatIsA: SystemWindow ].
>
> ^ (self ownerThatIsA: #GLMWindowBrick asClass)
> ifNil: [ self ownerThatIsA: SystemWindow ]
>
>
>
> sendUsageData: aBoolean
> | settingsClass |
> settingsClass := #GTSpotterEventRecorderSettings asClassIfAbsent: [ ^
> self ].
> ^ settingsClass sendUsageData: aBoolean
>
>
> sendUsageData
> | settingsClass |
> settingsClass := #GTSpotterEventRecorderSettings asClassIfAbsent: [ ^
> false ].
> ^ settingsClass sendUsageData
>
>
>
April 10, 2015
Re: [Pharo-dev] why we removed debugTest from nautilus?
by Clément Bera
I was using it frequently too and I have never experienced any issues...
2015-04-09 14:58 GMT-07:00 Nicolai Hess <nicolaihess(a)web.de>:
>
> 2015-04-09 23:38 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>:
>
>> No Debug Tests?
>>
>> Geez, I am using that all the time.
>>
>
> And you're never encountered this issue 14689
> <https://pharo.fogbugz.com/default.asp?14689>?
> Or did this work in older versions?
>
>
>
>
>>
>> Phil
>>
>>
>> On Thu, Apr 9, 2015 at 10:21 PM, Marcus Denker <marcus.denker(a)inria.fr>
>> wrote:
>>
>>>
>>> > On 09 Apr 2015, at 22:32, Sean P. DeNigris <sean(a)clipperadams.com>
>>> wrote:
>>> >
>>> > Nicolai Hess wrote
>>> >>
>>> http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-…
>>> >
>>> > Ah, I miss that too! From that thread, it seems it was removed
>>> temporarily
>>> > until we have real breakpoints. Is there an issue for its return?
>>> >
>>>
>>> Not yet.
>>>
>>> Marcus
>>>
>>
>>
>
April 10, 2015
Re: [Pharo-dev] New Cog VMs available
by Tobias Pape
Sorry the noise, did not look on whereto I replied.
:/
Best
-Tobias
On 10.04.2015, at 00:16, Tobias Pape <Das.Linux(a)gmx.de> wrote:
> Updated on the CI :)
>
> Best
> -Tobias
> On 09.04.2015, at 23:28, Eliot Miranda <eliot.miranda(a)gmail.com> wrote:
>
>> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3308/.
>>
>> CogVM binaries as per VMMaker.oscog-eem.1178/r3308
>>
>> Plugins:
>> Integrate Nicolas' fixes that use positiveMachineIntegerFor: for pointers.
>>
>> Newspeak:
>> Print a warning in the method shared under multiple selectors scenario.
>>
>> Implement outer sends as clean sends just like implicit receiver sends. Add
>> ObjectRepresentation>>illegalClassTag and use it for initializing and unlinking
>> implicit and outer sends.
>>
>> Newspeak & Sista:
>> The multiple bytecode set block initial nil counters need
>> to be specific to the bytecode set in effect.
>>
>> Spur:
>> Implement Clement's much better solution for the stale supersend problem.
>> Place code at the send site for super sends to follow stale forwarded
>> receivers. This parallels the interpreter implementation.
>>
>> Beef up the post-become scan of send sites to
>> unlink all send sites that link to an invalid class tag.
>>
>> Cogit:
>> Optimize StackToRegisterMappingCogit>>genReturnReceiver
>> to not load ReceiverResultReg if it already contains self.
>>
>> Revise method map generation to provide multiple send type annotations. Add
>> an IsAnnotationExtension annotation type that implicitly has a zero displacement
>> and uses its displacement bits to extend the preceeding IsSendCall annotation.
>> This allows us to eliminate all the exotic entry-points and keep only the
>> checked and unchecked entries.
>>
>> Change IA32's genPushRegisterArgsForNumArgs: to not smash TempReg now that it
>> is used in directed super send trampolines.
>>
>> Use PushCq to pass small integer constants in the trampolines instead of
>> smashing TempReg, which is now used to hold the directed supersend argument.
>> Add support for PushCq. Could use PushCw but on x86 PushCq is a lot shorter.
>>
>> Mac builds: Use UTC as the timezone for the build timestamp. Using the local
>> timezone doesn't work :(.
April 9, 2015
Re: [Pharo-dev] New Cog VMs available
by Tobias Pape
Updated on the CI :)
Best
-Tobias
On 09.04.2015, at 23:28, Eliot Miranda <eliot.miranda(a)gmail.com> wrote:
> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3308/.
>
> CogVM binaries as per VMMaker.oscog-eem.1178/r3308
>
> Plugins:
> Integrate Nicolas' fixes that use positiveMachineIntegerFor: for pointers.
>
> Newspeak:
> Print a warning in the method shared under multiple selectors scenario.
>
> Implement outer sends as clean sends just like implicit receiver sends. Add
> ObjectRepresentation>>illegalClassTag and use it for initializing and unlinking
> implicit and outer sends.
>
> Newspeak & Sista:
> The multiple bytecode set block initial nil counters need
> to be specific to the bytecode set in effect.
>
> Spur:
> Implement Clement's much better solution for the stale supersend problem.
> Place code at the send site for super sends to follow stale forwarded
> receivers. This parallels the interpreter implementation.
>
> Beef up the post-become scan of send sites to
> unlink all send sites that link to an invalid class tag.
>
> Cogit:
> Optimize StackToRegisterMappingCogit>>genReturnReceiver
> to not load ReceiverResultReg if it already contains self.
>
> Revise method map generation to provide multiple send type annotations. Add
> an IsAnnotationExtension annotation type that implicitly has a zero displacement
> and uses its displacement bits to extend the preceeding IsSendCall annotation.
> This allows us to eliminate all the exotic entry-points and keep only the
> checked and unchecked entries.
>
> Change IA32's genPushRegisterArgsForNumArgs: to not smash TempReg now that it
> is used in directed super send trampolines.
>
> Use PushCq to pass small integer constants in the trampolines instead of
> smashing TempReg, which is now used to hold the directed supersend argument.
> Add support for PushCq. Could use PushCw but on x86 PushCq is a lot shorter.
>
> Mac builds: Use UTC as the timezone for the build timestamp. Using the local
> timezone doesn't work :(.
April 9, 2015
Re: [Pharo-dev] why we removed debugTest from nautilus?
by Nicolai Hess
2015-04-09 23:38 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>:
> No Debug Tests?
>
> Geez, I am using that all the time.
>
And you're never encountered this issue 14689
<https://pharo.fogbugz.com/default.asp?14689>?
Or did this work in older versions?
>
> Phil
>
>
> On Thu, Apr 9, 2015 at 10:21 PM, Marcus Denker <marcus.denker(a)inria.fr>
> wrote:
>
>>
>> > On 09 Apr 2015, at 22:32, Sean P. DeNigris <sean(a)clipperadams.com>
>> wrote:
>> >
>> > Nicolai Hess wrote
>> >>
>> http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-…
>> >
>> > Ah, I miss that too! From that thread, it seems it was removed
>> temporarily
>> > until we have real breakpoints. Is there an issue for its return?
>> >
>>
>> Not yet.
>>
>> Marcus
>>
>
>
April 9, 2015