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

Re: [Pharo-dev] Improving Ghost proxies

by Eliot Miranda

On Mon, Feb 15, 2016 at 2:15 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > I think it is important to get single proxy framework for Pharo. It should > provide required integration support for our tools. > > I want push Ghost in that direction. Debuggers and inspectors should work > correctly with proxies which based on Ghost. > > Now Ghost is stored in CAR team repository. Should we move it to Pharo? > > P.S. Ghost has one failed tests due to Spur problem 17536 > <https://pharo.fogbugz.com/f/cases/17536/VM-Crash-when-adding-an-iVar-to-a-s…> > . > Thanks Denis. I can reproduce this and am taking a look at this today. Best regards, > Denis > _,,,^..^,,,_ best, Eliot

Feb. 15, 2016

Re: [Pharo-dev] Problems? with MC browser?Process?

by Volkert

Cool. A new research field for testing: vdt - video driven testing .... sorry, could not resist ;-) i look forward to see the results .... registered for the course today. Volkert On 15.02.2016 18:23, Aliaksei Syrel wrote: > > Now I cannot work with a system in that state. > To produce a videos of 8 min I lost more than 3 hours. Not fun. > > > I see you take a lot of videos and you catch lots of bugs during > filming. Which means that video can be used as helpers to reproduce > bugs you catch. Why would not you publish those videos on mail list? > > On Mon, Feb 15, 2016 at 5:19 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > >> >> 2016-02-15 17:09 GMT+01:00 stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>>: >> >> Hi >> >> Today I got several times problems with the refresh of the >> screen (see attachement) >> and I could >> not produce the videos I wanted. >> I wonder if there is not a problem with the processes around >> MC browser. >> I do not see what else it would be. >> >> Now I cannot work so I'm stuck with the Mooc videos >> production so I will >> try to use older images but this is slowing me down. >> >> Stef >> >> >> Most probable this happens when multiple Morphic UI-processes are >> active. >> (caused by the debugger ?) > > Exactly the case. > But the debugger was closed because I was about to save the code > once implemented in the debugger. > Now I cannot work with a system in that state. > To produce a videos of 8 min I lost more than 3 hours. Not fun. > > Stef > >> > >

Feb. 15, 2016

Re: [Pharo-dev] Problems? with MC browser?Process?

by Aliaksei Syrel

> > Now I cannot work with a system in that state. > To produce a videos of 8 min I lost more than 3 hours. Not fun. I see you take a lot of videos and you catch lots of bugs during filming. Which means that video can be used as helpers to reproduce bugs you catch. Why would not you publish those videos on mail list? On Mon, Feb 15, 2016 at 5:19 PM, stepharo <stepharo(a)free.fr> wrote: > > > 2016-02-15 17:09 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> Hi >> >> Today I got several times problems with the refresh of the screen (see >> attachement) >> and I could >> not produce the videos I wanted. >> I wonder if there is not a problem with the processes around MC browser. >> I do not see what else it would be. >> >> Now I cannot work so I'm stuck with the Mooc videos production so I will >> try to use older images but this is slowing me down. >> >> Stef >> > > Most probable this happens when multiple Morphic UI-processes are active. > (caused by the debugger ?) > > > Exactly the case. > But the debugger was closed because I was about to save the code once > implemented in the debugger. > Now I cannot work with a system in that state. > To produce a videos of 8 min I lost more than 3 hours. Not fun. > > Stef > > > > >

Feb. 15, 2016

Re: [Pharo-dev] Improving Ghost proxies

by Mariano Martinez Peck

On Mon, Feb 15, 2016 at 1:22 PM, stepharo <stepharo(a)free.fr> wrote: > our policy is > Any package used in the core of Pharo should be saved under Pharo. > > Stef, I think that's not correct. It might be the vision, but it's not the current state. QuallityAssistant, GT-Tools, etc are all examples of tools that come inside Pharo and are NOT under Pharo Shub team. Unless by "in the core of Pharo" you mean something smaller than current Pharo image? Cheers, > Stef > > Le 15/2/16 11:15, Denis Kudriashov a Ã©crit : > > Hello. > > I think it is important to get single proxy framework for Pharo. It should > provide required integration support for our tools. > > I want push Ghost in that direction. Debuggers and inspectors should work > correctly with proxies which based on Ghost. > > Now Ghost is stored in CAR team repository. Should we move it to Pharo? > > P.S. Ghost has one failed tests due to Spur problem 17536 > <https://pharo.fogbugz.com/f/cases/17536/VM-Crash-when-adding-an-iVar-to-a-s…> > . > > Best regards, > Denis > > > -- Mariano http://marianopeck.wordpress.com

