August 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] libpng fails to download

by Alistair Grant

Hi Nicolas, On Sat, Aug 26, 2017 at 10:10:02PM +0200, Nicolas Cellier wrote: > Yes, that's a problem. > Some projetcs have a strict policy and remove old versions (for example because > they have vulnerabilities). > So we have to regularly update our upstream links. > But we have caches on Travis/Appveyor because reconstructing those external > dependencies is very costly > (see the cache directive near line 7 of https://github.com/OpenSmalltalk/ > opensmalltalk-vm/blob/Cog/.travis.yml). > Consequently, a green build on the CI server might well be red anywhere else... > > Nicolas Thanks for the clarification, I guessed that something like this might be happening. I've opened issue #20341: https://pharo.fogbugz.com/f/cases/20341/ Pull request to follow... Cheers, Alistair > 2017-08-26 20:51 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > > Hi Stef, > > On Sat, Aug 26, 2017 at 07:59:09PM +0200, Stephane Ducasse wrote: > > Indeed. > > Tx alistair. > > This is a little terse for me to be sure of your meaning, but I'll take > it to mean I should submit the patch. :-) > > BTW: I tested libpng-1.6.30 on the full test suite, and the set of > failing tests was the same. > > > Cheers, > Alistair > > > > > On Fri, Aug 25, 2017 at 10:04 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > > Hi All, Esteban, > > > > > > I just attempted to build the pharo vm on Win32 and it failed due to: > > > > > > ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/ > libpng-1.6.29.tar.gz > > > > > > not being available. The current version is 1.6.30, which also appears > > > to be unavailable from this address. > > > > > > I successfully downloaded 1.6.29 from: > > > > > > http://prdownloads.sourceforge.net/libpng/libpng-1.6.29.tar.gz?download > > > > > > which is referenced on what appears to be the official web page: > > > > > > http://www.libpng.org/pub/png/libpng.html > > > > > > I plan to test with 1.6.30 tonight. > > > > > > Is there any reason not to submit a PR pointing to sourceforge? > > > > > > Thanks, > > > Alistair > > >

Aug. 26, 2017

Re: [Pharo-dev] libpng fails to download

by Nicolas Cellier

Yes, that's a problem. Some projetcs have a strict policy and remove old versions (for example because they have vulnerabilities). So we have to regularly update our upstream links. But we have caches on Travis/Appveyor because reconstructing those external dependencies is very costly (see the cache directive near line 7 of https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.travis.yml) Consequently, a green build on the CI server might well be red anywhere else... Nicolas 2017-08-26 20:51 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi Stef, > > On Sat, Aug 26, 2017 at 07:59:09PM +0200, Stephane Ducasse wrote: > > Indeed. > > Tx alistair. > > This is a little terse for me to be sure of your meaning, but I'll take > it to mean I should submit the patch. :-) > > BTW: I tested libpng-1.6.30 on the full test suite, and the set of > failing tests was the same. > > > Cheers, > Alistair > > > > > On Fri, Aug 25, 2017 at 10:04 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > > Hi All, Esteban, > > > > > > I just attempted to build the pharo vm on Win32 and it failed due to: > > > > > > ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/ > libpng-1.6.29.tar.gz > > > > > > not being available. The current version is 1.6.30, which also appears > > > to be unavailable from this address. > > > > > > I successfully downloaded 1.6.29 from: > > > > > > http://prdownloads.sourceforge.net/libpng/libpng- > 1.6.29.tar.gz?download > > > > > > which is referenced on what appears to be the official web page: > > > > > > http://www.libpng.org/pub/png/libpng.html > > > > > > I plan to test with 1.6.30 tonight. > > > > > > Is there any reason not to submit a PR pointing to sourceforge? > > > > > > Thanks, > > > Alistair > >

Aug. 26, 2017

Re: [Pharo-dev] [Vm-dev] usage of Pharo-vm repository [was Latest Debian, Ubuntu and CentOS packages of the pharo-vm]

by Nicolas Cellier

