- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Announcements & inter-thread communication

by stepharo

Thanks for your questions. My take is - I would minimize thread and fork. I have the feeling that some people forgot or never knew that when we fork a process we have to pay attention to sync points and race condition. - About Announcements - Ideally we would like to remove the changed:/update: and replace it by annoucements. Now it will take time because the widgets are not expecting Annoucements. Now to your point! "Now you might say that the programmer should know enough about the structure of their threaded code to wrap the action in as critical section, but Announcements are a DECOUPLING mechanism, and maybe a THIRD PARTY library subscribes to an Announcement that later someone else wraps in a fork, and no-one notices possible race conditions created." Yes!!! I like your ideas: " With this arrangement, a third party subscribed to someone else's announcement, that is quietly changed to be wrapped by forked thread, the third party's code now fails EARLY and OBVIOUS, rather than letting subtle race conditions occur at random times. " This Le 5/12/14 22:10, Ben Coman a Ã©crit : > _BACKGROUND_ > > In relation to... > https://pharo.fogbugz.com/default.asp?13182 > "Refactor MCFileRepositoryInspector >> versionSearchAccept:" > > I am reviewing... > https://pharo.fogbugz.com/default.asp?13007 > "Cannot integrate a slice with monticello (red square in the UI)" > > and in general considering how Monticello uses multiple threads to > allow you to type in the filter while its downloading info from the > remote repository (which would be good to have more of this sort thing). > > Looking back at build 30814 just prior to slice 13007 being integrated, > I notice that MCFileRepositoryInspector>>setRepository:workingCopy: [1] > forks and sends #refresh, which sends #changed: #packageList. > > and MCFileRepositoryInspector>>packageSearchAccept: [2] > also forks and sends #changed: #packageList > > So there were three threads (including UI [3]) modifying object state, > which was compounded by #packageList method doing a lot of work. > Issue 13007 worked around this by moving the work of #packageList out > to #packageListUpdate, and moved the #changed: sends from [1] & [2] > also out into #packageListUpdate (and wrapped in a #defer:). > > > _QUESTIONS_ > > Now I am considering doing the same for issue 13182 > #versionSearchAccept:, and considering Pharo's goal is to replace all > Dependents/#changed: mechanisms with Announcements. > > 1. So I am wondering if that would be a better direction to address this? > > Then I wonder about how Announcements interact with threads. I see > that SubscriptionRegistry>>deliver: #protect's the generation of > /interestedSubscriptions/, but the actual announcement delivery occurs > in the open, in AnnoucemenSubscription>>delvier:, > in the sender's thread. > > So for an example... > > action := [ :it | self inform: 'removing child'.]. > announcer on: RemoveChild do: action. > > /action/ might be executed from different concurrent threads. > > Now you might say that the programmer should know enough about the > structure of their threaded code to wrap the action in as critical > section, but Announcements are a DECOUPLING mechanism, and maybe a > THIRD PARTY library subscribes to an Announcement that later someone > else wraps in a fork, and no-one notices possible race conditions > created. > > 2. So, is there something reasonable we can do to make the > common/easier/safer single-threaded case the default, and make people > work a bit harder to shoot themselves in the foot with multiple threads? > > We could introduce Announcer>>onOtherThread:do: > with the purpose of making use of inter-thread announcements more > explicit in a self documenting way. > > Announcements accidentally passed between threads to Announcer>>on:do: > would generate an exception advising "use #onOtherThread:do: " > with the reasonable expectation that use of #onOtherThread:do: > would follow the pattern... > > announcer onOtherThread: RemoveChild do: [ :it | > myMutex critical: [ self inform: 'removing child' ]. > ]. > > With this arrangement, a third party subscribed to someone else's > announcement, that is quietly changed to be wrapped by forked thread, > the third party's code now fails EARLY and OBVIOUS, rather than > letting subtle race conditions occur at random times. > > > _PROPOSED IMPLEMENTATION_ > > "------------------" > > Announcer>>subscribe: anAnnouncementClass do: aValuable > ^ registry add: ( > AnnouncementSubscription new > announcer: self; > process: Processor activeProcess > announcementClass: anAnnouncementClass; > valuable: aValuable) > "------------------" > > AnnouncementSubscription>>deliver: anAnnouncement > process ~= Processor activeProcess ifTrue: [ > self error: [ 'Cross thread announcements should subscribe > using #onOtherThread:do: ' ]. > ^ (self handlesAnnouncement: anAnnouncement ) ifTrue: [ > [action cull: anAnnouncement cull: announcer] > on: UnhandledError fork: [:ex | ex pass ]] > "------------------" > > Announcer>>threadedSubscribe: anAnnouncementClass do: aValuable > ^ registry add: ( > ThreadedAnnouncementSubscription new > announcer: self; > process: Processor activeProcess > announcementClass: anAnnouncementClass; > valuable: aValuable) > "------------------" > > where ThreadedAnnouncementSubscription essentially functions the same > as the existing AnnoucementSubscription . > > > >

