[Vm-dev] VM Maker: VMMaker.oscog-nice.1733.mcz

[Nicolas Cellier]

Hi Stephane,
let's be clear: which tests are you speaking of?

There is practically no SUnit for the VM dev.

The first level is using the simulator.
But
- running the simulator is pretty long, it's efficient if you want to focus
on a specific bug, less for wide-range testing
 I used the simulator though by running most squeak tests and that took >
24h
 My goal was to see if I would not break the simulator because Eliot
heavily rely on it.
 I did mainly simulate one flavour : squeak stack spur 64bits. Maybe the 32
bits too, but I'm not sure now
- the simulator does not catch all, and have subtle differences about
signed/unsigned handling

The next level is to generate the code and compile it.
I generated these ones:
32bits squeak.cog.v3 squeak.cog.spur squeak.stack.v3 squeak.stack.spur
64bits squeak.cog.spur squeak.stack.spur
Then I compiled... It took me a bunch of efforts because the motion of
UUIDplugin from internal to external made the compilation failed, I don't
know exactly why, so Ias workaround  had to first undo it, find . -name
'*.o' -delete, then compile again.

At this time, I think it was late and I only checked the 64 bits squeak
stack spur which fits my main working image.
I ran a few tests that passed so I commited these changes that are two
years old and that I was preparing for several days.
My mistake was to not run a 32 bits image, that's pretty true I messed up.
I apologize again.

But you can't say that I don't test, it's insulting.
I do pretty much for one not being paid to.
For these reasons, I invite you to be a bit more forgiving.

What I tell you is that a bot DOES the rest of the tests for us.
What I tell you is that there is no other way to fire the bot than
committing currently.
It's not perfect, but that's already something.
So what's the point of blaming me for an architecture that I'm not in
charge of, that I did not decide, that I don't control?
Do you still think I could do more?

It's sad that the work of Igor was not leveraged, but it's a social problem
not a technical one.
Igor work was constructed as a fork. Surprisingly that failed.
Or wasn't it doomed to fail because you didn't have the
manpower/money/experienced team, whatever the tremendous quality of Igor?
Who did take care of the main VM contributor and his own constraints at
this time?

Please stop saying other do not understand,
it's absolutely un-constructive.

If you want to see some progress, there's another attitude than being
aggressive.
You could try to collaborate for example.
Do you really want a better infrastucture, git, etc?
If yes, then find a win-win attitude with Eliot, and we'll see some
progress.
Others like me will follow.
Can you understand that?


2016-03-19 7:48 GMT+01:00 stephane ducasse <stephane.ducasse at gmail.com>:

>
>
> Two points
>
>
> You know that I'm not found of the break it first, fix it later strategy.
>
>
> I have no problem with that.
> I have problem that automated tests do not catch it to free programmers
> and brain.
>
> Though it sometimes happen that I get caught.
> Here it sounds like you are not granting to me this right to break things
> when in the same time this right is totally abused in every day Pharo
> development…
>
>
> You see in Pharo our process is stagged. If the tests to not run, the
> tests is not in.
> For example this year we did not integrate Epicea and marcus tried 15
> times (for real 15 times)
> this is just that you did not see it. Now we break things because we do
> not have enough tests and UI/widgets is not covered.
>
> So despite the fact that you are completely right this time, I'd say that
> I would have been more inclined to take the lesson I deserved from say
> Eliot ;)
>
> I'm taking too much time writing this when there's probably more trouble
> with the spur VM currently and that ain't good.
> Stephane, I like your energy, and I wish I could use and promote Pharo,
> but please, keep it positive :)
> Tonight, you gave me bad vibrations :(
>
> Nicolas
>
>
> 2016-03-18 22:13 GMT+01:00 stephane ducasse <stephane.ducasse at gmail.com>:
>
>>
>> I wonder why you do not check our builds before pushing a change. Staging
>> changes can make sure that
>> we control the propagation of errors. And as you know, error = time =
>> money.
>> This is always difficult for someone to try to understand error that he
>> had  no clue from where they come.
>>
>> Stef
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160319/7e3f2d52/attachment-0001.htm