[Pharo-dev] Pharo crashes

Esteban Lorenzano estebanlm at gmail.com
Thu Apr 24 16:43:48 EDT 2014


On 24 Apr 2014, at 22:13, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140424/bae4d66d/attachment-0002.html>


More information about the Pharo-dev mailing list