Dec. 8, 2014

Re: [Pharo-dev] RBSmalllintContext>>primitiveComputerLiterals

by stepharo

Le 5/12/14 08:40, Ben Coman a Ã©crit : > > I just noticed RBSmalllintContext>>primitiveComputerLiterals > doesn't seem to follow the typical pattern for that naming convention. > > Without digging to really understand it, I just wondered if it maybe > should be called #computeLiteralsForPrimitive, > or #basicComputerLiterals, or something else... basic > > cheers -ben > >

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by stepharo

Le 8/12/14 05:43, stepharo a Ã©crit : > Hi doru > > I would like to have playground be named playground and that we keep > "workspace" but I would like to change the name to "SimpleNoteEditor". Why because this is always good to have simple tools to read from? (I'm not talking about the current workspace implementation but the new one). I would like even try to learn something from Playground implementation because the tools is more advanced while I'm not afraid to learn from a simple tool. > I do not like the idea that we are all forced to use one single tools. > We are adults. > > Stef > >> Hi, >> >> As you might see, the GTPlayground is called playground not >> workspace. The main reason for this is that workspace implies the >> place where work is done, and work is typically associated with >> creating code. >> >> This is not the intention of the workspace. >> >> Workspace also comes with a history that is associated with actual >> implementations. While the current GTPlayground might appear to be >> similar to the workspace, I think the way you can use the latter >> produces a significant shift. >> >> Furthermore, I think the term playground is more inline with the idea >> of "playing with live objects". And, in the future, the >> implementation will likely evolve towards even more liveliness. >> >> It is for this reason that I would prefer that the World menu item >> gets renamed to Playground. >> >> What do you think? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" >

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by stepharo

+1 And there is plenty of blog post to turn them into chapters. If everything we produce would have this documentation quality I would not be worried. Le 8/12/14 05:33, Sven Van Caekenberghe a Ã©crit : > More documentation is always better, but you can hardly accuse Doru from trying, he is making an excellent effort in explaining what he does and why, this is a lot of work, and I appreciate it very much. Note that he is also trying to convince others of alternative/new/experimental ideas, which is even harder. > > And apart from that, he (and his team) are not just talking, they write actual working code and make it available. Of course they get all sorts of feedback, that is why they do it, but please, please consider the amount of work and determination it costs to make all this real/useable and not just vapourware ! > > I have the utmost respect for what they are doing and how they are doing it. > > You (and other users) have a choice: you can keep using Pharo 3 and the tools there instead of going along with the development branch. Pharo 3 is meant for stable production use, it matches most of the current publications. > > There is pharo-users(a)lists.pharo.org for normal beginner discussions, most users should ask questions there, not the other way around as it is today. I read both and try to help anyone the best I can. > > Sven > >> On 08 Dec 2014, at 13:56, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> "But, those tools are already added. And they are documented on the humane-assessment.com blog, and this can serve as a strong basis for a more official documentation." >> >> my issue is not "when" but "whether" . If you want to wait out the release of Pharo 4 to make official documentation, thats fine by me . I take late documentation over no documentation, any day. >> >> The problem I see with Pharo and one factor I feel it may even lead to the demise of Pharo as a project is that we see new and very exciting sfuff added to Pharo like your tools, but the documentation part is lackaster to say the least. The real problem comes when the original author decides to abandon or not further develop his tools it becomes extremely difficult for new people to come in and contribute. The very fact that now we replace the old workspace with a new tool is the testament to this problem. I think the situation would be dramatically different if Worskpace was fully documented, both at the user level and developer level. Its afterall an extremely important tool for Pharo. If that was the case we would have seen a natural evolution of workspace which would have made Playground far less needed. >> >> So its not that I disagree just with you I disagree with the general management of Pharo that follows the mentality "let the new features in and we worry about the documentation later on". No , no and NO! >> >> I was recently asked by a newcomer to Pharo being a python developer himself whether he should invest in Pharo . He wanted my opinion because I have experience both in python and pharo . I was not suprised to find out that he struggled with the documentation and he was really reluctant to give Pharo a serious try. He loved the features and all that but his learning was a much bigger pain than his experience with python and other programming languages. I ended up recommending him to ask more question here in the mailing list and he replied he did not feel comfortable asking question that for him were "stupid". Can I blame him ? Of course not. He was not aware of many of the blog posts and other source of documentation that are not "official". >> >> Dont know who that person is and how important as a member would become for the Pharo community but I can clearly see his problems being common to anyone or almost anyone introduced to Pharo unless that person comes already with a Smalltalk background. >> >> What I do know is Pharo needs new people to come in and take it further and in order to do that we need to build a Pharo that is as inviting to newcomers as our abilities permits us to. Putting documentation as a second priority is a recipe to disaster. >> >> >> >> >> >> >> > >

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by stepharo

Hi doru I would like to have playground be named playground and that we keep "workspace" but I would like to change the name to "SimpleNoteEditor". I do not like the idea that we are all forced to use one single tools. We are adults. Stef > Hi, > > As you might see, the GTPlayground is called playground not workspace. > The main reason for this is that workspace implies the place where > work is done, and work is typically associated with creating code. > > This is not the intention of the workspace. > > Workspace also comes with a history that is associated with actual > implementations. While the current GTPlayground might appear to be > similar to the workspace, I think the way you can use the latter > produces a significant shift. > > Furthermore, I think the term playground is more inline with the idea > of "playing with live objects". And, in the future, the implementation > will likely evolve towards even more liveliness. > > It is for this reason that I would prefer that the World menu item > gets renamed to Playground. > > What do you think? > > Cheers, > Doru > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Dec. 8, 2014

Re: [Pharo-dev] From IRC: is glorp dead?

by stepharo

>> On 07 Dec 2014, at 17:59, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: >> >> GLORP-based applications is main source of income for me for last several yers. It works just now. And it definetely works in Ubuntu x64, if it's important. And also works fine in Windows. > Yes, I know, but sometimes it is a bit difficult to set things up, giving all the different platforms. > > Since this is a recurring question, I would be super if you could write a short article about your experiences. +1 Let me know if I can help. I gathered a lot of glorp material other the years but I never program with it. > > Another simple Glorp introduction is https://medium.com/@svenvc/reddit-st-in-10-cool-pharo-classes-1b5327ca0740 > >> 2014-12-07 18:31 GMT+03:00 Brad <bsselfridge(a)gmail.com>: >> No, it's not dead, just pretty sleepy. I've got it working with MySQL on an Ubuntu 14.04 32bit OS, but not yet on a 64bit OS. >> >> Once I get my 64bit OS working, I'm going to work on getting Glorp/DBXTalk working for real business activity. >> >> Look here for some resources http://dbxtalk.smallworks.eu >> >> Brad Selfridge >> 913-269-2385 >> >>> On Dec 7, 2014, at 8:25 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> From the IRC: >>> >>> LudicrousMango: Hi can anyone tell me is Glorp dead? I was trying to evaluate pharo as a replacement for an existing rails project, but I can't even find a way of connecting to my postgresql database. >>> LudicrousMango: can someone help point me in the right direction. The Enterprise book leaves the setup part of glorp blank. >>> LudicrousMango: and the glorp.org site has expired >>> maxleske: LudicrousMango: good question. Iâll forward it to the dev mailing list >>> >>> >>> Cheers, >>> Max >> > > >

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by Alexandre Bergel

I do not completely buy the documentation argument. It is not a big deal saying when you read âWorkspaceâ in a book, it is actually âPlaygroundâ. People even figure this out alone. The code browser mentioned in Pharo by example is fairly different from the one we have currently. It even has a different name! But people can sort this out very quickly. Letâs move on, without caring much about old books. New books are being written and more will come. Letâs focus on making the system better! Cheers, Alexandre > On Dec 8, 2014, at 10:29 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > First, I want to say that in this special case I tend to be in agreement with Torsten. Because I also see playground as an evolution of the good old workspace. Also, most documentation still refers to that area as âworkspaceâ and not âplaygroundââ¦ and honestly I still do not understand why is *fundamentally* different. Inspectors are also really different and nevertheless we are still calling them inspectorsâ¦ I suppose we can do the same with playground/workspace. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 8, 2014

Re: [Pharo-dev] untypeable key combination

by stepharo

Le 7/12/14 12:21, Nicolai Hess a Ã©crit : > We have a class KMUntypeableSingleKeyCombination > this is used for key kombinations with > tab > arrow > backspace .... > > This is useful for printing key kombinations like > Ctrl+TAB > > "space" does not use the KMUntypeableSingleKeyCombination class, therefore > a short cut like > Character space shift asKeyCombination > looks like > " Shift + " > > shouldn't space use this class? > And I find the name a little bit misleading, what is a untypeable key? > The key is typeable, otherwise we couldn't use it. > Renaming the class to KMUnprintableSingleKeyCombination > isn't better, because we can print this keycombination. > +1 > > nicolai >

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by Sven Van Caekenberghe

More documentation is always better, but you can hardly accuse Doru from trying, he is making an excellent effort in explaining what he does and why, this is a lot of work, and I appreciate it very much. Note that he is also trying to convince others of alternative/new/experimental ideas, which is even harder. And apart from that, he (and his team) are not just talking, they write actual working code and make it available. Of course they get all sorts of feedback, that is why they do it, but please, please consider the amount of work and determination it costs to make all this real/useable and not just vapourware ! I have the utmost respect for what they are doing and how they are doing it. You (and other users) have a choice: you can keep using Pharo 3 and the tools there instead of going along with the development branch. Pharo 3 is meant for stable production use, it matches most of the current publications. There is pharo-users(a)lists.pharo.org for normal beginner discussions, most users should ask questions there, not the other way around as it is today. I read both and try to help anyone the best I can. Sven > On 08 Dec 2014, at 13:56, kilon alios <kilon.alios(a)gmail.com> wrote: > > "But, those tools are already added. And they are documented on the humane-assessment.com blog, and this can serve as a strong basis for a more official documentation." > > my issue is not "when" but "whether" . If you want to wait out the release of Pharo 4 to make official documentation, thats fine by me . I take late documentation over no documentation, any day. > > The problem I see with Pharo and one factor I feel it may even lead to the demise of Pharo as a project is that we see new and very exciting sfuff added to Pharo like your tools, but the documentation part is lackaster to say the least. The real problem comes when the original author decides to abandon or not further develop his tools it becomes extremely difficult for new people to come in and contribute. The very fact that now we replace the old workspace with a new tool is the testament to this problem. I think the situation would be dramatically different if Worskpace was fully documented, both at the user level and developer level. Its afterall an extremely important tool for Pharo. If that was the case we would have seen a natural evolution of workspace which would have made Playground far less needed. > > So its not that I disagree just with you I disagree with the general management of Pharo that follows the mentality "let the new features in and we worry about the documentation later on". No , no and NO! > > I was recently asked by a newcomer to Pharo being a python developer himself whether he should invest in Pharo . He wanted my opinion because I have experience both in python and pharo . I was not suprised to find out that he struggled with the documentation and he was really reluctant to give Pharo a serious try. He loved the features and all that but his learning was a much bigger pain than his experience with python and other programming languages. I ended up recommending him to ask more question here in the mailing list and he replied he did not feel comfortable asking question that for him were "stupid". Can I blame him ? Of course not. He was not aware of many of the blog posts and other source of documentation that are not "official". > > Dont know who that person is and how important as a member would become for the Pharo community but I can clearly see his problems being common to anyone or almost anyone introduced to Pharo unless that person comes already with a Smalltalk background. > > What I do know is Pharo needs new people to come in and take it further and in order to do that we need to build a Pharo that is as inviting to newcomers as our abilities permits us to. Putting documentation as a second priority is a recipe to disaster. > > > > > > >

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by Esteban Lorenzano

Okâ¦ several things :) First, I want to say that in this special case I tend to be in agreement with Torsten. Because I also see playground as an evolution of the good old workspace. Also, most documentation still refers to that area as âworkspaceâ and not âplaygroundââ¦ and honestly I still do not understand why is *fundamentally* different. Inspectors are also really different and nevertheless we are still calling them inspectorsâ¦ I suppose we can do the same with playground/workspace. Second, while I understand people tend to react conservative to changes, please guys understand that to keep tools inside image forever just does not scales and then requirements like âok for adding, but please let the old tools tooâ can not be a path to follow. Of course we are not going to remove immediately, but certainly during next cycle one of both will fade away. It has to be like that because to maintain everything forever requires exponential resourcesâ¦ and we cannot do that. Third, documentation is important but hard to produce in a reliable way. Also, documentation style in pharo (or any smalltalk) is fundamentally different than documentation in other systems. We have a system and a culture that empowers system exploration and that is the way we need to improve things: more examples *in system* is better than written documentation (and we have several books now of written documentation, is just that some of them is outdated). And yes, we still need to improve a lot in that areaâ¦ but we are not in zero, quite the oppositeâ¦ anyway, we will never have the kind of documentation that other system hasâ¦ Finally, fourthâ¦ we as a community has this tendency of start talking of A and end talking of Z. Like this threadâ¦ this was a question about the name of a tool. Not a discussion about lack of documentation or a feedback thread. All concerns are super valid, but talking about them in the incorrect place are causing me (and I think several others) to miss the importance of all things. So: documentation is another thread, and feedback is another thread. I agree with both of you, but if you put it here it will be lost because they become invisible, cheers, Esteban > On 08 Dec 2014, at 10:55, Torsten Bergmann <astares(a)gmx.de> wrote: > > I would go the opposite direction and rename the "Playground" window to > "Workspace". > > Several reasons: > > 1. "Playground" reminds me too much on toyish things (and we had too much of this > in the past already, thats why Pharo was forked). The windows intention is to be > used for both: prototyping and serious stuff. > > 2. "Workspace" depicts the area where you usually work and this term is IMHO much much > better suited. It is also a common concept known not only in Smalltalk but also > other IDE's. > > 3. I do not understand where the significant shift is (that justifies a new name) as > we had similar tools already in the past. Basically it is a script space merged with > an inspector, so more an evolution instead of a revolution. > > (This does not mean that I'm not happy that the GT tools are now in and provide > such an easy to use extensibility!) > > 3. There is a "Workspace open" but no "Playground open" possibility. > > 4. Having two separate tools "Workspace" and "Playground" with nearly similar > goals (write scripts and inspect objects) would be confusing for newbees. > > Maybe we could set up a "community voting" somewhere. > > > > Other things I would like to see: > ================================= > A. Change to "double clicking" behavior instead of "single clicking" when diving > deeper into the iVars of objects. > > This would allow to use it as a normal inspector first without having > directly more and more panes opening to the right. > > Anytime I start with a script in the initial code pane it is moving away > when using "Do it and go" and clicking on my objects iVars in the right > list view. > > With a "double click" the user could decide hisself if he just wants to select > (single click to do any other menu item action) or dive deeper into the > object (double click). > > > B. Possibility to have splitters between the opened panes because sometimes the > area is not wide enough. > > C. When several windows are open the "playgrounds" can not be distinguished by > title in the world tool bar. > > Note that when I save a workspace contents the title of the workspace window > is changed to the *.ws file. > > D. Change the initial tab name to something more meaninful (related to C). > Or use a better timestamp representation as the current precision. As a human > I do not distinguish up to milliseconds when opening such a window. Maybe up to > seconds is enough. > > Using a tab is questionable by itself - we never have more than one on the > initial code pane... > > E. Easily saving in the cloud is nice - but I would ask the user before sending > it. This prevents wrong usage by accidentially clicking. > > Think of usage in a business scenario where you may work with confidential > data that would otherwise be posted on the web... > > > Thanks > T. > > > > > > > > >

Dec. 8, 2014