August 2012 - Pharo-dev - lists.pharo.org

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

by Ben Coman

Mariano Martinez Peck wrote: > On Sat, Aug 4, 2012 at 4:11 AM, Ben Coman <btc(a)openinworld.com> wrote: > > >> 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 > > > thanks Mariano. Very nice to know. That gets me half way there, however not being able to locate it arbitrarily in the method will be awkward (even though even though Smalltalk methods are typically short).

Aug. 4, 2012

[Pharo-project] Configuration Browser feedback

by Ben Coman

Just thinking that the second tab of the Configuration Browser being called "Untrusted" is a bit harsh and not really socially engaging. "Community" has a better feel to me. And perhaps not "Configurations" for the first tab either, since both tabs are configurations. Perhaps "Core" or "Supported" or "Vetted" or "Gold" or something similar. Also, what would be really fantastic would be some description of each configuration being displayed in a pane on the right hand side. There are A LOT of configurations listed there - which is great - but I don't feel inclined to go looking up every single one to see if they interest me. Sometimes what gets people interested in trying out new things is that it just catches their eye in casual browsing. I guess a pre-requisite of that would be the ConfigurationOf file containing such a description, as well as perhaps something on the back end server that caches those descriptions into one file. cheers -ben

Aug. 4, 2012

[Pharo-project] LaTeX formula in Smalltalk

by Hilaire Fernandes

Hello, Java has JLatex a self sufficient package to render latex formula. Is there any interest for a such think in Smalltalk? I guess most part of it could be portable. Thanks Hilaire

Aug. 4, 2012

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

by Esteban Lorenzano

Hi, On Aug 4, 2012, at 11:21 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi all. I am answering to all together: > > Stef: Yes, I imported and loaded the Pier of DBX website in Pharo 2.0 with seaside and magritte. With 5 minutes of opening debuggers and change things I was able to correctly make it work (at least, my app, I didn't run all tests to see). > > Dale: We don't want to just help you with "hacks", that why I send this email and several others, to see what others think so that can find better and non-hacky solutions. So, let's try to find good solutions: > > 1) does it help if we put back FildeDirectory and we remove it later ? so that you have time to update Metacello and that we can still use Metacello :) Ok, we could do as Dale proposed, reload the package adding prefix Obsolete... that will work just for a while, and I certainly prefer to help on the adaptation than reintroduce it... of course, maybe we should do that in the first instance and in this case it was possible (se below), but well... we already screw it, so, I prefer to do step forwards than backward (if possible). > 2) for the SystemChangeNotifier does it make sense to delegate to the closures? [ xx ] valueWithoutSystemNotifications. Or we add a #doSilently: and we add a MetacelloPharo20Platform that overrides the behavior. SystemChangeNotifier is a complete different situation than FileDirectory, and we removed it because the effort of keeping the system working having two different notification centers was eating all our time for make improvements. So, we (I myself) decided to unload it and stop waisting time on try to make the synchronization work... if you see the "before" and "after" (once we finish, that is not done yet) you will notice the clarity and simplicity gained. So... SystemChangeNotification is not going to go back, but an approach like Mariano proposed would work fine, since Metacello just uses the #doSilently stuff. Btw... this is internal from Pharo, and 99.99% of the packages around shouldn't even notice the difference. Of course, Metacello is in the 0.01% remaining :) > 3) as Janko said, what about improving/using Grease/Sport for this purpose? do they provide something for this? could this be added? I'm strongly against this option, because I think Metacello (base) should be part of Pharo Core (in fact I was planning to introduce it next days). If I need to load grease or sport, I certainly will banish Metacello from core... and I don't want to. Again, I prefer to spend time fixing Metacello to load on Pharo (and I maintain my offer of spending it, he). > 4) Should we integrate Metacello in the image with our changes until you have time and find a good solution that works everywhere? Maybe if we do 1) i > t is not very necessary. I want Metacello in core, so... this is probably a good idea. best, Esteban > > Thanks for considering this a friendly and positive thread. > > On Sat, Aug 4, 2012 at 9:16 AM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > 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 > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 4, 2012

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

by Mariano Martinez Peck

Hi all. I am answering to all together: Stef: Yes, I imported and loaded the Pier of DBX website in Pharo 2.0 with seaside and magritte. With 5 minutes of opening debuggers and change things I was able to correctly make it work (at least, my app, I didn't run all tests to see). Dale: We don't want to just help you with "hacks", that why I send this email and several others, to see what others think so that can find better and non-hacky solutions. So, let's try to find good solutions: 1) does it help if we put back FildeDirectory and we remove it later ? so that you have time to update Metacello and that we can still use Metacello :) 2) for the SystemChangeNotifier does it make sense to delegate to the closures? [ xx ] valueWithoutSystemNotifications. Or we add a #doSilently: and we add a MetacelloPharo20Platform that overrides the behavior. 3) as Janko said, what about improving/using Grease/Sport for this purpose? do they provide something for this? could this be added? 4) Should we integrate Metacello in the image with our changes until you have time and find a good solution that works everywhere? Maybe if we do 1) it is not very necessary. Thanks for considering this a friendly and positive thread. On Sat, Aug 4, 2012 at 9:16 AM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si>wrote: > 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 > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Mariano http://marianopeck.wordpress.com

Aug. 4, 2012

[Pharo-project] ScriptManager MNU #yellowButtonMenu

by Ben Coman

Using latest ConfigurationOfScriptManager-tbn.21, right clicking in the code window brings up a MNU #yellowButtonMenu. The same occurs with ScriptManager-Core-GuillermoPolito.15 listed in Pharo1.4 Configuration Browser. Given that this is one of the "trusted" configurations, should the issue be logged in the Pharo tracker, or elsewhere?

Aug. 4, 2012

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