April 2014 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 6f764a: 30830

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 6f764a96b114e9f78ea25bb8f7042e0d6fc47bd0 https://github.com/pharo-project/pharo-core/commit/6f764a96b114e9f78ea25bb8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-04-24 (Thu, 24 Apr 2014) Changed paths: A Kernel.package/Class.class/instance/accessing class hierarchy/addSubclass_.st M Slot.package/PharoClassInstaller.class/instance/migrating/updateClass_to_.st M Slot.package/PharoClassInstaller.class/instance/notifications/basicClassDefinitionChangedFrom_to_using_.st M Slot.package/SlotClassBuilder.class/instance/private/applyAndUpdateSharedVariableOrSharedPool_.st M SlotTests.package/SlotClassBuilderTest.class/instance/running/tearDown.st A SlotTests.package/SlotClassVariableTest.class/README.md A SlotTests.package/SlotClassVariableTest.class/definition.st A SlotTests.package/SlotClassVariableTest.class/instance/tests/testClassVariableDoesNotDuplicatesSubclassesOfSuperclass.st M Traits.package/TClass.class/instance/accessing class hierarchy/addSubclass_.st A Traits.package/Trait.class/instance/accessing class hierarchy/addSubclass_.st Log Message: ----------- 30830 http://files.pharo.org/image/30/30830.zip

April 24, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 1953a9: 30829

by Marcus Denker

On 23 Apr 2014, at 19:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 23 Apr 2014, at 19:21, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> >> On 23 avr. 2014, at 19:00, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 23 Apr 2014, at 18:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> >>>> On 23 Apr 2014, at 18:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>>> And we're all GREEN, great work ! >>>>> Let's keep it that way until release. >>>>> Everything that breaks a test should now be reverted. >>>>> >>>> Yes! >>>> >>>> there are just two issues that are for pharo3 with fixes: >>>> >>>> https://pharo.fogbugz.com/f/cases/13028/Adding-ClassVariables-corrupts-clas… >>>> >>> >>> Ok, so loading that one brakes *everything*. >>> >>> (the build did not get done, so no problem, other than a red build) >>> >>> I will revert tomorrow... >> >> Arg, I'm sick of that issue. >> So do we try to integrate it in two passes? >> > > I have no idea what goes wrongâ¦ it seems that it works fine when I merge the slice. > But then the update process (which just saved the packagesâ¦) does something wrong. > > Mayeb we could try to have a version without the method that sends #explicitRequirement > I integrated the issue as a change set (so there is some load order bug related to Traits with MCâ¦). This seems to have worked: all image tests are green. BUT: the Metacello Platformtests fail with a âshould not happenâ error. https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.3-MetacelloValidation… (it would have been nice to have integrated this issue 2 weeks agoâ¦) Fetched -> Metacello-TestsPlatform.squeakCommon-dkh.11 --- github://dalehenrich/metacello-work:master/repository --- github://dalehenrich/metacello-work:master/repository[31mError: Should not happen [0mLayoutEmptyScope(Object)>>error: LayoutEmptyScope(LayoutAbstractScope)>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: FixedLayout(ObjectLayout)>>reshapeFrom:to: ClassModificationPropagation>>propagate:to: ClassModificationPropagation class>>propagate:to: ClassModification(AbstractClassModification)>>propagate in Block: [ :subclass | propagations add: (ClassModification...etc... Metaclass>>subclassesDo: in Block: [ :aSubclass | ... Array(SequenceableCollection)>>do: MCFileTreeFileUtils class(Class)>>subclassesDo: Metaclass>>subclassesDo: ClassModification(AbstractClassModification)>>propagate SlotClassBuilder>>applyAndUpdateSharedVariableOrSharedPool: in Block: [ :old :new | ... SlotClassBuilder>>track:during: SlotClassBuilder>>applyAndUpdateSharedVariableOrSharedPool: SlotClassBuilder>>applySharedVariableOrPoolChange: SlotClassBuilder>>apply: SlotClassBuilder>>build PharoClassInstaller class(AbstractClassInstaller class)>>make: OldClassBuilderAdapter>>name:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category: MCClassDefinition>>createClass in Block: [ ... BlockClosure>>on:do:

April 24, 2014

Re: [Pharo-dev] Debugging in Production Servers

by S Krish

