- Pharo-dev - lists.pharo.org

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

by Serge Stinckwich

Ok thank you Marcus ! Missing my continuous dose of working images ;-) EnvoyÃ© de mon iPhone > Le 24 avr. 2014 Ã 16:17, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > > >> On 24 Apr 2014, at 04:50, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> >> Pharo and MOOSE CI seems to be in good condition now, but >> pharo-contribution still broken apparently. > > We are looking at this now... > >> >>> 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

Re: [Pharo-dev] Debugging in Production Servers

by kilon alios

"You do not have to stop while it is running in production and you can change and inspect or even fix the program at will. With all the up's and downs of this approach." Visual Studio can do this with Edit and Continue https://www.youtube.com/watch?v=M6J34B37wUc So the world definitely starts to catch up with Smalltalk. Which can only be a good thing. On Thu, Apr 24, 2014 at 12:26 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >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. > > This is not a problem of being expert or not. In languages like C/C++ you > often need > to deploy additional debug infos with the runtime (debug symbols in COFF, > ...) to get > anything useful - which usually is not done by default and needs > additional effort > if you want to debug in production. > > Situation in Java is better from the tooling side because there are no > different > CPU architectures/instruction sets to consider - just one bytecode set and > one JVM. > There are nice tools to monitor or debug - but still you have to run the > JVM with > debug option and debugging from the external side to get the right > debugging experience > with stepping through the code. > > So if you want to debug a web-app in Java the same way you debug at > development time > you would have to restart your JBoss, Websphere, ... and connect to a > specific debug port. > That is usually not done in a productive Java app because of a production > downtime, > limited developer access to it, ... > And yes - there is JMX with MBeans, but this is more for monitoring than > real debugging. > > > Comparing inspectors of Eclipse with the inspectors of Smalltalk is > comparing apples > with oranges. For sure Eclipse has catched up with the IDE and is now also > providing inspectors in the UI, also allows evaluating limited expression > and > good watches. > > In Smalltalk you can implement you own inspectors/install them at > runtime/change > similar to anything other. You can even load new tools and later remove > them while running. > As we know Smalltalk is different in many regards. > > Typical Debugging in other languages is often dealing with the already > deceased. > Developers work with logging info from production or at a crashed heap > dump, etc. > Errors are then often reproduced back in the IDE/dev environment. > > Unfortunately this often means additional costs and more time before a fix > is ready > - but the World seems to be satisfied with this already > > In Smalltalk you can easily catch specific cases while running. You can > easily > add code at runtime to check issues (if developer tools are not stripped): > > shopItem id = 1234567 ifTrue: [ shopItem inspect ] > > and even save a copy of the image at a specific point in time/situation > for offline > inspection. This is not comparable to a dump because the time to debug in > ST tends to zero. > While in Java you have to resetup the environment/IDE with the code > version, etc. > > You can even manipulate and fix data in production easily with Smalltalk: > > shopItem id = 1234567 ifTrue: [ shopItem price: 12.3s2 ] > > And ... you can also shoot yourself in the foot if not done carefully ;) > > Debugging in Smalltalk is different: you do not debug from the outside - > you > do not have to restart the program and navigate to the point where it > happened. > If the developer tools are included you can just switch and use them. You > also > do not have to recompile the whole thing when you found the problem. If > there > is an easy workaround you can directly apply it to your program and later > fix > it in the development stream. > > So Smalltalk - as a changeable dynamic object system - is here more > comparable to a database. > You do not have to stop while it is running in production and you can > change and > inspect or even fix the program at will. With all the up's and downs of > this approach. > > I doubt that this could/should be marketed as a killer feature. We should > keep > it as our own little secret. > > But it is not only a question of technical feasability: often "production > environment" > is seen as "holy" and "untouchable" for other reasons like security. So > nobody > is missing something when the developers do not debug/work directly in > production. > > Bye > T. > > > > > > > > >

April 24, 2014

Re: [Pharo-dev] Debugging in Production Servers

by Torsten Bergmann

