- Pharo-dev - lists.pharo.org

System Browser class pane strange behaviour

by Ben Coman

I have a talent for breaking things ;) ... Found some strange behaviour here... I open System Browser select package AST-Core select class ASTCache make code pane dirty by typing 11111 in the class definition select class ASTCacheReset click <Discard> button type 11111 --> oh! where did the buttons go? :) Bisecting finds it.... exists in... 50564, 50510, 50440, 50400, 50384, 50380, 50378 similar but located differently... 50300, 50368, 50376, 50377 still there... 50250, 50232, 50228 not in... 50100, 50150, 50200, 50216, 50224, 50226, 50227 So it looks like this was introduced in build 50228... * 16197 update and merge Rubric * 16198 Add users button in message browser * 16201 Remove unsent extension methods in System-Changes http://forum.world.st/pharo-project-pharo-core-56107d-50228-td4842794.html and it was modified by build 50378... * 16751 link invalidation: install cm directly for primitives and optionCompileOnLinkInstallation * 16729 Removing PluggableTextField from FT http://forum.world.st/pharo-project-pharo-core-e8c312-50378-td4854678.html Logged https://pharo.fogbugz.com/default.asp?17520 cheers -ben P.S. thank you to those who made PharoLauncher work seemlessly with pre-spur images

Feb. 3, 2016

Re: [Pharo-dev] Travis CI integration added to OSSubprocess and FFICHeaderExtractor

by Esteban Lorenzano

> On 03 Feb 2016, at 12:54, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Fri, Jan 29, 2016 at 5:00 PM, <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>> wrote: > For building Pharo, Squeak or GemStone projects on travis there is also the SmalltalkCI project: > https://github.com/hpi-swa/smalltalkCI/blob/master/README.md <https://github.com/hpi-swa/smalltalkCI/blob/master/README.md> > > Smalltalk language is supported by travis ;-) > > > Hi Serge, > > Thanks for the link. Yes, I knew that before starting. But at that time I talked with Esteban and he told me it was not yet working correctly with Pharo. In fact, there were some pull request from Esteban pending for integration. So I went with the old, simple, working approach. And it is still not working correctly (even if my pull request was integrated and Fabio continued working on it). > > Whenever it works in Pharo, I would indeed like to give it a try. > > > Sent from my iPhone > > On 29 janv. 2016, at 18:28, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > >> BTW, Esteban Maringolo asked me if the Travis scripts were "sharable". Well, Esteban Lorenzano shared them with me and I improved them a bit for my needs, so of course they are shareable! And all my projects listed as MIT, they are all MIT all the way down. >> >> Cheers, >> >> On Fri, Jan 29, 2016 at 3:36 AM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >> Nice ! >> >> > On 29 Jan 2016, at 01:03, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> > >> > Hi guys, >> > >> > This is just to let you know that with the help of Esteban and between some work together [1] [2] I was able to have Travis CI integrated with OSSubprocess and FFICHeaderExtractor [3] [4] . Both projects are built and tested under Linux and OSX. Note also that one of the projects does a lot of FFI calls to system libs like libc and the other even generates C programs, compiles them and run it. Even the OS dependencies (like installing the compiler) are resolved correctly :) >> > >> > If someone wants to know how it's done, simply check the .travis.yml and the scripts/run-test.sh of each project [5] [6]. >> > >> > [1] https://pharo.fogbugz.com/f/cases/17488 <https://pharo.fogbugz.com/f/cases/17488> >> > [2] https://pharo.fogbugz.com/f/cases/17490 <https://pharo.fogbugz.com/f/cases/17490> >> > [3] https://travis-ci.org/marianopeck/OSSubprocess <https://travis-ci.org/marianopeck/OSSubprocess> >> > [4] https://travis-ci.org/marianopeck/FFICHeaderExtractor <https://travis-ci.org/marianopeck/FFICHeaderExtractor> >> > [5] https://github.com/marianopeck/OSSubprocess <https://github.com/marianopeck/OSSubprocess> >> > [6] https://github.com/marianopeck/FFICHeaderExtractor <https://github.com/marianopeck/FFICHeaderExtractor> >> > >> > >> > Cheers, >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Feb. 3, 2016

Re: [Pharo-dev] Travis CI integration added to OSSubprocess and FFICHeaderExtractor

by Esteban Lorenzano

Hi Holger, As I pointed before, smalltalk-ci it is still not working. Mariano is using an alternative I explained here: http://log.smallworks.eu/web/post/84 In general, smalltalk-ci is an attempt to have a "level playing fieldâ between different smalltalks (for now pharo and squeak, in close future gemstone) and maybe it has sense to use it if you are going to develop compatible packagesâ¦ in âplain pharoâ my approach (who largely borrows from others) could do a perfectly fine job. > On 03 Feb 2016, at 11:37, Holger Freyther <holger(a)freyther.de> wrote: > > >> On 29 Jan 2016, at 21:00, serge.stinckwich(a)gmail.com wrote: > > Dear Serge, > >> >> For building Pharo, Squeak or GemStone projects on travis there is also the SmalltalkCI project: >> https://github.com/hpi-swa/smalltalkCI/blob/master/README.md >> >> Smalltalk language is supported by travis ;-) > > I tried to use it but I am struggling a bit. I have created a ConfigurationOfMyProject using Versionner and now I try to load it using the smalltalkCI/run.sh script. The issue is that I don't have a Baseline (as Versionner) doesn't create it and the tool tries to load #stable of my project that is contained in git. > > I looked at SCIMetacelloLoadSpec and it doesn't seem to have a 'version' instance variable. Do you know what I am missing? Do I have to create a BaselineOf by hand? > > kind regards > holger > >