2017-08-23 17:14 GMT+02:00 Holger Freyther <holger(a)freyther.de>: > > > > On 18. Aug 2017, at 23:56, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > Hi! > > Hi Holger, > > Are the packaging stuff in opensmalltalk too, or just in pharo-vm? > > It would be great to move all to opensmalltalk. > > What is specificity of pharo-vm repository now? > > the packaging bits are in the pharo-vm repository only. What is pharo > specific from a technical point of view is that I re-generate the sources > before building the source package. There is a Makefile[1] that drives > building the source package and the actual compilation is here[2]. > > Ah yes, there have been some propositions to perform this task in a specific development branch in opensmalltalk, but so far nothing has happened... As Eliot explained once, we currently have no guaranty to regenerate identical sources (mostly we observe signed/unsigned type swapping). Probably type inference depends on the order of MethodDictionary scanning which is random. Of course it should be fixed, but someone has to do it.... Untill then, generated sources have to be versionned, there is no alternative way, otherwise we don't have reproducible artefacts... A specific build could suddenly start crashing without any easy way to reproduce and debug, think of it twice before regenerating sources... Porting VM to another OS without having to regenerate still is another valuable feature. I also find the ability to track generated-source diffs valuable: it's a complementary check, especially when changing code-generation part. That's why we continue to version generated source, whatever the ready-made thinking. Once the code generation is stable, it can be done by a bot. But don't forget that not all VMMaker commit will produce interesting C sources, because a great deal of development happens in VM-Simulator, not in C - at least the major features that Eliot and Clement are after. > I don't want this to sound offensive but the non-technical part is that it > seems easier to get changes into the PharoVM than into opensmalltalk-vm. > One example could be the FilePlugin and my attempt to use inotify without > periodic polling (wastes power, adds latency and increases your bill in > cloud computing, etc). > > Backporting upstream changes between squeak/newspeak vm and pharo vm was not sustainable, and mostly one way (unfair). That's also what motivated the switch to opensmalltalk: it's dialect neutral. Of course, changes in opensmalltalk must be done with retro and cross compatibility constraints which may require a little more effort, but at worse we have dialect-specific #ifdef directives. Remember that VM stability is valued not only because there are grumpy old and conservative fellows here ;) Without VM stability, how could we have a smooth and sustainable overall development process? That said, I hate nothing much than stale pull request and it's clearly the next obstacle to contributions (in case vm contributions was easy enough). If that's the case, that's regrettable. So don't hesitate to complain here. It doesn't mean that every PR has to be accepted. Ideally, they should be closed in a reasonnable time, with comments telling why or what needs to be improved for inclusion... IMO in absence of dedicated paid staff, we should start closing old PR (exactly as Pharo is closing stale fogbugz entries). it's not satisfying, but letting a long list of open PR is worse. Non-technically speaking, Esteban is among the core developpers of opensmalltalk, so it should be as easy to integrate changes as in a pharo-vm copy, modulo cross and retro compatibility concerns. We are supposed to have non regression tests to lower the level of heroism of the poor human integrators that we all are. > I am happy to answer questions about the packaging process or the > OBS/travis-ci integration! > > holger > > Thanks! I hope someone will jump at the opportunity :) > > [1] https://github.com/pharo-project/pharo-vm/blob/master/Makefile.debian > [2] https://github.com/pharo-project/pharo-vm/blob/master/ > packaging/pharo6-vm-core/debian/rules

Aug. 26, 2017

Re: [Pharo-dev] pillars runs into an infinite loop on a simple typo

by Peter UhnÃ¡k

While we are at it, Pillar cannot parse strikethrough if it is on the start of the line On Sat, Aug 26, 2017 at 7:05 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > No pillar is line based and the beginning of the line is key. > > On Sat, Aug 26, 2017 at 5:56 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Apparently this is enough to run into an infinite loop somewhere. > > > > text := '- one > > - # cry'. > > doc := PRPillarParser parse: text. > > > > > > Also question regarding pillar syntax, is not possible to indent it in > the > > syntax? > > > > e.g. > > > > - one > > -# one.one > > - two > > -# two.one > > -# two.two > > > > Flattening it makes an _indented_ list hard to read (and defeats the > point > > why we indent things in the first place...) > > > > Peter > >

Aug. 26, 2017

Re: [Pharo-dev] libpng fails to download

by Alistair Grant

Hi Stef, On Sat, Aug 26, 2017 at 07:59:09PM +0200, Stephane Ducasse wrote: > Indeed. > Tx alistair. This is a little terse for me to be sure of your meaning, but I'll take it to mean I should submit the patch. :-) BTW: I tested libpng-1.6.30 on the full test suite, and the set of failing tests was the same. Cheers, Alistair > On Fri, Aug 25, 2017 at 10:04 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi All, Esteban, > > > > I just attempted to build the pharo vm on Win32 and it failed due to: > > > > ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/libpng-1.6.29.tar.gz > > > > not being available. The current version is 1.6.30, which also appears > > to be unavailable from this address. > > > > I successfully downloaded 1.6.29 from: > > > > http://prdownloads.sourceforge.net/libpng/libpng-1.6.29.tar.gz?download > > > > which is referenced on what appears to be the official web page: > > > > http://www.libpng.org/pub/png/libpng.html > > > > I plan to test with 1.6.30 tonight. > > > > Is there any reason not to submit a PR pointing to sourceforge? > > > > Thanks, > > Alistair

Aug. 26, 2017