Feb. 15, 2016

Status Updates for Hot New Libraries?

by Sean P. DeNigris

Can we get a general idea of progress on all the cool new core libraries/features? How production-ready are the following? What is the approximate timeline for that to happen? - TxText - SDL - Rubric - Bloc - Brick Did I miss any? It is unimaginably exciting to have these available. For me, SDL, Tx, and Bloc will be game changers. They will empower me to restart many exciting project I postponed after getting bogged down in Morphic and friends! Thanks :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Status-Updates-for-Hot-New-Libraries-tp4877653.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 15, 2016

Re: [Pharo-dev] Improving Ghost proxies

by stepharo

our policy is Any package used in the core of Pharo should be saved under Pharo. Stef Le 15/2/16 11:15, Denis Kudriashov a Ã©crit : > Hello. > > I think it is important to get single proxy framework for Pharo. It > should provide required integration support for our tools. > > I want push Ghost in that direction. Debuggers and inspectors should > work correctly with proxies which based on Ghost. > > Now Ghost is stored in CAR team repository. Should we move it to Pharo? > > P.S. Ghost has one failed tests due to Spur problem 17536 > <https://pharo.fogbugz.com/f/cases/17536/VM-Crash-when-adding-an-iVar-to-a-s…>. > > Best regards, > Denis

Feb. 15, 2016

Re: [Pharo-dev] Improving Ghost proxies

by stepharo

Le 15/2/16 14:10, Mariano Martinez Peck a Ã©crit : > > > On Mon, Feb 15, 2016 at 7:15 AM, Denis Kudriashov > <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > Hello. > > I think it is important to get single proxy framework for Pharo. > It should provide required integration support for our tools. > > I want push Ghost in that direction. Debuggers and inspectors > should work correctly with proxies which based on Ghost. > > > Hi Denis, > > I welcome you push on Ghost. The original source of Ghost was in SS3 > and then, the CAR team move it to Shub and hence why it is there. I > THINK they did not do many changes from the "upstream" project, so it > should be safe to take that one. I guess you should ask Luc Fabrese > about that. > > Debugging, inspecting, etc was some of the problems that Ghost did > solve. I was able to do all that. And you were able to enable/disabled > debugging capabilities dynamically. > > What I really really really recommend you is that before doing > anything with Ghost, please read the whole journal paper as there is a > lot of discussion, possibilities, explanations of why we took path X, > etc etc: > > https://hal.inria.fr/hal-01081236/file/Mart14z-Ghost-Final.pdf > > Now Ghost is stored in CAR team repository. Should we move it to > Pharo? > > > I know that is is subjective, but from my latest experience with git, > if I were to make the move of a repository (which requires some > effort) I would do it to github. No core package of Pharo should be managed with git. We will move all together and not pieces by pieces. > Finally, let me say something.... what I got from my Ghost proxies > experience is that Ghost could serve as a proxy library for "common" > usage. The code of Ghost is very very little. What is most important > is the idea, not the code. This is why, many of the people that got > interested in using Ghost for a project X, they ended up "forking" the > original Ghost code and adapt it. So...while Ghost can be used and > extended for different purposes, I think it's not bad either that > someone forks it and adjusts it for his needs. > > > P.S. Ghost has one failed tests due to Spur problem 17536 > <https://pharo.fogbugz.com/f/cases/17536/VM-Crash-when-adding-an-iVar-to-a-s…>. > > Best regards, > Denis > > > > > -- > Mariano > http://marianopeck.wordpress.com

Feb. 15, 2016

Re: [Pharo-dev] Problems? with MC browser?Process?

by stepharo

> > 2016-02-15 17:09 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi > > Today I got several times problems with the refresh of the screen > (see attachement) > and I could > not produce the videos I wanted. > I wonder if there is not a problem with the processes around MC > browser. > I do not see what else it would be. > > Now I cannot work so I'm stuck with the Mooc videos production so > I will > try to use older images but this is slowing me down. > > Stef > > > Most probable this happens when multiple Morphic UI-processes are active. > (caused by the debugger ?) Exactly the case. But the debugger was closed because I was about to save the code once implemented in the debugger. Now I cannot work with a system in that state. To produce a videos of 8 min I lost more than 3 hours. Not fun. Stef >

