On Thu, Apr 24, 2014 at 1:43 PM, Esteban Lorenzano <esteba...@gmail.com>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 <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
>>> 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

Reply via email to