- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo6 with Ubuntu and OSSubprocess/threaded heartbeat crashes and problems

by David T. Lewis

Thank you for the follow up on this. This kind of problem can be very difficult to find and debug! Dave On Wed, Mar 07, 2018 at 04:30:33PM +0100, Sabine Manaa wrote: > Now I know the reason for the crashes. I did a lot of log writing when > creating my reports (they use OSSubprocess). > This was only for debugging. Removing them removed the problem. OSProcess > and OSSubprocess are not guilty :-) > > I can crash the image with this (try several times) > (in /opt/local/bin/convert there is imagemagick): > > > 1000 timesRepeat: [ > | theFileName theStream thePath theFullPathAndFilename isFileNew | > OSSUnixSubprocess new > shellCommand: '/opt/local/bin/convert -background white -alpha remove > -density 200 > /Library/WebServer/Documents/reports/201801231322-419088218-250457/20170227_19_messdefuerhunde_Fahrten.pdf > /Library/WebServer/Documents/reports/201801231322-419088218-250457/20170227_19_messdefuerhunde_Fahrten_%02d.png'; > redirectStdout; > run. > thePath := '/data/db/' asFileReference. > thePath exists > ifFalse: [ thePath createDirectory ]. > theFileName := 'HALLO_' , Date today yyyymmdd , '.txt'. > theFullPathAndFilename := ('/data/db/' , theFileName) asFileReference . > theFullPathAndFilename asFileReference exists > ifTrue: [ isFileNew := false. > theStream := MultiByteFileStream oldFileNamed: theFullPathAndFilename. > theStream position: theStream size. > theStream crlf ] > ifFalse: [ isFileNew := true. > theStream := MultiByteFileStream newFileNamed: theFullPathAndFilename ]. > [ isFileNew > ifTrue: [ theStream > nextPutAll: Time now printString; > nextPutAll: Time now printString; > nextPutAll: Time now printString; > nextPutAll: Time now printString; > nextPutAll: Time now printString; > nextPutAll: Time now printString; > nextPutAll: Time now printString; > crlf ]. > theStream nextPutAll:'' ] > ensure: [ theStream close ]. > ]. > > > 2018-03-07 2:16 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: > > > On Tue, Mar 06, 2018 at 11:49:14AM +0100, Sabine Manaa wrote: > > > Hi, > > > > > > I can report the following: > > > > > > The problem with the Buffer overflow remains also with OSProcess. > > > Also with the normal vm (https://get.pharo.org ). > > > > > > Summary: I have buffer overflow crashes with my application on Linux. > > > The same code runs without problems on MacOS and on Windows. > > > I have the same test data/database and do exactly the same. > > > > > > The problem occurs only after calling several times > > OSProcess/OSSubprocess. > > > This is the reason why I first had a suspicion that OSSubprocess is > > > responsible for the crashes. > > > > > > Can anyone tell me how to proceed to find the reason for the buffer > > > overflow? > > > There is no PharoDebug.log > > > > > > Help is very appreciated! > > > > > > This is the message when terminating: > > > > > > root@Pharo_ubuntu_16:/spf/build# ./pharo Pharo-Productive-SPF.image > > > --no-quit > > > > > > SmalltalkImageInstanceID class>>startUp*** buffer overflow detected ***: > > > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo terminated > > > > > > > What is class SmalltalkImageInstanceID? I have a Pharo 6.1 image, and I > > am running on Ubuntu. I loaded OSProcess to check this out, but I am not > > sure what that #startUp message is doing. > > > > Thanks, > > Dave > > > > > >

March 8, 2018

Problems with Epicea on Pharo 7

by Cyril Ferlicot D.

Hi, I have a little problem with Epicea and there is some things I would like to discuss. My problem is that I have a Jenkins job downloading a Pharo 7 image, loading inside a little project via an eval command launching a Metacello script. Then I launch tests. And then I archive the image. When I get this image and try to open it with the --no-default-preferences option, I get a window saying that I lost changes and asking if I want to recover them. The only two commands I launched on Jenkins where: ./pharo Pharo.image eval --save ' Metacello new blabla...' and ./pharo Pharo.image test --junit-xml-output '(bla).*' So here my first problem: I don't see why I would have lost changes. Second problem: I did not include pharo-local/ in the archive. So there is no ombu log next to the image. Even if I had a crash on the Jenkins, I would not expect to get this recovery message since I have no epicea log and cannot recover anything. At most I would just expect an #inform: saying "A crash was detected but cannot be recovered" Third problem: This is the case where I have the --no-default-preferences option. If I don't have this option, the image open, the epicea message open and I can do nothing because my Pharo froze. I cannot close the message. I cannot interrupt (ctrl + .). I can just force close the image and the loading of my settings never ends. If I am right on the problems I'll open bug entries about them. Thank you in advance. -- Cyril Ferlicot https://ferlicot.fr

March 7, 2018

[Pharo 7.0-dev] Build #665: 21511-add-baseTrait-on-the-instance-side-of-the-trait-and-deprecate-it

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

There is a new Pharo build available! The status of the build #665 was: SUCCESS. The Pull Request #1040 was integrated: "21511-add-baseTrait-on-the-instance-side-of-the-trait-and-deprecate-it" Pull request url: https://github.com/pharo-project/pharo/pull/1040 Issue Url: https://pharo.fogbugz.com/f/cases/21511 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 7, 2018

generated webdoc?

by Guillermo Polito

Hi all, I know that we had before the generated webdoc from pharo releases in the file server (files.pharo.org) But I cannot see it anymore. Do we still have it hosted somewhere? We were planning to use it as online material for a course. I know that it is mostly not needed, but newby students need somehow to bootstrap themselves :). Thanks, Guille -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 7, 2018