Feb. 15, 2016

Re: [Pharo-dev] Proxy DNU vs CannotInterpret. (Ghost related)

by stepharo

Hi eliot I think that the difference is really what guillermo explained. With DNU you can only trapped methods that are not defined while if you want to implement true proxy you do not want holes. I think that also with DNU proxy there were some limits realyed to classe but I do not remember. Stef Le 15/2/16 16:06, Eliot Miranda a Ã©crit : > Hi Denis, > > On Feb 15, 2016, at 6:53 AM, Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>> wrote: > >> >> 2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck >> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>>: >> >> As far as I can remember (this was about 4 years ago) The use of >> #cannotInterpret: was the only way to be able to intercept >> everything without breaking the system. Subclassing from >> ProtoObject make your proxy to understand some messages. >> Subclassing from nil was technically possible, but I found out >> the system would simply crash as it didn't know at all how to >> handle other subclasses of nil. Even with the debugging support I >> added as you can read in the paper. Maybe things have changed. >> >> If subclassing from nil does not break the system and you can >> still inspect, debug proxies, then sure, you can give a try to >> Ghost using #dnu rather than #cannotInterpret:. In fact, I would >> like to have a dnu-based approeach that is as reliable as it was >> #cannotInterpret: in the sense of how much I can intercept. With >> #cannotInterpret I could trap EVERYTHING (everything but #==) and >> then decide what to do. Subclassing from nil would get you there >> too if you make it work. >> >> >> Actually I already implemented it many yeas ago for Mocketry. But >> subclassing from nil works correctly only in VW. I got problems when >> porting it to Squeak (at that time). >> Now I want to give DNU another chance. It will simplify logic very >> much. It will remove strange hierarchy of proxies which is needed for >> trick but raises many questions. > > There is no reason in principle why Squeak/Pharo should not be able to > use MNU proxies in the same way as VW. The key is to use the mirror > primitives in basic inspectors that are used to inspect the proxies > and in the debugger to simulate code. Without the mirror primitives > many sends to a proxy are likely to create an infinite recursion. As > yet we don't have a robust low space handler that catches infinite > recursion so debugging can be frustrating. But we can work on this. > IMO the MNU approach is to be preferred.

Feb. 15, 2016

Re: [Pharo-dev] More tests for new frameworks

by stepharo

I agree. Now what I would like is the community to push and shout for tests. The question that we can ask ourselves is how can we push more tests. Stef Le 15/2/16 14:15, Mariano Martinez Peck a Ã©crit : > Stef, I know it's easy to speak with Monday's newspaper, but I > wouldn't accept projects for Pharo that do not have tests. I do not > pretend X number of percentage, but at least some tests. Otherwise, > YOU will have to pay the costs. > > Max: we already have a test coverage tool already in the image since > years. Open Test Runner -> Run Coverage. > > Cheers, > > > On Sun, Feb 14, 2016 at 9:14 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Thanks > I do not have the cycle for that but I would love to get some > feedback on if this is possible to run > and for which packages. > > Stef > > Le 14/2/16 04:09, Alejandro Infante a Ã©crit : > > If you plan to add it to an automatic CI Job with Hapao, I > would recommend to load the following group of Spy2: > âââââ > (ConfigurationOfSpy2 project version: #stable) load: #HapaoCore > âââââ > > This is going to load just the core of Spy and Hapao and will > not load Roassal, GT-Inspector and GT-Debugger extensions. > > Cheers, > Alejandro > > On Feb 13, 2016, at 6:39 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Yes I would even buy 20% coverage right now. > > Stef > > > Le 13/2/16 20:22, Max Leske a Ã©crit : > > How about enforcing coverage? I know that coverage > tests donât say anything about the quality of the test > cases but itâs (almost) always better to have some > tests than none. I wouldnât set the bar too high > either for coverage, maybe 60 or 70%. 100% is > unrealistic, but 60 to 70 should be achievable with a > couple of well written tests. > > Of course we would need a way to run coverage tests on > the test suite. Do we have a tool for coverage tests? > > On 13 Feb 2016, at 19:35, stepharo > <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > > Hi guys > > with damien cassou we had an interesting > discussion. Basically we are teaching tests and we > see that many Pharo subsystems are not really well > tested. I wonder how we can change this. For > example, we will have a new graphical core without > any tests > and this is sad because tests could be really good > to make sure that we will be able to move forward > in the future. > I would like to get tests for Ring. > > Stef > > > > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Feb. 15, 2016