- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] SSL error on windows 7

by Cyril Ferlicot D.

Le 02/04/2018 Ã 23:49, Sven Van Caekenberghe a Ã©critÂ : > Well, it works for me on macOS and Ubuntu with [version] 'Pharo7.0' 'Pharo-7.0+alpha.build.660.sha.2eb9bd2f41e7b0bd8f9f4190906910f83c178ab1 (32 Bit)' > > Both socket(stream) code as well as SSL plugin code is different between the 3 main platforms. SSL plugin code also depends on your OS's libraries. It is complex and messy. > > Maybe other Windows user can help, I don't know. I can't try on Windows 7, sorry. > > Did it work before ? > > > It has been a long time since I loaded a project on this computer (I usually takes pre made image from CI), but I know it worked before. I know it also work on my laptop with Windows 10 since I could load the latest Iceberg on it. I tried with different Pharo and: - Pharo 70: Fail - Pharo 61: Fail - Pharo 60: Fail - Pharo 50: Success -- Cyril Ferlicot https://ferlicot.fr

April 2, 2018

Re: [Pharo-dev] SSL error on windows 7

by Sven Van Caekenberghe

> On 2 Apr 2018, at 22:13, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Hi! > > I have some trouble with SSL in Pharo 7. > > If I execute this code: > > ZnClient new url: 'https://google.com'; get. > > I get a result. > > If I execute this code: > > ZnClient new url: 'https://github.com'; get. > > I get this error: Error: SSL Exception: connect failed [code:-5] Well, it works for me on macOS and Ubuntu with [version] 'Pharo7.0' 'Pharo-7.0+alpha.build.660.sha.2eb9bd2f41e7b0bd8f9f4190906910f83c178ab1 (32 Bit)' Both socket(stream) code as well as SSL plugin code is different between the 3 main platforms. SSL plugin code also depends on your OS's libraries. It is complex and messy. Maybe other Windows user can help, I don't know. I can't try on Windows 7, sorry. Did it work before ? > I tried with both stable and latest vm. > > This is very troublesome because I cannot load some projects on this > computer :( > > I am on windows 7. > > Here are the details and the stack: > > Image > ----- > E:\Pharo\images\Pharo 7.0 (development version)-22\Pharo 7.0 > (development version)-22.image > Pharo7.0alpha > Build information: > Pharo-7.0+alpha.build.749.sha.039a4b6f0d61ba99778349c4cff2c4e8d5ff9227 > (32 Bit) > Unnamed > > Virtual Machine > --------------- > C:\Users\JeCisC\Documents\Pharo\vms\70-x86\Pharo.exe > CoInterpreter VMMaker.oscog-eem.2359 uuid: > b3273e3e-dd9d-4819-a928-7034e1cf412c Mar 16 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2359 uuid: > b3273e3e-dd9d-4819-a928-7034e1cf412c Mar 16 2018 > VM: 201803161038 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Date: Fri Mar 16 11:38:09 2018 +0100 $ Plugins: 201803161038 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > Win32 built on Mar 16 2018 11:02:19 GMT Compiler: 6.4.0 > VMMaker versionString VM: 201803161038 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Fri Mar 16 > 11:38:09 2018 +0100 $ Plugins: 201803161038 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > CoInterpreter VMMaker.oscog-eem.2359 uuid: > b3273e3e-dd9d-4819-a928-7034e1cf412c Mar 16 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2359 uuid: > b3273e3e-dd9d-4819-a928-7034e1cf412c Mar 16 2018 > > Operating System/Hardware > ------------------------- > Win32 6.1 IX86 > > Operating System Details > ------------------------ > Operating System: Windows 7 Professional N (Build 7601 Service Pack 1) > SP major version: 1 > SP minor version: 0 > Suite mask: 100 > Product type: 1 > > > ============================================================== > > ZdcSecureSocketStream(Object)>>error: > ZdcSecureSocketStream>>sslException:code: > ZdcSecureSocketStream>>connect > ZnClient>>setupTLSTo: > ZnClient>>newConnectionTo: > ZnClient>>getConnectionAndExecute > ZnClient>>executeWithRedirectsRemaining: > [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in > ZnClient>>executeWithRetriesRemaining: in Block: [ self > executeWithRedirectsRemaining: self maxNumb...etc... > BlockClosure>>on:do: > ZnClient>>executeWithRetriesRemaining: > [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self > executeWithRetriesRemaining: self numberOfRetries ] > on: Error > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self > executeWithRetriesRemaining: self numberOfR...etc... > BlockClosure>>on:do: > [ [ self executeWithRetriesRemaining: self numberOfRetries ] > on: Error > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ > self executeWithRetriesRemaining: self numberO...etc... > [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ] > [ activeProcess psValueAt: index put: anObject. > aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in > Block: [ activeProcess psValueAt: index put: anObject.... > BlockClosure>>ensure: > ZnConnectionTimeout(DynamicVariable)>>value:during: > ZnConnectionTimeout class(DynamicVariable class)>>value:during: > ZnClient>>withTimeoutDo: > ZnClient>>executeWithTimeout > [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ > result := self executeWithTimeout ] > [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ] > [ activeProcess psValueAt: index put: anObject. > aBlock value ] in ZnSignalProgress(DynamicVariable)>>value:during: in > Block: [ activeProcess psValueAt: index put: anObject.... > BlockClosure>>ensure: > ZnSignalProgress(DynamicVariable)>>value:during: > ZnSignalProgress class(DynamicVariable class)>>value:during: > ZnClient>>withProgressDo: > ZnClient>>execute > ZnClient>>get > UndefinedObject>>DoIt > > > > -- > Cyril Ferlicot > https://ferlicot.fr >

