- Pharo-dev - lists.pharo.org

Re: [Pharo-project] 'self halt' safety net

by Mariano Martinez Peck

On Sat, Aug 4, 2012 at 4:11 AM, Ben Coman <btc(a)openinworld.com> wrote: > As probably many newbies do from time to time, I am learning the system > splattering 'self halt' around, and once again slipped one into the wrong > place where I should have used 'haltOnce' and had a massive number of > pre-debugger windows come up. I managed to get it back this time with the > user interrupt - but not always - and anyhow clearing so many debug windows > is a pain. So..... could 'self halt' be made to monitor the rate that the > halt windows appear, and when more than some value from one of them (say > five per second) it starts getting ignored and shows a dialog asking the > user if they really meant this and enable danger mode, or if they screwed > up and want to revert the method containing the suspect 'halt'. > > it would be nice :) > Advanced features > + button to close all debugger windows. > It is there in the meun: Windows -> Close all debuggers > + display the method showing the suspect 'self halt' > > Another thought, it would be useful to be able to see a list of 'self > halts' throughout the system and the timestamp of when they were insert, > and perhaps distinguish whether they were inserted by the user or came when > the package was loaded - and so providing more functionality than just > using the Finder to 'search source'. > > +9999 not only the halts but all the #flag: > Another thought, are there any plans for a "breakpoint" facility, so that > I don't dirty a package by only inserting 'self halt' to aid debugging. it already exists. Right click on a method -> Add breakpoint > The effect would be just the same as a 'self halt' and even be compiled in > to the bytecode as if it was but the source code remains pristine. This > could be represented by a symbol that could be dragged through a code > window to anywhere immediately following a statement separator. Perhaps > the statement separator itself gets special significance as a point that > could be activated as a debug point - and displayed using a big red font > when it is active. > > anyhow, just musing.... -ben > > -- Mariano http://marianopeck.wordpress.com

Aug. 4, 2012

Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?

by Janko MivÅ¡ek

Hi Dale, Dne 04. 08. 2012 07:31, piÅ¡e Dale Henrichs: > The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today. Just FYI, there is a Sport portability library and by using Sport's SpFilename you have an instantly portable file support over quite a dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 filesystem first .. Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Aug. 4, 2012

Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?

by StÃ©phane Ducasse

BTW we discussed about it yesterday and I proposed that we keep the FileDirectory package for compatibility even if we are in 2.0. Dale I imagine that it would solve your problem. Stef On Aug 4, 2012, at 8:54 AM, StÃ©phane Ducasse wrote: > Dale > > Can we use an old version of Metacello that we maintain? > Then we migrate when needed and this is ok. > > Stef > > >> | > What I'd _like_ to do for Metacello and Pharo-2.0 is to make the >> | > changes against the MetacelloPreview release, which I'm managing >> | > on github. >> | > >> | > The MetacelloPreview is aimed at an eventual 1.0 release of >> | > Metacello (hopefully in the fall). >> | > >> | > I would _like_ Metacello-Base to be included in the Pharo-2.0 base >> | > image, the sooner the better and I'm poised to pull the trigger on >> | > that, but the recent changes have crippled FileTree ... >> | > >> | yeah.. we talking about it all the time "how good it would be to have >> | metacello preloaded in image" :) >> | >> | > So until FileTree is functional again, I can't really do anything >> | > with Pharo-2.0... >> | > >> | > Hacking Metacello to get it running on Pharo-2.0 doesn't help _me_ >> | > move forward. >> | > >> | >> | You can tell how they could help, so they will (if they will still >> | want), leaving less work for you :) Of course, if you need help or >> | can >> | see where it can be useful. >> | But i know it is hard to coordinate & organize activities.. sometimes >> | harder than doing everything alone. :) >> >> The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today. >> >> | >> | > It is likely that I will have to redo whatever hacks that are done >> | > to get it running on Pharo-2.0 to be compatible with the rest of >> | > platforms that I am supporting and doing it right takes a little >> | > more effort ... >> | > >> | yes.. it is hard to keep up with moving target.. But i hope this is >> | for good of us all (FileSystem ,as to me, is no doubt much better >> | comparing to what we had before). >> >> Oh don't get me wrong, I agree with the overall goals ... I actually think that renaming FileDirectory to ObsoleteFileDirectory (and keeping the implementation) would be a good compromise ... I can easily switch class names for the short term which then buys me time for doing a proper rewrite ... >> >> | >> | > So if you are just going to hack around to get things running on >> | > Pharo-2.0 I guess I would have to say that I don't care what you >> | > do, because the hacks don't make my job any easier. >> | > >> | > Dale >> | > >> | >> | -- >> | Best regards, >> | Igor Stasenko. >> | _______________________________________________ >> | seaside mailing list >> | seaside(a)lists.squeakfoundation.org >> | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> | >> > >