Feb. 3, 2016

Re: [Pharo-dev] Travis CI integration added to OSSubprocess and FFICHeaderExtractor

by Mariano Martinez Peck

On Fri, Jan 29, 2016 at 5:00 PM, <serge.stinckwich(a)gmail.com> wrote: > For building Pharo, Squeak or GemStone projects on travis there is also > the SmalltalkCI project: > https://github.com/hpi-swa/smalltalkCI/blob/master/README.md > > Smalltalk language is supported by travis ;-) > > Hi Serge, Thanks for the link. Yes, I knew that before starting. But at that time I talked with Esteban and he told me it was not yet working correctly with Pharo. In fact, there were some pull request from Esteban pending for integration. So I went with the old, simple, working approach. Whenever it works in Pharo, I would indeed like to give it a try. > Sent from my iPhone > > On 29 janv. 2016, at 18:28, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > BTW, Esteban Maringolo asked me if the Travis scripts were "sharable". > Well, Esteban Lorenzano shared them with me and I improved them a bit for > my needs, so of course they are shareable! And all my projects listed as > MIT, they are all MIT all the way down. > > Cheers, > > On Fri, Jan 29, 2016 at 3:36 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Nice ! >> >> > On 29 Jan 2016, at 01:03, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> > >> > Hi guys, >> > >> > This is just to let you know that with the help of Esteban and between >> some work together [1] [2] I was able to have Travis CI integrated with >> OSSubprocess and FFICHeaderExtractor [3] [4] . Both projects are built and >> tested under Linux and OSX. Note also that one of the projects does a lot >> of FFI calls to system libs like libc and the other even generates C >> programs, compiles them and run it. Even the OS dependencies (like >> installing the compiler) are resolved correctly :) >> > >> > If someone wants to know how it's done, simply check the .travis.yml >> and the scripts/run-test.sh of each project [5] [6]. >> > >> > [1] https://pharo.fogbugz.com/f/cases/17488 >> > [2] https://pharo.fogbugz.com/f/cases/17490 >> > [3] https://travis-ci.org/marianopeck/OSSubprocess >> > [4] https://travis-ci.org/marianopeck/FFICHeaderExtractor >> > [5] https://github.com/marianopeck/OSSubprocess >> > [6] https://github.com/marianopeck/FFICHeaderExtractor >> > >> > >> > Cheers, >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Feb. 3, 2016

Re: [Pharo-dev] Travis CI integration added to OSSubprocess and FFICHeaderExtractor

by Frank Shearar

On 3 February 2016 at 10:37, Holger Freyther <holger(a)freyther.de> wrote: > >> On 29 Jan 2016, at 21:00, serge.stinckwich(a)gmail.com wrote: > > Dear Serge, > >> >> For building Pharo, Squeak or GemStone projects on travis there is also the SmalltalkCI project: >> https://github.com/hpi-swa/smalltalkCI/blob/master/README.md >> >> Smalltalk language is supported by travis ;-) > > I tried to use it but I am struggling a bit. I have created a ConfigurationOfMyProject using Versionner and now I try to load it using the smalltalkCI/run.sh script. The issue is that I don't have a Baseline (as Versionner) doesn't create it and the tool tries to load #stable of my project that is contained in git. > > I looked at SCIMetacelloLoadSpec and it doesn't seem to have a 'version' instance variable. Do you know what I am missing? Do I have to create a BaselineOf by hand? This bug report might help?: https://github.com/hpi-swa/smalltalkCI/issues/24 frank > kind regards > holger

Feb. 3, 2016

Re: [Pharo-dev] Travis CI integration added to OSSubprocess and FFICHeaderExtractor

by Serge Stinckwich

Dear Holger, you have to talk with, Fabio Niephaus, the lead dev of SmalltalkCI. Regards On Wed, Feb 3, 2016 at 11:37 AM, Holger Freyther <holger(a)freyther.de> wrote: > >> On 29 Jan 2016, at 21:00, serge.stinckwich(a)gmail.com wrote: > > Dear Serge, > >> >> For building Pharo, Squeak or GemStone projects on travis there is also the SmalltalkCI project: >> https://github.com/hpi-swa/smalltalkCI/blob/master/README.md >> >> Smalltalk language is supported by travis ;-) > > I tried to use it but I am struggling a bit. I have created a ConfigurationOfMyProject using Versionner and now I try to load it using the smalltalkCI/run.sh script. The issue is that I don't have a Baseline (as Versionner) doesn't create it and the tool tries to load #stable of my project that is contained in git. > > I looked at SCIMetacelloLoadSpec and it doesn't seem to have a 'version' instance variable. Do you know what I am missing? Do I have to create a BaselineOf by hand? > > kind regards > holger > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Feb. 3, 2016