[Pharo 7.0-dev] Build #664: 21510-The-traits-definition-ignores-the-slots-for-stateful-traits

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

There is a new Pharo build available! The status of the build #664 was: SUCCESS. The Pull Request #1038 was integrated: "21510-The-traits-definition-ignores-the-slots-for-stateful-traits" Pull request url: https://github.com/pharo-project/pharo/pull/1038 Issue Url: https://pharo.fogbugz.com/f/cases/21510 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 7, 2018

Re: [Pharo-dev] Pharo6 with Ubuntu and OSSubprocess/threaded heartbeat crashes and problems

by Sabine Manaa

Now I know the reason for the crashes. I did a lot of log writing when creating my reports (they use OSSubprocess). This was only for debugging. Removing them removed the problem. OSProcess and OSSubprocess are not guilty :-) I can crash the image with this (try several times) (in /opt/local/bin/convert there is imagemagick): 1000 timesRepeat: [ | theFileName theStream thePath theFullPathAndFilename isFileNew | OSSUnixSubprocess new shellCommand: '/opt/local/bin/convert -background white -alpha remove -density 200 /Library/WebServer/Documents/reports/201801231322-419088218-250457/20170227_19_messdefuerhunde_Fahrten.pdf /Library/WebServer/Documents/reports/201801231322-419088218-250457/20170227_19_messdefuerhunde_Fahrten_%02d.png'; redirectStdout; run. thePath := '/data/db/' asFileReference. thePath exists ifFalse: [ thePath createDirectory ]. theFileName := 'HALLO_' , Date today yyyymmdd , '.txt'. theFullPathAndFilename := ('/data/db/' , theFileName) asFileReference . theFullPathAndFilename asFileReference exists ifTrue: [ isFileNew := false. theStream := MultiByteFileStream oldFileNamed: theFullPathAndFilename. theStream position: theStream size. theStream crlf ] ifFalse: [ isFileNew := true. theStream := MultiByteFileStream newFileNamed: theFullPathAndFilename ]. [ isFileNew ifTrue: [ theStream nextPutAll: Time now printString; nextPutAll: Time now printString; nextPutAll: Time now printString; nextPutAll: Time now printString; nextPutAll: Time now printString; nextPutAll: Time now printString; nextPutAll: Time now printString; crlf ]. theStream nextPutAll:'' ] ensure: [ theStream close ]. ]. 2018-03-07 2:16 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: > On Tue, Mar 06, 2018 at 11:49:14AM +0100, Sabine Manaa wrote: > > Hi, > > > > I can report the following: > > > > The problem with the Buffer overflow remains also with OSProcess. > > Also with the normal vm (https://get.pharo.org ). > > > > Summary: I have buffer overflow crashes with my application on Linux. > > The same code runs without problems on MacOS and on Windows. > > I have the same test data/database and do exactly the same. > > > > The problem occurs only after calling several times > OSProcess/OSSubprocess. > > This is the reason why I first had a suspicion that OSSubprocess is > > responsible for the crashes. > > > > Can anyone tell me how to proceed to find the reason for the buffer > > overflow? > > There is no PharoDebug.log > > > > Help is very appreciated! > > > > This is the message when terminating: > > > > root@Pharo_ubuntu_16:/spf/build# ./pharo Pharo-Productive-SPF.image > > --no-quit > > > > SmalltalkImageInstanceID class>>startUp*** buffer overflow detected ***: > > /spf/build/pharo-vm/lib/pharo/5.0-201707201942/pharo terminated > > > > What is class SmalltalkImageInstanceID? I have a Pharo 6.1 image, and I > am running on Ubuntu. I loaded OSProcess to check this out, but I am not > sure what that #startUp message is doing. > > Thanks, > Dave > > >

March 7, 2018

Re: [Pharo-dev] PharoDays?

by Stephane Ducasse

ok I will check if we can get the amphitheater. On Wed, Mar 7, 2018 at 1:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 28 Feb 2018, at 18:09, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi guys >> >> many people are asking when and where there will be PharoDays. >> And we do not know. >> We are looking for local organisers and else we do it at Lille. >> Now what would be a good date? >> >> What about >> 7-8 June? > > yes, is ok for me :) > > Esteban > >> >> Stef >> > >