Aug. 4, 2012

Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?

by StÃ©phane Ducasse

Dale Can we use an old version of Metacello that we maintain? Then we migrate when needed and this is ok. Stef > | > What I'd _like_ to do for Metacello and Pharo-2.0 is to make the > | > changes against the MetacelloPreview release, which I'm managing > | > on github. > | > > | > The MetacelloPreview is aimed at an eventual 1.0 release of > | > Metacello (hopefully in the fall). > | > > | > I would _like_ Metacello-Base to be included in the Pharo-2.0 base > | > image, the sooner the better and I'm poised to pull the trigger on > | > that, but the recent changes have crippled FileTree ... > | > > | yeah.. we talking about it all the time "how good it would be to have > | metacello preloaded in image" :) > | > | > So until FileTree is functional again, I can't really do anything > | > with Pharo-2.0... > | > > | > Hacking Metacello to get it running on Pharo-2.0 doesn't help _me_ > | > move forward. > | > > | > | You can tell how they could help, so they will (if they will still > | want), leaving less work for you :) Of course, if you need help or > | can > | see where it can be useful. > | But i know it is hard to coordinate & organize activities.. sometimes > | harder than doing everything alone. :) > > The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today. > > | > | > It is likely that I will have to redo whatever hacks that are done > | > to get it running on Pharo-2.0 to be compatible with the rest of > | > platforms that I am supporting and doing it right takes a little > | > more effort ... > | > > | yes.. it is hard to keep up with moving target.. But i hope this is > | for good of us all (FileSystem ,as to me, is no doubt much better > | comparing to what we had before). > > Oh don't get me wrong, I agree with the overall goals ... I actually think that renaming FileDirectory to ObsoleteFileDirectory (and keeping the implementation) would be a good compromise ... I can easily switch class names for the short term which then buys me time for doing a proper rewrite ... > > | > | > So if you are just going to hack around to get things running on > | > Pharo-2.0 I guess I would have to say that I don't care what you > | > do, because the hacks don't make my job any easier. > | > > | > Dale > | > > | > | -- > | Best regards, > | Igor Stasenko. > | _______________________________________________ > | seaside mailing list > | seaside(a)lists.squeakfoundation.org > | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > | >

Aug. 4, 2012

Re: [Pharo-project] What is the plan with Pharo changes?

by StÃ©phane Ducasse

On Aug 3, 2012, at 11:26 PM, Mariano Martinez Peck wrote: > Hi guys. PLEASE: I DON'T WANT TO START A WAR. > I am just concerned about Pharo and it's future. bright and shinny. > I am totally in favor of making progress even if it breaks compatibility. I am all in favor of having to spend time and effort in updating projects to use latest Pharo changes. > Today I faced a couple of problems with Metacello and Pier. Most problems were related to: You are telling to us that you loaded Pier in 20 excellent. > 1) SystemChangeNotifier -> SystemAnnouncer > 2) FileDirectory -> FileSystem Is it not a dream that comes true? > so...after a couple of fixes, I was able to make them both to work in last Pharo version. So, DO NOT GO OFFTOPIC please. > My question is, how can we make sure that we are not all trying to updated existing packages? yes this is a good question. > I mean, I have updated Metacello (a part of it) and Pier. So what do we do? publish a new configuration of the packages so that the new versions get loaded. This is the purpose of configurations > where do I commit without affecting all those not using Pharo 2.0 ? how can others take advantage of it? Use configurations. > > thanks guys. > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 4, 2012