>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. This is not a problem of being expert or not. In languages like C/C++ you often need to deploy additional debug infos with the runtime (debug symbols in COFF, ...) to get anything useful - which usually is not done by default and needs additional effort if you want to debug in production. Situation in Java is better from the tooling side because there are no different CPU architectures/instruction sets to consider - just one bytecode set and one JVM. There are nice tools to monitor or debug - but still you have to run the JVM with debug option and debugging from the external side to get the right debugging experience with stepping through the code. So if you want to debug a web-app in Java the same way you debug at development time you would have to restart your JBoss, Websphere, ... and connect to a specific debug port. That is usually not done in a productive Java app because of a production downtime, limited developer access to it, ... And yes - there is JMX with MBeans, but this is more for monitoring than real debugging. Comparing inspectors of Eclipse with the inspectors of Smalltalk is comparing apples with oranges. For sure Eclipse has catched up with the IDE and is now also providing inspectors in the UI, also allows evaluating limited expression and good watches. In Smalltalk you can implement you own inspectors/install them at runtime/change similar to anything other. You can even load new tools and later remove them while running. As we know Smalltalk is different in many regards. Typical Debugging in other languages is often dealing with the already deceased. Developers work with logging info from production or at a crashed heap dump, etc. Errors are then often reproduced back in the IDE/dev environment. Unfortunately this often means additional costs and more time before a fix is ready - but the World seems to be satisfied with this already In Smalltalk you can easily catch specific cases while running. You can easily add code at runtime to check issues (if developer tools are not stripped): shopItem id = 1234567 ifTrue: [ shopItem inspect ] and even save a copy of the image at a specific point in time/situation for offline inspection. This is not comparable to a dump because the time to debug in ST tends to zero. While in Java you have to resetup the environment/IDE with the code version, etc. You can even manipulate and fix data in production easily with Smalltalk: shopItem id = 1234567 ifTrue: [ shopItem price: 12.3s2 ] And ... you can also shoot yourself in the foot if not done carefully ;) Debugging in Smalltalk is different: you do not debug from the outside - you do not have to restart the program and navigate to the point where it happened. If the developer tools are included you can just switch and use them. You also do not have to recompile the whole thing when you found the problem. If there is an easy workaround you can directly apply it to your program and later fix it in the development stream. So Smalltalk - as a changeable dynamic object system - is here more comparable to a database. You do not have to stop while it is running in production and you can change and inspect or even fix the program at will. With all the up's and downs of this approach. I doubt that this could/should be marketed as a killer feature. We should keep it as our own little secret. But it is not only a question of technical feasability: often "production environment" is seen as "holy" and "untouchable" for other reasons like security. So nobody is missing something when the developers do not debug/work directly in production. Bye T. Â

April 24, 2014

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

by Marcus Denker

On 24 Apr 2014, at 04:50, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Pharo and MOOSE CI seems to be in good condition now, but > pharo-contribution still broken apparently. > We are looking at this now... > > 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

Re: [Pharo-dev] GUI TestRunner failures not found by CI (was Re: [pharo-project/pharo-core] 1953a9: 30829)

by Sven Van Caekenberghe

On 23 Apr 2014, at 23:27, Ben Coman <btc(a)openInWorld.com> wrote: > Agreed, but can you confirm that TestRunner GUI shows all-green for yourself. No, it is not all green, as to be expected: 11850 run, 11797 passes, 15 skipped, 43 expected failures, 6 failures, 4 errors, 0 unexpected passes Failures: ReleaseTest>>#testUnknownProcesses MetacelloDevelopmentCycleTutorialTests>>#testCreateNewDevelopment MetacelloDevelopmentCycleTutorialTests>>#testValidateAndSave JobTest>>#testCurrent ReleaseTest>>#testObsoleteClasses MetacelloDevelopmentCycleTutorialTests>>#testCreateDevelopment Errors: MetacelloDevelopmentCycleTutorialTests>>#testCreateNewBaseline MetacelloDevelopmentCycleTutorialTests>>#testCreateNewDevelopment MetacelloDevelopmentCycleTutorialTests>>#testReleaseDevelopment MetacelloDevelopmentCycleTutorialTests>>#testValidateAndSave And my system details are: Image ----- /Users/sven/Develop/git/IntegrationScripts/current/Pharo.image Pharo3.0 Latest update: #30830 Unnamed Virtual Machine --------------- /Users/sven/Develop/Smalltalk/Pharo3.0.app/Contents/MacOS/Pharo NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013

April 24, 2014

[pharo-project/pharo-core]

by GitHub

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

April 24, 2014

[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