February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Getting coherent shortcuts

by Damien Cassou

Guille Polito <guillermopolito(a)gmail.com> writes: > So, since today I was able to commit again, I decided to make a couple > of slices/new configurations fixing the majority of shortcuts in the > image. Like this, mac shortcuts will remain in cmd, but linux and > windows shortcuts will be with ctrl, as expected by the vast majority of > users :). The changes I made should fix 97.8882% of the shortcut > experience in linux and windows, without degrading the one in mac. Of > course, if you see any glitch, just tell. thank you very much! -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Feb. 9, 2016

Re: [Pharo-dev] Getting coherent shortcuts

by Guille Polito

Esteban was telling me that he is going to re-integrate the VM fixes to the shortcuts for windows soon. On 02/09/2016 04:48 PM, stepharo wrote: > > > Le 9/2/16 15:50, Guille Polito a Ã©crit : >> Hi all, >> >> Since a week, I'm back to using linux (debian) due to a new job. And >> it became SOOOO evident that the shortcuts are wrongly configured, >> that I actually cannot work! >> >> Sometimes windows are closed with ctrl w, sometimes with alt w. >> Nautilus is used with alt, playgrounds with ctrl... >> >> So, since today I was able to commit again, I decided to make a >> couple of slices/new configurations fixing the majority of shortcuts >> in the image. > > THANKS!!!!! > >> Like this, mac shortcuts will remain in cmd, but linux and windows >> shortcuts will be with ctrl, as expected by the vast majority of >> users :). The changes I made should fix 97.8882% of the shortcut >> experience in linux and windows, without degrading the one in mac. Of >> course, if you see any glitch, just tell. >> >> I had to touch several packages, which some are not in the Pharo >> repository. For this I prepared several issues for the monkey: >> >> *Slice - >> SLICE-Issue-17552-In-Linux-some-shortcuts-use-alt-some-others-ctrl-GuillermoPolito.2 >> https://pharo.fogbugz.com/f/cases/17552/In-Linux-some-shortcuts-use-alt-som… >> >> >> *Rubric - 2.7 >> https://pharo.fogbugz.com/f/cases/17558/Update-Rubric-In-Linux-some-shortcu… >> >> >> *DependencyAnalyzer - 1.15 >> https://pharo.fogbugz.com/f/cases/17557/Update-DependencyAnalyzer-In-Linux-… >> >> >> *FastTable - 0.10 >> https://pharo.fogbugz.com/f/cases/17555/Update-FastTable-In-Linux-some-shor… >> >> >> *TxText - 2.12.2 >> https://pharo.fogbugz.com/f/cases/17556/Update-TxText-In-Linux-some-shortcu… >> >> >> >> Also, I did some changes in Glamour and GTSpotter, but I have no >> permissions to commit there. How do we do to commit in those >> packages? Should I ask for permissions or is there any other process >> in place? >> >> Guille >> >> > >

Feb. 9, 2016

Re: [Pharo-dev] Spec Experience in Need for Feedback :)

by stepharo

