Re: [Pharo-dev] Pharo crashes
And please don't take this as a criticism. It's more my anxiety. I appreciate it :)
[Pharo-dev] Pharo crashes
Hi pharoers, I am trying to load Phratch in the latest Pharo3.0 Installer Mac (image+vm), and Pharo crashes during the install. It is easy to reproduce: - Load the latest Pharo Installer for Mac - Run this code: --- Gofer it url: 'http://smalltalkhub.com/mc/JLaval/Phratch/main' username: '' password: ''; package: 'ConfigurationOfPhratch'; load. (Smalltalk at: #ConfigurationOfPhratch) loadBleedingEdge. --- Cheers, Jannik -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 13:44, jannik laval jannik.la...@gmail.com wrote: Hi pharoers, I am trying to load Phratch in the latest Pharo3.0 Installer Mac (image+vm), and Pharo crashes during the install. Yes, and I have no clue why. Marcus
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 1:48 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 13:44, jannik laval jannik.la...@gmail.com wrote: Hi pharoers, I am trying to load Phratch in the latest Pharo3.0 Installer Mac (image+vm), and Pharo crashes during the install. Yes, and I have no clue why. Marcus The package I tried loads fine in 80829, but crashes in 80830, so there’s something in that update which needs to be revisited. Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
[Pharo-dev] Pharo crashes
Forum crashes on 30830 with 335, 336 and 337. The crash is while showing 'Compiling...' Stephan
Re: [Pharo-dev] Pharo crashes
Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 the stacktrace: [0mLayoutEmptyScope(Object)error: LayoutEmptyScope(LayoutAbstractScope)rebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: LayoutClassScoperebase:to: FixedLayout(ObjectLayout)reshapeFrom:to: ClassModificationPropagationpropagate:to: ClassModificationPropagation classpropagate:to: ClassModification(AbstractClassModification)propagate in Block: [ :subclass | propagations add: (ClassModification...etc... MetaclasssubclassesDo: in Block: [ :aSubclass | ... Array(SequenceableCollection)do: MCFileTreeFileUtils class(Class)subclassesDo: MetaclasssubclassesDo: ClassModification(AbstractClassModification)propagate SlotClassBuilderapplyAndUpdateSharedVariableOrSharedPool: in Block: [ :old :new | ... SlotClassBuildertrack:during: SlotClassBuilderapplyAndUpdateSharedVariableOrSharedPool: SlotClassBuilderapplySharedVariableOrPoolChange: SlotClassBuilderapply: SlotClassBuilderbuild PharoClassInstaller class(AbstractClassInstaller class)make: OldClassBuilderAdaptername:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category: MCClassDefinitioncreateClass in Block: [ ... BlockClosureon:do: Le 24 avr. 2014 à 13:59, Henrik Johansen a écrit : On 24 Apr 2014, at 1:48 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 13:44, jannik laval jannik.la...@gmail.com wrote: Hi pharoers, I am trying to load Phratch in the latest Pharo3.0 Installer Mac (image+vm), and Pharo crashes during the install. Yes, and I have no clue why. Marcus The package I tried loads fine in 80829, but crashes in 80830, so there’s something in that update which needs to be revisited. Cheers, Henry smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] Pharo crashes
what is forum? On 24 Apr 2014, at 13:58, Stephan Eggermont step...@stack.nl wrote: Forum crashes on 30830 with 335, 336 and 337. The crash is while showing 'Compiling...' Stephan
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 14:04, Christophe Demarey christophe.dema...@inria.fr wrote: Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 Yes, this is already here: https://pharo.fogbugz.com/f/cases/13223/Error-Should-not-happen-in-rebase-to Marcus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 2:21 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 14:04, Christophe Demarey christophe.dema...@inria.fr wrote: Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 Yes, this is already here: https://pharo.fogbugz.com/f/cases/13223/Error-Should-not-happen-in-rebase-to Marcus If I revert (comment out classModification propagate) SlotClassBuilder #applyAndUpdateSharedVariableOrSharedPool: classModification ^ self track: classModification during: [ :old :new | installer classDefinitionChangedFrom: old to: new by: classModification. classModification propagate ]. in a 80830 image, loading works fine. … but I guess that change might be the entire point of the patch? Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Pharo crashes
On 24 avr. 2014, at 14:37, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 24 Apr 2014, at 2:21 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 14:04, Christophe Demarey christophe.dema...@inria.fr wrote: Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 Yes, this is already here: https://pharo.fogbugz.com/f/cases/13223/Error-Should-not-happen-in-rebase-to Marcus If I revert (comment out classModification propagate) SlotClassBuilder #applyAndUpdateSharedVariableOrSharedPool: classModification ^ self track: classModification during: [ :old :new | installer classDefinitionChangedFrom: old to: new by: classModification. classModification propagate ]. in a 80830 image, loading works fine. … but I guess that change might be the entire point of the patch? Yes removing this line will reintroduce the subclass bug. Moreover I think this line is not the cause but a symptom revealer (cf my other mails about classes that have wrong layout). Now I think the segfault is because of a wrong class format somewhere. Cheers, Henry
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 14:57, Camille Teruel camille.ter...@gmail.com wrote: On 24 avr. 2014, at 14:37, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 24 Apr 2014, at 2:21 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 14:04, Christophe Demarey christophe.dema...@inria.fr wrote: Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 Yes, this is already here: https://pharo.fogbugz.com/f/cases/13223/Error-Should-not-happen-in-rebase-to Marcus If I revert (comment out classModification propagate) SlotClassBuilder #applyAndUpdateSharedVariableOrSharedPool: classModification ^ self track: classModification during: [ :old :new | installer classDefinitionChangedFrom: old to: new by: classModification. classModification propagate ]. in a 80830 image, loading works fine. … but I guess that change might be the entire point of the patch? Yes removing this line will reintroduce the subclass bug. Moreover I think this line is not the cause but a symptom revealer (cf my other mails about classes that have wrong layout). Now I think the segfault is because of a wrong class format somewhere. So we do another update with the postscript. if that fails, we revert so not all builds are broken. Do we then revert just that method? Or really all updates to 829? Marcus
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 14:57, Camille Teruel camille.ter...@gmail.com wrote: On 24 avr. 2014, at 14:37, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 24 Apr 2014, at 2:21 , Marcus Denker marcus.den...@inria.fr wrote: On 24 Apr 2014, at 14:04, Christophe Demarey christophe.dema...@inria.fr wrote: Yes it looks like there is a bug in the slot class builder. I also have a job failing since #30830 Yes, this is already here: https://pharo.fogbugz.com/f/cases/13223/Error-Should-not-happen-in-rebase-to Marcus If I revert (comment out classModification propagate) SlotClassBuilder #applyAndUpdateSharedVariableOrSharedPool: classModification ^ self track: classModification during: [ :old :new | installer classDefinitionChangedFrom: old to: new by: classModification. classModification propagate ]. in a 80830 image, loading works fine. … but I guess that change might be the entire point of the patch? Yes removing this line will reintroduce the subclass bug. Moreover I think this line is not the cause but a symptom revealer (cf my other mails about classes that have wrong layout). Now I think the segfault is because of a wrong class format somewhere. I revert this method in 3.0 834 so we get rid of the crashes… then we can find a better fix later. Marcus
Re: [Pharo-dev] Pharo crashes
2014-04-24 20:44 GMT+02:00 Eliot Miranda eliot.mira...@gmail.com: Again, cc'ing vm-dev is courteous. On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel camille.ter...@gmail.comwrote: Segfault! Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstallermigrateClasses:to:using:) I suspect the become. Thats the last primitive. I suspect it's something to do with become on machine code. I suspect some of my recent changes have not been integrated. e.g. VMMaker.oscog-eem.669. Hi Eliot, no, it is way behind ! The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. As for the platform sources, I have no idea what/when was the last merge with your svn branch... As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. It could be a better start for integrating your changes. But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications. I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. Igor, Esteban and co may have a different idea about it. -- best, Eliot
Re: [Pharo-dev] Pharo crashes
On 24 Apr 2014, at 22:13, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 2014-04-24 20:44 GMT+02:00 Eliot Miranda eliot.mira...@gmail.com: Again, cc'ing vm-dev is courteous. On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel camille.ter...@gmail.com wrote: Segfault! Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstallermigrateClasses:to:using:) I suspect the become. Thats the last primitive. I suspect it's something to do with become on machine code. I suspect some of my recent changes have not been integrated. e.g. VMMaker.oscog-eem.669. Hi Eliot, no, it is way behind ! The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. As for the platform sources, I have no idea what/when was the last merge with your svn branch... As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. It could be a better start for integrating your changes. But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications. I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. Igor, Esteban and co may have a different idea about it. no, I was thinking more or less the same… but still did not looked at it deeply :) btw… I do not know which randomly picked changes you are talking about. I certainly stopped doing integrations when Eliot started to commit spur stuff, to wait until is more or less ready (bah, with Clement we tried once and it was not worthy, so we rolled back). then… other stuff: I also don’t know about random methods reformatted. I know I reformatted some, but those I worked on (usually not in VMMaker, with minor exceptions). Of course, I’m not the only one working on those sources, but I certainly did many changes with the years. Finally: ok, vm shouldn’t crash… but this bug was not vm related but a bad integration (in the new class builder) we rollbacked. That’s why it was not copied to vm-dev :) cheers, Esteban -- best, Eliot
Re: [Pharo-dev] Pharo crashes
On Thu, Apr 24, 2014 at 1:43 PM, Esteban Lorenzano esteba...@gmail.comwrote: On 24 Apr 2014, at 22:13, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 2014-04-24 20:44 GMT+02:00 Eliot Miranda eliot.mira...@gmail.com: Again, cc'ing vm-dev is courteous. On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel camille.ter...@gmail.com wrote: Segfault! Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstallermigrateClasses:to:using:) I suspect the become. Thats the last primitive. I suspect it's something to do with become on machine code. I suspect some of my recent changes have not been integrated. e.g. VMMaker.oscog-eem.669. Hi Eliot, no, it is way behind ! The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. As for the platform sources, I have no idea what/when was the last merge with your svn branch... As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. It could be a better start for integrating your changes. But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications. I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. Igor, Esteban and co may have a different idea about it. no, I was thinking more or less the same… but still did not looked at it deeply :) btw… I do not know which randomly picked changes you are talking about. I certainly stopped doing integrations when Eliot started to commit spur stuff, to wait until is more or less ready (bah, with Clement we tried once and it was not worthy, so we rolled back). then… other stuff: I also don’t know about random methods reformatted. I know I reformatted some, but those I worked on (usually not in VMMaker, with minor exceptions). Of course, I’m not the only one working on those sources, but I certainly did many changes with the years. Finally: ok, vm shouldn’t crash… but this bug was not vm related but a bad integration (in the new class builder) we rollbacked. That’s why it was not copied to vm-dev :) At last for the core VM classes (ignore plugins) I wish you would integrate by integrating your ephemeron and NativeBoost changes into my tip. I think you're losing a lot of goodness coming form the continuous integration and testing my colleague Bob Westergaard does at Cadence. It worries me that the Pharo VM is buggy. I don't think it needs to be. And please don't take this as a criticism. It's more my anxiety. cheers, Esteban cheers! -- best, Eliot -- best, Eliot
Re: [Pharo-dev] Pharo crashes
2014-04-24 22:43 GMT+02:00 Esteban Lorenzano esteba...@gmail.com: On 24 Apr 2014, at 22:13, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 2014-04-24 20:44 GMT+02:00 Eliot Miranda eliot.mira...@gmail.com: Again, cc'ing vm-dev is courteous. On Thu, Apr 24, 2014 at 4:58 AM, Camille Teruel camille.ter...@gmail.com wrote: Segfault! Could it be due to #become: or #valueUnpreemptively ? (see PharoClassInstallermigrateClasses:to:using:) I suspect the become. Thats the last primitive. I suspect it's something to do with become on machine code. I suspect some of my recent changes have not been integrated. e.g. VMMaker.oscog-eem.669. Hi Eliot, no, it is way behind ! The https://github.com/pharo-project/pharo-vm/ master head is marked as merged with VMMaker.oscog-eem.333 though the merge is very partial. There are also some changes that have been picked from further MC versions, quite randomly IMO (most are related to the Spur VM and are of no value for COG!), but the MC versions are not marked as merged this time. As for the platform sources, I have no idea what/when was the last merge with your svn branch... As I already ranted about, there have been a lot of cosmetic changes (like reformatting some methods) which now are a drag causing many conflicts at each MC merge operation... I've cancelled most of these in my https://github.com/nicolas-cellier-aka-nice/pharo-vm nicedevel branch just to see a bit clearer. It could be a better start for integrating your changes. But synchronizing the svn changes with the MC changes is not that easy; doing it manually is error prone, it should be automated. For this reason, the all-in-one git repo is superior IMO, despite the small MC-git complications. I think the fastest strategy for catching up with Spur would be to re-apply the Pharo changes to the svn/VMMaker.oscog head one by one, rather than the opposite, but I'm not the maintainer. Igor, Esteban and co may have a different idea about it. no, I was thinking more or less the same… but still did not looked at it deeply :) btw… I do not know which randomly picked changes you are talking about. I certainly stopped doing integrations when Eliot started to commit spur stuff, to wait until is more or less ready (bah, with Clement we tried once and it was not worthy, so we rolled back). then… other stuff: I also don’t know about random methods reformatted. I know I reformatted some, but those I worked on (usually not in VMMaker, with minor exceptions). Of course, I’m not the only one working on those sources, but I certainly did many changes with the years. It's easy for me to say, because I did the job of tracing the differences when tracking bug https://pharo.fogbugz.com/f/cases/11130 And since git is a super tool, all is publicly traced. So here is the major source of cosmetic changes: the scripts for applying the transformation (self var: #foo ...) - var: #foo type: ... have been applied separately in pharo branch, but with a different layout (space after :) like Dave did in interpreter VM, but unlike Eliot did in .oscog branch if I remember correctly. Then a few other formatting have been done manually. Normally after a merge they are not shown... But since the last merge wirth 333 was partial, we can't use merge from MC, we are forced to use changes that show all the diffs, otherwise we'll miss some of the changes not merged in further merges. Thoses changes can be cancelled by re-applying Eliot's version. You can check on my branch UndoBlankChanges https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/7ee237a851f2470ca433dcd53388570248778c19 As for the random changes, they are all marked LucFabresse (I think an effect of older gitfiletree). I don't think they are really random: it's more like an aborted merge that was partially reverted. So logically, the things that were not reverted were harmless (the Spur related things). There was certainly a good reason for wanting to merge (like work on simulator maybe) And reverting was probably a good decision at that time because Spur introduction was wausing some Cog regressions. My point is not to denigrate Luc's or Esteban's work, maintaining a parallel branch is complex enough! But when you are searching for a specific bug like those differences appear as random and are parasiting... And when it's time to cancel the debt toward Eliot's branch, that can be disturbing : those methods conflict because of author and time stamp, as I said probably a former gitfiletree bug... You can check the changes in my branch revertLucFabresseAheadChanges https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/847c254168d0b246c49dfcfe3f3b294c92ca60a8 Looking at history, the merge was with Eliot's 406: https://github.com/nicolas-cellier-aka-nice/pharo-vm/commits/a05cda7fb80d891a3ded12f049d4efa5cc41b477/mc/VMMaker-oscog.package/ObjectMemory.class/instance/shouldRemapObj..st The last thing I
