Re: [Pharo-dev] [pharo-project/pharo-core] 1953a9: 30829
On 23 Apr 2014, at 19:30, Marcus Denker wrote: > > On 23 Apr 2014, at 19:21, Camille Teruel wrote: > >> >> On 23 avr. 2014, at 19:00, Marcus Denker wrote: >> >>> >>> On 23 Apr 2014, at 18:34, Marcus Denker wrote: >>> On 23 Apr 2014, at 18:18, Sven Van Caekenberghe 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: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: FixedLayout(ObjectLayout)>>reshapeFrom:to: ClassModificationPropagation>>propagate:to: ClassModificationPropagation class>>propagate:to: ClassModification(AbstractClassModification)>>propagate in Block: [ :subclass | propagations add: (ClassModification...etc... Metaclass>>subclassesDo: in Block: [ :aSubclass | ... Array(SequenceableCollection)>>do: MCFileTreeFileUtils class(Class)>>subclassesDo: Metaclass>>subclassesDo: ClassModification(AbstractClassModification)>>propagate SlotClassBuilder>>applyAndUpdateSharedVariableOrSharedPool: in Block: [ :old :new | ... SlotClassBuilder>>track:during: SlotClassBuilder>>applyAndUpdateSharedVariableOrSharedPool: SlotClassBuilder>>applySharedVariableOrPoolChange: SlotClassBuilder>>apply: SlotClassBuilder>>build PharoClassInstaller class(AbstractClassInstaller class)>>make: OldClassBuilderAdapter>>name:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category: MCClassDefinition>>createClass in Block: [ ... BlockClosure>>on:do:
[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 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 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 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 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 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 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 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 a écrit : > > >> On 24 Apr 2014, at 04:50, Serge Stinckwich >> 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 >>> 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: 0xa061
Re: [Pharo-dev] [Pharo CI] Linux slave problem solved
On 24 Apr 2014, at 12:12, Serge Stinckwich 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 a écrit : >> >> >>> On 24 Apr 2014, at 04:50, Serge Stinckwich >>> 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 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 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 > > 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 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 > 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 >> >> > 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 wrote: > > On 23 Apr 2014, at 19:30, Marcus Denker wrote: > >> >> On 23 Apr 2014, at 19:21, Camille Teruel wrote: >> >>> >>> On 23 avr. 2014, at 19:00, Marcus Denker wrote: >>> On 23 Apr 2014, at 18:34, Marcus Denker wrote: > > On 23 Apr 2014, at 18:18, Sven Van Caekenberghe 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: > LayoutClassScope>>rebase:to: > LayoutClassScope>>rebase:to: > LayoutClassScope>>rebase:to: > LayoutClassScope>>rebase:to: > LayoutClassScope>>rebase:to: > LayoutClassScope>>rebase:to: > LayoutClassScope>>rebase:to: > LayoutClassScope>>rebase:to: > LayoutClassScope>>rebase:to: > FixedLayout(ObjectLayout)>>reshapeFrom:to: > ClassModificationPropagation>>propagate:to: > ClassModificationPropagation class>>propagate:to: > ClassModification(AbstractClassModification)>>propagate in Block: [ :subclass > | propagations add: (ClassModification...etc... > Metaclass>>subclassesDo: in Block: [ :aSubclass | ... > Array(SequenceableCollection)>>do: > MCFileTreeFileUtils class(Class)>>subclassesDo: > Metaclass>>subclassesDo: > ClassModification(AbstractClassModification)>>propagate > SlotClassBuilder>>applyAndUpdateSharedVariableOrSharedPool: in Block: [ :old > :new | ... > SlotClassBuilder>>track:during: > SlotClassBuilder>>applyAndUpdateSharedVariableOrSharedPool: > SlotClassBuilder>>applySharedVariableOrPoolChange: > SlotClassBuilder>>apply: > SlotClassBuilder>>build > PharoClassInstaller class(AbstractClassInstaller class)>>make: > OldClassBuilderAdapter>>name:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category: > MCClassDefinition>>createClass in Block: [ ... > BlockClosure>>on:do:
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 13:44, jannik laval 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 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 wrote: > > On 24 Apr 2014, at 13:44, jannik laval 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 wrote: > > On 24 avr. 2014, at 09:59, Marcus Denker wrote: > >> >> On 23 Apr 2014, at 19:30, Marcus Denker wrote: >> >>> >>> On 23 Apr 2014, at 19:21, Camille Teruel wrote: >>> On 23 avr. 2014, at 19:00, Marcus Denker wrote: > > On 23 Apr 2014, at 18:34, Marcus Denker wrote: > >> >> On 23 Apr 2014, at 18:18, Sven Van Caekenberghe 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: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: LayoutClassScope>>rebase:to: FixedLayout(ObjectLayout)>>reshapeFrom:to: ClassModificationPropagation>>propagate:to: ClassModificationPropagation class>>propagate:to: ClassModification(AbstractClassModification)>>propagate in Block: [ :subclass | propagations add: (ClassModification...etc... Metaclass>>subclassesDo: in Block: [ :aSubclass | ... Array(SequenceableCollection)>>do: MCFileTreeFileUtils class(Class)>>subclassesDo: Metaclass>>subclassesDo: ClassModification(AbstractClassModification)>>propagate SlotClassBuilder>>applyAndUpdateSharedVariableOrSharedPool: in Block: [ :old :new | ... SlotClassBuilder>>track:during: SlotClassBuilder>>applyAndUpdateSharedVariableOrSharedPool: SlotClassBuilder>>applySharedVariableOrPoolChange: SlotClassBuilder>>apply: SlotClassBuilder>>build PharoClassInstaller class(AbstractClassInstaller class)>>make: OldClassBuilderAdapter>>name:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category: MCClassDefinition>>createClass in Block: [ ... BlockClosure>>on:do: Le 24 avr. 2014 à 13:59, Henrik Johansen a écrit : > > On 24 Apr 2014, at 1:48 , Marcus Denker wrote: > >> >> On 24 Apr 2014, at 13:44, jannik laval 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 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 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-project/pharo-core] 6f764a: 30830
GitHub wrote > Log Message: > --- > 30830 > > http://files.pharo.org/image/30/30830.zip Which issues did this include? - Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-6f764a-30830-tp4756163p4756218.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 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 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 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 wrote: > > On 24 Apr 2014, at 14:04, Christophe Demarey > 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 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 wrote: > > On 24 Apr 2014, at 2:21 , Marcus Denker wrote: > >> >> On 24 Apr 2014, at 14:04, Christophe Demarey >> 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 wrote: > > On 24 avr. 2014, at 14:37, Henrik Johansen > wrote: > >> >> On 24 Apr 2014, at 2:21 , Marcus Denker wrote: >> >>> >>> On 24 Apr 2014, at 14:04, Christophe Demarey >>> 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 wrote: > > On 24 Apr 2014, at 14:21, Sean P. DeNigris 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 wrote: > 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 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 wrote: > > On 24 avr. 2014, at 14:37, Henrik Johansen > wrote: > >> >> On 24 Apr 2014, at 2:21 , Marcus Denker wrote: >> >>> >>> On 24 Apr 2014, at 14:04, Christophe Demarey >>> 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 wrote: > > On 24 Apr 2014, at 2:24 , Marcus Denker wrote: > >> >> On 24 Apr 2014, at 14:21, Sean P. DeNigris 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" An: "Pharo Development List" 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] Soon the LaserGame book for Pharo
Hi guys Steve just told me that he is ok that we port his book to Pharo :) This is a great news. So I will start during my spare time. Stef Begin forwarded message: From: Stephan Wessels Subject: Re: [vwnc] Can this idea work Date: 24 Apr 2014 15:21:27 GMT+2 To: stephane ducasse Hi. Actually I got those requests and replied both times that you have my permission provided I'm credited or noted as the original author. Please go forward with it; it can only help the Smalltalk community. Sent from my iPhone On Apr 24, 2014, at 8:16 AM, stephane ducasse wrote: Hi steve I tried to contact you several times in the past but I got no answer. I would like to know if we can port the tutorial to Pharo and if we can turn it into a book to fit in the open-source book collection we are slowly building (SqueakbyExample, PharoByExample, Seaside, DeepintoPharo). Now since there is no license it is not clear that it is worth the effort. Stef On 22 Apr 2014, at 01:44, stevewessels wrote: As the author of the tutorial I'm not sure how I feel about my work being referred to as "old". The tutorial is remarkably still in use to this day. I still get emails from folks thanking me for it or reporting bugs. When the tutorial was written my intended audience was Smalltalk developers wanting to build Test Driven Development (TDD) skills. It was not intended for beginners. But as it turns out lots of beginners have slogged through it. The key concepts I tried to demonstrate were how to do TDD and building good models that were testable. I also wanted to show you could make stand-alone apps using Smalltalk/Squeak for the Mac. To convert the tutorial to VisualWorks might end up being a challenge, but alas, I haven't used VW since the late 90's and I know it's grown a whole lot since those days. So I cannot recommend how you go about doing it. You're welcome to send me questions about it and any design decisions that were made. I don't claim that it is a "proper OO design" or anything like that. Interestingly, I did port the design to Objective-C for the iPhone years ago and the basic design held up fine. The GUI was obviously done differently -- I ended up adopting OpenGL for the GUI. That was work. But it turned out well and has been in the App Store ever since. So if I can help you, drop me a note. -- View this message in context: http://forum.world.st/Can-this-idea-work-tp4753741p4755668.html Sent from the VisualWorks mailing list archive at Nabble.com. ___ vwnc mailing list v...@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
[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 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 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" > An: "Pharo Development List" > 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 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 > > > > The color mapping is explainning in > http://www.humane-assessment.com/blog/?_k=W1xeAy75PKaNEd2G > > > > Purple nodes ares nodes that have the same class of the selected method. > > > > This is inti profiler in pharo, this allows your to compare 2 (or more) > instances of MessageTally, > and see the difference of this tallies. > > > > 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 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 >> >> >> >> The color mapping is explainning in >> http://www.humane-assessment.com/blog/?_k=W1xeAy75PKaNEd2G >> >> >> >> Purple nodes ares nodes that have the same class of the selected method. >> >> >> >> This is inti profiler in pharo, this allows your to compare 2 (or more) >> instances of MessageTally, >> and see the difference of this tallies. >> >> >> >> 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 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. 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 > 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 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 : > Again, cc'ing vm-dev is courteous. > > > On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel > wrote: > >> Segfault! >> >> Could it be due to #become: or #valueUnpreemptively ? (see >> PharoClassInstaller>>migrateClasses: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 wrote: > > 2014-04-24 20:44 GMT+02:00 Eliot Miranda : > Again, cc'ing vm-dev is courteous. > > > On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel > wrote: > Segfault! > > Could it be due to #become: or #valueUnpreemptively ? (see > PharoClassInstaller>>migrateClasses: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 wrote: > > 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 : > >> Again, cc'ing vm-dev is courteous. >> >> >> On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel > > wrote: >> >>> Segfault! >>> >>> Could it be due to #become: or #valueUnpreemptively ? (see >>> PharoClassInstaller>>migrateClasses: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] What is forum (was Re: Pharo Crashes)
Torsten wrote: >> FYI: Forum is available in the config browser. > >But does not load out of the box. Dependency to Glamour seems to >be missing. Forum uses quite a number of large packages that use different Metacello strategies. Stable loads 167 packages. I tend to just download from ci. If you just ignore the warnings and proceed, you get a usable image, with either stable or bleedingEdge. FOTutorial open FOBrowser open You are right that there is a configuration issue, as there are now two versions of neo-csv, grease and seaside loaded. I’ll check it out. Stephan
Re: [Pharo-dev] Pharo crashes
2014-04-24 22:43 GMT+02:00 Esteban Lorenzano : > > 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 : > >> Again, cc'ing vm-dev is courteous. >> >> >> On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel > > wrote: >> >>> Segfault! >>> >>> Could it be due to #become: or #valueUnpreemptively ? (see >>> PharoClassInstaller>>migrateClasses: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 ...) -> 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 thin
[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 : > 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 Caekenberghewrote: 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 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 : >> 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] CPU usage change on newer OS
> Am 25.04.2014 um 01:19 schrieb "Esteban A. Maringolo" : > > What % of CPU is it using? > On the old instance it is a stable 2% and on the new it is 1-1,3 %. That was the reason making me looking at it. I was so used to the 2 % I spotted the difference immediately. Norbert > My VM on idle state consumes about ~4-5% CPU. > Esteban A. Maringolo > > > 2014-04-24 15:43 GMT-03:00 Norbert Hartl : >> 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 >