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

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

[Pharo-project] 'self halt' safety net

by Ben Coman

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. + 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'. 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. anyhow, just musing.... -ben

Aug. 4, 2012

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

by Dale Henrichs

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 ... 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. 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 ... 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 ----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr>, "Seaside - general discussion" | <seaside(a)lists.squeakfoundation.org>, metacello(a)googlegroups.com | Sent: Friday, August 3, 2012 2:26:08 PM | Subject: [Metacello] What is the plan with Pharo changes? | | Hi guys. PLEASE: I DON'T WANT TO START A WAR. | I am just concerned about Pharo and it's future. 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: | 1) SystemChangeNotifier -> SystemAnnouncer | 2) FileDirectory -> FileSystem | | | 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? I mean, I have updated Metacello (a part | of it) and Pier. So what do we do? where do I commit without | affecting all those not using Pharo 2.0 ? how can others take | advantage of it? | | | thanks guys. | | | -- | Mariano | http://marianopeck.wordpress.com | |

Aug. 4, 2012

[Pharo-project] using color tables with forms and bitblt?

by Lawson English

OK, I'm such a noob here, that I'm not quite sure how to ask my question... I have a "dwell file" -an array of values generated by a Mandelbrot Set application, one per pixel, with arbitrary values between 1 and xxxxxxxxxxx (currently less than 2 billion, and right now far less than 1,000,000)- and I would like to use them, suitably tweaked, as indices into a ColorMap. The ColorMap need not have 1,000,000 entries. No-one can see that many color differences in a Mandelbrot set anyway. I can generate an array of Color (ColorArray?) but I'm not sure how to use them to create the ColorMap, and I'm not sure how to use the ColorMap to speedily change what is drawn in the first place. Right now, I'm creating a color dictionary and drawing via: 1 to: 800 do: [:y| 1 to: 800 do: [:x| |i| i := x+ ((y-1) *800). aForm colorAt: x@y put:( myDictColors at: (myArray at: i )).] ]. where myDictColors is a dictionary whose keys are the dwells listed in the dwell array file and whose values are Color objects from my array of colors. Drawing the above takes about 1.5 seconds, which is a bit slow. I'd like realtime-ish updating as I play with colors in the palette. Can this be done, at least up to the 4096 color limit that BitBlt has for ColorMaps? If so, how? I've been trying to figure out the various classes and I'm stumped. Thanks -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all

Aug. 3, 2012

Re: [Pharo-project] about mirroring

by phil＠highoctane.be

I discussed with a quite large company and there is a definite possibility to have space there as well. I am back to business soon and will come with solid proposals. (on holidays now) 2012/8/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi guys > > I would like to raise this issue while this is calm and that the servers > are working. > What do we do to replicate our servers: > ss3 and smalltalkHub > > I asked nicolas and christophe to check because the original plan (I still > like it) > is to host SmalltalkHub servers on INRIA infrastructure and the plan was > to replicate it > in three nodes of the server rooms across the country. > > Now we could have a mirroring also between such server and the one hosted > by nicolas company. > I will start to migrate all my projects from Squeaksource. > > > Stef > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

Aug. 3, 2012