The good developers / expert users will not do what you state. The eclipse debug, inspector, watches are very much part of a normal dev cycle in our place with around 100 devs. Even in Smalltalk I have seen less capable developers not exploiting even a fraction of the capability Smalltalk has and depend on loggers / prints to transcripts and lot less use of reflection live to inquire and detect issues faster. The issue I explained is that the capability exists and is not exploited due to process constraints in the industry even for Java, so Smalltalk capability will not be seen as a killer feature per se even if its more flexible and capable. The reflection to dump more logger information is of course most welcome but without adding any performance overhead at runtime except when the error occurs. I would further aver that all the Smalltalk capabilities are highly leveraged in a dev environment and is capable of cutting dev time to one third or even lesser in the hands of an expert. On Thu, Apr 24, 2014 at 11:12 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > I am sorry, but I disagree. > > Yes, technically, much of what we take for granted is partially possible > in most other languages, but it is often hard to use, an add-on, an > afterthought. But more important, Java developers even do not use > debuggers/inspectors/browsers during development, let alone during > production. It's just edit/compile/run/crash - add some print statements > and run again. During production its all massive plain logging. > > We can dump live stacks with FUEL for example. > > On 24 Apr 2014, at 06:01, S Krish <krishnamachari.sudhakar(a)gmail.com> > wrote: > > > One can easily do that with Java / Eclipse or for VC++ / Visual Studio > with attach to process. Probably I would reckon these to be more "secure" > as industry prefers rather than having live debug capabilities built in to > the code delivered or somehow "in-process". I am sure all others as in > python, ruby et als will have debug in prod capabilities if reqd. > > > > Javascript with Rhino also can easily allow live debug if the reqd jar > is present.. > > > > The bigger purchase Smalltalk gives is in reflection that can be > leveraged to produce fairly extensive logger reports which no other > langauge currently does when fault occurs in production. > > > > I doubt in production the industry is as of now willing to let debug be > acceptable specially in Banking domain. > > > > The smalltalk advantages are not translating into business gains per se > given the comfort zone of security, safety production systems are wrapped > in procedurally. > > > > > > On Thu, Apr 24, 2014 at 7:39 AM, askoh <askoh(a)askoh.com> wrote: > > Smalltalk has the capability of allowing live debugging in production > > servers. How unique is this capability? What other systems allow that? > > > > Is there a name for such capability? Can we coin one and market it? > > > > What are the pros and cons of having such a capability? > > > > All the best, > > Aik-Siong Koh > > > > > > > > -- > > View this message in context: > http://forum.world.st/Debugging-in-Production-Servers-tp4756136.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > >

April 24, 2014

Re: [Pharo-dev] Debugging in Production Servers

by Sven Van Caekenberghe

I am sorry, but I disagree. Yes, technically, much of what we take for granted is partially possible in most other languages, but it is often hard to use, an add-on, an afterthought. But more important, Java developers even do not use debuggers/inspectors/browsers during development, let alone during production. It's just edit/compile/run/crash - add some print statements and run again. During production its all massive plain logging. We can dump live stacks with FUEL for example. On 24 Apr 2014, at 06:01, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > One can easily do that with Java / Eclipse or for VC++ / Visual Studio with attach to process. Probably I would reckon these to be more "secure" as industry prefers rather than having live debug capabilities built in to the code delivered or somehow "in-process". I am sure all others as in python, ruby et als will have debug in prod capabilities if reqd. > > Javascript with Rhino also can easily allow live debug if the reqd jar is present.. > > The bigger purchase Smalltalk gives is in reflection that can be leveraged to produce fairly extensive logger reports which no other langauge currently does when fault occurs in production. > > I doubt in production the industry is as of now willing to let debug be acceptable specially in Banking domain. > > The smalltalk advantages are not translating into business gains per se given the comfort zone of security, safety production systems are wrapped in procedurally. > > > On Thu, Apr 24, 2014 at 7:39 AM, askoh <askoh(a)askoh.com> wrote: > Smalltalk has the capability of allowing live debugging in production > servers. How unique is this capability? What other systems allow that? > > Is there a name for such capability? Can we coin one and market it? > > What are the pros and cons of having such a capability? > > All the best, > Aik-Siong Koh > > > > -- > View this message in context: http://forum.world.st/Debugging-in-Production-Servers-tp4756136.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

April 24, 2014

Re: [Pharo-dev] Debugging in Production Servers

by S Krish