Re: [Pharo-dev] Travis CI integration added to OSSubprocess and FFICHeaderExtractor

by Holger Freyther

> On 29 Jan 2016, at 21:00, serge.stinckwich(a)gmail.com wrote: Dear Serge, > > For building Pharo, Squeak or GemStone projects on travis there is also the SmalltalkCI project: > https://github.com/hpi-swa/smalltalkCI/blob/master/README.md > > Smalltalk language is supported by travis ;-) I tried to use it but I am struggling a bit. I have created a ConfigurationOfMyProject using Versionner and now I try to load it using the smalltalkCI/run.sh script. The issue is that I don't have a Baseline (as Versionner) doesn't create it and the tool tries to load #stable of my project that is contained in git. I looked at SCIMetacelloLoadSpec and it doesn't seem to have a 'version' instance variable. Do you know what I am missing? Do I have to create a BaselineOf by hand? kind regards holger

Feb. 3, 2016

Re: [Pharo-dev] Contributing to Pharo

by Sven Van Caekenberghe

Thanks Thierry for pushing this subject and working so patiently with the community. > On 03 Feb 2016, at 10:18, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > I went through all the different possible file formats, class-based, package-based, method-based, log metadata and the like, and I concluded that: > > - the method based format is as good as any other. Even better since it has a spec (cypress). > - method based format allow for method-history queries on the git/vcs history (as well as class based / package based queries). > - the tree structure on github or bitbucket is quite convenient (and browsable) to the point one could edit a package directly in it (I do when I need to do a quick fix). > - anything that can compress a bit the metadata version is probably good to consider. version files can be huge. > - merge drivers really work and releave us from conflict resolution > - we need a merge tool written in Smalltalk/MC > - MC version numbering is a very bad idea > - MC almost never using properly UUIDs is a very bad behavior > - MC packages history can be considered broken in the general case > - it takes time to define, implement, test and really use a new format and tooling Excellent summary. I also feel that the current structure (basic filetree) is more than OK. You can /almost/ browse through github. I am sure we'll get there with the meta data and tooling. Sven

Feb. 3, 2016

Re: [Pharo-dev] Monkey: "Check seems to be stuck. I will try it again"

by Denis Kudriashov

I increased timeout for two hours 2016-02-03 10:10 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > We added new job to resume hanging status "Monkey is checking". > Maybe we should increase timeout. Now when Monkey checks issue more than 1 > hour we revert it status to "Fix Review Needed" > > 2016-02-03 4:24 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: > >> Hi, >> >> That's Monkey's result in my case ( >> https://pharo.fogbugz.com/f/cases/14605/Integrate-Epicea) I don't see >> other cases with the same result. Don't know where to look up to understand >> it... Any pointer? >> >> Thanks >> Martin >> > >

Feb. 3, 2016

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Hi Ben, Le 03/02/2016 06:00, Ben Coman a Ã©crit :> > I'm curious how the merge driver is implemented. I think it was > mentioned that git calls-back to Pharo to do the processing. Is this > it something like this... > > * How to make Git preserve specific files while merging > https://medium.com/@porteneuve/how-to-make-git-preserve-specific-files-whil… Probably, haven't read it. > * A few of my Git tricks, tips and workflows > section under gitattribute(5) > http://nuclearsquid.com/writings/git-tricks-tips-workflows/ Yes. You use git attributes to trigger the use of a pharo-implemented command line tool which does the merge for git. > Or... rather than the metadata being a specific file (e.g. > 'metadata'), the file could change for each commit (e.g. > 'metadata.nnn') where nnn is the revision number, so each commit > deletes the old metadata file and writes the new metadata file. > Monticello could know to use whichever single 'metadata.*' file > exists. Would that avoid the problem of metadata merge conflict? I've thought of that, and it seems hard to get right (which file goes first? how do you recognize a merge?). You have to remember that packages have hundreds, even thousands of versions so this would mean that number of files. I went through all the different possible file formats, class-based, package-based, method-based, log metadata and the like, and I concluded that: - the method based format is as good as any other. Even better since it has a spec (cypress). - method based format allow for method-history queries on the git/vcs history (as well as class based / package based queries). - the tree structure on github or bitbucket is quite convenient (and browsable) to the point one could edit a package directly in it (I do when I need to do a quick fix). - anything that can compress a bit the metadata version is probably good to consider. version files can be huge. - merge drivers really work and releave us from conflict resolution - we need a merge tool written in Smalltalk/MC - MC version numbering is a very bad idea - MC almost never using properly UUIDs is a very bad behavior - MC packages history can be considered broken in the general case - it takes time to define, implement, test and really use a new format and tooling Thierry

Feb. 3, 2016