Hi Nicolas, This is looking much better, thanks! Can I suggest 1 more regrouping? I think moving the Pharo.cog.spur, and Squeak if you want, Linux32ArmV6 build(s) to the main Linux builds is worthwhile (when convenient). Thanks again, Alistair On 2 April 2018 at 19:02, GitHub <[hidden email]> wrote: > > Branch: refs/heads/compile_sista_with_clang > Home: https://github.com/OpenSmalltalk/opensmalltalk-vm > Commit: 3249967cf0ab72b59bce184afd19774d3e1e6957 > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3249967cf0ab72b59bce184afd19774d3e1e6957 > Author: Nicolas Cellier <[hidden email]> > Date: 2018-04-02 (Mon, 02 Apr 2018) > > Changed paths: > M .travis.yml > > Log Message: > ----------- > Add a main build stage for Squeak and Pharo > > > Commit: 1b0f7d285f589937e9be341d6ae7a3b91b59ddb1 > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1b0f7d285f589937e9be341d6ae7a3b91b59ddb1 > Author: Nicolas Cellier <[hidden email]> > Date: 2018-04-02 (Mon, 02 Apr 2018) > > Changed paths: > M .appveyor.yml > > Log Message: > ----------- > Reorder the appveyor matrix so as to put main Squeak/Pharo build first > > While at it, add -L flag to curl so as to follow redirection > > > Commit: b7b3943dfb38dd44bdca184cf1aa8f129486a5f0 > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/b7b3943dfb38dd44bdca184cf1aa8f129486a5f0 > Author: Nicolas Cellier <[hidden email]> > Date: 2018-04-02 (Mon, 02 Apr 2018) > > Changed paths: > M .travis.yml > > Log Message: > ----------- > Try to force CC=clang in the .travis.yml matrix for linux32x86 pharo.sista.spur > > > Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/e2cfdcc731ba...b7b3943dfb38 |
Yes sure, I should do that. I had a doubt also about the HEARTBEAT="itimer" variant of Pharo.2018-04-02 20:39 GMT+02:00 Alistair Grant <[hidden email]>:
|
> On 02-04-2018, at 11:55 AM, Nicolas Cellier <[hidden email]> wrote: > > Yes sure, I should do that. > I had a doubt also about the HEARTBEAT="itimer" variant of Pharo. > Is this brand officially supported and elligible to "Main" stage? Since this relates to a question I asked some time ago I'll chime in here with a "please use the threaded timer". At least for the Pi related builds. Part of my problem is that the current builds off bintray are itimer based but appear to be labelled as threaded. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Love may be blind, but marriage is a real eye-opener. |
In reply to this post by Nicolas Cellier
Hi Nicolas, On 2 April 2018 at 20:55, Nicolas Cellier <[hidden email]> wrote: > > Yes sure, I should do that. > I had a doubt also about the HEARTBEAT="itimer" variant of Pharo. > Is this brand officially supported and elligible to "Main" stage? The threaded heartbeat is what is included in the default downloads, the itimer is there as a backup in case the threaded heartbeat has problems. My personal view is that I'd keep the main stage as small as practical, so would leave itimer out of it. Others may have a different view, of course. Cheers, Alistair > 2018-04-02 20:39 GMT+02:00 Alistair Grant <[hidden email]>: >> >> >> Hi Nicolas, >> >> This is looking much better, thanks! >> >> Can I suggest 1 more regrouping? >> >> I think moving the Pharo.cog.spur, and Squeak if you want, >> Linux32ArmV6 build(s) to the main Linux builds is worthwhile (when >> convenient). >> >> Thanks again, >> Alistair >> >> >> >> On 2 April 2018 at 19:02, GitHub <[hidden email]> wrote: >> > >> > Branch: refs/heads/compile_sista_with_clang >> > Home: https://github.com/OpenSmalltalk/opensmalltalk-vm >> > Commit: 3249967cf0ab72b59bce184afd19774d3e1e6957 >> > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3249967cf0ab72b59bce184afd19774d3e1e6957 >> > Author: Nicolas Cellier <[hidden email]> >> > Date: 2018-04-02 (Mon, 02 Apr 2018) >> > >> > Changed paths: >> > M .travis.yml >> > >> > Log Message: >> > ----------- >> > Add a main build stage for Squeak and Pharo >> > >> > >> > Commit: 1b0f7d285f589937e9be341d6ae7a3b91b59ddb1 >> > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1b0f7d285f589937e9be341d6ae7a3b91b59ddb1 >> > Author: Nicolas Cellier <[hidden email]> >> > Date: 2018-04-02 (Mon, 02 Apr 2018) >> > >> > Changed paths: >> > M .appveyor.yml >> > >> > Log Message: >> > ----------- >> > Reorder the appveyor matrix so as to put main Squeak/Pharo build first >> > >> > While at it, add -L flag to curl so as to follow redirection >> > >> > >> > Commit: b7b3943dfb38dd44bdca184cf1aa8f129486a5f0 >> > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/b7b3943dfb38dd44bdca184cf1aa8f129486a5f0 >> > Author: Nicolas Cellier <[hidden email]> >> > Date: 2018-04-02 (Mon, 02 Apr 2018) >> > >> > Changed paths: >> > M .travis.yml >> > >> > Log Message: >> > ----------- >> > Try to force CC=clang in the .travis.yml matrix for linux32x86 pharo.sista.spur >> > >> > >> > Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/e2cfdcc731ba...b7b3943dfb38 > > > |
2018-04-02 21:23 GMT+02:00 Alistair Grant <[hidden email]>:
Yes, that makes sense. Anyway if threaded compiles, itimer probably compiles as well, so the feedbcak is less important and we can delay its production. Note that the ARM builds are very slow (not finished after 16 minutes), I think that it was the reason to put them at end of Queue. https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/361280744
|
> On 02-04-2018, at 12:31 PM, Nicolas Cellier <[hidden email]> wrote: > es), I think that it was the reason to put them at end of Queue. Wow; that's noticeably longer than it takes on my Pi 3. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim A conclusion is the place where you got tired of thinking. |
In reply to this post by timrowledge
2018-04-02 21:17 GMT+02:00 tim Rowledge <[hidden email]>:
Hi Tim, which flavour of VM? we build 3 squeak, 2 newspeak and 1 pharo...
|
2018-04-02 21:47 GMT+02:00 Nicolas Cellier <[hidden email]>:
Normally, the itimer heartbeat is triggered by -DITIMER_HEARTBEAT=1 compiler option See for example https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.linux32x86/pharo.cog.spur/build.itimerheartbeat/mvm near line 47 I see no such option in ARM build, except maybe the HowToBuild instructions https://github.com/OpenSmalltalk/opensmalltalk-vm/search?p=5&q=-DITIMER_HEARTBEAT&type=Code&utf8=%E2%9C%93
|
In reply to this post by Nicolas Cellier
> On 02-04-2018, at 12:47 PM, Nicolas Cellier <[hidden email]> wrote: > > > > 2018-04-02 21:17 GMT+02:00 tim Rowledge <[hidden email]>: > > > > > On 02-04-2018, at 11:55 AM, Nicolas Cellier <[hidden email]> wrote: > > > > Yes sure, I should do that. > > I had a doubt also about the HEARTBEAT="itimer" variant of Pharo. > > Is this brand officially supported and elligible to "Main" stage? > > Since this relates to a question I asked some time ago I'll chime in here with a "please use the threaded timer". At least for the Pi related builds. > > Part of my problem is that the current builds off bintray are itimer based but appear to be labelled as threaded. > > > Hi Tim, > which flavour of VM? > we build 3 squeak, 2 newspeak and 1 pharo... I normally build just the plain old squeak/cog/spur and occasionally debug stuff. Given the absence of the -DUSE_ITIMER_HEARTBEAT=1 incantation Eliot mentioned, build.linux32ARMv6/squeak.cog.spur/mvm *should* be making the pthread timer version. The version on bintray is labelled squeak.cog.spur_linux32ARMv6_itimer_201803052012.tar.gz (for example) and I have to admit I'm not at all sure how one checks a vm to see which option it actually uses. It may simply be mislabelling of the built system? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Propaganda: a good look |
Hi Tim, On 3 April 2018 at 05:12, tim Rowledge <[hidden email]> wrote: > > I normally build just the plain old squeak/cog/spur and occasionally debug stuff. Given the absence of the -DUSE_ITIMER_HEARTBEAT=1 incantation Eliot mentioned, build.linux32ARMv6/squeak.cog.spur/mvm *should* be making the pthread timer version. The version on bintray is labelled squeak.cog.spur_linux32ARMv6_itimer_201803052012.tar.gz (for example) and I have to admit I'm not at all sure how one checks a vm to see which option it actually uses. It may simply be mislabelling of the built system? The version information tells you which heartbeat it uses: $ ./pharo --version 5.0-201710221351 Sun Oct 22 15:20:13 UTC 2017 gcc 4.9.2 [Production Spur VM] The above is threaded heartbeat (pharo.cog.spur). The itimer version will have something like "[Production ITMR Spur VM]" (from memory, I don't have one handy, but it is fairly obvious). Cheers, Alistair |
> On 02-04-2018, at 10:59 PM, Alistair Grant <[hidden email]> wrote: > > > The version information tells you which heartbeat it uses: Yeah, so 'my' version is indeed threaded (good grief it's been a long time since I looked at the code in sqUnixMain.c!) and the most recent ARMv6 vm from bintray *also* says it's threaded-timer; despite the package being labelled as squeak.cog.spur_linux32ARMv6_itimer_201804030952.tar.gz So, something small but potentially very confusing is wrong in the package building scripts. And I can't help thinking that making the information we get in the About Squeak window for 'VM General' match (as closely as possible) the results of `--version` would be helpful. It would be simple enough to re-organise the About report so long as we can get the 'BuildVariant' and 'HBID' etc values into the relevant getAttribute code. While I'm thinking about it, the version output is pretty densely packed and difficult to human-read - is anyone wedded to the precise output format for parsing with scripts etc? Would making it a bit more eye-friendly cause problems? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Engineers work to a couple of decimal places; Physicists work to an order of magnitude; Astrophysicists work to an order of magnitude in the exponent |
Free forum by Nabble | Edit this page |