Re: [Pharo-dev] Debugging in Production Servers
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 s...@stfx.euwrote: 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.sudha...@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 as...@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.
Re: [Pharo-dev] [pharo-project/pharo-core] 1953a9: 30829
On 23 Apr 2014, at 19:30, Marcus Denker marcus.den...@inria.fr wrote: On 23 Apr 2014, at 19:21, Camille Teruel camille.ter...@gmail.com wrote: On 23 avr. 2014, at 19:00, Marcus Denker marcus.den...@inria.fr wrote: On 23 Apr 2014, at 18:34, Marcus Denker marcus.den...@inria.fr wrote: On 23 Apr 2014, at 18:18, Sven Van Caekenberghe s...@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-class-hierarchy 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/label=linux-stable-worker/388/consoleText (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: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: FixedLayout(ObjectLayout)reshapeFrom:to: ClassModificationPropagationpropagate:to: ClassModificationPropagation classpropagate:to: ClassModification(AbstractClassModification)propagate in Block: [ :subclass | propagations add: (ClassModification...etc... MetaclasssubclassesDo: in Block: [ :aSubclass | ... Array(SequenceableCollection)do: MCFileTreeFileUtils class(Class)subclassesDo: MetaclasssubclassesDo: ClassModification(AbstractClassModification)propagate SlotClassBuilderapplyAndUpdateSharedVariableOrSharedPool: in Block: [ :old :new | ... SlotClassBuildertrack:during: SlotClassBuilderapplyAndUpdateSharedVariableOrSharedPool: SlotClassBuilderapplySharedVariableOrPoolChange: SlotClassBuilderapply: SlotClassBuilderbuild PharoClassInstaller class(AbstractClassInstaller class)make: OldClassBuilderAdaptername:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category: MCClassDefinitioncreateClass in Block: [ ... BlockClosureon:do:
[Pharo-dev] [pharo-project/pharo-core] 6f764a: 30830
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 6f764a96b114e9f78ea25bb8f7042e0d6fc47bd0 https://github.com/pharo-project/pharo-core/commit/6f764a96b114e9f78ea25bb8f7042e0d6fc47bd0 Author: Jenkins Build Server bo...@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
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30830 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] GUI TestRunner failures not found by CI (was Re: [pharo-project/pharo-core] 1953a9: 30829)
On 23 Apr 2014, at 23:27, Ben Coman b...@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 esteba...@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 esteba...@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
Re: [Pharo-dev] [Pharo CI] Linux slave problem solved
On 24 Apr 2014, at 04:50, Serge Stinckwich serge.stinckw...@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.den...@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/
Re: [Pharo-dev] Debugging in Production Servers
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.
Re: [Pharo-dev] Debugging in Production Servers
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 asta...@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.
Re: [Pharo-dev] [Pharo CI] Linux slave problem solved
Ok thank you Marcus ! Missing my continuous dose of working images ;-) Envoyé de mon iPhone Le 24 avr. 2014 à 16:17, Marcus Denker marcus.den...@inria.fr a écrit : On 24 Apr 2014, at 04:50, Serge Stinckwich serge.stinckw...@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.den...@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/
[Pharo-dev] Stable Mac VM for latest 3.0?
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-builder-mac/lastSuccessfulBuild/artifact/337.zip
And both crash for me during load (attached report)…
Anyone know where a VM which works is located?
Cheers,
Henry
{\rtf1\ansi\ansicpg1252\cocoartf1265\cocoasubrtf190
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww10800\viewh8400\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\pardirnatural
\f0\fs24 \cf0 Process: Pharo [2231]\
Path:/Applications/ST VMs/Pharo.app/Contents/MacOS/Pharo\
Identifier: org.pharo-project.Pharo\
Version: Pharo VM 6.0-pre (21.0)\
Code Type: X86 (Native)\
Parent Process: launchd [251]\
Responsible: Pharo [2231]\
User ID: 501\
\
Date/Time: 2014-04-24 12:50:04.839 +0200\
OS Version: Mac OS X 10.9.2 (13C1021)\
Report Version: 11\
Anonymous UUID: 807E8F4D-5002-01D5-CB7B-BAF2D17DAC27\
\
\
Crashed Thread: 0 Dispatch queue: com.apple.main-thread\
\
Exception Type: EXC_BAD_ACCESS (SIGABRT)\
Exception Codes: KERN_INVALID_ADDRESS at 0x40bf1210\
\
VM Regions Near 0x40bf1210:\
__LINKEDIT 40399000-4048 [ 924K] r--/rwx SM=COW /System/Library/Extensions/AppleIntelHD3000GraphicsGLDriver.bundle/Contents/MacOS/AppleIntelHD3000GraphicsGLDriver\
-- \
__TEXT 5000-502b7000 [ 2780K] r-x/rwx SM=COW /System/Library/Extensions/AMDRadeonX3000GLDriver.bundle/Contents/MacOS/AMDRadeonX3000GLDriver\
\
Application Specific Information:\
abort() called\
\
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread\
0 libsystem_kernel.dylib 0x91685952 __pthread_kill + 10\
1 libsystem_pthread.dylib 0x928c2167 pthread_kill + 101\
2 libsystem_c.dylib 0x990fb29c abort + 155\
3 org.pharo-project.Pharo 0x0004a43f sigsegv + 175\
4 libsystem_platform.dylib 0x9b0a4deb _sigtramp + 43\
5 ??? 0x 0 + 4294967295\
\
Thread 1:: Dispatch queue: com.apple.libdispatch-manager\
0 libsystem_kernel.dylib 0x91686992 kevent64 + 10\
1 libdispatch.dylib 0x997cb8ad _dispatch_mgr_invoke + 238\
2 libdispatch.dylib 0x997cb546 _dispatch_mgr_thread + 52\
\
Thread 2:\
0 libsystem_kernel.dylib 0x91680f7a mach_msg_trap + 10\
1 libsystem_kernel.dylib 0x9168016c mach_msg + 68\
2 com.apple.CoreFoundation 0x98e87c09 __CFRunLoopServiceMachPort + 169\
3 com.apple.CoreFoundation 0x98e871e1 __CFRunLoopRun + 1393\
4 com.apple.CoreFoundation 0x98e869fa CFRunLoopRunSpecific + 394\
5 com.apple.CoreFoundation 0x98e8685b CFRunLoopRunInMode + 123\
6 com.apple.AppKit 0x9402cb68 _NSEventThread + 283\
7 libsystem_pthread.dylib 0x928c15fb _pthread_body + 144\
8 libsystem_pthread.dylib 0x928c1485 _pthread_start + 130\
9 libsystem_pthread.dylib 0x928c6cf2 thread_start + 34\
\
Thread 3:: com.apple.coreaudio.AQClient\
0 libsystem_kernel.dylib 0x91680f7a mach_msg_trap + 10\
1 libsystem_kernel.dylib 0x9168016c mach_msg + 68\
2 com.apple.CoreFoundation 0x98e87c09 __CFRunLoopServiceMachPort + 169\
3 com.apple.CoreFoundation 0x98e871e1 __CFRunLoopRun + 1393\
4 com.apple.CoreFoundation 0x98e869fa CFRunLoopRunSpecific + 394\
5 com.apple.CoreFoundation 0x98e8685b CFRunLoopRunInMode + 123\
6 com.apple.audio.toolbox.AudioToolbox 0x9a91b5b8 GenericRunLoopThread::Entry(void*) + 194\
7 com.apple.audio.toolbox.AudioToolbox 0x9a8cbc2a CAPThread::Entry(CAPThread*) + 134\
8 libsystem_pthread.dylib 0x928c15fb _pthread_body + 144\
9 libsystem_pthread.dylib 0x928c1485 _pthread_start + 130\
10 libsystem_pthread.dylib 0x928c6cf2 thread_start + 34\
\
Thread 4:\
0 libsystem_kernel.dylib 0x91685b76 __semwait_signal + 10\
1 libsystem_c.dylib 0x99119fb7 nanosleep$UNIX2003 + 219\
2 org.pharo-project.Pharo 0x0005b94c beatStateMachine + 108\
3 libsystem_pthread.dylib 0x928c1485 _pthread_start + 130\
4 libsystem_pthread.dylib 0x928c6cf2 thread_start + 34\
\
Thread 5:\
0 libsystem_kernel.dylib 0x91686046 __workq_kernreturn + 10\
1 libsystem_pthread.dylib 0x928c2dcf _pthread_wqthread + 372\
2 libsystem_pthread.dylib 0x928c6cce start_wqthread + 30\
\
Thread 0 crashed with X86 Thread State (32-bit):\
eax: 0x ebx: 0xbffaca40 ecx: 0xbffac5bc edx: 0x91685952\
edi:
Re: [Pharo-dev] [Pharo CI] Linux slave problem solved
On 24 Apr 2014, at 12:12, Serge Stinckwich serge.stinckw...@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.den...@inria.fr a écrit : On 24 Apr 2014, at 04:50, Serge Stinckwich serge.stinckw...@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.den...@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/
Re: [Pharo-dev] Stable Mac VM for latest 3.0?
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.johan...@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-builder-mac/lastSuccessfulBuild/artifact/337.zip And both crash for me during load (attached report)… Anyone know where a VM which works is located? Cheers, Henry VMcrash.rtf signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Stable Mac VM for latest 3.0?
On 24 Apr 2014, at 13:23, Henrik Johansen henrik.s.johan...@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.johan...@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-builder-mac/lastSuccessfulBuild/artifact/337.zip And both crash for me during load (attached report)… Anyone know where a VM which works is located? Cheers, Henry VMcrash.rtf signature.asc Description: Message signed with OpenPGP using GPGMail
[Pharo-dev] Pharo crashes
Hi pharoers, I am trying to load Phratch in the latest Pharo3.0 Installer Mac (image+vm), and Pharo crashes during the install. It is easy to reproduce: - Load the latest Pharo Installer for Mac - Run this code: --- Gofer it url: 'http://smalltalkhub.com/mc/JLaval/Phratch/main' username: '' password: ''; package: 'ConfigurationOfPhratch'; load. (Smalltalk at: #ConfigurationOfPhratch) loadBleedingEdge. --- Cheers, Jannik -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/
Re: [Pharo-dev] [Pharo CI] Linux slave problem solved
With vm 337 and 30830 on Mac Mavericks 10.9.2 I can reproduce the crash by loading the ConfigurationOfForum and then loading bleedingEdge. crash.dmp Description: Binary data Stephan
Re: [Pharo-dev] [pharo-project/pharo-core] 1953a9: 30829
On 24 avr. 2014, at 09:59, Marcus Denker marcus.den...@inria.fr wrote: On 23 Apr 2014, at 19:30, Marcus Denker marcus.den...@inria.fr wrote: On 23 Apr 2014, at 19:21, Camille Teruel camille.ter...@gmail.com wrote: On 23 avr. 2014, at 19:00, Marcus Denker marcus.den...@inria.fr wrote: On 23 Apr 2014, at 18:34, Marcus Denker marcus.den...@inria.fr wrote: On 23 Apr 2014, at 18:18, Sven Van Caekenberghe s...@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-class-hierarchy 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. Did you run the postscript? Smalltalk allClassesDo: [ :c | c superclass addSubclass: c ] https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.3-MetacelloValidation/label=linux-stable-worker/388/consoleText (it would have been nice to have integrated this issue 2 weeks ago…) Indeed 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: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: FixedLayout(ObjectLayout)reshapeFrom:to: ClassModificationPropagationpropagate:to: ClassModificationPropagation classpropagate:to: ClassModification(AbstractClassModification)propagate in Block: [ :subclass | propagations add: (ClassModification...etc... MetaclasssubclassesDo: in Block: [ :aSubclass | ... Array(SequenceableCollection)do: MCFileTreeFileUtils class(Class)subclassesDo: MetaclasssubclassesDo: ClassModification(AbstractClassModification)propagate SlotClassBuilderapplyAndUpdateSharedVariableOrSharedPool: in Block: [ :old :new | ... SlotClassBuildertrack:during: SlotClassBuilderapplyAndUpdateSharedVariableOrSharedPool: SlotClassBuilderapplySharedVariableOrPoolChange: SlotClassBuilderapply: SlotClassBuilderbuild PharoClassInstaller class(AbstractClassInstaller class)make: OldClassBuilderAdaptername:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category: MCClassDefinitioncreateClass in Block: [ ... BlockClosureon:do:
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 13:44, jannik laval jannik.la...@gmail.com wrote: Hi pharoers, I am trying to load Phratch in the latest Pharo3.0 Installer Mac (image+vm), and Pharo crashes during the install. Yes, and I have no clue why. Marcus
Re: [Pharo-dev] Debugging in Production Servers
Kilon wrote: Visual Studio can do this with Edit and Continue I know - but still not comparable. Apples and oranges - you know ;) In VS it works only to a certain extent and has same limits (mostly that in static languages nothing is so late bound as like in dynamic languages): Edit and Continue handles most types of code changes within method bodies. Most changes outside method bodies, and a few changes within method bodies, cannot be applied during debugging, however. as you can read on MSDN http://msdn.microsoft.com/en-us/library/vstudio/ms164927%28v=vs.100%29.aspx Try to change the debugger in .NET while it is running ;) So the world definitely starts to catch up with Smalltalk. Which can only be a good thing. For sure - virtual machines and GC are now common accepted concepts. Java catched up on the tool side with Eclipse as former Smalltalkers laid the ground. (OTI comes to mind). Now even there is a movement to more dynamic environments/languages as JavaScript, Groovy and Dart prove. Unfortunately most of the languages these days are static and still predefined (syntax and facilities) by vendors. Also the runtimes are vendor controlled. And not to forgert: ST concepts like #allInstances would render security concepts like AppDomains in .NET runtime useless, ... Runtimes like .NET or Java catch up these days for better support on dynamic languages (see #dynamicInvoke in JVM). But to run the way you are used to in Smalltalk you need a different base with more control. That's why it is so hard to get Smalltalk with all features and good performance on top of these VMs/runtimes. Contrary the Smalltalk language just sits on top of a dynamic changeable object environment. So if you like you can add new language constucts while running (Traits, Namespaces/Environments, Interfaces, ...) or even new language support (see Helvetica in Pharo). You can change nearly anything (despite the basics in the VM while running). That a SmalltalkVM can run other languages/bytecodes like Java was already demonstrated by VisualAge (IBM) and by Except with Java on top of Smalltalk/X. And just to clarify: Smalltalk has to catch up as well, especially regard better scoping and modularity. That's why Pharo is Smalltalk inspired. Especially the meta-facilities of Smalltalk are currently not used as they could be used. Especially to do a big part of daily software work nearly automagically ... Bye T.
[Pharo-dev] [pharo-project/pharo-core] 38bca4: 30831
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 38bca442b7123caa5ce7497b9f0df2f8d4f06420 https://github.com/pharo-project/pharo-core/commit/38bca442b7123caa5ce7497b9f0df2f8d4f06420 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-04-24 (Thu, 24 Apr 2014) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script483.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script484.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30830.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30831.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 30831 sync dirty packages http://files.pharo.org/image/30/30831.zip
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 1:48 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 13:44, jannik laval jannik.la...@gmail.com wrote: Hi pharoers, I am trying to load Phratch in the latest Pharo3.0 Installer Mac (image+vm), and Pharo crashes during the install. Yes, and I have no clue why. Marcus The package I tried loads fine in 80829, but crashes in 80830, so there’s something in that update which needs to be revisited. Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
[Pharo-dev] Pharo crashes
Forum crashes on 30830 with 335, 336 and 337. The crash is while showing 'Compiling...' Stephan
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30831 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] [pharo-project/pharo-core] 1953a9: 30829
On 24 Apr 2014, at 13:46, Camille Teruel camille.ter...@gmail.com wrote: On 24 avr. 2014, at 09:59, Marcus Denker marcus.den...@inria.fr wrote: On 23 Apr 2014, at 19:30, Marcus Denker marcus.den...@inria.fr wrote: On 23 Apr 2014, at 19:21, Camille Teruel camille.ter...@gmail.com wrote: On 23 avr. 2014, at 19:00, Marcus Denker marcus.den...@inria.fr wrote: On 23 Apr 2014, at 18:34, Marcus Denker marcus.den...@inria.fr wrote: On 23 Apr 2014, at 18:18, Sven Van Caekenberghe s...@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-class-hierarchy 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. Did you run the postscript? Smalltalk allClassesDo: [ :c | c superclass addSubclass: c ] No, but if that would be inconsistent, there is a test that fails… But I can do it the next update. Marcus
Re: [Pharo-dev] Pharo crashes
Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 the stacktrace: [0mLayoutEmptyScope(Object)error: LayoutEmptyScope(LayoutAbstractScope)rebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: FixedLayout(ObjectLayout)reshapeFrom:to: ClassModificationPropagationpropagate:to: ClassModificationPropagation classpropagate:to: ClassModification(AbstractClassModification)propagate in Block: [ :subclass | propagations add: (ClassModification...etc... MetaclasssubclassesDo: in Block: [ :aSubclass | ... Array(SequenceableCollection)do: MCFileTreeFileUtils class(Class)subclassesDo: MetaclasssubclassesDo: ClassModification(AbstractClassModification)propagate SlotClassBuilderapplyAndUpdateSharedVariableOrSharedPool: in Block: [ :old :new | ... SlotClassBuildertrack:during: SlotClassBuilderapplyAndUpdateSharedVariableOrSharedPool: SlotClassBuilderapplySharedVariableOrPoolChange: SlotClassBuilderapply: SlotClassBuilderbuild PharoClassInstaller class(AbstractClassInstaller class)make: OldClassBuilderAdaptername:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category: MCClassDefinitioncreateClass in Block: [ ... BlockClosureon:do: Le 24 avr. 2014 à 13:59, Henrik Johansen a écrit : On 24 Apr 2014, at 1:48 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 13:44, jannik laval jannik.la...@gmail.com wrote: Hi pharoers, I am trying to load Phratch in the latest Pharo3.0 Installer Mac (image+vm), and Pharo crashes during the install. Yes, and I have no clue why. Marcus The package I tried loads fine in 80829, but crashes in 80830, so there’s something in that update which needs to be revisited. Cheers, Henry smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] Phexample: API Change Proposal (was Phexample: Image Destroying Bug)
Hi Sean: On 24 Apr 2014, at 02:49, Sean P. DeNigris s...@clipperadams.com wrote: Stefan Marr-3 wrote First of all, I enabled public write access on the repository. It doesn’t look like it has public write access. Guess the error is between chair and screen. I probably forgot to save the change or something… Now it should be enabled. Could you try again? Thanks Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/
Re: [Pharo-dev] Pharo crashes
what is forum? On 24 Apr 2014, at 13:58, Stephan Eggermont step...@stack.nl wrote: Forum crashes on 30830 with 335, 336 and 337. The crash is while showing 'Compiling...' Stephan
Re: [Pharo-dev] [pharo-project/pharo-core] 1953a9: 30829
This seems to have worked: all image tests are green. BUT: the Metacello Platformtests fail with a “should not happen” error. Did you run the postscript? Smalltalk allClassesDo: [ :c | c superclass addSubclass: c ] No, but if that would be inconsistent, there is a test that fails… But I can do it the next update. I did one update 30 832 with this. But I guess it will not change anything… after that I will revert to 3.0 829. Marcus
Re: [Pharo-dev] Verifying Ubuntu downloads
Sean P. DeNigris wrote I will push to sthub tomorrow morning. Done. You should now be able to insert and verify your own file into the following: Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'Superuser'; configuration; loadStable. #inform: success or signal an error #SuUbuntuHash asClass verify: 'ubuntu-12.04.4-desktop-amd64.iso' asFileReference. - Cheers, Sean -- View this message in context: http://forum.world.st/Verifying-Ubuntu-downloads-tp4754637p4756217.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 14:04, Christophe Demarey christophe.dema...@inria.fr wrote: Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 Yes, this is already here: https://pharo.fogbugz.com/f/cases/13223/Error-Should-not-happen-in-rebase-to Marcus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] [pharo-project/pharo-core] 6f764a: 30830
On 24 Apr 2014, at 14:21, Sean P. DeNigris s...@clipperadams.com wrote: GitHub wrote Log Message: --- 30830 http://files.pharo.org/image/30/30830.zip Which issues did this include? https://pharo.fogbugz.com/f/cases/13028/ I integrated it with a .cs as it did not work as a slice. I will rever 830, 831 and 832 (which is just that + reload of dirty + the postscript for the change). But then we need to fix the issue of 13028… Marcus
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30832 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] d3c35d: 30832
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: d3c35d16796a121d571ddf0f3f0cf6b3a2b6110d https://github.com/pharo-project/pharo-core/commit/d3c35d16796a121d571ddf0f3f0cf6b3a2b6110d Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-04-24 (Thu, 24 Apr 2014) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script485.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30832.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 30832 Postscript: Smalltalk allClassesDo: [ :c | c superclass addSubclass: c ] http://files.pharo.org/image/30/30832.zip
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 2:21 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 14:04, Christophe Demarey christophe.dema...@inria.fr wrote: Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 Yes, this is already here: https://pharo.fogbugz.com/f/cases/13223/Error-Should-not-happen-in-rebase-to Marcus If I revert (comment out classModification propagate) SlotClassBuilder #applyAndUpdateSharedVariableOrSharedPool: classModification ^ self track: classModification during: [ :old :new | installer classDefinitionChangedFrom: old to: new by: classModification. classModification propagate ]. in a 80830 image, loading works fine. … but I guess that change might be the entire point of the patch? Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] [Pharo CI] Linux slave problem solved
Marcus Denker-4 wrote The problem with the linux slaves is fixed… things should get normal again. Thank you Marcus for taking care of all these boring, but crucial, details! - Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-CI-Linux-slave-problem-solved-tp4755938p4756226.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Phexample: API Change Proposal (was Phexample: Image Destroying Bug)
Stefan Marr-3 wrote Now it should be enabled. Looks good, thanks! - Cheers, Sean -- View this message in context: http://forum.world.st/Phexample-API-Change-Proposal-was-Phexample-Image-Destroying-Bug-tp4755787p4756229.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [pharo-project/pharo-core] 1953a9: 30829
On 24 avr. 2014, at 14:18, Marcus Denker marcus.den...@inria.fr wrote: This seems to have worked: all image tests are green. BUT: the Metacello Platformtests fail with a “should not happen” error. Did you run the postscript? Smalltalk allClassesDo: [ :c | c superclass addSubclass: c ] No, but if that would be inconsistent, there is a test that fails… But I can do it the next update. I did one update 30 832 with this. But I guess it will not change anything… after that I will revert to 3.0 829. My bad I confuses issues... In fact this is not related to this issue but to issue 11596, I never noticed but it has never been integrated!!! By running the script I gave back then, you can see that a lot of classes have still a wrong layout!! That is the scope of the layout of their superclass is not the parent scope of their layout, which give this #shouldNotHappen error Namely: DialogWindowModel class MBAbstractInfoList class MBLabelInfo class MBSpecInfo class MCClassDefinition MCClassDefinition class MCClassTraitDefinition MCClassTraitDefinition class MCFileTreeFileSystemUtils class MCMethodDefinition MCMethodDefinition class MCMockDefinition MCMockDefinition class MCOrganizationDefinition MCOrganizationDefinition class MCScriptDefinition MCScriptDefinition class ProfStef class SpecDebugActionButton class TTLCache TTLCache class TextInputFieldModel class UIThemeVistary class UIThemeWatery class WorldModel class Please run this script we cannot release Pharo with all these corrupted classes!!! Marcus
Re: [Pharo-dev] Pharo crashes
On 24 avr. 2014, at 14:37, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 24 Apr 2014, at 2:21 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 14:04, Christophe Demarey christophe.dema...@inria.fr wrote: Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 Yes, this is already here: https://pharo.fogbugz.com/f/cases/13223/Error-Should-not-happen-in-rebase-to Marcus If I revert (comment out classModification propagate) SlotClassBuilder #applyAndUpdateSharedVariableOrSharedPool: classModification ^ self track: classModification during: [ :old :new | installer classDefinitionChangedFrom: old to: new by: classModification. classModification propagate ]. in a 80830 image, loading works fine. … but I guess that change might be the entire point of the patch? Yes removing this line will reintroduce the subclass bug. Moreover I think this line is not the cause but a symptom revealer (cf my other mails about classes that have wrong layout). Now I think the segfault is because of a wrong class format somewhere. Cheers, Henry
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 14:57, Camille Teruel camille.ter...@gmail.com wrote: On 24 avr. 2014, at 14:37, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 24 Apr 2014, at 2:21 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 14:04, Christophe Demarey christophe.dema...@inria.fr wrote: Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 Yes, this is already here: https://pharo.fogbugz.com/f/cases/13223/Error-Should-not-happen-in-rebase-to Marcus If I revert (comment out classModification propagate) SlotClassBuilder #applyAndUpdateSharedVariableOrSharedPool: classModification ^ self track: classModification during: [ :old :new | installer classDefinitionChangedFrom: old to: new by: classModification. classModification propagate ]. in a 80830 image, loading works fine. … but I guess that change might be the entire point of the patch? Yes removing this line will reintroduce the subclass bug. Moreover I think this line is not the cause but a symptom revealer (cf my other mails about classes that have wrong layout). Now I think the segfault is because of a wrong class format somewhere. So we do another update with the postscript. if that fails, we revert so not all builds are broken. Do we then revert just that method? Or really all updates to 829? Marcus
Re: [Pharo-dev] [pharo-project/pharo-core] 6f764a: 30830
On 24 Apr 2014, at 2:24 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 14:21, Sean P. DeNigris s...@clipperadams.com wrote: GitHub wrote Log Message: --- 30830 http://files.pharo.org/image/30/30830.zip Which issues did this include? https://pharo.fogbugz.com/f/cases/13028/ I integrated it with a .cs as it did not work as a slice. I will rever 830, 831 and 832 (which is just that + reload of dirty + the postscript for the change). But then we need to fix the issue of 13028… Marcus Maybe it’s just me, but isn’t it entirely wrong to fix subclasses being kept unmodified when a Shared Variable is added using change propagation? To me, it seems that mechanism is intended only to be used when a class change actually affects its subclass’ definition (iow, when Fields are modified...). I mean, it *should* be possible to setup the new class being migrated to with proper subclasses instvar, though I can’t exactly see where that is through all the layers of indirection… Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
[Pharo-dev] Nautilus is cool
Hi! Just to say that I am happy to have nautilus. It works well even for details. For example I selected all the methods of a class, and did a push up refactoring. It works perfectly. I then selected all the method categories, and do a remove all. No error ! Nautilus is cool :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] Nautilus is cool
Try the RB Rename for class names in a workspace and then, it will be less cool. Phil On Thu, Apr 24, 2014 at 3:23 PM, Alexandre Bergel alexandre.ber...@me.comwrote: Hi! Just to say that I am happy to have nautilus. It works well even for details. For example I selected all the methods of a class, and did a push up refactoring. It works perfectly. I then selected all the method categories, and do a remove all. No error ! Nautilus is cool :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
[Pharo-dev] [pharo-project/pharo-core] 05484b: 30833
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 05484b1f2be0a50410fbedea74a162bb59740f96 https://github.com/pharo-project/pharo-core/commit/05484b1f2be0a50410fbedea74a162bb59740f96 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-04-24 (Thu, 24 Apr 2014) Changed paths: A KernelTests.package/ClassHierarchyTest.class/class/fixing/fixSlotScope.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script486.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30833.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 30833 11596 Adding an iVar to class Class gives error https://pharo.fogbugz.com/f/cases/11596 http://files.pharo.org/image/30/30833.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30833 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 14:57, Camille Teruel camille.ter...@gmail.com wrote: On 24 avr. 2014, at 14:37, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 24 Apr 2014, at 2:21 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 14:04, Christophe Demarey christophe.dema...@inria.fr wrote: Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 Yes, this is already here: https://pharo.fogbugz.com/f/cases/13223/Error-Should-not-happen-in-rebase-to Marcus If I revert (comment out classModification propagate) SlotClassBuilder #applyAndUpdateSharedVariableOrSharedPool: classModification ^ self track: classModification during: [ :old :new | installer classDefinitionChangedFrom: old to: new by: classModification. classModification propagate ]. in a 80830 image, loading works fine. … but I guess that change might be the entire point of the patch? Yes removing this line will reintroduce the subclass bug. Moreover I think this line is not the cause but a symptom revealer (cf my other mails about classes that have wrong layout). Now I think the segfault is because of a wrong class format somewhere. I revert this method in 3.0 834 so we get rid of the crashes… then we can find a better fix later. Marcus
Re: [Pharo-dev] [pharo-project/pharo-core] 6f764a: 30830
On 24 Apr 2014, at 3:19 , Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 24 Apr 2014, at 2:24 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 14:21, Sean P. DeNigris s...@clipperadams.com wrote: GitHub wrote Log Message: --- 30830 http://files.pharo.org/image/30/30830.zip Which issues did this include? https://pharo.fogbugz.com/f/cases/13028/ I integrated it with a .cs as it did not work as a slice. I will rever 830, 831 and 832 (which is just that + reload of dirty + the postscript for the change). But then we need to fix the issue of 13028… Marcus Maybe it’s just me, but isn’t it entirely wrong to fix subclasses being kept unmodified when a Shared Variable is added using change propagation? To me, it seems that mechanism is intended only to be used when a class change actually affects its subclass’ definition (iow, when Fields are modified...). I mean, it *should* be possible to setup the new class being migrated to with proper subclasses instvar, though I can’t exactly see where that is through all the layers of indirection… Cheers, Henry What is the purpose of self subclasses: nil in Class superclass:methodDictionary:format:? Is there any case it might be needed except when format changes, and old subclasses are invalid? (and will it ever crash even then until change is propagated and the old instances become’d into subclasses of proper format?) If not, it might be a decent change to simply change that method to: Class superclass: aClass methodDictionary: mDict format: fmt Basic initialization of the receiver self format = fmt ifFalse:[self subclasses: nil. ]. super superclass: aClass methodDictionary: mDict format: fmt. so only cases where format changes are actually responsible for re-registering properly updated subclasses. (which excludes addition of shared vars/pool variables) Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] What is forum (was Re: Pharo Crashes)
FYI: Forum is available in the config browser. Interesting enough in a recent image Pharo3.0 Latest update: #30829 the ConfigurationOfForum is not visible in Versionner after loading the config into the image (although the class ConfigurationOfForum is there). May be related to the slot class builder issue that is currently discussed. It works and shows up in Versionner when I use an older one (Pharo3.0 Latest update: #30814 for instance) Bye T. Gesendet: Donnerstag, 24. April 2014 um 14:54 Uhr Von: Stephan Eggermont step...@stack.nl An: Pharo Development List pharo-dev@lists.pharo.org Betreff: [Pharo-dev] What is forum (was Re: Pharo Crashes) Esteban wrote: what is forum? The workshop image for 'Back to the future, (re)learn smalltalk’. The workshop is targeted at experienced developers and focuses on what’s different in smalltalk. It has a QCMagritte/Bootstrap based beginning of a Seaside application which the participants have to extend. The workshop exercises are in a glamour browser, as are some code quality visualizations. Stephan
[Pharo-dev] [pharo-project/pharo-core] 7b27f8: 30834
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 7b27f80cb692f7d8e02b7ea26a51718ec07a9deb https://github.com/pharo-project/pharo-core/commit/7b27f80cb692f7d8e02b7ea26a51718ec07a9deb Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-04-24 (Thu, 24 Apr 2014) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script487.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30834.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/SlotClassBuilder.class/instance/private/applyAndUpdateSharedVariableOrSharedPool_.st Log Message: --- 30834 revert #applyAndUpdateSharedVariableOrSharedPool: for now http://files.pharo.org/image/30/30834.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30834 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] What is forum (was Re: Pharo Crashes)
On 24 Apr 2014, at 16:26, Torsten Bergmann asta...@gmx.de wrote: FYI: Forum is available in the config browser. Interesting enough in a recent image Pharo3.0 Latest update: #30829 the ConfigurationOfForum is not visible in Versionner after loading the config into the image (although the class ConfigurationOfForum is there). May be related to the slot class builder issue that is currently discussed. No, that got added as 30830. It works and shows up in Versionner when I use an older one (Pharo3.0 Latest update: #30814 for instance) Bye T. Gesendet: Donnerstag, 24. April 2014 um 14:54 Uhr Von: Stephan Eggermont step...@stack.nl An: Pharo Development List pharo-dev@lists.pharo.org Betreff: [Pharo-dev] What is forum (was Re: Pharo Crashes) Esteban wrote: what is forum? The workshop image for 'Back to the future, (re)learn smalltalk’. The workshop is targeted at experienced developers and focuses on what’s different in smalltalk. It has a QCMagritte/Bootstrap based beginning of a Seaside application which the participants have to extend. The workshop exercises are in a glamour browser, as are some code quality visualizations. Stephan
Re: [Pharo-dev] Inti in Pharo
Really beautiful! I will take a look as soon as possible at the code. This is definitely a candidate to be included in GT. In the meantime, please just do not use a Gary background to show gray data. Just use white. Doru -- www.tudorgirba.com Every thing has its own flow. On 24.04.2014, at 16:58, milton mamani akeval...@gmail.com wrote: Hi all, I would like to show you the Inti, Inti is a cool visualization to compare and handle instances of MessageTally. This is just a demo, nothing in this mail is final. This image shows the Inti program in GTInspector image.png The color mapping is explainning in http://www.humane-assessment.com/blog/?_k=W1xeAy75PKaNEd2G image.png Purple nodes ares nodes that have the same class of the selected method. image.png This is inti profiler in pharo, this allows your to compare 2 (or more) instances of MessageTally, and see the difference of this tallies. image.png You can get this program executing the next piece of code: Gofer new smalltalkhubUser: 'azazael' project: 'inti'; package: 'ConfigurationOfInti'; load. (Smalltalk at: #ConfigurationOfInti) load. http://objectprofile.com/Inti.html Best regards, Milton
Re: [Pharo-dev] [pharo-project/pharo-core] 6f764a: 30830
Hi henryk thanks for your feedback, we need more people looking at changes. Stef
Re: [Pharo-dev] [Moose-dev] Inti in Pharo
I will take a look as soon as possible at the code. This is definitely a candidate to be included in GT. Excellent! In the meantime, please just do not use a Gary background to show gray data. Just use white. +1 Alexandre Doru -- www.tudorgirba.com Every thing has its own flow. On 24.04.2014, at 16:58, milton mamani akeval...@gmail.com wrote: Hi all, I would like to show you the Inti, Inti is a cool visualization to compare and handle instances of MessageTally. This is just a demo, nothing in this mail is final. This image shows the Inti program in GTInspector image.png The color mapping is explainning in http://www.humane-assessment.com/blog/?_k=W1xeAy75PKaNEd2G image.png Purple nodes ares nodes that have the same class of the selected method. image.png This is inti profiler in pharo, this allows your to compare 2 (or more) instances of MessageTally, and see the difference of this tallies. image.png You can get this program executing the next piece of code: Gofer new smalltalkhubUser: 'azazael' project: 'inti'; package: 'ConfigurationOfInti'; load. (Smalltalk at: #ConfigurationOfInti) load. http://objectprofile.com/Inti.html Best regards, Milton ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Re: [Pharo-dev] What is forum (was Re: Pharo Crashes)
FYI: Forum is available in the config browser. But does not load out of the box. Dependency to Glamour seems to be missing.
[Pharo-dev] CPU usage change on newer OS
I have a strange effect on my machines. I have a dedicated server and a lot of virtual instances using LXC. The last few days I migrated most projects of our projects from pharo2.0 to pharo3.0. And on the same time the images moved from an ubuntu 12.04. system to a ubuntu 14.04 system. Looking at the top command it appears the images/vms need noticable less CPU or better the tools report less. The monitored overall CPU usage also is much lesser than before. This is not proved by any measurement. Has anyone an idea why this could happen or appear differently? Norbert
Re: [Pharo-dev] Debugging in Production Servers
On Wed, Apr 23, 2014 at 10:42 PM, Sven Van Caekenberghe s...@stfx.euwrote: 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. And the crucial linguistic difference is Smalltalk's (and LISP's) resume semantics for exceptions vs Java's restart semantics. This difference is that in Smalltalk the exception handler is executed in the context of the exception, allowing the programmer to see the point of error and provide a value with which to /resume/ execution. In Java the exception is delivered in the context of the handler, discarding the execution state that caused the exception, only allowing the program to /restart/ the code that caused the exception, and making investigating the cause of the exception impossible in the current run. We can dump live stacks with FUEL for example. And this because Smalltalk provides first-class activation records (contexts) /and/ has resume semantics for exceptions. On 24 Apr 2014, at 06:01, S Krish krishnamachari.sudha...@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 as...@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. -- best, Eliot
Re: [Pharo-dev] Pharo crashes
2014-04-24 20:44 GMT+02:00 Eliot Miranda eliot.mira...@gmail.com: Again, cc'ing vm-dev is courteous. On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel camille.ter...@gmail.comwrote: Segfault! Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstallermigrateClasses:to:using:) I suspect the become. Thats the last primitive. I suspect it's something to do with become on machine code. I suspect some of my recent changes have not been integrated. e.g. VMMaker.oscog-eem.669. Hi Eliot, no, it is way behind ! The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. As for the platform sources, I have no idea what/when was the last merge with your svn branch... As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. It could be a better start for integrating your changes. But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications. I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. Igor, Esteban and co may have a different idea about it. -- best, Eliot
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 22:13, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 2014-04-24 20:44 GMT+02:00 Eliot Miranda eliot.mira...@gmail.com: Again, cc'ing vm-dev is courteous. On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel camille.ter...@gmail.com wrote: Segfault! Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstallermigrateClasses:to:using:) I suspect the become. Thats the last primitive. I suspect it's something to do with become on machine code. I suspect some of my recent changes have not been integrated. e.g. VMMaker.oscog-eem.669. Hi Eliot, no, it is way behind ! The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. As for the platform sources, I have no idea what/when was the last merge with your svn branch... As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. It could be a better start for integrating your changes. But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications. I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. Igor, Esteban and co may have a different idea about it. no, I was thinking more or less the same… but still did not looked at it deeply :) btw… I do not know which randomly picked changes you are talking about. I certainly stopped doing integrations when Eliot started to commit spur stuff, to wait until is more or less ready (bah, with Clement we tried once and it was not worthy, so we rolled back). then… other stuff: I also don’t know about random methods reformatted. I know I reformatted some, but those I worked on (usually not in VMMaker, with minor exceptions). Of course, I’m not the only one working on those sources, but I certainly did many changes with the years. Finally: ok, vm shouldn’t crash… but this bug was not vm related but a bad integration (in the new class builder) we rollbacked. That’s why it was not copied to vm-dev :) cheers, Esteban -- best, Eliot
Re: [Pharo-dev] Pharo crashes
On Thu, Apr 24, 2014 at 1:43 PM, Esteban Lorenzano esteba...@gmail.comwrote: On 24 Apr 2014, at 22:13, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 2014-04-24 20:44 GMT+02:00 Eliot Miranda eliot.mira...@gmail.com: Again, cc'ing vm-dev is courteous. On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel camille.ter...@gmail.com wrote: Segfault! Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstallermigrateClasses:to:using:) I suspect the become. Thats the last primitive. I suspect it's something to do with become on machine code. I suspect some of my recent changes have not been integrated. e.g. VMMaker.oscog-eem.669. Hi Eliot, no, it is way behind ! The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. As for the platform sources, I have no idea what/when was the last merge with your svn branch... As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. It could be a better start for integrating your changes. But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications. I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. Igor, Esteban and co may have a different idea about it. no, I was thinking more or less the same… but still did not looked at it deeply :) btw… I do not know which randomly picked changes you are talking about. I certainly stopped doing integrations when Eliot started to commit spur stuff, to wait until is more or less ready (bah, with Clement we tried once and it was not worthy, so we rolled back). then… other stuff: I also don’t know about random methods reformatted. I know I reformatted some, but those I worked on (usually not in VMMaker, with minor exceptions). Of course, I’m not the only one working on those sources, but I certainly did many changes with the years. Finally: ok, vm shouldn’t crash… but this bug was not vm related but a bad integration (in the new class builder) we rollbacked. That’s why it was not copied to vm-dev :) At last for the core VM classes (ignore plugins) I wish you would integrate by integrating your ephemeron and NativeBoost changes into my tip. I think you're losing a lot of goodness coming form the continuous integration and testing my colleague Bob Westergaard does at Cadence. It worries me that the Pharo VM is buggy. I don't think it needs to be. And please don't take this as a criticism. It's more my anxiety. cheers, Esteban cheers! -- best, Eliot -- best, Eliot
Re: [Pharo-dev] Pharo crashes
2014-04-24 22:43 GMT+02:00 Esteban Lorenzano esteba...@gmail.com: On 24 Apr 2014, at 22:13, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 2014-04-24 20:44 GMT+02:00 Eliot Miranda eliot.mira...@gmail.com: Again, cc'ing vm-dev is courteous. On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel camille.ter...@gmail.com wrote: Segfault! Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstallermigrateClasses:to:using:) I suspect the become. Thats the last primitive. I suspect it's something to do with become on machine code. I suspect some of my recent changes have not been integrated. e.g. VMMaker.oscog-eem.669. Hi Eliot, no, it is way behind ! The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. As for the platform sources, I have no idea what/when was the last merge with your svn branch... As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. It could be a better start for integrating your changes. But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications. I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. Igor, Esteban and co may have a different idea about it. no, I was thinking more or less the same… but still did not looked at it deeply :) btw… I do not know which randomly picked changes you are talking about. I certainly stopped doing integrations when Eliot started to commit spur stuff, to wait until is more or less ready (bah, with Clement we tried once and it was not worthy, so we rolled back). then… other stuff: I also don’t know about random methods reformatted. I know I reformatted some, but those I worked on (usually not in VMMaker, with minor exceptions). Of course, I’m not the only one working on those sources, but I certainly did many changes with the years. It's easy for me to say, because I did the job of tracing the differences when tracking bug https://pharo.fogbugz.com/f/cases/11130 And since git is a super tool, all is publicly traced. So here is the major source of cosmetic changes: the scripts for applying the transformation (self var: #foo ...) - var: #foo type: ... have been applied separately in pharo branch, but with a different layout (space after :) like Dave did in interpreter VM, but unlike Eliot did in .oscog branch if I remember correctly. Then a few other formatting have been done manually. Normally after a merge they are not shown... But since the last merge wirth 333 was partial, we can't use merge from MC, we are forced to use changes that show all the diffs, otherwise we'll miss some of the changes not merged in further merges. Thoses changes can be cancelled by re-applying Eliot's version. You can check on my branch UndoBlankChanges https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/7ee237a851f2470ca433dcd53388570248778c19 As for the random changes, they are all marked LucFabresse (I think an effect of older gitfiletree). I don't think they are really random: it's more like an aborted merge that was partially reverted. So logically, the things that were not reverted were harmless (the Spur related things). There was certainly a good reason for wanting to merge (like work on simulator maybe) And reverting was probably a good decision at that time because Spur introduction was wausing some Cog regressions. My point is not to denigrate Luc's or Esteban's work, maintaining a parallel branch is complex enough! But when you are searching for a specific bug like those differences appear as random and are parasiting... And when it's time to cancel the debt toward Eliot's branch, that can be disturbing : those methods conflict because of author and time stamp, as I said probably a former gitfiletree bug... You can check the changes in my branch revertLucFabresseAheadChanges https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/847c254168d0b246c49dfcfe3f3b294c92ca60a8 Looking at history, the merge was with Eliot's 406: https://github.com/nicolas-cellier-aka-nice/pharo-vm/commits/a05cda7fb80d891a3ded12f049d4efa5cc41b477/mc/VMMaker-oscog.package/ObjectMemory.class/instance/shouldRemapObj..st The last thing I
[Pharo-dev] Modifications to be integrated in Pharo 3.0 VM
I think this fix is essential and should be applied before releasing Pharo VM: https://github.com/pharo-project/pharo-vm/pull/31 Those are optionals but would be nice to have: https://github.com/pharo-project/pharo-vm/pull/32 https://github.com/pharo-project/pharo-vm/pull/33 https://github.com/pharo-project/pharo-vm/pull/34 https://github.com/pharo-project/pharo-vm/pull/42 Those can wait but are ready and not dangerous IMO: https://github.com/pharo-project/pharo-vm/pull/37 https://github.com/pharo-project/pharo-vm/pull/39 https://github.com/pharo-project/pharo-vm/pull/40 This one works perfectly for me but failed on the CI server I really wonder why... https://github.com/pharo-project/pharo-vm/pull/41 This one would be nice to have too but does not fully work on my mac. I really fail to understand why... The exact same code in Cog branch works perfectly with same compiler (slightly different options maybe?) I'd be curious to know if all Kernel-Number tests pass when compiled by someone else. https://github.com/pharo-project/pharo-vm/pull/35 And last, the compiler flags should be fixed on MacOSX for bug https://pharo.fogbugz.com/f/cases/11130 Or clang replaced by an older gcc...
Re: [Pharo-dev] CPU usage change on newer OS
What % of CPU is it using? My VM on idle state consumes about ~4-5% CPU. Esteban A. Maringolo 2014-04-24 15:43 GMT-03:00 Norbert Hartl norb...@hartl.name: I have a strange effect on my machines. I have a dedicated server and a lot of virtual instances using LXC. The last few days I migrated most projects of our projects from pharo2.0 to pharo3.0. And on the same time the images moved from an ubuntu 12.04. system to a ubuntu 14.04 system. Looking at the top command it appears the images/vms need noticable less CPU or better the tools report less. The monitored overall CPU usage also is much lesser than before. This is not proved by any measurement. Has anyone an idea why this could happen or appear differently? Norbert
Re: [Pharo-dev] Debugging in Production Servers
Eliot Miranda wrote: On Wed, Apr 23, 2014 at 10:42 PM, Sven Van Caekenberghe s...@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. And the crucial linguistic difference is Smalltalk's (and LISP's) resume semantics for exceptions vs Java's restart semantics. This difference is that in Smalltalk the exception handler is executed in the context of the exception, allowing the programmer to see the point of error and provide a value with which to /resume/ execution. In Java the exception is delivered in the context of the handler, discarding the execution state that caused the exception, only allowing the program to /restart/ the code that caused the exception, and making investigating the cause of the exception impossible in the current run. Thanks for that Eliot. Its very interesting to learn that distinction. cheers -ben
Re: [Pharo-dev] CPU usage change on newer OS
On 25 Apr 2014, at 01:19, Esteban A. Maringolo emaring...@gmail.com wrote: What % of CPU is it using? My VM on idle state consumes about ~4-5% CPU. That is about what I am used to, here is a real view of an Amazon AWS EC2 Small Instance running 4 Pharo VMs: top - 05:25:09 up 413 days, 15:27, 1 user, load average: 0.88, 0.66, 0.49 Tasks: 73 total, 3 running, 70 sleeping, 0 stopped, 0 zombie Cpu(s): 0.6%us, 0.4%sy, 0.0%ni, 96.3%id, 0.2%wa, 0.0%hi, 0.0%si, 2.5%st Mem: 1706660k total, 1654928k used,51732k free, 136692k buffers Swap:0k total,0k used,0k free, 1006556k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 31639 ubuntu20 0 1030m 99m 1444 R 4.0 5.9 61:47.82 pharo 4314 ubuntu20 0 1030m 162m 1504 S 2.0 9.7 140:28.55 pharo 8014 ubuntu20 0 1030m 77m 1512 S 2.0 4.6 561:06.30 pharo 31647 ubuntu20 0 1030m 92m 1444 R 2.0 5.6 63:31.80 pharo 1 root 20 0 3540 1392 732 S 0.0 0.1 0:58.61 init Sven Esteban A. Maringolo 2014-04-24 15:43 GMT-03:00 Norbert Hartl norb...@hartl.name: I have a strange effect on my machines. I have a dedicated server and a lot of virtual instances using LXC. The last few days I migrated most projects of our projects from pharo2.0 to pharo3.0. And on the same time the images moved from an ubuntu 12.04. system to a ubuntu 14.04 system. Looking at the top command it appears the images/vms need noticable less CPU or better the tools report less. The monitored overall CPU usage also is much lesser than before. This is not proved by any measurement. Has anyone an idea why this could happen or appear differently? Norbert