Hi peter :) If I recall, one of the key problem is that the state of certain widgets does not let the adpater do its job nicely and disappear after the bridging. Stef Le 9/2/16 16:31, Peter UhnÃ¡k a Ã©crit : > The widget becomes available only once the UI is built, however when > you are configuring Spec it is not yet built so it's not available and > thus the ugly nil check (well, one of the reasons anyway). > > This is a big problem with morphic/spec ui elements. You never > know for sure > what code this > self update ---> search through all (dynamicly added) > dependents and notify > will finally call. > > I don't think there is any way around it. You have to decouple > view(s) from model(s), and, hence have those propagation > constraints by way of notifications. > > > About a year ago we were discussing this with Stef and one of the > options was to expose all value holders (which has happened in the > meantime) and have adapter just connect Spec with Morphic. > This is a bit older and needs updating, but I think it still holds > somewhat https://gist.github.com/peteruhnak/0fc752d0cea9bde69315 (the > idea was to to connect Morphic directly to observe Spec and therefore > not have Adapter at all during runtime). > > Peter > > On Tue, Feb 9, 2016 at 1:46 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi nicolai > > I agree. I will have a look at the Calipso experience of Alain. > Because may be Calipso + Spec layout format would be much nicer. > Did you look at it? > Alain just brainstormed but this is interesting for thinking. > > Stef > > What I hate also is that the > > AbstractApdate>>update: aSymbol > > self changed: aSymbol > > This is a bit terrible because the adpater should not exist at > runtime > and adapter should just encapsulate how to create and set the > communication > between the model and the view. Now it is in the middle and this > is not good. > > stef > > > Le 8/2/16 11:31, Nicolai Hess a Ã©crit : >> >> >> 2016-02-08 10:37 GMT+01:00 stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>>: >> >> Hi guys >> >> I should say that I'm sick (gift from my little boy) so may >> be this is obvious. >> >> I'm looking at the code of Spec and I hate this code :) >> >> widgetDo: aBlock >> >> ^ self widget ifNotNil: aBlock >> >> >> I do not see why widgetDo: has to test for nil >> So I transformed >> >> widgetDo: aBlock >> >> ^ self widget ifNotNil: aBlock >> >> into >> >> >> widgetDo: aBlock >> >> ^ aBlock cull: self widget >> >> BTW I hate all the cull: call. They are connected with >> sloppiness). It is far too easy to use cull: >> I do not know how many arguments, I do not care I use cull: >> cull: is slow slow and help producing messing API. >> >> And it broke. The methodBrowser example did not work anymore >> and many others. >> Debugger felt down.... >> I feel sad. Now my brain is dead so I cannot concentrate more. >> >> >> Stef >> >> >> This is a big problem with morphic/spec ui elements. You never >> know for sure >> what code this >> self update ---> search through all (dynamicly added) dependents >> and notify >> will finally call. >> In this example we are about to *built* the widgets and in this >> run , we change a component that >> will update all dependents goes back and forth between model, >> adapter and widget. And all >> before the widget is actually accessible for the widgetDo: call. >> >> (and, REALLY we need to clean this up. This is really bad code if >> we announce a textChanged announcement for >> a text component, if we *initialize* an *empty textcomponent* >> with an *empty text*!). >> >> > >

Feb. 9, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by stepharo