March 7, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Stephane Ducasse

Thanks dale I will watch and read and sync with guys when I'm back to civilisation :) On Tue, Mar 6, 2018 at 6:35 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > On 03/06/2018 06:21 AM, Guillermo Polito wrote: > > Hi Dale! > > On Mon, Mar 5, 2018 at 8:07 PM, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > >> >> >> On 03/05/2018 09:07 AM, Guillermo Polito wrote: >> >>> On the other side, there is the fact that Metacello baselines are so far >>> nice to describe release project dependencies, but they are not so nice to >>> describe subprojects/development dependencies that may get edited along >>> with the parent project. Kind of what we used to do with #bleedingEdge. I >>> feel this is a complex problem, that not even SBT or maven that are there >>> since years are capable of solving nicely... Tode and Iceberg metacello >>> integration try to solve this problem by "ignoring the dependency and using >>> the loaded repository" but this may not be successful either... >>> >> >> I have not been following this thread in detail, but this comment leads >> me to believe that the issue that you guys are running into has to do with >> trying to ongoing distributed development across multiple projects and >> multiple platform versions ... > > > I don't know exactly the case of Calypso, but I don't think it is being > maintained for other than latest Pharo 7. > > The Calypso case as I understand it is that it has a couple of dependencies > > Calypso > | - commander > | - class annotations > > The three projects are hosted in different repositories, but Denis wants > to work on "bleeding edge" of the three of them at the same time. > Then when he loads calypso in a new image, if he just uses a baseline he > will load specific versions of the dependencies and not the latest ones... > > I think this is the particular use case for locking, isn't it? > > Yes this is exactly the use case for locking. > > > >> >> If so then I think that the moral equivalent of #bleedingEdge should be a >> branch structure along the lines of: >> >> master branch --- the project release that is known to work on all >> supported platform versions. >> dev_pharo6 --- the current #bleedingEdge for Pharo6.0 >> dev_pharo7 --- the current #bleedingEdge for Pharo7.0 >> >> In an image where you want to use the dev_pharo7 for a project, you do a >> Metacello lock on github://xxxx/xxx:dev_pharo7/src BEFORE loading the >> project ... if there are multiple projects that need to all coordinate >> development then you follow the same convention and use a Metacello lock >> for each of the projects ... Executing expressions to lock projects is >> tedious to use and manage. >> > > It is not that complicated I think ^^. > > I have found that "load specifications" are much easier to work with than > "load expressions", similar to the way class definitions are superior to > smalltalk code for creating classes, one can reason about a "load > specification" for example it is possible to merge two load specifications > to produce a single load specification whereas this kind of thing is not > possible if you are given two arbitrary Smalltalk expressions to merge ... > > > >> >> In tODE I started using project entries[1] that are downloaded to disk >> and shared by multiple images that allow a developer to specify what >> branch/tag/commit they are interested in using ... each image that is >> started up in a "cluster" uses the project entry to do a Metacello lock on >> the project "automagically"... if there is a series of projects where the >> developer needs to use dev_pharo6 they can arrange to edit the project >> entry to reflect the proper branches for the set of projects that need >> special _development_ treatment ... these .ston files can be shared amongst >> groups of developers ... of course once the local clones of these projects >> are on the local disk, then it is up to the developer (or a set of scripts) >> to periodically update to the latest development version of each of the >> projects ... > > > YES. This gets closer to what I want. What I don't like from locking is > that I have to: > - know in advance all the projects (+ dependencies) I want to develop > (specially if I'm not the main project developer) > - know where they are stored in the disk > - do an explicit locking on each of them > > Haha, and that is why I created the project entries ("load > specifications") in the first place:) > > > There is a missing abstraction that probably you get in Rowan or tODE with > that project entry specification? > > Yes, tODE project entries are an implementation that I have been using for > several years now and over time I have found some limitations in the tODE > implementation that I am attempting to correct in the Rowan implementation > ... The Rowan spec I originally referenced[1] is actually "load expression" > that is the equivalent of a Gofer load expression ... I have classes for a > Metacello-based "load expression" but I haven't gotten to the point where I > have integrated Metacello into Rowan. > > [1] https://github.com/dalehenrich/Rowan/blob/master/specs/Rowan.ston > > Because the reality is that personally I'm starting a new image every a > couple of days, and having a specification for it would be much easier than > locking here and there... > I want just to specify "My project X at development time requires Y, Z, H > and Z and H are subprojects". > Then, he should realize he should lock Z and H for me. > > Yes this is exactly the problem I was dealing with in the early > implementation of tODE and with project entries. > > You might want to look again at my FAST talk on "Dangerous Liaisons: > Smalltalk, Files, And Git"[2] as I talk about "image clusters" that share a > collection of project entries and the fact that each image needs to be able > to have a private set of "project entries" ... now that you are > experiencing the pain my talk might make more sense:) > > ... also I am thinking in terms of an "image specification" that is made > up of a collection of Rowan "load specifications" ... Rowan has the notion > of a Project Set and it is possible to load a set of projects. So it is not > that big of a stretch to imagine a .ston image specification (collection > load specifications) can be passed around and then customized if needed by > individual developers and then project set can be used to create the image > or images .... > > > [2] https://www.youtube.com/watch?v=Ejmqs0xLvSk > > > Now, If subprojects Z and H are in the same repository as X, that should > not be complicated :). > In Denis' case it could be more complicated... > > Right but once Denis gets his dependent projects cloned to local disk he > can update each of the projects on his schedule by pulling later versions > of the projects as he goes ... I lean to disk-based clones that can be > shared by multiple images (an "image cluster") ... tODE does not have the > notion of image clusters, but I do have sets of images that are sharing a > common set of projects where a number of those projects are on > development-specific branches so Iknow that this concept makes sense ... > > > >> To share a specific configuration of development git repos, you need to >> know that SHA anyway, so the image can produce a collection of project >> entries with the SHA of the commit and those project entries can be >> included in a bug report ... >> >> For Rowan[2], I am using a "load specification"[3], which is a second >> generation project entry .... the Rowan work is still evolving ... >> >> Anyway, I think that putting the control of what is being used for >> development completely in the developers hands and avoiding the need to >> edit baselines is a good thing ... and I think that the idea of having >> specifications that are shared by a cluster of images is a good way to go >> ... >> >> Dale >> >> [1] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seas >> ide32.ston >> [2] https://github.com/dalehenrich/Rowan >> [3] https://github.com/dalehenrich/Rowan/blob/master/specs/Rowan.ston >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > > >

