[Vm-dev] Validation builds failing
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:
> 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?).
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.
>> 2017-06-10 20:22 GMT+02:00 K K Subbu <kksubbu.ml at gmail.com
>> <mailto:kksubbu.ml at gmail.com>>:
>> I tried revalidating my pull request
>> But validation checks are failing in Appveyor and Travis.
>> Appveyor ld suffers a seg fault in win32x86/squeak.cog.v3 since 3
>> Travis has been failing for past 4 months (since build 603)
>> 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...
More information about the Vm-dev