[Vm-dev] Validation builds failing

Ben Coman btc at openinworld.com
Mon Jun 12 15:30:34 UTC 2017


On Sun, Jun 11, 2017 at 4:24 PM, K K Subbu <kksubbu.ml at gmail.com> wrote:

>
> Eliot/Esteban,
>
> Thank you for the clarifications.
>
> I have no specific preference on - or -- but I took care to ensure that no
> existing script or code will break and others can continue to follow their
> convention. More accommodation with less code.
>
> The patch is really a trial towards a larger goal. As per sloccount(1)
> tool, platforms/unix has grown quite big - ~ 37k C and ~ 10k of sh with vm
> alone accounting for ~6k. It has already exceeded the comfort zone of a
> single developer. Without careful pruning, the trunk branch will bloat and
> rot over time. Git makes pruning really simple.
>
> The main vm code should really be a thin layer which just reifies
> host-specific objects (processor, memory, file, os, ...) and enters the
> interpreter loop as early as possible. Rest of the logic can be handled in
> Smalltalk. We don't even have to wait to detect peripherals like display or
> audio to start the main loop, as they can be loaded at any time. Keeping
> the vm code small also encourages more ports.
>
> Regards .. Subbu
>
> On Sunday 11 June 2017 01:31 AM, Nicolas Cellier wrote:
>
>> Hi Subbu,
>> yes the red status is not very instructive...
>> The status of change seems OK, no regression,
>> I'd like to have an opinion of Pharo team, because it sounds like
>> reverting their double dash changes (which you say was unecessary), and
>> allowing backward double dash compatibility for everyone (which Squeak
>> does not really need, but it does not hurt).
>>
>> To me, reducing the unecessary differences between Squeak/Pharo is a
>> good thing, but I don't want to decide such things alone, as Ben
>> suggested, this should be discussed here (or was it?).
>> Esteban?
>>
>
If I can hazard to guess, some "#if PharoVM" were simply the
easiest/quickest way to deal with all the little divergences the
Pharo-non-OpenSmalltalkVM had accumulated, to efficently re-integrate with
OpenSmalltalkVM without getting caught up in discussions such as this.  My
initial concerns may have been over-enthusiastic at guessing at Pharo's
requirements.  While Esteban has been very busy ironing out the Pharo 6
release, maybe we can take from his lack of comment that the remaining
issue "--help showing only single-dashes" is not a big deal.

So lets integrate the PR (because there are some other good things in it,
and also its good to minimise the "#if PharoVM"s ).  Part of Pharo
philosophy to facilitate moving forward is that mistakes are okay.  Its
only a mistake if someone complains, and its then easy to add double-dash
to help message.  I wouldn't expect the permissive single+double dash in
actual options to be any problem.

cheers -ben


>
>>
>>
>> 2017-06-10 20:22 GMT+02:00 K K Subbu <kksubbu.ml at gmail.com
>> <mailto:kksubbu.ml at gmail.com>>:
>>
>>
>>
>>     Hi,
>>
>>     I tried revalidating my pull request
>>     https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/136
>>     <https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/136>
>>
>>     But validation checks are failing in Appveyor and Travis.
>>
>>     Appveyor ld suffers a seg fault in win32x86/squeak.cog.v3 since 3
>> days:
>>
>>       https://ci.appveyor.com/project/OpenSmalltalk/vm/history
>>     <https://ci.appveyor.com/project/OpenSmalltalk/vm/history>
>>
>>     Travis has been failing for past 4 months (since build 603)
>>
>>      https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds
>>     <https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds>
>>
>>     What should I do with my pull request? Close it now? or Wait for a
>>     green build and resubmit a new PR against this commit?
>>
>>     Appreciate your help in resolving this bottleneck.
>>
>>     TIA .. Subbu
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170612/b9bbbafe/attachment.html>


More information about the Vm-dev mailing list