Re: [Pharo-project] 'self halt' safety net

by Ben Coman

Igor Stasenko wrote: > On 4 August 2012 04:11, Ben Coman <btc(a)openinworld.com> wrote: > >> As probably many newbies do from time to time, I am learning the system >> splattering 'self halt' around, and once again slipped one into the wrong >> place where I should have used 'haltOnce' and had a massive number of >> pre-debugger windows come up. I managed to get it back this time with the >> user interrupt - but not always - and anyhow clearing so many debug windows >> is a pain. So..... could 'self halt' be made to monitor the rate that the >> halt windows appear, and when more than some value from one of them (say >> five per second) it starts getting ignored and shows a dialog asking the >> user if they really meant this and enable danger mode, or if they screwed up >> and want to revert the method containing the suspect 'halt'. >> >> Advanced features >> + button to close all debugger windows. >> > > i think there already such.. ( Camillo did that today before my eyes, > with the shortcut only he knows ;) > > >> + display the method showing the suspect 'self halt' >> >> Another thought, it would be useful to be able to see a list of 'self halts' >> throughout the system and the timestamp of when they were insert, and >> perhaps distinguish whether they were inserted by the user or came when the >> package was loaded - and so providing more functionality than just using the >> Finder to 'search source'. >> >> > IMO, there should be no senders of #halt except from debugging purposes.. > of course if package doesn't overrides it for own purposes.. (but i > doubt that even if one needs that, it is good idea) > > As an extension to debugging, it is useful when trying to learn and understand any particular framework for which there is little documentation. But sometimes I forget where I put them all. >> Another thought, are there any plans for a "breakpoint" facility, so that I >> don't dirty a package by only inserting 'self halt' to aid debugging. The >> effect would be just the same as a 'self halt' and even be compiled in to >> the bytecode as if it was but the source code remains pristine. This could >> be represented by a symbol that could be dragged through a code window to >> anywhere immediately following a statement separator. Perhaps the statement >> separator itself gets special significance as a point that could be >> activated as a debug point - and displayed using a big red font when it is >> active. >> >> > > Opal... we need opal. so we can hack the method's bytecode without > need to recompile the method . > Also, there is other tools like method wrappers.. but they are not > come as part of pharo by default. > > > If we look from user's perspective (not machine perspective), apparently > it is pointless to throw so many messages at the user's face, because > he cannot deal with them > in meaningful manner at such rate. > So, i think there should be something like following: > - if exception requires a user interaction, we do show the popup, but > meanwhile remember the exception which initiated it. > - if there's next exception incoming and also asks UI manager to show > it to user, we queue it, > letting user to deal with first one.. (or we delay the popup , say 1 > each 5 seconds). > Perhaps the pre-debug window can display this queue - so that either the pre-debug window is a Singleton, or at most one pre-debug window for each source of "breakpoint". Then any massive amounts of "halts" will just scroll off-window and not block the UI when trying to fix the problem. > and finally, a queue should have some reasonable limit, after which we > stop queuing , because again, user certainly won't be willing to waste > his time dealing with 10000000 exceptions of same kind one by one. It > doesn't makes sense anyways. > > In such case we can just ignore halt and let program continue (but > increment some counter to show user how many of them are there). > If exception is different (an Error) then on queue overflow, i think > it should terminate the process with exception (but of course, special > care must be taken if process is UI process). > Of course making it too smart is pointless, because it is impossible > to predict whether it is good idea > to terminate process or letting it continue to run in case of exception. > But for that we can have settings and options, to tune that at user's > discretion, as well as default > settings on a per-exception class base. > > >> anyhow, just musing.... -ben >> >> > > i know by myself how annoying it can be (up to unresponsive image) > and i think most of us is facing such situation time to time (heh.. > just yesterday we had it with Camillo while hacking ocompletion > stuff). > i learned to be careful and avoid such situations.. but sometimes it > is hard and better tooling support will be helpful, no doubt. > > New users are not so good at being careful, and less frustrating if they don't get overrun. Thanks for your thoughts.

