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

Re: [Pharo-dev] Stable Mac VM for latest 3.0?

by Marcus Denker

On 24 Apr 2014, at 13:23, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > OK, so it crashes loading NBOpenGL-Core from http://www.smalltalkhub.com/mc/PharoExtras/NBOpenGL/main. > > The Pharo VM includes NBâ¦ right? > Yes! > Cheers, > Henry > > On 24 Apr 2014, at 12:52 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> I tried loading Roassal3d into 30830 using >> Gofer new smalltalkhubUser: 'ronsaldo' project: 'roassal3d'; package: 'ConfigurationOfRoassal3d'; load. (Smalltalk at: #ConfigurationOfRoassal3d) loadDevelopment >> >> using both the VM linked at >> http://files.pharo.org/vm/pharo/mac/Pharo-VM-mac-stable.zip (from December?) >> and the latest successful from CI >> https://ci.inria.fr/pharo/view/3.0-VM/job/PharoVM/Architecture=32,Slave=vm-… >> >> And both crash for me during load (attached report)â¦ >> >> Anyone know where a VM which works is located? >> >> Cheers, >> Henry >> >> <VMcrash.rtf> >

April 24, 2014

Re: [Pharo-dev] Stable Mac VM for latest 3.0?

by Henrik Johansen

OK, so it crashes loading NBOpenGL-Core from http://www.smalltalkhub.com/mc/PharoExtras/NBOpenGL/main. The Pharo VM includes NBâ¦ right? Cheers, Henry On 24 Apr 2014, at 12:52 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > I tried loading Roassal3d into 30830 using > Gofer new smalltalkhubUser: 'ronsaldo' project: 'roassal3d'; package: 'ConfigurationOfRoassal3d'; load. (Smalltalk at: #ConfigurationOfRoassal3d) loadDevelopment > > using both the VM linked at > http://files.pharo.org/vm/pharo/mac/Pharo-VM-mac-stable.zip (from December?) > and the latest successful from CI > https://ci.inria.fr/pharo/view/3.0-VM/job/PharoVM/Architecture=32,Slave=vm-… > > And both crash for me during load (attached report)â¦ > > Anyone know where a VM which works is located? > > Cheers, > Henry > > <VMcrash.rtf>

April 24, 2014

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

by Marcus Denker

On 24 Apr 2014, at 12:12, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Ok thank you Marcus ! > Missing my continuous dose of working images ;-) > The slaves are online again (thanks to Damien Cassou). But now we have the problem that in Pharo3, on load, the VM crashes for same casesâ¦ and no clue why this suddenly happens now. > 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

Stable Mac VM for latest 3.0?

by Henrik Johansen

I tried loading Roassal3d into 30830 using Gofer new smalltalkhubUser: 'ronsaldo' project: 'roassal3d'; package: 'ConfigurationOfRoassal3d'; load. (Smalltalk at: #ConfigurationOfRoassal3d) loadDevelopment using both the VM linked at http://files.pharo.org/vm/pharo/mac/Pharo-VM-mac-stable.zip (from December?) and the latest successful from CI https://ci.inria.fr/pharo/view/3.0-VM/job/PharoVM/Architecture=32,Slave=vm-… And both crash for me during load (attached report)â¦ Anyone know where a VM which works is located? Cheers, Henry

April 24, 2014

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