Re: [Pharo-dev] [Ann][Pillar] Travis -> Bintray for PDFs

by Damien Pollet

On 25 August 2017 at 22:31, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > A problem I anticipate is that since we only keep the latest build, > > how did you manage that? :-o > > When I was using bintray we had trouble that we could only store every > commit; so I guess I am interested to see what your process is. :-) > Simply uploading to always the same files to the same "latest" version, with the overwrite flag set. This overwrite feature is not provided by the Travis deployer for Github releases, which is what I would prefer to use (it should be possible through their REST API to detect/delete outdated releases and then deploy the new files). -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 26, 2017

Re: [Pharo-dev] libpng fails to download

by Stephane Ducasse

Indeed. Tx alistair. On Fri, Aug 25, 2017 at 10:04 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi All, Esteban, > > I just attempted to build the pharo vm on Win32 and it failed due to: > > ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/libpng-1.6.29.tar.gz > > not being available. The current version is 1.6.30, which also appears > to be unavailable from this address. > > I successfully downloaded 1.6.29 from: > > http://prdownloads.sourceforge.net/libpng/libpng-1.6.29.tar.gz?download > > which is referenced on what appears to be the official web page: > > http://www.libpng.org/pub/png/libpng.html > > I plan to test with 1.6.30 tonight. > > Is there any reason not to submit a PR pointing to sourceforge? > > Thanks, > Alistair > >

Aug. 26, 2017

Re: [Pharo-dev] new chapter on double dispatch for new book :)

by Stephane Ducasse

Hi I took into account most of the remarks and the chapter improved significantly. Here is the new version. Now back to the lecture slides. Stef On Wed, Aug 23, 2017 at 10:13 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Fixed it > Tx > > On Wed, Aug 23, 2017 at 1:37 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> Ah, it is singular and plural form of word :) >> I was just confusing that DieHandleTest uses DiceHandle class. Maybe this >> should be fixed >> >> 2017-08-23 13:33 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>> I found little mistake: >>> >>> In a previous chapter you implemented a small DSL to add dice and manage >>> dieHandle. >>> >>> >>> It should be dice I guess. >>> >>> 2017-08-23 12:53 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>> >>>> feedback is welcome >>>> Good reading >>> >>> >>

Aug. 26, 2017

Re: [Pharo-dev] [Pharo6] [Issue Tracker] Help Needed: issues tagged Pharo6

by Stephane Ducasse

Oh yes :) Esteban is fully aware of that because you cannot imagine the amount of energy we are losing. On Fri, Aug 25, 2017 at 3:47 PM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Less crassly, what I meant to say, was; it'd be really nice if the > integration process was fixed before too much energy is spent trying to > backport/solve reported issues. > > Cheers, > Henry > > > > -- > View this message in context: http://forum.world.st/Pharo6-Issue-Tracker-Help-Needed-issues-tagged-Pharo6… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 26, 2017

Re: [Pharo-dev] [Ann][Pillar] Travis -> Bintray for PDFs

by Stephane Ducasse

We are in the process to rewrote all the makefile to push as much as logic to Pharo - to avoid to have to duplicate between pillar.conf and makefile - to make sure that slowly we can get rid of make Luc did a successful makefile generator from pillar.conf and I should check what he did. For now I have migrated most of the booklets and books (I have problem with the tinyBlogTutorial but it fails when I clone it) to work with a first version of the makefile using pillar itself to extract information from the pillar.conf. Tuesday we will - adapt the makefile to make them better (the problem is to install pillar first then run the make so you cannot use make to down pillar as damien proposed in June makefile. - check what luc did and see how we can use that. But I wanted to have a milestone in the middle of our migration. On Fri, Aug 25, 2017 at 7:14 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > This is great Stef ! > I'm waiting for the documentation to update all my projects with the new > process. > > > On Fri, Aug 25, 2017 at 4:42 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Hi >> >> with Damien Pollet, we went over all the booklets and some of the >> Pharo books currently written in Pillar and made sure that each time >> you commit >> >> - a travis job is run >> - latex is produced as well as pdf >> - the pdf is stored on bintray >> - the release versions are stored on the github repo (I should verify) >> >> So now you can just do a PR and you get a super nice PDF. >> >> Have a look at Glorp or Voyage for example >> >> - https://github.com/SquareBracketAssociates/Booklet-Glorp >> - https://github.com/SquareBracketAssociates/Booklet-Voyage >> >> You can access the bintray files from the squarebracketassociates >> lovely binTray account :) >> >> >> https://bintray.com/squarebracketassociates/wip/download_file?file_path=voy… >> >> >> I'm writing a doc of the process so that other people can do it for >> their private projects. >> >> >> Stef >> > > > > -- > Serge Stinckwich > UCN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/

Aug. 26, 2017