- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Linux Numeric Keyboard issue in Pharo-VM fix

by Eliot Miranda

Thanks Phil! On Thu, Apr 24, 2014 at 2:16 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > > Hello, > > As I am now working on a CentOS sytem with Pharo, I got into: > > https://pharo.fogbugz.com/default.asp?11352 > > So, I put back the fix that was done in Gitorious #2e6f231 and it now > works. > > May someone integrate that fix into the main Linux repo? > It's integrated into the Cog branch now at least. -- best, Eliot

April 24, 2014

Re: [Pharo-dev] Pharo crashes

by Eliot Miranda

On Thu, Apr 24, 2014 at 1:43 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On 24 Apr 2014, at 22:13, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2014-04-24 20:44 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Again, cc'ing vm-dev is courteous. >> >> >> On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel <camille.teruel(a)gmail.com >> > 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

April 24, 2014

Linux Numeric Keyboard issue in Pharo-VM fix

by phil＠highoctane.be

Hello, As I am now working on a CentOS sytem with Pharo, I got into: https://pharo.fogbugz.com/default.asp?11352 So, I put back the fix that was done in Gitorious #2e6f231 and it now works. May someone integrate that fix into the main Linux repo? Thx Phil

April 24, 2014

Re: [Pharo-dev] Pharo crashes

by Esteban Lorenzano

On 24 Apr 2014, at 22:13, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2014-04-24 20:44 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Again, cc'ing vm-dev is courteous. > > > On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel <camille.teruel(a)gmail.com> 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 >

April 24, 2014

Re: [Pharo-dev] Pharo crashes

by Nicolas Cellier

2014-04-24 20:44 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Again, cc'ing vm-dev is courteous. > > > On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel <camille.teruel(a)gmail.com>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 >

April 24, 2014

Re: [Pharo-dev] Debugging in Production Servers

by Eliot Miranda

