Validation builds failing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Validation builds failing

K K Subbu
 
Hi,

I tried revalidating my pull request
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

Travis has been failing for past 4 months (since build 603)

  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
Reply | Threaded
Open this post in threaded view
|

Re: Validation builds failing

Nicolas Cellier
 
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?



2017-06-10 20:22 GMT+02:00 K K Subbu <[hidden email]>:

Hi,

I tried revalidating my pull request 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

Travis has been failing for past 4 months (since build 603)

 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

Reply | Threaded
Open this post in threaded view
|

Re: Validation builds failing

K K Subbu
 
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?
>
>
>
> 2017-06-10 20:22 GMT+02:00 K K Subbu <[hidden email]
> <mailto:[hidden email]>>:
>
>
>     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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Validation builds failing

Ben Coman
 


On Sun, Jun 11, 2017 at 4:24 PM, K K Subbu <[hidden email]> 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 <[hidden email]
<mailto:[hidden email]>>:



    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




Reply | Threaded
Open this post in threaded view
|

Re: Validation builds failing

Eliot Miranda-2
 
Hi Ben, Hi Subbu,

On Jun 12, 2017, at 8:30 AM, Ben Coman <[hidden email]> wrote:

On Sun, Jun 11, 2017 at 4:24 PM, K K Subbu <[hidden email]> 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. 


Whatever gets omitted please make sure that the help text remains correct t and that the Pharo vm accepts double dashes and the Squeak vm accepts si tie dashes.  There are a host of scripts and documents that use either one or the other depending on dialect and the vm must not break them.

Personally I don't object to the Squeak vm access the my both single and double dashes, but others might differ.  What the Pharo vm should do with single dashes is, I think, up to Esteban.

cheers -ben

 



2017-06-10 20:22 GMT+02:00 K K Subbu <[hidden email]
<mailto:[hidden email]>>:



    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




Reply | Threaded
Open this post in threaded view
|

Re: Validation builds failing

K K Subbu
 
On Monday 12 June 2017 09:35 PM, Eliot Miranda wrote:
>
> Whatever gets omitted please make sure that the help text remains
> correct t and that the Pharo vm accepts double dashes and the Squeak vm
> accepts si tie dashes.  There are a host of scripts and documents that
> use either one or the other depending on dialect and the vm must not
> break them.

I posted a smoke test script for important combinations (see my comment
in PR). Perhaps these could be added to the post-build smoke tests to
ensure that critical scripts don't break.

Regards .. Subbu