March 7, 2018

Re: [Pharo-dev] Esteban's ChangeLog week of 26 February 2018

by Ben Coman

On 7 March 2018 at 21:30, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 7 Mar 2018, at 14:11, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On 5 March 2018 at 15:00, <estebanlm(a)gmail.com> wrote: > >> Hello! >> >> This is my weekly ChangeLog, from 26 February 2018 to 4 March 2018. >> You can see it in a better format by going here: http://log.smallworks. >> eu/web/search?from=26/2/2018&to=4/3/2018 >> >> ChangeLog >> ========= >> >> 2 March 2018: >> ------------- >> >> * I've been working on Iceberg UI. >> I have first versions of: >> >> * repositories browser >> * individual repository browser >> * individual repository management browser >> * commit window >> * push window >> * pull windows >> >> I'm not woking on fix a couple of problems on refreshing windows and >> defining how the pull will work (by default, >> it will trigger a merge of the changes your are pulling into your >> image). >> >> >> 1 March 2018: >> ------------- >> >> * I made a new backport for 6.1, [case: 21344](https://pharo.fogbugz.c >> om/f/cases/21344) >> >> enjoy >> >> >> 28 February 2018: >> ----------------- >> >> * Well... I spent an stupid amount of time to figure out why the >> latest VM for macOS was not including libgit2. >> >> Turns out, there was a "deploy filter" problem (two problems, in >> fact), that was making that all pharo flavours >> were being uploaded to the file server and with same name so in >> fact, one flavour was being copied on top of the >> other. And "lowcode VM", for example, does not includes libgi2. >> >> So, now that's fixed. You can start using latest VM again (which is >> the one that is signed) ;) >> > > Just to confirm, you mean downloads from here...? > http://files.pharo.org/vm/pharo-spur64/mac > http://files.pharo.org/vm/pharo-spur32/mac > > Should we expect to see a lowcode tagged VM there? > > > no :) > first, I mean VMs from > > files.pharo.org/get-files/70 <http://giles.pharo.org/get-files/70> > thx for the clarification. cheers -ben > > they *point* to same VMs you refer, but the official download place is the > one I said, where there is one stable and one latest. > the place you link is the general repository where people can find an > specific version, but is not the regular place. > > also, no about Lowcode. Lowcode VMs are experimental VMs and at the moment > we do not distribute them as part of Pharo. > If we decide to make them official, we will put them there, but so far > people willing to experiment with them can download from the place were > they are. > > cheers, > Esteban > > ps: Iâm just describing our process. This is not wrote in stone (or STON > ;) ) and it could change if we find there are good reasons to do it. > > > > cheers -ben > > >