April 2, 2018

SSL error on windows 7

by Cyril Ferlicot D.

Hi! I have some trouble with SSL in Pharo 7. If I execute this code: ZnClient new url: 'https://google.com'; get. I get a result. If I execute this code: ZnClient new url: 'https://github.com'; get. I get this error: Error: SSL Exception: connect failed [code:-5] I tried with both stable and latest vm. This is very troublesome because I cannot load some projects on this computer :( I am on windows 7. Here are the details and the stack: Image ----- E:\Pharo\images\Pharo 7.0 (development version)-22\Pharo 7.0 (development version)-22.image Pharo7.0alpha Build information: Pharo-7.0+alpha.build.749.sha.039a4b6f0d61ba99778349c4cff2c4e8d5ff9227 (32 Bit) Unnamed Virtual Machine --------------- C:\Users\JeCisC\Documents\Pharo\vms\70-x86\Pharo.exe CoInterpreter VMMaker.oscog-eem.2359 uuid: b3273e3e-dd9d-4819-a928-7034e1cf412c Mar 16 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2359 uuid: b3273e3e-dd9d-4819-a928-7034e1cf412c Mar 16 2018 VM: 201803161038 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Fri Mar 16 11:38:09 2018 +0100 $ Plugins: 201803161038 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Win32 built on Mar 16 2018 11:02:19 GMT Compiler: 6.4.0 VMMaker versionString VM: 201803161038 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Fri Mar 16 11:38:09 2018 +0100 $ Plugins: 201803161038 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ CoInterpreter VMMaker.oscog-eem.2359 uuid: b3273e3e-dd9d-4819-a928-7034e1cf412c Mar 16 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2359 uuid: b3273e3e-dd9d-4819-a928-7034e1cf412c Mar 16 2018 Operating System/Hardware ------------------------- Win32 6.1 IX86 Operating System Details ------------------------ Operating System: Windows 7 Professional N (Build 7601 Service Pack 1) SP major version: 1 SP minor version: 0 Suite mask: 100 Product type: 1 ============================================================== ZdcSecureSocketStream(Object)>>error: ZdcSecureSocketStream>>sslException:code: ZdcSecureSocketStream>>connect ZnClient>>setupTLSTo: ZnClient>>newConnectionTo: ZnClient>>getConnectionAndExecute ZnClient>>executeWithRedirectsRemaining: [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... BlockClosure>>on:do: ZnClient>>executeWithRetriesRemaining: [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self executeWithRetriesRemaining: self numberOfRetries ] on: Error do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... BlockClosure>>on:do: [ [ self executeWithRetriesRemaining: self numberOfRetries ] on: Error do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ self executeWithRetriesRemaining: self numberO...etc... [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ] [ activeProcess psValueAt: index put: anObject. aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... BlockClosure>>ensure: ZnConnectionTimeout(DynamicVariable)>>value:during: ZnConnectionTimeout class(DynamicVariable class)>>value:during: ZnClient>>withTimeoutDo: ZnClient>>executeWithTimeout [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ result := self executeWithTimeout ] [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ] [ activeProcess psValueAt: index put: anObject. aBlock value ] in ZnSignalProgress(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... BlockClosure>>ensure: ZnSignalProgress(DynamicVariable)>>value:during: ZnSignalProgress class(DynamicVariable class)>>value:during: ZnClient>>withProgressDo: ZnClient>>execute ZnClient>>get UndefinedObject>>DoIt -- Cyril Ferlicot https://ferlicot.fr

April 2, 2018

[Pharo7] halt inside and outside tests

by Marcus Denker

Hi, As we can not very easily decide if we are inside a test execution or not there was the idea to have special #halt messages https://pharo.fogbugz.com/f/cases/20151/new-halt-messages <https://pharo.fogbugz.com/f/cases/20151/new-halt-messages> This PR implements them: https://github.com/pharo-project/pharo/pull/1177 <https://github.com/pharo-project/pharo/pull/1177> There is now #haltIfInsideTest and #haltfOutsideTest. In addition, the PR adds a helper method to make checking if the current execution environment is a test run a bit easier: "CurrentExecutionEnvironment value isTestâ. Marcus

April 2, 2018

[Pharo 7.0-dev] Build #749: 21669-Style-deprecated-classes-in-source-code

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #749 was: SUCCESS. The Pull Request #1170 was integrated: "21669-Style-deprecated-classes-in-source-code" Pull request url: https://github.com/pharo-project/pharo/pull/1170 Issue Url: https://pharo.fogbugz.com/f/cases/21669 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 2, 2018

Regroup pharo ARMv6 builds (was: 324996: Add a main build stage for Squeak and Pharo)

by Alistair Grant

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 <noreply(a)github.com> wrote: > > Branch: refs/heads/compile_sista_with_clang > Home: https://github.com/OpenSmalltalk/opensmalltalk-vm > Commit: 3249967cf0ab72b59bce184afd19774d3e1e6957 > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3249967cf0ab72b59b… > Author: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > 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/1b0f7d285f589937e9… > Author: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > 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/b7b3943dfb38dd44bd… > Author: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > 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...b7…

April 2, 2018

Re: [Pharo-dev] AnnouncementSubscription and Ephemerons

by Esteban A. Maringolo

Thank you for the detailed info Stef. Regards! Esteban A. Maringolo 2018-04-01 16:16 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > My last email on VM topics... > > Hi esteban > > Just for the record, our team spent a lot of engineering time and > money on Pharo. > May be I forgot some people. Often we bent research projects to > squeese in Pharo activities. > > - Pavel 1 year paid for bootstrap and general improvements > - Denis 2 years paid for TelePharo (for research projects) > - Igor 4 years paid for athens, SDL, VM Build, TxText > - Christophe 5 years bootstrap, ci, infras, plauncher, cargo > - Clement two years as young engineer on compiler/VM > - Clement 6 months on Sista > > - Camillo 3 years for his Phd > - Guille 3 years for his Phd > - Pablo 3 years for his Phd > - Mariano 3 years for his Phd > - Clement 3 years for thisPhd > > - Guille two years on various improvements > - Me several years > - Marcus several years > - Damien on side project > - Esteban 4 years by Inria > > - Nicolas Passerini got paid by the consortium 9 months > - Guillermo paid 6 months for database > - you and mariano got paid for side projects for a couple of months > > Right now only Esteban is paid by the consortium because this what the > consortium > can pay! > > If I sum up Inria put a lot of money on the table compared to the > users and people > benefitting from Pharo. But this is like that. > > So I think that the consortium is a positive thing. Some people may > think the contrary. > Now do not expect miracles. A single guy cannot do much. > Retrospectively I think that > I made a mistake pushing to have tools for git. We should have go the > filetree way > and command line and gain 18 months of work. But I cannot be right all > the time. > > Now if all the companies doing Pharo would put money on the table then > we could have > another full time engineer working to improve the situation. I hope > that this will happen. > > Then about the VM: a VM is a complex piece of engineering. > And in the open-source community people apparently like to put in addition > not good process and extra constraints (super compatibility, different > dialects), not good communication, > So we end up with a not good situation. > > Now I will not read and send any emails about the VM in the future. I > have a set a filter to > automatically trash any emails on the topic. So if you send me an > email and you see now reaction it is normal. > I think that we make no progress and we are even on regression on this part. > > We will talk with the consortium members and asked them what is the priority > and if the VM is one of them, then we will have to take real decisions > to make progress. > Now since we cannot form someone on VM core rapidly we will see what are the > options. But to me what is clear is that the situation cannot continue > to be like that. > We cannot not control our process. > > Stef > > > On Sun, Apr 1, 2018 at 6:02 PM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: >> Stef, >> >> I encourage you to disclose as much details as possible. >> >> For "bystanders" as myself, it is, a Pharo _user_ that always thinks >> of Pharo as the first option but >> doesn't contribute to the core of it, all this discussions only add >> noise and concerns about the >> stability of the whole Pharo ecosystem. >> >> I've always had the impression that Pharo is heavily dependent on >> INRIA's/government institutions, >> which in the end depend on political decisions instead of >> "market/profit" objectives. >> With the support of members of the Consortium I thought this had changed, but >> reading your statements it seems it is not enough. >> >> It is known you don't have the best temper, but it is also known you >> strive to get the best for Pharo, >> so if you're also aware of that you can avoid restraining yourself, >> and say what you have >> in mind trying to not make personal accusations. >> >> I'd prefer a brutal and noisy truth instead of false quiet calm. >> >> I hope this helps. >> >> Regards, >> >> Esteban A. Maringolo >> >> >> 2018-04-01 10:16 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> I will not reply publicly to this email because I think that it will get worse. >>> So I will not talk publicly about anything related to the Pharo VM in >>> the Pharo mailing-list and any other lists. >>> I will put a filter and trash emails automatically. Like that I will >>> get touched anymore by what I see. >>> >>> You may think that I'm wrong. I'm probably. >>> >>> Now just to make clear: I funded all the PhD of Clement, and all the >>> work of Igor around the VM. >>> And many other engineers and PhD (C. Bruni, Sophie, ...) >>> I'm fighting to make the Pharo consortium working so that we can pay >>> people like Esteban >>> (Esteban is not working in Pharo just because he cannot find a job >>> outside our little community and this >>> is the case for many other people) and other people. >>> >>> Stef >>> >>> On Sun, Apr 1, 2018 at 2:33 PM, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> >>>> 2018-04-01 11:36 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>>> >>>>> Hi Torsten >>>>> >>>>> Thanks for this question. >>>>> >>>>> Ephemerons do not work in Pharo sadly and we know it. We cannot then >>>>> take advantage of them. >>>>> What you see is in fact a degradation of the situation around the VM. :( >>>>> We are concerned about this but the path for our future in this domain >>>>> is unclear. >>>>> >>>> >>>> Hi Stephane, >>>> the future is in your hand. >>>> Put milestones on opensmalltalk-vm, open new entries on opensmalltalk-vm >>>> issue tracker, put engineering force to solve pharo-specific build failures. >>>> In one word, help us to help you. >>>> >>>> So could you please explain what did you do exactly to help ephemerons being >>>> implemented in spur, and what are the forces couter-acting your efforts? >>>> >>>> >>>>> >>>>> What is clear is that we will reduce the number of Plugin (as pablo >>>>> did for freetype) and use FFI. >>>>> But FFI callbacks are not really good. And we need a threaded VM. Now >>>>> nothing happens on this front. >>>>> >>>> >>>> Yes, we all want that! >>>> It's just that it does not happen by magic nor handwaving. >>>> >>>>> >>>>> Let us face it there is a bad energy around. After years of discussion >>>>> our engineers >>>>> are still struggling and slowed down because of the dispersion of plugin >>>>> code. >>>>> In addition, from what I understood there is no development branch :) >>>>> amazing is not it in 2020! >>>>> >>>> How sarcasms are going to federate and encourage people to make progress? >>>> What can you obtain with this sort of sentence but further splitting the >>>> community? >>>> Is it your goal? >>>> >>>>> >>>>> >>>>> On another scale, since 1 year, I was focusing on making that our >>>>> institute offers a permanent position to Clement but I failed >>>>> because the forces against where too strong (politics) and clement >>>>> should reapply next year. >>>>> Now to improve his CV, clement is doing a postdoc at VUB and will >>>>> start working on Truffle (the VM of Oracle) >>>>> and continue to work part time on Sista. >>>>> This is not that bad, like that he will gain experience on other >>>>> systems and in the future >>>>> we will be in the position to see if there are real alternatives for >>>>> us. May be writing a new VM >>>>> on top of other existing infrastructure is the way to go. We will see >>>>> in the future. >>>>> >>>> >>>> Unfortunately, the rules of French institutions certainly do not help you... >>>> Maybe Truffle is a possible future for you, more solid than 100% own fork >>>> for sure. >>>> >>>> >>>>> To be fully transparent >>>>> >>>>> - we will have one phd working on IoT and how to reduce/clean the image >>>>> and >>>>> VM size and many other points she will probably work on a fork because >>>>> I cannot suicide a >>>>> student (by asking her to understand the messy plugin architecture) >>>>> and she will need some space to experiment. >>>>> Now if improvements she will perform take ages to be integrated in the >>>>> main VM I will ask >>>>> her not to do it and to focus on her future and science. >>>>> I imagine that everybody paying attention to people can understand this. >>>>> >>>>> >>>> >>>> Good to know that you are paying attention to people, I had the impression >>>> that this was not allways the case. >>>> I'm willing to help Pharo, I've helped producing Pharo brand 64 bits windows >>>> VM more than one year ago. >>>> I'm struggling to make the community beneficial to all, but I don't feel >>>> like I get a lot of support and wonder if I'm not completely mistaken when I >>>> see all the efforts deployed to tear it apart... >>>> >>>> >>>>> >>>>> Stef >>>>> >>>>> On Tue, Nov 7, 2017 at 9:00 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>> > Hi, >>>>> > >>>>> > by accident I stumbled upon the following code in >>>>> > AnnouncementSubscription: >>>>> > >>>>> > makeWeak >>>>> > action isBlock ifTrue: [ self error: 'Not currently available due to >>>>> > missing ephemerons support']. >>>>> > ... >>>>> > >>>>> > My understanding is that we have Ephemeron support in Pharo now working. >>>>> > Right? >>>>> > >>>>> > Anyone with more insights who knows how to fix/complete this? Should we >>>>> > at least open an issue? >>>>> > >>>>> > Thx >>>>> > T. >>>>> > >>>>> > >>>>> >>>> >>> >> >

April 2, 2018

Re: [Pharo-dev] [Vm-dev] VM git commit hash (was: Image crashing on startup, apparently during GC)

by Alistair Grant

Hi Ben, On 2 April 2018 at 15:42, Ben Coman <btc(a)openinworld.com> wrote: > > > > On 2 April 2018 at 20:26, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> >> On Sun, Apr 01, 2018 at 10:46:14AM -0700, Eliot Miranda wrote: >> > Hi Alistair, >> > >> > _,,,^..^,,,_ (phone) >> > >> > > On Mar 31, 2018, at 1:42 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> > > >> > > git doesn't provide a substitution mechanism like sccs, but the script >> > > we have that embeds the date can just as easily embed the hash. In >> > > .git_filters/RevDateURL.smudge there's a line that retrieves the >> > > commit date from git: >> > > >> > > $date = `git log --format=%ad -1`; >> > > >> > > to get the (short) hash we can simply add: >> > > >> > > $shorthash = `git log --format=%h -1`; >> > > >> > > The string substitution can then proceed as for the date. >> > > >> > > I think it would be worthwhile having both the date and hash in the >> > > --version info. >> > > >> > > I'm happy to add this in and update the --version output if there's >> > > general agreement. >> > >> > Yes please!!! The conventional alternative is to invoke git log from >> > the makefiles and lass in the commit hash as a compiler-line default >> > me. But this is messy and slows down compilation (unless there is a >> > special rule for just one file, and that's fragile). I much prefer >> > having the commit somewhere in source. >> >> Done: >> >> $ git log --oneline | head >> 5a5b1c7 vm version string: add commit short hash >> 4c4686e Skip SUnit testing in Sista builds >> 79c0809 Merge pull request #230 from smalltalking/Cog >> 804ed5c Fixed typo in the download URL >> >> >> $ products/cogspur64linuxht/pharo --version >> 5.0-201804012008-version_hash Sun Apr 1 22:15:07 CEST 2018 gcc 5.4.0 [Production Spur 64-bit VM] >> CoInterpreter VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 1 2018 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 1 2018 >> VM: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm $ >> Date: Sun Apr 1 22:08:11 2018 +0200 $ Hash: 5a5b1c7 $ > > > Maybe rather than just "Hash:" could it be more explicit as "GitHash:" or even "GitSHA1:" > One day the algorithm is likely to change... "Moving Git past SHA-1" (https://lwn.net/Articles/715716/) > and it may be useful later to be able to distinguish. I like "GitHash" as it may not be obvious what the hash refers to for a newcomer. Even if/when git moves away from sha1, from a cli/ui perspective presumably it will still just be "the hash". >> Plugins: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm $ >> Linux 4c0a4b2bdb79 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux >> plugin path: products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash [default: /home/alistair/vmmaker/opensmalltalk-vm/products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash/] >> >> >> As expected, the hash is also included in: >> >> - the VirtualMachine object (in Pharo, and the equivalent in squeak) > > > I presume this is what shows up under System > System Reporter ? Yes. >> - crash.dmp >> - kill -USR1 output >> >> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/233 >> if anyone wants to take a look. > > > > An interesting insight for me into how the version info is generated. thx. Glad it was useful. :-) Thanks for your feedback. I'll update the PR (probably tomorrow). Cheers, Alistair

April 2, 2018

Re: [Pharo-dev] [Vm-dev] VM git commit hash (was: Image crashing on startup, apparently during GC)

by Ben Coman

On 2 April 2018 at 20:26, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > On Sun, Apr 01, 2018 at 10:46:14AM -0700, Eliot Miranda wrote: > > Hi Alistair, > > > > _,,,^..^,,,_ (phone) > > > > > On Mar 31, 2018, at 1:42 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > > > > > git doesn't provide a substitution mechanism like sccs, but the script > > > we have that embeds the date can just as easily embed the hash. In > > > .git_filters/RevDateURL.smudge there's a line that retrieves the > > > commit date from git: > > > > > > $date = `git log --format=%ad -1`; > > > > > > to get the (short) hash we can simply add: > > > > > > $shorthash = `git log --format=%h -1`; > > > > > > The string substitution can then proceed as for the date. > > > > > > I think it would be worthwhile having both the date and hash in the > > > --version info. > > > > > > I'm happy to add this in and update the --version output if there's > > > general agreement. > > > > Yes please!!! The conventional alternative is to invoke git log from > > the makefiles and lass in the commit hash as a compiler-line default > > me. But this is messy and slows down compilation (unless there is a > > special rule for just one file, and that's fragile). I much prefer > > having the commit somewhere in source. > > Done: > > $ git log --oneline | head > 5a5b1c7 vm version string: add commit short hash > 4c4686e Skip SUnit testing in Sista builds > 79c0809 Merge pull request #230 from smalltalking/Cog > 804ed5c Fixed typo in the download URL > > > $ products/cogspur64linuxht/pharo --version > 5.0-201804012008-version_hash Sun Apr 1 22:15:07 CEST 2018 gcc 5.4.0 > [Production Spur 64-bit VM] > CoInterpreter VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b > Apr 1 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid: > 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 1 2018 > VM: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm > $ > Date: Sun Apr 1 22:08:11 2018 +0200 $ Hash: 5a5b1c7 $ > Maybe rather than just "Hash:" could it be more explicit as "GitHash:" or even "GitSHA1:" One day the algorithm is likely to change... "Moving Git past SHA-1" ( https://lwn.net/Articles/715716/) and it may be useful later to be able to distinguish. > Plugins: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm > $ > Linux 4c0a4b2bdb79 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 > 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > plugin path: products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash > [default: /home/alistair/vmmaker/opensmalltalk-vm/products/ > cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash/] > > > As expected, the hash is also included in: > > - the VirtualMachine object (in Pharo, and the equivalent in squeak) > I presume this is what shows up under System > System Reporter ? > - crash.dmp > - kill -USR1 output > > > https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/233 > if anyone wants to take a look. > An interesting insight for me into how the version info is generated. thx. cheers -ben

April 2, 2018

VM git commit hash (was: Image crashing on startup, apparently during GC)

by Alistair Grant

On Sun, Apr 01, 2018 at 10:46:14AM -0700, Eliot Miranda wrote: > Hi Alistair, > > _,,,^..^,,,_ (phone) > > > On Mar 31, 2018, at 1:42 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > git doesn't provide a substitution mechanism like sccs, but the script > > we have that embeds the date can just as easily embed the hash. In > > .git_filters/RevDateURL.smudge there's a line that retrieves the > > commit date from git: > > > > $date = `git log --format=%ad -1`; > > > > to get the (short) hash we can simply add: > > > > $shorthash = `git log --format=%h -1`; > > > > The string substitution can then proceed as for the date. > > > > I think it would be worthwhile having both the date and hash in the > > --version info. > > > > I'm happy to add this in and update the --version output if there's > > general agreement. > > Yes please!!! The conventional alternative is to invoke git log from > the makefiles and lass in the commit hash as a compiler-line default > me. But this is messy and slows down compilation (unless there is a > special rule for just one file, and that's fragile). I much prefer > having the commit somewhere in source. Done: $ git log --oneline | head 5a5b1c7 vm version string: add commit short hash 4c4686e Skip SUnit testing in Sista builds 79c0809 Merge pull request #230 from smalltalking/Cog 804ed5c Fixed typo in the download URL $ products/cogspur64linuxht/pharo --version 5.0-201804012008-version_hash Sun Apr 1 22:15:07 CEST 2018 gcc 5.4.0 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 1 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 1 2018 VM: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm $ Date: Sun Apr 1 22:08:11 2018 +0200 $ Hash: 5a5b1c7 $ Plugins: 201804012008-version_hash alistair@4c0a4b2bdb79:vmmaker/opensmalltalk-vm $ Linux 4c0a4b2bdb79 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux plugin path: products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash [default: /home/alistair/vmmaker/opensmalltalk-vm/products/cogspur64linuxht/lib/pharo/5.0-201804012008-version_hash/] As expected, the hash is also included in: - the VirtualMachine object (in Pharo, and the equivalent in squeak) - crash.dmp - kill -USR1 output https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/233 if anyone wants to take a look. > If you do go ahead with this also consider modifying the makefiles to > ensure that updateSCCSVersions has been run at least once before the > bulk of the build is done. I'll think about this separately. updateSCCSVersions is quite slow to execute on Windows in a VM, and I think there are other proposed changes waiting to be reviewed. Cheers, Alistair

April 2, 2018