Le 9/2/16 09:58, Sven Van Caekenberghe a Ã©crit : > I can do the integration too, but I need some people to say go ahead. > I vote for replacing everything, there is no need for a plugin. me too. Less plugin! > >> On 09 Feb 2016, at 09:25, Guille Polito <guillermopolito(a)gmail.com> wrote: >> >> Sven, just to answer your last question. The UUID generation right now generates the UUID fields like this: >> >> UUIDGenerator>>generateFieldsVersion4 >> >> timeLow := self generateRandomBitsOfLength: 32. >> timeMid := self generateRandomBitsOfLength: 16. >> timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength: 12). >> clockSeqHiAndReserved := 16r80 bitOr: (self generateRandomBitsOfLength: 6). >> clockSeqLow := self generateRandomBitsOfLength: 8. >> node := self generateRandomBitsOfLength: 48. >> >> So... It's basically completely random. There is no part of the UUID that is actually based on the node, the clock or the time. It is actually a random string of bits that are generated using a number from /dev/urandom as seed (in linux). >> >> Does the mac VM include the plugin? (I do not have a mac any more to test fast ^^) >> >> I'll work on the integration of NeoUUID now, I hope this is the kind of issues that got integrated in code-freeze :) >> >> Guille >> >> On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote: >>> Here is a new version, in preparation of possible integration in the main image: >>> >>> === >>> Name: Neo-UUID-SvenVanCaekenberghe.2 >>> Author: SvenVanCaekenberghe >>> Time: 8 February 2016, 8:33:04.141334 pm >>> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e >>> Ancestors: Neo-UUID-SvenVanCaekenberghe.1 >>> >>> Streamline UUID generation >>> >>> Add a current, shared instance >>> >>> Added better class and method comments >>> >>> Add more tests >>> >>> As suggested by Henrik Johansen, change to a version 0 UUID to indicate that we follow a custom approach >>> === >>> >>> The class comments now reads as follows: >>> >>> === >>> I am NeoUUIDGenerator, I generate UUIDs. >>> >>> An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit number that can be used for identification purposes. Concretely, a UUID is a 16 element byte array. >>> >>> The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. In this context the word unique should be taken to mean "practically unique" rather than "guaranteed unique". >>> I generate UUIDs similar, in spirit, to those defined in RFC4122, though I use version 0 to indicate that I follow none of the defined versions. This does not matter much, if at all, in practice. >>> >>> I try to conform to the following aspects: >>> - each 'node' (machine, image, instance) should generate unique UUIDs >>> - even when generating UUIDs at a very fast rate, they should remain unique >>> - be fast and efficient >>> >>> To achieve this goal, I >>> - take several aspects into account to generate a unique node ID >>> - combine a clock, a counter and some random bits >>> - hold a state, protected for multi user access >>> >>> I can generate about 500K UUIDs per second. >>> >>> Implementation: >>> >>> Although a UUID should be seen as totally opaque, here is the concrete way I generate one: >>> - the first 8 bytes are the millisecond clock value with the smallest quantity first; this means that the later of these 8 bytes will be identical when generated with small(er) timespans; within the same millisecond, the full first 8 bytes will be identical >>> - the next 2 bytes represent a counter with safe overflow, held as protected state inside me; after 2*16 this value will repeat; the counter initalizes with a random value >>> - the next 2 bytes are simply random, based on the system PRNG, Random >>> - the final 4 bytes represent the node ID; the node ID is unique per instance of me, across OS environments where the image might run; the node ID is the MD5 hash of a string that is the concatenation of several elements (see #computeNodeIdentifier) >>> Some bits are set to some predefined value, to indicate the variant and version (see #setVariantAndVersion:) >>> >>> Usage: >>> >>> NeoUUIDGenerator next. >>> NeoUUIDGenerator current next. >>> NeoUUIDGenerator new next. >>> >>> Sharing an instance is more efficient and correct. >>> Instances should be reset whenever the image comes up. >>> >>> See also: >>> >>> http://en.wikipedia.org/wiki/UUID >>> https://tools.ietf.org/html/rfc4122 >>> === >>> >>> If we integrate this, I think we should replace the old generator and the use of the primitive/plugin. But that requires at least some support apart from me. >>> >>> And although I think that we should integrate this generator and get rid of the plugin, I think there is probably an underlying problem here (why did the generator fail ?) that could be important to find. >>> >>> Sven >>> >>>> On 08 Feb 2016, at 10:38, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>>> >>>>> On 08 Feb 2016, at 10:29 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>>> 2) Misrepresenting the way the UUID was generated (a combination of node identifier + timestamp + random value, similar to type 3, but with differently sized/ordered fields) by marking it as being of type 4, which is defined to be UUID consisting of random bytes. >>>>>> IOW, I think it should be marked as type 0 instead of 4, so for the 1 person in each country who might be found to assume something about the implementation based on the type field, won't later feel he's been duped when checking the generator. >>>>> OK, I certainly want to change the type. Thing is, I cannot find a reference to type 0 anywhere that I am looking (I mostly used https://en.wikipedia.org/wiki/Universally_unique_identifier) Where did you find a definition of type 0 ? Or would that be a way to say 'no specific type' then ? >>>> My rationale was that it is currently unassigned, and the least likely number to be chosen as identifier by new versions of the standard. >>>> IOW, for those who care, it might raise a "hmm, this is strange, better check the source", upon which they will discover it is generated in a non-standard fashion (but can verify for themselves it is generated in a way still pretty much guaranteed to be unique), and the rest... well, they can (most probably) keep on living happily without ever seeing a collision. >>>> >>>> Cheers, >>>> Henry > >

Feb. 9, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by stepharo

I love the class comment! This is because of such class comment that I love also pharo Le 8/2/16 20:39, Sven Van Caekenberghe a Ã©crit : > Here is a new version, in preparation of possible integration in the main image: > > === > Name: Neo-UUID-SvenVanCaekenberghe.2 > Author: SvenVanCaekenberghe > Time: 8 February 2016, 8:33:04.141334 pm > UUID: a909453e-35dd-4c25-8273-62a9b2bd982e > Ancestors: Neo-UUID-SvenVanCaekenberghe.1 > > Streamline UUID generation > > Add a current, shared instance > > Added better class and method comments > > Add more tests > > As suggested by Henrik Johansen, change to a version 0 UUID to indicate that we follow a custom approach > === > > The class comments now reads as follows: > > === > I am NeoUUIDGenerator, I generate UUIDs. > > An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit number that can be used for identification purposes. Concretely, a UUID is a 16 element byte array. > > The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. In this context the word unique should be taken to mean "practically unique" rather than "guaranteed unique". > > I generate UUIDs similar, in spirit, to those defined in RFC4122, though I use version 0 to indicate that I follow none of the defined versions. This does not matter much, if at all, in practice. > > I try to conform to the following aspects: > - each 'node' (machine, image, instance) should generate unique UUIDs > - even when generating UUIDs at a very fast rate, they should remain unique > - be fast and efficient > > To achieve this goal, I > - take several aspects into account to generate a unique node ID > - combine a clock, a counter and some random bits > - hold a state, protected for multi user access > > I can generate about 500K UUIDs per second. > > Implementation: > > Although a UUID should be seen as totally opaque, here is the concrete way I generate one: > - the first 8 bytes are the millisecond clock value with the smallest quantity first; this means that the later of these 8 bytes will be identical when generated with small(er) timespans; within the same millisecond, the full first 8 bytes will be identical > - the next 2 bytes represent a counter with safe overflow, held as protected state inside me; after 2*16 this value will repeat; the counter initalizes with a random value > - the next 2 bytes are simply random, based on the system PRNG, Random > - the final 4 bytes represent the node ID; the node ID is unique per instance of me, across OS environments where the image might run; the node ID is the MD5 hash of a string that is the concatenation of several elements (see #computeNodeIdentifier) > > Some bits are set to some predefined value, to indicate the variant and version (see #setVariantAndVersion:) > > Usage: > > NeoUUIDGenerator next. > NeoUUIDGenerator current next. > NeoUUIDGenerator new next. > > Sharing an instance is more efficient and correct. > Instances should be reset whenever the image comes up. > > See also: > > http://en.wikipedia.org/wiki/UUID > https://tools.ietf.org/html/rfc4122 > === > > If we integrate this, I think we should replace the old generator and the use of the primitive/plugin. But that requires at least some support apart from me. > > And although I think that we should integrate this generator and get rid of the plugin, I think there is probably an underlying problem here (why did the generator fail ?) that could be important to find. > > Sven > >> On 08 Feb 2016, at 10:38, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >>> On 08 Feb 2016, at 10:29 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> 2) Misrepresenting the way the UUID was generated (a combination of node identifier + timestamp + random value, similar to type 3, but with differently sized/ordered fields) by marking it as being of type 4, which is defined to be UUID consisting of random bytes. >>>> IOW, I think it should be marked as type 0 instead of 4, so for the 1 person in each country who might be found to assume something about the implementation based on the type field, won't later feel he's been duped when checking the generator. >>> OK, I certainly want to change the type. Thing is, I cannot find a reference to type 0 anywhere that I am looking (I mostly used https://en.wikipedia.org/wiki/Universally_unique_identifier) Where did you find a definition of type 0 ? Or would that be a way to say 'no specific type' then ? >> My rationale was that it is currently unassigned, and the least likely number to be chosen as identifier by new versions of the standard. >> IOW, for those who care, it might raise a "hmm, this is strange, better check the source", upon which they will discover it is generated in a non-standard fashion (but can verify for themselves it is generated in a way still pretty much guaranteed to be unique), and the rest... well, they can (most probably) keep on living happily without ever seeing a collision. >> >> Cheers, >> Henry > >

Feb. 9, 2016

Re: [Pharo-dev] Getting coherent shortcuts

by stepharo

Le 9/2/16 15:50, Guille Polito a Ã©crit : > Hi all, > > Since a week, I'm back to using linux (debian) due to a new job. And > it became SOOOO evident that the shortcuts are wrongly configured, > that I actually cannot work! > > Sometimes windows are closed with ctrl w, sometimes with alt w. > Nautilus is used with alt, playgrounds with ctrl... > > So, since today I was able to commit again, I decided to make a couple > of slices/new configurations fixing the majority of shortcuts in the > image. THANKS!!!!! > Like this, mac shortcuts will remain in cmd, but linux and windows > shortcuts will be with ctrl, as expected by the vast majority of users > :). The changes I made should fix 97.8882% of the shortcut experience > in linux and windows, without degrading the one in mac. Of course, if > you see any glitch, just tell. > > I had to touch several packages, which some are not in the Pharo > repository. For this I prepared several issues for the monkey: > > *Slice - > SLICE-Issue-17552-In-Linux-some-shortcuts-use-alt-some-others-ctrl-GuillermoPolito.2 > https://pharo.fogbugz.com/f/cases/17552/In-Linux-some-shortcuts-use-alt-som… > > > *Rubric - 2.7 > https://pharo.fogbugz.com/f/cases/17558/Update-Rubric-In-Linux-some-shortcu… > > > *DependencyAnalyzer - 1.15 > https://pharo.fogbugz.com/f/cases/17557/Update-DependencyAnalyzer-In-Linux-… > > > *FastTable - 0.10 > https://pharo.fogbugz.com/f/cases/17555/Update-FastTable-In-Linux-some-shor… > > > *TxText - 2.12.2 > https://pharo.fogbugz.com/f/cases/17556/Update-TxText-In-Linux-some-shortcu… > > > > Also, I did some changes in Glamour and GTSpotter, but I have no > permissions to commit there. How do we do to commit in those packages? > Should I ask for permissions or is there any other process in place? > > Guille > >

Feb. 9, 2016

Re: [Pharo-dev] newFrom: vs. withAll:

by stepharo

> Hi guys > > I was looking at the Collection chapter and I stumbled upon newFrom: > and I wonder what is the real > difference between newFrom: and withAll:. > I have the impression that there is not much difference. There are > only 47 senders of newFrom: in the default Pharo image. > > Dictionary class>>withAll: interprets its argument as a collection of > values, > whereas Dictionary class>>newFrom: expects a collection of associations. > > I would really deprecate newFrom: in the future. > > Stef I can understand using anObject newFrom: anotherObject newFrom: aSimilarObject "Create an object that has similar contents to aSimilarObject. If the classes have any instance variables with the same names, copy them across. If this is bad for a class, override this method." ^ (self isVariable ifTrue: [self basicNew: aSimilarObject basicSize] ifFalse: [self basicNew]) copySameFrom: aSimilarObject copySameFrom: otherObject "Copy to myself all instance variables named the same in otherObject. This ignores otherObject's control over its own inst vars." | myInstVars otherInstVars | myInstVars := self class allInstVarNames. otherInstVars := otherObject class allInstVarNames. myInstVars doWithIndex: [:each :index | | match | (match := otherInstVars indexOf: each) > 0 ifTrue: [self instVarAt: index put: (otherObject instVarAt: match)]]. 1 to: (self basicSize min: otherObject basicSize) do: [:i | self basicAt: i put: (otherObject basicAt: i)]. but I do not see the point to use this protocol over withAll: for collection. And in general I would prefer to call it cloneFrom: Stef

Feb. 9, 2016

newFrom: vs. withAll:

by stepharo

Hi guys I was looking at the Collection chapter and I stumbled upon newFrom: and I wonder what is the real difference between newFrom: and withAll:. I have the impression that there is not much difference. There are only 47 senders of newFrom: in the default Pharo image. Dictionary class>>withAll: interprets its argument as a collection of values, whereas Dictionary class>>newFrom: expects a collection of associations. I would really deprecate newFrom: in the future. Stef

Feb. 9, 2016

Re: [Pharo-dev] Spec Experience in Need for Feedback :)

by Peter UhnÃ¡k

The widget becomes available only once the UI is built, however when you are configuring Spec it is not yet built so it's not available and thus the ugly nil check (well, one of the reasons anyway). This is a big problem with morphic/spec ui elements. You never know for sure >> what code this >> self update ---> search through all (dynamicly added) dependents and >> notify >> will finally call. >> > I don't think there is any way around it. You have to decouple view(s) > from model(s), and, hence have those propagation constraints by way of > notifications. About a year ago we were discussing this with Stef and one of the options was to expose all value holders (which has happened in the meantime) and have adapter just connect Spec with Morphic. This is a bit older and needs updating, but I think it still holds somewhat https://gist.github.com/peteruhnak/0fc752d0cea9bde69315 (the idea was to to connect Morphic directly to observe Spec and therefore not have Adapter at all during runtime). Peter On Tue, Feb 9, 2016 at 1:46 PM, stepharo <stepharo(a)free.fr> wrote: > Hi nicolai > > I agree. I will have a look at the Calipso experience of Alain. > Because may be Calipso + Spec layout format would be much nicer. > Did you look at it? > Alain just brainstormed but this is interesting for thinking. > > Stef > > What I hate also is that the > > AbstractApdate>>update: aSymbol > > self changed: aSymbol > > This is a bit terrible because the adpater should not exist at runtime > and adapter should just encapsulate how to create and set the > communication > between the model and the view. Now it is in the middle and this is not > good. > > stef > > > Le 8/2/16 11:31, Nicolai Hess a Ã©crit : > > > > 2016-02-08 10:37 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> Hi guys >> >> I should say that I'm sick (gift from my little boy) so may be this is >> obvious. >> >> I'm looking at the code of Spec and I hate this code :) >> >> widgetDo: aBlock >> >> ^ self widget ifNotNil: aBlock >> >> >> I do not see why widgetDo: has to test for nil >> So I transformed >> >> widgetDo: aBlock >> >> ^ self widget ifNotNil: aBlock >> >> into >> >> >> widgetDo: aBlock >> >> ^ aBlock cull: self widget >> >> BTW I hate all the cull: call. They are connected with sloppiness). It is >> far too easy to use cull: >> I do not know how many arguments, I do not care I use cull: >> cull: is slow slow and help producing messing API. >> >> And it broke. The methodBrowser example did not work anymore and many >> others. >> Debugger felt down.... >> I feel sad. Now my brain is dead so I cannot concentrate more. >> >> >> Stef >> >> > This is a big problem with morphic/spec ui elements. You never know for > sure > what code this > self update ---> search through all (dynamicly added) dependents and notify > will finally call. > In this example we are about to *built* the widgets and in this run , we > change a component that > will update all dependents goes back and forth between model, adapter and > widget. And all > before the widget is actually accessible for the widgetDo: call. > > (and, REALLY we need to clean this up. This is really bad code if we > announce a textChanged announcement for > a text component, if we *initialize* an *empty textcomponent* with an > *empty text*!). > > > >

Feb. 9, 2016

Re: [Pharo-dev] Getting coherent shortcuts

by Cyril Ferlicot Delbecque

On 09/02/2016 15:50, Guille Polito wrote: > Hi all, > > Since a week, I'm back to using linux (debian) due to a new job. And it > became SOOOO evident that the shortcuts are wrongly configured, that I > actually cannot work! > > Sometimes windows are closed with ctrl w, sometimes with alt w. Nautilus > is used with alt, playgrounds with ctrl... > > So, since today I was able to commit again, I decided to make a couple > of slices/new configurations fixing the majority of shortcuts in the > image. Like this, mac shortcuts will remain in cmd, but linux and > windows shortcuts will be with ctrl, as expected by the vast majority of > users :). The changes I made should fix 97.8882% of the shortcut > experience in linux and windows, without degrading the one in mac. Of > course, if you see any glitch, just tell. > > I had to touch several packages, which some are not in the Pharo > repository. For this I prepared several issues for the monkey: > > *Slice - > SLICE-Issue-17552-In-Linux-some-shortcuts-use-alt-some-others-ctrl-GuillermoPolito.2 > > https://pharo.fogbugz.com/f/cases/17552/In-Linux-some-shortcuts-use-alt-som… > > > *Rubric - 2.7 > https://pharo.fogbugz.com/f/cases/17558/Update-Rubric-In-Linux-some-shortcu… > > > *DependencyAnalyzer - 1.15 > https://pharo.fogbugz.com/f/cases/17557/Update-DependencyAnalyzer-In-Linux-… > > > *FastTable - 0.10 > https://pharo.fogbugz.com/f/cases/17555/Update-FastTable-In-Linux-some-shor… > > > *TxText - 2.12.2 > https://pharo.fogbugz.com/f/cases/17556/Update-TxText-In-Linux-some-shortcu… > > > > Also, I did some changes in Glamour and GTSpotter, but I have no > permissions to commit there. How do we do to commit in those packages? > Should I ask for permissions or is there any other process in place? > > Guille > You even made the configurations yourself! Perfect :) Thank you! -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Feb. 9, 2016