On Wed, Apr 23, 2014 at 10:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > I am sorry, but I disagree. > > Yes, technically, much of what we take for granted is partially possible > in most other languages, but it is often hard to use, an add-on, an > afterthought. But more important, Java developers even do not use > debuggers/inspectors/browsers during development, let alone during > production. It's just edit/compile/run/crash - add some print statements > and run again. During production its all massive plain logging. > And the crucial linguistic difference is Smalltalk's (and LISP's) resume semantics for exceptions vs Java's restart semantics. This difference is that in Smalltalk the exception handler is executed in the context of the exception, allowing the programmer to see the point of error and provide a value with which to /resume/ execution. In Java the exception is delivered in the context of the handler, discarding the execution state that caused the exception, only allowing the program to /restart/ the code that caused the exception, and making investigating the cause of the exception impossible in the current run. We can dump live stacks with FUEL for example. > And this because Smalltalk provides first-class activation records (contexts) /and/ has resume semantics for exceptions. > On 24 Apr 2014, at 06:01, S Krish <krishnamachari.sudhakar(a)gmail.com> > wrote: > > > One can easily do that with Java / Eclipse or for VC++ / Visual Studio > with attach to process. Probably I would reckon these to be more "secure" > as industry prefers rather than having live debug capabilities built in to > the code delivered or somehow "in-process". I am sure all others as in > python, ruby et als will have debug in prod capabilities if reqd. > > > > Javascript with Rhino also can easily allow live debug if the reqd jar > is present.. > > > > The bigger purchase Smalltalk gives is in reflection that can be > leveraged to produce fairly extensive logger reports which no other > langauge currently does when fault occurs in production. > > > > I doubt in production the industry is as of now willing to let debug be > acceptable specially in Banking domain. > > > > The smalltalk advantages are not translating into business gains per se > given the comfort zone of security, safety production systems are wrapped > in procedurally. > > > > > > On Thu, Apr 24, 2014 at 7:39 AM, askoh <askoh(a)askoh.com> wrote: > > Smalltalk has the capability of allowing live debugging in production > > servers. How unique is this capability? What other systems allow that? > > > > Is there a name for such capability? Can we coin one and market it? > > > > What are the pros and cons of having such a capability? > > > > All the best, > > Aik-Siong Koh > > > > > > > > -- > > View this message in context: > http://forum.world.st/Debugging-in-Production-Servers-tp4756136.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > > -- best, Eliot

April 24, 2014

Re: [Pharo-dev] Pharo crashes

by Eliot Miranda

Again, cc'ing vm-dev is courteous. On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel <camille.teruel(a)gmail.com>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. > > Dump: > Segmentation fault > > > > Smalltalk stack dump: > 0xbffb58a0 M [] in PharoClassInstaller>migrateClasses:to:using: > 0x2172b068: a(n) PharoClassInstaller > 0xbffb3f88 M BlockClosure>ensure: 0x21779288: a(n) BlockClosure > 0xbffb3fb4 M BlockClosure>valueUnpreemptively 0x21779288: a(n) BlockClosure > 0xbffb3fd4 I PharoClassInstaller>migrateClasses:to:using: 0x2172b068: a(n) > PharoClassInstaller > 0xbffb4000 I SlotClassBuilder>migrateClasses: 0x2172b138: a(n) > SlotClassBuilder > 0xbffb4020 M SlotClassBuilder>apply: 0x2172b138: a(n) SlotClassBuilder > 0xbffb4048 M SlotClassBuilder>build 0x2172b138: a(n) SlotClassBuilder > 0xbffb4064 M PharoClassInstaller class(AbstractClassInstaller class)>make: > 0x1f9d440c: a(n) PharoClassInstaller class > 0xbffb4080 M > OldClassBuilderAdapter>name:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category: > 0x2172a278: a(n) OldClassBuilderAdapter > 0xbffb476c M [] in MCClassDefinition>createClass 0x2146d174: a(n) > MCClassDefinition > 0xbffb4788 M BlockClosure>on:do: 0x2172a200: a(n) BlockClosure > 0xbffb47b4 M MCClassDefinition>createClass 0x2146d174: a(n) > MCClassDefinition > 0xbffb47d8 I MCClassDefinition>load 0x2146d174: a(n) MCClassDefinition > 0xbffb47f0 M MCClassDefinition(MCDefinition)>addMethodAdditionTo: > 0x2146d174: a(n) MCClassDefinition > 0xbffb4810 M [] in MCPackageLoader>tryToLoad: 0x2140a3c8: a(n) > MCPackageLoader > 0xbffb482c M BlockClosure>on:do: 0x2172a104: a(n) BlockClosure > 0xbffb484c M MCPackageLoader>tryToLoad: 0x2140a3c8: a(n) MCPackageLoader > 0xbffb4868 M [] in MCPackageLoader>basicLoadDefinitions 0x2140a3c8: a(n) > MCPackageLoader > 0xbffb489c M [] in > OrderedCollection(Collection)>do:displayingProgress:every: 0x21477678: a(n) > OrderedCollection > 0xbffb0efc M OrderedCollection>do: 0x21477678: a(n) OrderedCollection > 0xbffb0f2c M [] in > OrderedCollection(Collection)>do:displayingProgress:every: 0x21477678: a(n) > OrderedCollection > 0xbffb0f48 M BlockClosure>cull: 0x214969dc: a(n) BlockClosure > 0xbffb0f68 M [] in Job>run 0x21496a04: a(n) Job > 0xbffb0f84 M BlockClosure>on:do: 0x21497014: a(n) BlockClosure > 0xbffb0fa8 M [] in Job>run 0x21496a04: a(n) Job > 0xbffb0fc8 M BlockClosure>ensure: 0x21496ad0: a(n) BlockClosure > 0xbffb0fe8 M Job>run 0x21496a04: a(n) Job > 0xbffb1000 M MorphicUIManager(UIManager)>displayProgress:from:to:during: > 0x1fbfab0c: a(n) MorphicUIManager > 0xbffb1030 I ByteString(String)>displayProgressFrom:to:during: 0x209a3f20: > a(n) ByteString > 0xbffb105c M OrderedCollection(Collection)>do:displayingProgress:every: > 0x21477678: a(n) OrderedCollection > 0xbffb1080 M OrderedCollection(Collection)>do:displayingProgress: > 0x21477678: a(n) OrderedCollection > 0xbffb10a0 M MCPackageLoader>basicLoadDefinitions 0x2140a3c8: a(n) > MCPackageLoader > 0xbffb1ec4 I [] in MCPackageLoader>basicLoad 0x2140a3c8: a(n) > MCPackageLoader > 0xbffb1ee0 M BlockClosure>on:do: 0x21478ffc: a(n) BlockClosure > 0xbffb1f0c I [] in MCPackageLoader>handleLoadErrorsDuring: 0x2140a3c8: > a(n) MCPackageLoader > 0xbffb1f28 M BlockClosure>on:do: 0x21479068: a(n) BlockClosure > 0xbffb1f50 I MCPackageLoader>handleLoadErrorsDuring: 0x2140a3c8: a(n) > MCPackageLoader > 0xbffb1f74 I [] in MCPackageLoader>basicLoad 0x2140a3c8: a(n) > MCPackageLoader > 0xbffb1f94 M BlockClosure>ensure: 0x21478f80: a(n) BlockClosure > 0xbffb1fb8 I MCPackageLoader>basicLoad 0x2140a3c8: a(n) MCPackageLoader > 0xbffb1fd8 I [] in MCPackageLoader>loadWithNameLike: 0x2140a3c8: a(n) > MCPackageLoader > 0xbffb1ff8 M BlockClosure>ensure: 0x21478b50: a(n) BlockClosure > 0xbffb2024 I MCPackageLoader>useChangeSetNamed:during: 0x2140a3c8: a(n) > MCPackageLoader > 0xbffb204c I MCPackageLoader>useNewChangeSetNamedLike:during: 0x2140a3c8: > a(n) MCPackageLoader > 0xbffb2074 I MCPackageLoader>loadWithNameLike: 0x2140a3c8: a(n) > MCPackageLoader > 0xbffb209c I MCVersionLoader>loadWithNameLike: 0x2140a0e0: a(n) > MCVersionLoader > 0xbffad750 I [] in MCVersionLoader>load 0x2140a0e0: a(n) MCVersionLoader > 0xbffad770 M BlockClosure>ensure: 0x2140a184: a(n) BlockClosure > 0xbffad798 I RPackageSet class>withCacheDo: 0x1fb96f88: a(n) RPackageSet > class > 0xbffad7bc I MCVersionLoader>load 0x2140a0e0: a(n) MCVersionLoader > 0xbffad7dc I MetacelloGoferLoad(GoferLoad)>execute 0x2140a0d0: a(n) > MetacelloGoferLoad > 0xbffad800 M [] in > MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)>loadPackageDirective:gofer: > 0x21409e74: a(n) MetacelloLoadingMCSpecLoader > 0xbffad834 M [] in > MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)>loadPackageDirective:gofer: > 0x21409e74: a(n) MetacelloLoadingMCSpecLoader > 0xbffad84c M MetacelloPharo30Platform(MetacelloPlatform)>do:displaying: > 0x1fcacac0: a(n) MetacelloPharo30Platform > 0xbffad870 M > MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)>loadPackageDirective:gofer: > 0x21409e74: a(n) MetacelloLoadingMCSpecLoader > 0xbffad898 I > MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadPackageDirective:gofer: > 0x213c6cbc: a(n) MetacelloLinearLoadDirective > 0xbffb1724 M MetacelloPackageLoadDirective>loadUsing:gofer: 0x213cec08: > a(n) MetacelloPackageLoadDirective > 0xbffb174c M [] in > MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: > 0x213c6ab0: a(n) MetacelloLinearLoadDirective > 0xbffb176c M OrderedCollection>do: 0x213c70c0: a(n) OrderedCollection > 0xbffb1788 M > MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: > 0x213c6ab0: a(n) MetacelloLinearLoadDirective > 0xbffb17a8 M MetacelloLinearLoadDirective>loadUsing:gofer: 0x213c6cbc: > a(n) MetacelloLinearLoadDirective > 0xbffb17d0 M [] in > MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: > 0x213a379c: a(n) MetacelloLinearLoadDirective > 0xbffb17f0 M OrderedCollection>do: 0x213c6cd0: a(n) OrderedCollection > 0xbffb180c M > MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: > 0x213a379c: a(n) MetacelloLinearLoadDirective > 0xbffb182c M MetacelloLinearLoadDirective>loadUsing:gofer: 0x213c6ab0: > a(n) MetacelloLinearLoadDirective > 0xbffb1854 M [] in > MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: > 0x213a379c: a(n) MetacelloLinearLoadDirective > 0xbffb1874 M OrderedCollection>do: 0x213a37b0: a(n) OrderedCollection > 0xbffb1898 I > MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadLinearLoadDirective:gofer: > 0x213a379c: a(n) MetacelloLinearLoadDirective > 0xbffb976c I MetacelloLinearLoadDirective>loadUsing:gofer: 0x213a379c: > a(n) MetacelloLinearLoadDirective > 0xbffb9798 I > MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>loadWithPolicy: > 0x213a379c: a(n) MetacelloLinearLoadDirective > 0xbffb97bc I MetacelloLoaderPolicy>load 0x21400830: a(n) > MetacelloLoaderPolicy > 0xbffb97dc I MetacelloFetchingMCSpecLoader>doLoad 0x213a36d4: a(n) > MetacelloFetchingMCSpecLoader > 0xbffb9800 I [] in MetacelloMCVersion>doLoadRequiredFromArray: 0x213a2ff4: > a(n) MetacelloMCVersion > 0xbffb9818 M MetacelloPharo30Platform(MetacelloPlatform)>do:displaying: > 0x1fcacac0: a(n) MetacelloPharo30Platform > 0xbffb984c I [] in MetacelloMCVersion>doLoadRequiredFromArray: 0x213a2ff4: > a(n) MetacelloMCVersion > 0xbffb986c M BlockClosure>ensure: 0x213a3404: a(n) BlockClosure > 0xbffb989c I MetacelloMCVersion>doLoadRequiredFromArray: 0x213a2ff4: a(n) > MetacelloMCVersion > 0xbffb8754 I MetacelloMCVersion>load 0x213a2ff4: a(n) MetacelloMCVersion > 0xbffb8774 I ConfigurationOfPhratch class>loadBleedingEdge 0x213a0124: > a(n) ConfigurationOfPhratch class > 0xbffb878c M UndefinedObject()>? 0x1f500004: a(n) UndefinedObject > 0xbffb87bc I OpalCompiler>evaluate 0x2139d354: a(n) OpalCompiler > 0xbffb87e8 I SmalltalkEditor>evaluateSelectionAndDo: 0x21350720: a(n) > SmalltalkEditor > 0xbffb880c I SmalltalkEditor>evaluateSelection 0x21350720: a(n) > SmalltalkEditor > 0xbffb882c I [] in PluggableTextMorph>doIt 0x213151c0: a(n) > PluggableTextMorph > 0xbffb8854 I [] in PluggableTextMorph>handleEdit: 0x213151c0: a(n) > PluggableTextMorph > 0xbffb8874 I TextMorphForEditView(TextMorph)>handleEdit: 0x21315ed8: a(n) > TextMorphForEditView > 0xbffb889c I PluggableTextMorph>handleEdit: 0x213151c0: a(n) > PluggableTextMorph > 0xbffb8f7c I PluggableTextMorph>doIt 0x213151c0: a(n) PluggableTextMorph > 0xbffb8f9c I [] in SmalltalkEditor > class>buildSmalltalkEditorKeymappingsOn: 0x1f7a53bc: a(n) SmalltalkEditor > class > 0xbffb8fb8 M BlockClosure>cull: 0x20cef928: a(n) BlockClosure > 0xbffb8fd4 M BlockClosure>cull:cull: 0x20cef928: a(n) BlockClosure > 0xbffb8ff4 M BlockClosure>cull:cull:cull: 0x20cef928: a(n) BlockClosure > 0xbffb9020 I KMCategoryBinding>completeMatch:buffer: 0x21321a1c: a(n) > KMCategoryBinding > 0xbffb904c I [] in KMKeymap>notifyCompleteMatchTo:buffer: 0x20cf3e98: a(n) > KMKeymap > 0xbffb9070 M Array(SequenceableCollection)>do: 0x2139cf44: a(n) Array > 0xbffb9098 I KMKeymap>notifyCompleteMatchTo:buffer: 0x20cf3e98: a(n) > KMKeymap > 0xbffb7f98 M KMKeymap>onMatchWith:notify:andDo: 0x20cf3e98: a(n) KMKeymap > 0xbffb7fc8 M [] in KMCategory>onMatchWith:notify:andDo: 0x20cf3550: a(n) > KMCategory > 0xbffb7ff0 M Set>do: 0x2139cf54: a(n) Set > 0xbffb800c M KMCategory>onMatchWith:notify:andDo: 0x20cf3550: a(n) > KMCategory > 0xbffb8030 M KMCategoryBinding>verifyMatchWith:notifying:thenDoing: > 0x21321a1c: a(n) KMCategoryBinding > 0xbffb8058 M [] in KMDispatcher>dispatch: 0x21321940: a(n) KMDispatcher > 0xbffb8078 M OrderedCollection>do: 0x2139ce2c: a(n) OrderedCollection > 0xbffb809c M KMDispatcher>dispatch: 0x21321940: a(n) KMDispatcher > 0xbffb7730 M KMTarget>dispatch: 0x2132195c: a(n) KMTarget > 0xbffb7750 M [] in KMDispatchChain>dispatch: 0x2139ccf8: a(n) > KMDispatchChain > 0xbffb7778 I KMDispatchChain>do: 0x2139ccf8: a(n) KMDispatchChain > 0xbffb7794 M KMDispatchChain>dispatch: 0x2139ccf8: a(n) KMDispatchChain > 0xbffb77bc I KMDispatcher>dispatchKeystroke: 0x21315fc8: a(n) KMDispatcher > 0xbffb77d8 M TextMorphForEditView(Morph)>dispatchKeystrokeForEvent: > 0x21315ed8: a(n) TextMorphForEditView > 0xbffb7800 I TextMorphForEditView(TextMorph)>handleKeystroke: 0x21315ed8: > a(n) TextMorphForEditView > 0xbffb781c M KeyboardEvent>sentTo: 0x2139cca0: a(n) KeyboardEvent > 0xbffb7838 M TextMorphForEditView(Morph)>handleEvent: 0x21315ed8: a(n) > TextMorphForEditView > 0xbffb7854 M TextMorphForEditView(Morph)>handleFocusEvent: 0x21315ed8: > a(n) TextMorphForEditView > 0xbffb787c M [] in HandMorph>sendFocusEvent:to:clear: 0x1fabfbb8: a(n) > HandMorph > 0xbffb7898 M BlockClosure>on:do: 0x2139cbac: a(n) BlockClosure > 0xbffb6eec M WorldMorph(PasteUpMorph)>becomeActiveDuring: 0x1fabfaa4: a(n) > WorldMorph > 0xbffb6f10 M HandMorph>sendFocusEvent:to:clear: 0x1fabfbb8: a(n) HandMorph > 0xbffb6f38 M HandMorph>sendEvent:focus:clear: 0x1fabfbb8: a(n) HandMorph > 0xbffb6f5c M HandMorph>sendKeyboardEvent: 0x1fabfbb8: a(n) HandMorph > 0xbffb6f88 M HandMorph>handleEvent: 0x1fabfbb8: a(n) HandMorph > 0xbffb6fb4 M HandMorph>processEvents 0x1fabfbb8: a(n) HandMorph > 0xbffb6fcc M [] in WorldState>doOneCycleNowFor: 0x1fabfad8: a(n) WorldState > 0xbffb6ff0 M Array(SequenceableCollection)>do: 0x1fabfc34: a(n) Array > 0xbffb700c M WorldState>handsDo: 0x1fabfad8: a(n) WorldState > 0xbffb7028 M WorldState>doOneCycleNowFor: 0x1fabfad8: a(n) WorldState > 0xbffb7044 M WorldState>doOneCycleFor: 0x1fabfad8: a(n) WorldState > 0xbffb7060 M WorldMorph>doOneCycle 0x1fabfaa4: a(n) WorldMorph > 0xbffb7080 I [] in MorphicUIManager>spawnNewProcess 0x1fbfab0c: a(n) > MorphicUIManager > 0xbffb70a0 I [] in BlockClosure>newProcess 0x2135fa6c: a(n) BlockClosure > > Most recent primitives > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > basicNew > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > at:put: > elementsForwardIdentityTo: > basicNew > new: > someInstance > nextInstance > at:put: > new: > replaceFrom:to:with:startingAt: > new: > shallowCopy > species > new: > species > new: > replaceFrom:to:with:startingAt: > species > new: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > species > new: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > species > new: > replaceFrom:to:with:startingAt: > species > new: > replaceFrom:to:with:startingAt: > species > new: > replaceFrom:to:with:startingAt: > species > new: > replaceFrom:to:with:startingAt: > shallowCopy > species > new: > species > new: > replaceFrom:to:with:startingAt: > species > new: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > species > new: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > species > new: > replaceFrom:to:with:startingAt: > species > new: > replaceFrom:to:with:startingAt: > species > new: > replaceFrom:to:with:startingAt: > species > new: > replaceFrom:to:with:startingAt: > species > new: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > compare:with:collated: > at:put: > basicNew > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > instVarAt: > instVarAt:put: > at:put: > elementsForwardIdentityTo: > elementsForwardIdentityTo: > /usr/local/bin/pharo-ui: line 11: 17173 Abort trap: 6 > "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" "$@" > On 24 avr. 2014, at 13:48, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 24 Apr 2014, at 13:44, jannik laval <jannik.laval(a)gmail.com> wrote: > > Hi pharoers, > > I am trying to load Phratch in the latest Pharo3.0 Installer Mac > (image+vm), and Pharo crashes during the install. > > > Yes, and I have no clue why. > > Marcus > > > > -- best, Eliot

April 24, 2014

CPU usage change on newer OS

by 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

April 24, 2014

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

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

April 24, 2014

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

by 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 <akevalion(a)gmail.com> wrote: > >> Hi all, >> >> I would like to show you the Inti, Inti is a cool visualization to compare and handle instances of MessageTally. >> >> This is just a demo, nothing in this mail is final. >> >> This image shows the Inti program in GTInspector >> >> <image.png> >> >> The color mapping is explainning in http://www.humane-assessment.com/blog/?_k=W1xeAy75PKaNEd2G >> >> <image.png> >> >> Purple nodes ares nodes that have the same class of the selected method. >> >> <image.png> >> >> This is inti profiler in pharo, this allows your to compare 2 (or more) instances of MessageTally, >> and see the difference of this tallies. >> >> <image.png> >> >> You can get this program executing the next piece of code: >> >> Gofer new smalltalkhubUser: 'azazael' >> project: 'inti'; >> package: 'ConfigurationOfInti'; >> load. >> (Smalltalk at: #ConfigurationOfInti) load. >> >> >> http://objectprofile.com/Inti.html >> >> Best regards, >> Milton >> >> > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

April 24, 2014