Aug. 4, 2012

Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?

by Dale Henrichs

----- Original Message ----- | From: "Igor Stasenko" <siguctua(a)gmail.com> | To: "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org> | Cc: metacello(a)googlegroups.com, "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> | Sent: Friday, August 3, 2012 9:52:18 PM | Subject: Re: [Seaside] Re: [Metacello] What is the plan with Pharo changes? | | On 4 August 2012 02:16, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > Mariano, | > | > What I'd _like_ to do for Metacello and Pharo-2.0 is to make the | > changes against the MetacelloPreview release, which I'm managing | > on github. | > | > The MetacelloPreview is aimed at an eventual 1.0 release of | > Metacello (hopefully in the fall). | > | > I would _like_ Metacello-Base to be included in the Pharo-2.0 base | > image, the sooner the better and I'm poised to pull the trigger on | > that, but the recent changes have crippled FileTree ... | > | yeah.. we talking about it all the time "how good it would be to have | metacello preloaded in image" :) | | > So until FileTree is functional again, I can't really do anything | > with Pharo-2.0... | > | > Hacking Metacello to get it running on Pharo-2.0 doesn't help _me_ | > move forward. | > | | You can tell how they could help, so they will (if they will still | want), leaving less work for you :) Of course, if you need help or | can | see where it can be useful. | But i know it is hard to coordinate & organize activities.. sometimes | harder than doing everything alone. :) The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today. | | > It is likely that I will have to redo whatever hacks that are done | > to get it running on Pharo-2.0 to be compatible with the rest of | > platforms that I am supporting and doing it right takes a little | > more effort ... | > | yes.. it is hard to keep up with moving target.. But i hope this is | for good of us all (FileSystem ,as to me, is no doubt much better | comparing to what we had before). Oh don't get me wrong, I agree with the overall goals ... I actually think that renaming FileDirectory to ObsoleteFileDirectory (and keeping the implementation) would be a good compromise ... I can easily switch class names for the short term which then buys me time for doing a proper rewrite ... | | > So if you are just going to hack around to get things running on | > Pharo-2.0 I guess I would have to say that I don't care what you | > do, because the hacks don't make my job any easier. | > | > Dale | > | | -- | Best regards, | Igor Stasenko. | _______________________________________________ | seaside mailing list | seaside(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |

Aug. 4, 2012

Re: [Pharo-project] Completion

by Igor Stasenko

The main issue as to me is not the logic how ocompletion works (i find it pretty ok btw), but paramount of mess in event handling. I don't mind having multiple kinds/styles of autocompletion in system (so users can choose to their taste).. but what i don't understand is why we need different shortcuts and different ui displaying completion list(s), spreading over multiple places in system. On 3 August 2012 22:19, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-08-03, at 22:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Please keep in mind that the reason for showing only the OCompletion list at first was speed. If you are using both at the same time, you might get a performance penalty. > > so far it works reasonably fast. > and looking at the code I see that the complete list is calculated each time anyway. > > not showing the complete list IMO renders the completion utterly useless. > > -- Best regards, Igor Stasenko.

Aug. 4, 2012

Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?

by Igor Stasenko

On 4 August 2012 02:16, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Mariano, > > What I'd _like_ to do for Metacello and Pharo-2.0 is to make the changes against the MetacelloPreview release, which I'm managing on github. > > The MetacelloPreview is aimed at an eventual 1.0 release of Metacello (hopefully in the fall). > > I would _like_ Metacello-Base to be included in the Pharo-2.0 base image, the sooner the better and I'm poised to pull the trigger on that, but the recent changes have crippled FileTree ... > yeah.. we talking about it all the time "how good it would be to have metacello preloaded in image" :) > So until FileTree is functional again, I can't really do anything with Pharo-2.0... > > Hacking Metacello to get it running on Pharo-2.0 doesn't help _me_ move forward. > You can tell how they could help, so they will (if they will still want), leaving less work for you :) Of course, if you need help or can see where it can be useful. But i know it is hard to coordinate & organize activities.. sometimes harder than doing everything alone. :) > It is likely that I will have to redo whatever hacks that are done to get it running on Pharo-2.0 to be compatible with the rest of platforms that I am supporting and doing it right takes a little more effort ... > yes.. it is hard to keep up with moving target.. But i hope this is for good of us all (FileSystem ,as to me, is no doubt much better comparing to what we had before). > So if you are just going to hack around to get things running on Pharo-2.0 I guess I would have to say that I don't care what you do, because the hacks don't make my job any easier. > > Dale > -- Best regards, Igor Stasenko.

Aug. 4, 2012

Re: [Pharo-project] 'self halt' safety net

by Igor Stasenko

On 4 August 2012 04:11, Ben Coman <btc(a)openinworld.com> wrote: > As probably many newbies do from time to time, I am learning the system > splattering 'self halt' around, and once again slipped one into the wrong > place where I should have used 'haltOnce' and had a massive number of > pre-debugger windows come up. I managed to get it back this time with the > user interrupt - but not always - and anyhow clearing so many debug windows > is a pain. So..... could 'self halt' be made to monitor the rate that the > halt windows appear, and when more than some value from one of them (say > five per second) it starts getting ignored and shows a dialog asking the > user if they really meant this and enable danger mode, or if they screwed up > and want to revert the method containing the suspect 'halt'. > > Advanced features > + button to close all debugger windows. i think there already such.. ( Camillo did that today before my eyes, with the shortcut only he knows ;) > + display the method showing the suspect 'self halt' > > Another thought, it would be useful to be able to see a list of 'self halts' > throughout the system and the timestamp of when they were insert, and > perhaps distinguish whether they were inserted by the user or came when the > package was loaded - and so providing more functionality than just using the > Finder to 'search source'. > IMO, there should be no senders of #halt except from debugging purposes.. of course if package doesn't overrides it for own purposes.. (but i doubt that even if one needs that, it is good idea) > Another thought, are there any plans for a "breakpoint" facility, so that I > don't dirty a package by only inserting 'self halt' to aid debugging. The > effect would be just the same as a 'self halt' and even be compiled in to > the bytecode as if it was but the source code remains pristine. This could > be represented by a symbol that could be dragged through a code window to > anywhere immediately following a statement separator. Perhaps the statement > separator itself gets special significance as a point that could be > activated as a debug point - and displayed using a big red font when it is > active. > Opal... we need opal. so we can hack the method's bytecode without need to recompile the method . Also, there is other tools like method wrappers.. but they are not come as part of pharo by default. If we look from user's perspective (not machine perspective), apparently it is pointless to throw so many messages at the user's face, because he cannot deal with them in meaningful manner at such rate. So, i think there should be something like following: - if exception requires a user interaction, we do show the popup, but meanwhile remember the exception which initiated it. - if there's next exception incoming and also asks UI manager to show it to user, we queue it, letting user to deal with first one.. (or we delay the popup , say 1 each 5 seconds). and finally, a queue should have some reasonable limit, after which we stop queuing , because again, user certainly won't be willing to waste his time dealing with 10000000 exceptions of same kind one by one. It doesn't makes sense anyways. In such case we can just ignore halt and let program continue (but increment some counter to show user how many of them are there). If exception is different (an Error) then on queue overflow, i think it should terminate the process with exception (but of course, special care must be taken if process is UI process). Of course making it too smart is pointless, because it is impossible to predict whether it is good idea to terminate process or letting it continue to run in case of exception. But for that we can have settings and options, to tune that at user's discretion, as well as default settings on a per-exception class base. > anyhow, just musing.... -ben > i know by myself how annoying it can be (up to unresponsive image) and i think most of us is facing such situation time to time (heh.. just yesterday we had it with Camillo while hacking ocompletion stuff). i learned to be careful and avoid such situations.. but sometimes it is hard and better tooling support will be helpful, no doubt. -- Best regards, Igor Stasenko.

Aug. 4, 2012