The capability exists, any dev team can take advantage if reqd of it, I am sure many may have in rare occassions. On the remote on the same LAN it will not be any different than debug is for eclipse / VisualStudio in dev. In Insurance, Banking in my experience, it will be the last resort, unless it is critical and there is no other alternative to it but with production data set. As I reiterated the reflection based data gathering that can enabled along with the superb exception handling capability it is something that is leveraged by smalltalk in production ( Unicycle reports in VA) and that is terrific for resolving bugs. Reflection based tools like in Groovy can bring any Java system close to Smalltalk offers also in production as I have done in my work place. On Thu, Apr 24, 2014 at 9:50 AM, askoh <askoh(a)askoh.com> wrote: > Thanks for reply. Are there cases of Java/Eclipse running in Production? > Similarly with VC++ / Visual Studio? They would be very very slow wouldn't > they? > > I am referring to real use case of live debugging in Production servers. I > agree that this capability might not be attractive from point of view of > security and safety. But there are insurance and financial companies that > use Smalltalk. How do they view this capability? Do they forbid it totally? > If they allow it, how do they prevent abuse? > > The pros is of course the easy of finding bugs and inspection of states > during production. > > All the best, > Aik-Siong Koh > > > > -- > View this message in context: > http://forum.world.st/Debugging-in-Production-Servers-tp4756136p4756141.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 24, 2014

Re: [Pharo-dev] Debugging in Production Servers

by askoh

Thanks for reply. Are there cases of Java/Eclipse running in Production? Similarly with VC++ / Visual Studio? They would be very very slow wouldn't they? I am referring to real use case of live debugging in Production servers. I agree that this capability might not be attractive from point of view of security and safety. But there are insurance and financial companies that use Smalltalk. How do they view this capability? Do they forbid it totally? If they allow it, how do they prevent abuse? The pros is of course the easy of finding bugs and inspection of states during production. All the best, Aik-Siong Koh -- View this message in context: http://forum.world.st/Debugging-in-Production-Servers-tp4756136p4756141.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 24, 2014

Re: [Pharo-dev] Debugging in Production Servers

by S Krish

One can easily do that with Java / Eclipse or for VC++ / Visual Studio with attach to process. Probably I would reckon these to be more "secure" as industry prefers rather than having live debug capabilities built in to the code delivered or somehow "in-process". I am sure all others as in python, ruby et als will have debug in prod capabilities if reqd. Javascript with Rhino also can easily allow live debug if the reqd jar is present.. The bigger purchase Smalltalk gives is in reflection that can be leveraged to produce fairly extensive logger reports which no other langauge currently does when fault occurs in production. I doubt in production the industry is as of now willing to let debug be acceptable specially in Banking domain. The smalltalk advantages are not translating into business gains per se given the comfort zone of security, safety production systems are wrapped in procedurally. On Thu, Apr 24, 2014 at 7:39 AM, askoh <askoh(a)askoh.com> wrote: > Smalltalk has the capability of allowing live debugging in production > servers. How unique is this capability? What other systems allow that? > > Is there a name for such capability? Can we coin one and market it? > > What are the pros and cons of having such a capability? > > All the best, > Aik-Siong Koh > > > > -- > View this message in context: > http://forum.world.st/Debugging-in-Production-Servers-tp4756136.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 24, 2014

Re: [Pharo-dev] [Pharo CI] Linux slave problem solved

by Serge Stinckwich

Pharo and MOOSE CI seems to be in good condition now, but pharo-contribution still broken apparently. On Wed, Apr 23, 2014 at 3:28 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > The problem with the linux slaves is fixedâ¦ things should get normal again. > > " there was an inconsistency between libvirt (used on CloudStack's hypervisor nodes) > and the configuration of system's locale. As a consequence, a CloudStack test was failing sometimes, > leading to the removal of all the iptables rules and thus, to a full network disruption.â > > Seemingly that was quite hard to findâ¦ > > Marcus -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

April 24, 2014

Debugging in Production Servers

by askoh

Smalltalk has the capability of allowing live debugging in production servers. How unique is this capability? What other systems allow that? Is there a name for such capability? Can we coin one and market it? What are the pros and cons of having such a capability? All the best, Aik-Siong Koh -- View this message in context: http://forum.world.st/Debugging-in-Production-Servers-tp4756136.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 24, 2014

Pharo Inbox now Public Writable

by Sean P. DeNigris

IIRC you still need to be logged in... <http://forum.world.st/file/n4756131/Pharo_Inbox.png> ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-Inbox-now-Public-Writable-tp4756131.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 24, 2014