July 2015 - Pharo-dev - lists.pharo.org

https://readthedocs.org/

by phil＠highoctane.be

How would we integrated pillar html output in here? https://readthedocs.org/

July 8, 2015

Re: [Pharo-dev] Moldable Pharo

by Alexandre Bergel

Indeed! Hey! The Glamorous team! This is a call :-) Alexandre > On Jul 8, 2015, at 1:28 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > with GT Inspector/Spotter we now have more moldable tools and Pharo becomes again a more flexible Tool and IDE. > The settings framework also allows to use the settings browser for own purposes and in own applications > - which is nice. One can even have a custom world menu in Pharo for the own app (see [1]) > > Reminds me on Eclipse (RCP, ...) where one can extend the IDE at specific extension > points to provide own custom tools and even build applications that are not IDE's. > > What about a moldable browser? For instance it would be nice if I could extend > the browser with own panes as replacement for the regular code pane. > > So for instance a method that returns an XML string could be shown as > a clickable tree instead of the code pane, ... > > foo > <xml> > ^'<someXML></someXML> > > With a flexible code editor like Rubric/TxText and Petit infrastructure or > other one could even provide moldable code panes with syntax highlighting for > different languages (PHP, CSS, HTML, ... > > Even the browser panes (packages, classes, ...) could be moldable - you display in a tree > an object with relations to other objects - when you click on them more customizable > details (depending on the displayed object) open up in new panes. > > The more (moldable) infrastructure Pharo provides the more cases one will find where it > can be applied. > > So the question is how modable is Pharo already (beside the mentioned cases) and > how moldable will Pharo be in the future? What is the next planned step in this area (if any)? > > Thx > T. > > > [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/032670.… > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 8, 2015

Re: [Pharo-dev] Strange Slice+Changes behavior

by Christophe Demarey

You can write it like that: MCDefinitionIndex>>addAll: aCollection aCollection flattened do: [ :each | self add: each ] Le 8 juil. 2015 Ã 12:45, Peter UhnÃ¡k a Ã©crit : > Hi Nicolai, > > I had to also do this (this is ugly and I shouldn't query class types, but maybe this should be fixed elsewhere anyway) > MCDefinitionIndex>>addAll: aCollection > aCollection > do: [ :ea | > (ea isKindOf: OrderedCollection) > ifTrue: [ self addAll: ea ] > ifFalse: [ self add: ea ] ] > > Because aCollection can now be also collection of collections. > > But after both those changes it looks like a correct changeset. > > Peter > > > On Wed, Jul 8, 2015 at 11:59 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > There is a bug on how it collects all definitions from all dependencies. > > @Peter can you fix this please, it is a missing yourself in > > MCWorkingCopy>>#loadRemoteDependenciesIn: > > ... > > ^ dependencies > inject: OrderedCollection new > into: [ :all :deps| all addAll: deps;yourself ] > > > > > > 2015-07-07 14:19 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > I'm encountering very strange slice+changes behavior and I am not sure wtf is going on... > because it's showing that there are changes in untouched code... > > So imagine I've changed two packages "Spec-Core" and "Spec-Examples" > > If I create a slice for the package independently, then displaying changes looks fine > > Spec-Core Changes > <2015-07-07_14:09:56.png> > â > or > > Spec-Examples Changes > <2015-07-07_14:10:26.png> > â > so far so good, but if I in the slice maker select both packages... and then check the changes this shows up > <2015-07-07_14:11:02.png> > â > which is wtf... I didn't touch AbstractAdapter nor other classes. It's almost like it's comparing "Spec-Examples" against "Spec-Core" > > If I (after creating slice for both packages) select "Spec-Core" it's complaining about removed classes... which are from "Spec-Examples" > <2015-07-07_14:11:18.png> > â > âHowever "Spec-Examples" still looks just fine > <2015-07-07_14:11:35.png> > â > What is going on? What am I missing? > > This is not the first time I am making slices, but I've never encountered this. > > Thanks, > Peter > >

July 8, 2015

Moldable Pharo

by Torsten Bergmann

Hi, with GT Inspector/Spotter we now have more moldable tools and Pharo becomes again a more flexible Tool and IDE. The settings framework also allows to use the settings browser for own purposes and in own applications - which is nice. One can even have a custom world menu in Pharo for the own app (see [1]) Reminds me on Eclipse (RCP, ...) where one can extend the IDE at specific extension points to provide own custom tools and even build applications that are not IDE's. What about a moldable browser? For instance it would be nice if I could extend the browser with own panes as replacement for the regular code pane. So for instance a method that returns an XML string could be shown as a clickable tree instead of the code pane, ... foo <xml> ^'<someXML></someXML> With a flexible code editor like Rubric/TxText and Petit infrastructure or other one could even provide moldable code panes with syntax highlighting for different languages (PHP, CSS, HTML, ... Even the browser panes (packages, classes, ...) could be moldable - you display in a tree an object with relations to other objects - when you click on them more customizable details (depending on the displayed object) open up in new panes. The more (moldable) infrastructure Pharo provides the more cases one will find where it can be applied. So the question is how modable is Pharo already (beside the mentioned cases) and how moldable will Pharo be in the future? What is the next planned step in this area (if any)? Thx T. [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/032670.…

July 8, 2015

Re: [Pharo-dev] merging in a filetree repository

by Sven Van Caekenberghe

> On 08 Jul 2015, at 12:46, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > Yurij post also an explanation recently here: > http://code.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.h… That link does not seem to work ... > > On Wed, Jul 8, 2015 at 12:31 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> Hi Alex, >> >> I've been troubled by this some time ago, so Thierry and Dale gave me >> exhaustive explanation here >> http://forum.world.st/Metacello-GIT-methodProperties-json-td4818097.html >> >> As for merging via git, there is also mentioned MergeDriver that's very easy >> to use and should be able to resolve most problems. >> >> Peter >> >> On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> >> wrote: >>> >>> Hi! >>> >>> Do I still need to press the merge button in Monticello when I am working >>> on a filtree git repository? >>> I understand that no since the merging has to be done by Git, and not by >>> monticello. >>> >>> I tried to not do the merge in monticello, but I get some conflicts when >>> doing the git merge. For example: >>> >>> CONFLICT (content): Merge conflict in >>> Hackathon.package/monticello.meta/version >>> CONFLICT (content): Merge conflict in >>> Hackathon.package/HProject.class/methodProperties.json >>> CONFLICT (content): Merge conflict in >>> Hackathon.package/HClass.class/methodProperties.json >>> >>> Why do we need this methodProperties.json and version files? Shouldnât git >>> handle this? >>> >>> How should I merge these files? Any experience? >>> >>> Cheers, >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >

July 8, 2015

Re: [Pharo-dev] merging in a filetree repository

by Serge Stinckwich

Yurij post also an explanation recently here: http://code.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.h… On Wed, Jul 8, 2015 at 12:31 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi Alex, > > I've been troubled by this some time ago, so Thierry and Dale gave me > exhaustive explanation here > http://forum.world.st/Metacello-GIT-methodProperties-json-td4818097.html > > As for merging via git, there is also mentioned MergeDriver that's very easy > to use and should be able to resolve most problems. > > Peter > > On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: >> >> Hi! >> >> Do I still need to press the merge button in Monticello when I am working >> on a filtree git repository? >> I understand that no since the merging has to be done by Git, and not by >> monticello. >> >> I tried to not do the merge in monticello, but I get some conflicts when >> doing the git merge. For example: >> >> CONFLICT (content): Merge conflict in >> Hackathon.package/monticello.meta/version >> CONFLICT (content): Merge conflict in >> Hackathon.package/HProject.class/methodProperties.json >> CONFLICT (content): Merge conflict in >> Hackathon.package/HClass.class/methodProperties.json >> >> Why do we need this methodProperties.json and version files? Shouldnât git >> handle this? >> >> How should I merge these files? Any experience? >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

July 8, 2015

Re: [Pharo-dev] Strange Slice+Changes behavior

by Peter UhnÃ¡k

Hi Nicolai, I had to also do this (this is ugly and I shouldn't query class types, but maybe this should be fixed elsewhere anyway) MCDefinitionIndex>>addAll: aCollection aCollection do: [ :ea | (ea isKindOf: OrderedCollection) ifTrue: [ self addAll: ea ] ifFalse: [ self add: ea ] ] Because aCollection can now be also collection of collections. But after both those changes it looks like a correct changeset. Peter On Wed, Jul 8, 2015 at 11:59 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > There is a bug on how it collects all definitions from all dependencies. > > @Peter can you fix this please, it is a missing yourself in > > MCWorkingCopy>>#loadRemoteDependenciesIn: > > ... > > ^ dependencies > inject: OrderedCollection new > into: [ :all :deps| all addAll: deps;yourself ] > > > > > > 2015-07-07 14:19 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> Hi, >> >> I'm encountering very strange slice+changes behavior and I am not sure >> wtf is going on... >> because it's showing that there are changes in untouched code... >> >> So imagine I've changed two packages "Spec-Core" and "Spec-Examples" >> >> If I create a slice for the package independently, then displaying >> changes looks fine >> >> Spec-Core Changes >> >> â >> or >> >> Spec-Examples Changes >> >> â >> so far so good, but if I in the slice maker select both packages... and >> then check the changes this shows up >> >> â >> which is wtf... I didn't touch AbstractAdapter nor other classes. It's >> almost like it's comparing "Spec-Examples" against "Spec-Core" >> >> If I (after creating slice for both packages) select "Spec-Core" it's >> complaining about removed classes... which are from "Spec-Examples" >> >> â >> âHowever "Spec-Examples" still looks just fine >> >> â >> What is going on? What am I missing? >> >> This is not the first time I am making slices, but I've never encountered >> this. >> >> Thanks, >> Peter >> > >

July 8, 2015

Re: [Pharo-dev] merging in a filetree repository

by Alexandre Bergel

Thanks Peter, I will have a lookâ¦ Alexandre > On Jul 8, 2015, at 12:31 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi Alex, > > I've been troubled by this some time ago, so Thierry and Dale gave me exhaustive explanation here http://forum.world.st/Metacello-GIT-methodProperties-json-td4818097.html > > As for merging via git, there is also mentioned MergeDriver that's very easy to use and should be able to resolve most problems. > > Peter > > On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Do I still need to press the merge button in Monticello when I am working on a filtree git repository? > I understand that no since the merging has to be done by Git, and not by monticello. > > I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: > > CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version > CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json > CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json > > Why do we need this methodProperties.json and version files? Shouldnât git handle this? > > How should I merge these files? Any experience? > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 8, 2015

Re: [Pharo-dev] merging in a filetree repository

by Peter UhnÃ¡k

Hi Alex, I've been troubled by this some time ago, so Thierry and Dale gave me exhaustive explanation here http://forum.world.st/Metacello-GIT-methodProperties-json-td4818097.html As for merging via git, there is also mentioned MergeDriver that's very easy to use and should be able to resolve most problems. Peter On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Do I still need to press the merge button in Monticello when I am working > on a filtree git repository? > I understand that no since the merging has to be done by Git, and not by > monticello. > > I tried to not do the merge in monticello, but I get some conflicts when > doing the git merge. For example: > > CONFLICT (content): Merge conflict in > Hackathon.package/monticello.meta/version > CONFLICT (content): Merge conflict in > Hackathon.package/HProject.class/methodProperties.json > CONFLICT (content): Merge conflict in > Hackathon.package/HClass.class/methodProperties.json > > Why do we need this methodProperties.json and version files? Shouldnât git > handle this? > > How should I merge these files? Any experience? > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

July 8, 2015

merging in a filetree repository

by Alexandre Bergel

Hi! Do I still need to press the merge button in Monticello when I am working on a filtree git repository? I understand that no since the merging has to be done by Git, and not by monticello. I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json Why do we need this methodProperties.json and version files? Shouldnât git handle this? How should I merge these files? Any experience? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 8, 2015