- Pharo-users - lists.pharo.org

Re: [Pharo-users] Nautilus questions

by Stephan Eggermont

On 18/08/15 21:59, Peter UhnÃ¡k wrote: > I would expect the left/right history buttons being right next to the > History Navigator selector. That way history-related controls are > together and the purpose of the buttons is obvious The history navigation would be better without the selector by addding a drop-down menu to the back button in a way similar to that in web browsers, i.e. click goes back, while mouseDown and hold opens the menu. > Placing them all on a single line would also save up vertical space, > which considering we've added QualityAssistant and Rubric adds another > line is quite valuable. The single line was a pretty bad idea, considering that we could not make clear which button applied to what part of the UI. There are two places where new users expect that, either at the top or at the bottom of a window. > And finally, code-wise I've never really interacted with Morphic and > stayed in Spec, so when I was digging through code it seems that the way > Morphs are composed are through these "addMorph:fullFrame: (LayoutFrame > identity rightFraction: 0.10; yourself);" constructs sprinkled > haphazardly throughout the code. Is there nothing like SpecLayout? Sure, just take a look at LayoutPolicy and subclasses. I feel like we're missing a constraints based or grid layout in Morphic. Stephan

Aug. 19, 2015

Re: [Pharo-users] [Pharo-dev] Nautilus questions

by Dimitris Chloupis

