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

[Marcus Denker]

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/repositoryError: Should not 
happen
LayoutEmptyScope(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

[GitHub]

  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]

[GitHub]

  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)

[Sven Van Caekenberghe]

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

[Marcus Denker]

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

[Torsten Bergmann]

>The good developers / expert users will not do what you state. The eclipse 
>debug, inspector, watches >are very much part of a normal dev cycle in our 
>place with around 100 devs.

This is not a problem of being expert or not. In languages like C/C++ you often 
need 
to deploy additional debug infos with the runtime (debug symbols in COFF, ...) 
to get
anything useful - which usually is not done by default and needs additional 
effort 
if you want to debug in production.

Situation in Java is better from the tooling side because there are no different
CPU architectures/instruction sets to consider - just one bytecode set and one 
JVM. 
There are nice tools to monitor or debug - but still you have to run the JVM 
with 
debug option and debugging from the external side to get the right debugging 
experience
with stepping through the code.

So if you want to debug a web-app in Java the same way you debug at development 
time 
you would have to restart your JBoss, Websphere, ... and connect to a specific 
debug port. 
That is usually not done in a productive Java app because of a production 
downtime,
limited developer access to it, ...
And yes - there is JMX with MBeans, but this is more for monitoring than real 
debugging.


Comparing inspectors of Eclipse with the inspectors of Smalltalk is comparing 
apples
with oranges. For sure Eclipse has catched up with the IDE and is now also 
providing inspectors in the UI, also allows evaluating limited expression and 
good watches. 

In Smalltalk you can implement you own inspectors/install them at 
runtime/change 
similar to anything other. You can even load new tools and later remove them 
while running.
As we know Smalltalk is different in many regards.

Typical Debugging in other languages is often dealing with the already deceased.
Developers work with logging info from production or at a crashed heap dump, 
etc.
Errors are then often reproduced back in the IDE/dev environment. 

Unfortunately this often means additional costs and more time before a fix is 
ready
- but the World seems to be satisfied with this already

In Smalltalk you can easily catch specific cases while running. You can easily
add code at runtime to check issues (if developer tools are not stripped):

  shopItem id = 1234567 ifTrue: [ shopItem inspect ]

and even save a copy of the image at a specific point in time/situation for 
offline 
inspection. This is not comparable to a dump because the time to debug in ST 
tends to zero. 
While in Java you have to resetup the environment/IDE with the code version, 
etc.

You can even manipulate and fix data in production easily with Smalltalk:

  shopItem id = 1234567 ifTrue: [ shopItem price: 12.3s2 ]

And ... you can also shoot yourself in the foot if not done carefully ;)

Debugging in Smalltalk is different: you do not debug from the outside - you
do not have to restart the program and navigate to the point where it happened. 
If the developer tools are included you can just switch and use them. You also
do not have to recompile the whole thing when you found the problem. If there
is an easy workaround you can directly apply it to your program and later fix
it in the development stream.

So Smalltalk - as a changeable dynamic object system - is here more comparable 
to a database.
You do not have to stop while it is running in production and you can change and
inspect or even fix the program at will. With all the up's and downs of this 
approach.

I doubt that this could/should be marketed as a killer feature. We should keep
it as our own little secret.

But it is not only a question of technical feasability: often "production 
environment" 
is seen as "holy" and "untouchable"  for other reasons like security. So nobody
is missing something when the developers do not debug/work directly in 
production.

Bye
T.




 
 

Re: [Pharo-dev] Debugging in Production Servers

[kilon alios]

"You do not have to stop while it is running in production and you can
change and
inspect or even fix the program at will. With all the up's and downs of
this approach."

Visual Studio can do this with Edit and Continue

https://www.youtube.com/watch?v=M6J34B37wUc

So the world definitely starts to catch up with Smalltalk. Which can only
be a good thing.


On Thu, Apr 24, 2014 at 12:26 PM, Torsten Bergmann  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

[Serge Stinckwich]

Ok thank you Marcus !
Missing my continuous dose of working images ;-)

Envoyé de mon iPhone

> Le 24 avr. 2014 à 16:17, Marcus Denker  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?

[Henrik Johansen]

I tried loading Roassal3d into 30830 using
Gofer new smalltalkhubUser: 'ronsaldo' project: 'roassal3d'; package: 
'ConfigurationOfRoassal3d'; load. (Smalltalk at: #ConfigurationOfRoassal3d) 
loadDevelopment

using both the VM linked at
http://files.pharo.org/vm/pharo/mac/Pharo-VM-mac-stable.zip (from December?)
and the latest successful from CI
https://ci.inria.fr/pharo/view/3.0-VM/job/PharoVM/Architecture=32,Slave=vm-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

[Marcus Denker]

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?

[Henrik Johansen]

OK, so it crashes loading NBOpenGL-Core from 
http://www.smalltalkhub.com/mc/PharoExtras/NBOpenGL/main.

The Pharo VM includes NB… right?

Cheers,
Henry

On 24 Apr 2014, at 12:52 , Henrik Johansen  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?

[Marcus Denker]

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

[jannik laval]

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

[Stephan Eggermont]

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

[Camille Teruel]

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/repositoryError: Should not 
> happen
> LayoutEmptyScope(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

[Marcus Denker]

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

[Torsten Bergmann]

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

[GitHub]

  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

[Henrik Johansen]

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

[Stephan Eggermont]

Forum crashes on 30830 with 335, 336 and 337.
The crash is while showing 'Compiling...'

Stephan

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

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

[Marcus Denker]

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

[Christophe Demarey]

Yes it looks like there is a bug in the slot class builder.
I also have a job failing since #30830

the stacktrace:
LayoutEmptyScope(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)

[Stefan Marr]

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

[Esteban Lorenzano]

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

[Marcus Denker]

>>> 
>>> 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]

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

[Sean P. DeNigris]

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

[Marcus Denker]

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

[Marcus Denker]

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]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] d3c35d: 30832

[GitHub]

  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

[Henrik Johansen]

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

[Sean P. DeNigris]

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)

[Sean P. DeNigris]

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

[Camille Teruel]

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

[Camille Teruel]

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

[Marcus Denker]

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

[Henrik Johansen]

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

[Alexandre Bergel]

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

[p...@highoctane.be]

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

[GitHub]

  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]

[GitHub]

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

Re: [Pharo-dev] Pharo crashes

[Marcus Denker]

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

[Henrik Johansen]

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)

[Torsten Bergmann]

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

[stepharo]

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

[GitHub]

  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]

[GitHub]

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

Re: [Pharo-dev] What is forum (was Re: Pharo Crashes)

[Marcus Denker]

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

[Tudor Girba]

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

[stepharo]

Hi henryk

thanks for your feedback, we need more people looking at changes.

Stef

Re: [Pharo-dev] [Moose-dev] Inti in Pharo

[Alexandre Bergel]

> 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)

[Torsten Bergmann]

> 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

[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]

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

[Nicolas Cellier]

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

[Esteban Lorenzano]

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

[Eliot Miranda]

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)

[Stephan Eggermont]

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

[Nicolas Cellier]

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

[Nicolas Cellier]

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

[Esteban A. Maringolo]

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

[Ben Coman]

Eliot Miranda wrote:

  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. 
  
  
  
  
  

Thanks for that Eliot.  Its very interesting to learn that
distinction.  
cheers -ben

Re: [Pharo-dev] CPU usage change on newer OS

[Sven Van Caekenberghe]

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

[Norbert Hartl]

> 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
>