March 7, 2018

Re: [Pharo-dev] [ANN] 64 bits support preview

by Ben Coman

Side question. What is the status of Windows support for OSSubProcess ? cheers -ben On 6 March 2018 at 11:19, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys, > > Thanks for Guillermo Polito we now have 64 bits support for OSSubprocess. > You can see the required changes in this PR [1]. I made a branch called > `support64bits` so that you can help us test it even if CI said it was good > [2]. If you do test it and come back to us with the results, please tell us > which OS you used. > > To install from the branch: > > Metacello new > configuration: 'OSSubprocess'; > repository: 'github://marianopeck/OSSubprocess:support64bits/ > repository'; > version: #stable; > load. > > > Roadmap: Current release is v0.2.5. So I will let that release for Pharo > <= 5.0. I will make a new release with the Pharo 64 bits and call it v0.3. > That release should be used for Pharo 6.x. Once v0.3 is out, I will make a > new release v0.4 with some changes I wanted to do since a loooong time and > its a small refactor to minimize OSSubprocess dependency on OSProcesses > primitives (at VM side). This is thanks to Holger Freyther and Alistair > Grant [3]. As that requires a new VM, then v0.4 should be used in Pharo >= > 7.0. > > Cheers, > > > [1] https://github.com/marianopeck/OSSubprocess/pull/30 > [2] https://travis-ci.org/guillep/OSSubprocess/builds/349280174 > [3] https://github.com/pharo-project/pharo-vm/pull/142 > > -- > Mariano > http://marianopeck.wordpress.com >

March 7, 2018