I agree with your post about the buttons. Personally I have never used scoped or really need it as feature , I dont think I would be needing variables either. Actually two buttons I miss from Squeak is implementers and senders which I found super useful. On Tue, Aug 18, 2015 at 11:00 PM Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > maybe I'm too picky, but I have couple of questions/remarks regarding > current Nautilus UI. > Now, I'm happy that new features were added/reorganized, but it does feel > it is a little bit chaotic right now. > > > I would expect the left/right history buttons being right next to the > History Navigator selector. That way history-related controls are together > and the purpose of the buttons is obvious > > "Hier.", "Com."... abbreviating button labels? Really? > > âAnd finally, why was part of the buttons moved up? And part stayed down? > I know that you wanted to distinguish "Scoped", because it opens a new > browser, and Variables, because they have intermediate menu (and later open > another menu). > But I think the fact that Variables are tied to a particular selected > class would make much more sense to place the button beside hierachy/class > button. > > And opening Scoped can be denoted with an appropriate icon ( > https://www.google.com/search?site=&tbm=isch&source=hp&biw=&bih=&q=new+wind… > ) > > Placing them all on a single line would also save up vertical space, which > considering we've added QualityAssistant and Rubric adds another line is > quite valuable. > > (And finally the width of the buttons should perhaps match more closely > the actual needs of the label, because now it's bit cramped.) > > > â > And finally, code-wise I've never really interacted with Morphic and > stayed in Spec, so when I was digging through code it seems that the way > Morphs are composed are through these "addMorph:fullFrame: (LayoutFrame > identity rightFraction: 0.10; yourself);" constructs sprinkled haphazardly > throughout the code. Is there nothing like SpecLayout? Maybe it wasn't so > hard once you get used to Morphic, because I spent probably more time doing > elementary changes to layout than learning half of Spec... (Also since Spec > can interoperate with Morphic, maybe the layout could also be adapted? Or > slowly migrate Nautilus to Spec (if there are even plans like that)?) > > Now as I've mentioned I'm not an UI/UX expert, but you don't need to be a > chef to tell when food isn't great (which is of course amplified by > personal tastes). > > So unless I am the only person bothered by this, I would like to raise a > discussion (or send a slice, but the way I've done the layout weirds me > out, so I still want to look into that regardless). > > Cheers, > Peter > >

Aug. 18, 2015

Re: [Pharo-users] Is RBClassNotReferencedRule ~200x slower in Pharo 4 vs Pharo 3 ?

by Yuriy Tymchuk

This may have happened when I was removing contexts from the rules. Uko > On 18 Aug 2015, at 18:25, stepharo <stepharo(a)free.fr> wrote: > > Hi marcus > > do you get an idea why we got this slowdown? > > Stef > > Le 30/7/15 14:08, Marcus Denker a Ã©crit : >> I added an issue: >> >> https://pharo.fogbugz.com/f/cases/16074/Is-RBClassNotReferencedRule-200x-sl… <https://pharo.fogbugz.com/f/cases/16074/Is-RBClassNotReferencedRule-200x-sl…> >> >> i think we need to put in some cashingâ¦ here if we would could all *used* classes once for an enviromentâ¦. >> >>> On 29 Jul 2015, at 17:33, Paul DeBruicker <pdebruic(a)gmail.com <mailto:pdebruic@gmail.com>> wrote: >>> >>> Paul DeBruicker wrote >>>> Hi Stef, >>>> >>>> The slowdown is dependent upon the # of classes in the package. If you >>>> use Fuel then you should see a slowdown of 20x. I just have a lot of >>>> classes in this package. The source of the slowdown is in the changes to >>>> RBSmallLintChecker>>#checkClass: and >>>> RBClassNotReferencedRule>>#checkClass: . The old versions use the linter >>>> to check if the literal is used anywhere and the new one uses #allCallsOn. >>>> >>>> >>>> Hope this helps >>>> >>>> Paul >>> >>> >>> and by "use Fuel" I mean: >>> >>> rule:=RBClassNotReferencedRule new. >>> environment:=RBBrowserEnvironment new forPackageNames: #('Fuel'). >>> >>> >>> AndreasSystemProfiler spyOn:[RBSmalllintChecker runRule: rule onEnvironment: >>> environment] >>> >>> >>> >>> >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/Is-RBClassNotReferencedRule-200x-slower-in-Pharo-4-vs… <http://forum.world.st/Is-RBClassNotReferencedRule-200x-slower-in-Pharo-4-vs…> >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com <http://nabble.com/>. >>> >> >

Aug. 18, 2015

Re: [Pharo-users] Chinese Character Data

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Yes, it should work with the right font Thanks to all! Yes, changing the "default" font to e.g. "Arial Unicode MS" did the trick for e.g. GT Inspector display, and changing the "code" font to same made pasting work as expected. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Chinese-Character-Data-tp4843635p4843896.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 18, 2015

Nautilus questions

by Peter UhnÃ¡k

Hi, maybe I'm too picky, but I have couple of questions/remarks regarding current Nautilus UI. Now, I'm happy that new features were added/reorganized, but it does feel it is a little bit chaotic right now. I would expect the left/right history buttons being right next to the History Navigator selector. That way history-related controls are together and the purpose of the buttons is obvious "Hier.", "Com."... abbreviating button labels? Really? âAnd finally, why was part of the buttons moved up? And part stayed down? I know that you wanted to distinguish "Scoped", because it opens a new browser, and Variables, because they have intermediate menu (and later open another menu). But I think the fact that Variables are tied to a particular selected class would make much more sense to place the button beside hierachy/class button. And opening Scoped can be denoted with an appropriate icon ( https://www.google.com/search?site=&tbm=isch&source=hp&biw=&bih=&q=new+wind… ) Placing them all on a single line would also save up vertical space, which considering we've added QualityAssistant and Rubric adds another line is quite valuable. (And finally the width of the buttons should perhaps match more closely the actual needs of the label, because now it's bit cramped.) â And finally, code-wise I've never really interacted with Morphic and stayed in Spec, so when I was digging through code it seems that the way Morphs are composed are through these "addMorph:fullFrame: (LayoutFrame identity rightFraction: 0.10; yourself);" constructs sprinkled haphazardly throughout the code. Is there nothing like SpecLayout? Maybe it wasn't so hard once you get used to Morphic, because I spent probably more time doing elementary changes to layout than learning half of Spec... (Also since Spec can interoperate with Morphic, maybe the layout could also be adapted? Or slowly migrate Nautilus to Spec (if there are even plans like that)?) Now as I've mentioned I'm not an UI/UX expert, but you don't need to be a chef to tell when food isn't great (which is of course amplified by personal tastes). So unless I am the only person bothered by this, I would like to raise a discussion (or send a slice, but the way I've done the layout weirds me out, so I still want to look into that regardless). Cheers, Peter

Aug. 18, 2015

Re: [Pharo-users] ***UNCHECKED*** Re: [ANN] Magma 1.5

by Pablo R. Digonzelli

i was using voyage for these tests. Pablo Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Esteban Lorenzano" <estebanlm(a)gmail.com> Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> CC: "stephan" <stephan(a)stack.nl>, "Torsten Bergmann" <astares(a)gmx.de>, hilaire(a)drgeo.eu Enviados: Martes, 18 de Agosto 2015 13:55:10 Asunto: Re: [Pharo-users] ***UNCHECKED*** Re: [ANN] Magma 1.5 > On 18 Aug 2015, at 18:35, Pablo R. Digonzelli <pdigonzelli(a)gmail.com> wrote: > > Yes I checkesd. It is by far better approach to pharo and I like it very much. > The problem i found was when i stress mongo, it lost some transactions (i.e 10000 rewrites lost about 80 or more don't remember exactly) . > In bussiness apps i cannot take that risk. targeting plain mongo or using voyage? I find hard to believe a production database as is mongo can have those problems so I would think more on voyage (and in that case, we can find a solution because this is obviously a bug :P) Esteban > > > > > > Ing. Pablo Digonzelli > Software Solutions > IP-Solutiones SRL > Metrotec SRL > 25 de Mayo 521 > San Miguel de TucumÃ¡n > Email: pdigonzelli(a)softsargentina.com > pdigonzelli(a)gmail.com > Cel: 5493815982714 > > ----- Mensaje original ----- > De: "Esteban Lorenzano" <estebanlm(a)gmail.com> > Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > CC: stephan(a)stack.nl, "Torsten Bergmann" <astares(a)gmx.de>, hilaire(a)drgeo.eu > Enviados: Martes, 18 de Agosto 2015 12:45:05 > Asunto: ***UNCHECKED*** Re: [Pharo-users] [ANN] Magma 1.5 > >> On 18 Aug 2015, at 17:20, Pablo R. Digonzelli <pdigonzelli(a)gmail.com> wrote: >> >> I can colaborate. I do not know if i have the time and technical skills to do it alone, but for shure i can colaborate. >> I think magma will be a very interesting option for object persistence in pharo. >> I am currently working with garage and glorp and i suffers the innecesary complexity and other bad things thet persistence layer introduce in developing pharo apps. > > have you checked voyage? (to work with a MongoDB)â¦ it will avoid all the pain of using a relational database. > > Esteban > > ps: But yes, I do believe having magma would be cool too. > >> >> Pharo >> >> >> Ing. Pablo Digonzelli >> Software Solutions >> IP-Solutiones SRL >> Metrotec SRL >> 25 de Mayo 521 >> San Miguel de TucumÃ¡n >> Email: pdigonzelli(a)softsargentina.com >> pdigonzelli(a)gmail.com >> Cel: 5493815982714 >> >> ----- Mensaje original ----- >> De: "Torsten Bergmann" <astares(a)gmx.de> >> Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> >> CC: stephan(a)stack.nl, stepharo(a)free.fr, hilaire(a)drgeo.eu, "Pablo Digonzelli" <pdigonzelli(a)gmail.com> >> Enviados: Martes, 18 de Agosto 2015 10:26:44 >> Asunto: Fwd: [ANN] Magma 1.5 >> >> Stephan Eggermont wrote: >>> It is possible, and it needs someone who can deal with low-level >>> details. Magma has its own mailing list. Chris has repeatedly said he'd >>> be willing to help out, but is not willing to be the Pharo port maintainer. >> >> I asked Chris directly and you can find his answer here on the magma list: >> >> http://lists.squeakfoundation.org/pipermail/magma/2015-August/001955.html >> >> As ever it requires someone to move this forward to make it happen. >> But as there was an initiative with Magma 1.3 for Pharo 1.3 already it does not >> seem impossible. >> >> Also - as Stef already pointed out - community services like CI could be used >> to maintain it once an initial up to date port was done. >> >> Bye >> T. >> >

Aug. 18, 2015

Re: [Pharo-users] ***UNCHECKED*** Re: [ANN] Magma 1.5

by Paul DeBruicker

EstebanLM wrote > I find hard to believe a production database as is mongo can have those > problems so I would think more on voyage (and in that case, we can find a > solution because this is obviously a bug :P) > > Esteban > >> https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads describes how almost all "write concern" levels allow data loss in Mongo. The author but points out that the default setting of Acknowledged is unsafe and a setting of at least Majority should be used, but even then no guarantees. I'm not capable of analyzing it but it would seem like Mongo may not be a production database one would want to use. -- View this message in context: http://forum.world.st/Fwd-ANN-Magma-1-5-tp4843768p4843863.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 18, 2015

Re: [Pharo-users] ***UNCHECKED*** Re: [ANN] Magma 1.5

by Esteban Lorenzano

> On 18 Aug 2015, at 18:35, Pablo R. Digonzelli <pdigonzelli(a)gmail.com> wrote: > > Yes I checkesd. It is by far better approach to pharo and I like it very much. > The problem i found was when i stress mongo, it lost some transactions (i.e 10000 rewrites lost about 80 or more don't remember exactly) . > In bussiness apps i cannot take that risk. targeting plain mongo or using voyage? I find hard to believe a production database as is mongo can have those problems so I would think more on voyage (and in that case, we can find a solution because this is obviously a bug :P) Esteban > > > > > > Ing. Pablo Digonzelli > Software Solutions > IP-Solutiones SRL > Metrotec SRL > 25 de Mayo 521 > San Miguel de TucumÃ¡n > Email: pdigonzelli(a)softsargentina.com > pdigonzelli(a)gmail.com > Cel: 5493815982714 > > ----- Mensaje original ----- > De: "Esteban Lorenzano" <estebanlm(a)gmail.com> > Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > CC: stephan(a)stack.nl, "Torsten Bergmann" <astares(a)gmx.de>, hilaire(a)drgeo.eu > Enviados: Martes, 18 de Agosto 2015 12:45:05 > Asunto: ***UNCHECKED*** Re: [Pharo-users] [ANN] Magma 1.5 > >> On 18 Aug 2015, at 17:20, Pablo R. Digonzelli <pdigonzelli(a)gmail.com> wrote: >> >> I can colaborate. I do not know if i have the time and technical skills to do it alone, but for shure i can colaborate. >> I think magma will be a very interesting option for object persistence in pharo. >> I am currently working with garage and glorp and i suffers the innecesary complexity and other bad things thet persistence layer introduce in developing pharo apps. > > have you checked voyage? (to work with a MongoDB)â¦ it will avoid all the pain of using a relational database. > > Esteban > > ps: But yes, I do believe having magma would be cool too. > >> >> Pharo >> >> >> Ing. Pablo Digonzelli >> Software Solutions >> IP-Solutiones SRL >> Metrotec SRL >> 25 de Mayo 521 >> San Miguel de TucumÃ¡n >> Email: pdigonzelli(a)softsargentina.com >> pdigonzelli(a)gmail.com >> Cel: 5493815982714 >> >> ----- Mensaje original ----- >> De: "Torsten Bergmann" <astares(a)gmx.de> >> Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> >> CC: stephan(a)stack.nl, stepharo(a)free.fr, hilaire(a)drgeo.eu, "Pablo Digonzelli" <pdigonzelli(a)gmail.com> >> Enviados: Martes, 18 de Agosto 2015 10:26:44 >> Asunto: Fwd: [ANN] Magma 1.5 >> >> Stephan Eggermont wrote: >>> It is possible, and it needs someone who can deal with low-level >>> details. Magma has its own mailing list. Chris has repeatedly said he'd >>> be willing to help out, but is not willing to be the Pharo port maintainer. >> >> I asked Chris directly and you can find his answer here on the magma list: >> >> http://lists.squeakfoundation.org/pipermail/magma/2015-August/001955.html >> >> As ever it requires someone to move this forward to make it happen. >> But as there was an initiative with Magma 1.3 for Pharo 1.3 already it does not >> seem impossible. >> >> Also - as Stef already pointed out - community services like CI could be used >> to maintain it once an initial up to date port was done. >> >> Bye >> T. >> >

Aug. 18, 2015

Re: [Pharo-users] ***UNCHECKED*** Re: [ANN] Magma 1.5

by Pablo R. Digonzelli

Yes I checkesd. It is by far better approach to pharo and I like it very much. The problem i found was when i stress mongo, it lost some transactions (i.e 10000 rewrites lost about 80 or more don't remember exactly) . In bussiness apps i cannot take that risk. Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 San Miguel de TucumÃ¡n Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Esteban Lorenzano" <estebanlm(a)gmail.com> Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> CC: stephan(a)stack.nl, "Torsten Bergmann" <astares(a)gmx.de>, hilaire(a)drgeo.eu Enviados: Martes, 18 de Agosto 2015 12:45:05 Asunto: ***UNCHECKED*** Re: [Pharo-users] [ANN] Magma 1.5 > On 18 Aug 2015, at 17:20, Pablo R. Digonzelli <pdigonzelli(a)gmail.com> wrote: > > I can colaborate. I do not know if i have the time and technical skills to do it alone, but for shure i can colaborate. > I think magma will be a very interesting option for object persistence in pharo. > I am currently working with garage and glorp and i suffers the innecesary complexity and other bad things thet persistence layer introduce in developing pharo apps. have you checked voyage? (to work with a MongoDB)â¦ it will avoid all the pain of using a relational database. Esteban ps: But yes, I do believe having magma would be cool too. > > Pharo > > > Ing. Pablo Digonzelli > Software Solutions > IP-Solutiones SRL > Metrotec SRL > 25 de Mayo 521 > San Miguel de TucumÃ¡n > Email: pdigonzelli(a)softsargentina.com > pdigonzelli(a)gmail.com > Cel: 5493815982714 > > ----- Mensaje original ----- > De: "Torsten Bergmann" <astares(a)gmx.de> > Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > CC: stephan(a)stack.nl, stepharo(a)free.fr, hilaire(a)drgeo.eu, "Pablo Digonzelli" <pdigonzelli(a)gmail.com> > Enviados: Martes, 18 de Agosto 2015 10:26:44 > Asunto: Fwd: [ANN] Magma 1.5 > > Stephan Eggermont wrote: >> It is possible, and it needs someone who can deal with low-level >> details. Magma has its own mailing list. Chris has repeatedly said he'd >> be willing to help out, but is not willing to be the Pharo port maintainer. > > I asked Chris directly and you can find his answer here on the magma list: > > http://lists.squeakfoundation.org/pipermail/magma/2015-August/001955.html > > As ever it requires someone to move this forward to make it happen. > But as there was an initiative with Magma 1.3 for Pharo 1.3 already it does not > seem impossible. > > Also - as Stef already pointed out - community services like CI could be used > to maintain it once an initial up to date port was done. > > Bye > T. >

Aug. 18, 2015

Re: [Pharo-users] [ANN] Magma 1.5

by Esteban Lorenzano

> On 18 Aug 2015, at 17:20, Pablo R. Digonzelli <pdigonzelli(a)gmail.com> wrote: > > I can colaborate. I do not know if i have the time and technical skills to do it alone, but for shure i can colaborate. > I think magma will be a very interesting option for object persistence in pharo. > I am currently working with garage and glorp and i suffers the innecesary complexity and other bad things thet persistence layer introduce in developing pharo apps. have you checked voyage? (to work with a MongoDB)â¦ it will avoid all the pain of using a relational database. Esteban ps: But yes, I do believe having magma would be cool too. > > Pharo > > > Ing. Pablo Digonzelli > Software Solutions > IP-Solutiones SRL > Metrotec SRL > 25 de Mayo 521 > San Miguel de TucumÃ¡n > Email: pdigonzelli(a)softsargentina.com > pdigonzelli(a)gmail.com > Cel: 5493815982714 > > ----- Mensaje original ----- > De: "Torsten Bergmann" <astares(a)gmx.de> > Para: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > CC: stephan(a)stack.nl, stepharo(a)free.fr, hilaire(a)drgeo.eu, "Pablo Digonzelli" <pdigonzelli(a)gmail.com> > Enviados: Martes, 18 de Agosto 2015 10:26:44 > Asunto: Fwd: [ANN] Magma 1.5 > > Stephan Eggermont wrote: >> It is possible, and it needs someone who can deal with low-level >> details. Magma has its own mailing list. Chris has repeatedly said he'd >> be willing to help out, but is not willing to be the Pharo port maintainer. > > I asked Chris directly and you can find his answer here on the magma list: > > http://lists.squeakfoundation.org/pipermail/magma/2015-August/001955.html > > As ever it requires someone to move this forward to make it happen. > But as there was an initiative with Magma 1.3 for Pharo 1.3 already it does not > seem impossible. > > Also - as Stef already pointed out - community services like CI could be used > to maintain it once an initial up to date port was done. > > Bye > T. >

Aug. 18, 2015