- Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] Territorial Re-Licensing

by Johan Fabry

Dory, can your mail be put on the Pharo web page, the contributions part? It seems that with a bit of polishing it would fit in well there, and this way future discussions can point to that page. -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Sep 8, 2016, at 06:40, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Offray, > > I am sorry you feel down. > > The wording of Stef did appear strong. However, please keep in mind that email is a terrible medium for expressing and transmitting feelings. I would kindly ask you to reconsider the emails and focus on the content and you will see that the wording was not about the external project but about the decisions that relate to the licensing of Pharo itself. As Esteban and I clarified, Pharo is MIT and will remain MIT. There is a long history of why this is so and a huge amount of effort to make it clean MIT. To keep it clean we have to be aware of the implications of another kind of a license, and our clarifications were about how we, those that work on the main Pharo code, will not touch a GPL code and that this might have a counter productive impact on the originator of the code in question (due to a lack of engagement from other people). > > Please also keep in mind that we do not want to prevent people from choosing their own licenses. The decision of the license belongs exclusively to the creators of the code. We are only looking for the interests of the core of Pharo to make sure that you will continue to have whatever options you choose on top of it. And you will always be free to choose what you want for your projects. > > Just a note about other licenses you mentioned: in the context of Pharo, LGPL has the same effect as GPL given that there is no concept of binary reusability in our system. So, for that purpose, we also do not touch LGPL. > > A final point: when someone says that "we decided something a long time agoâ, it is easy to take it as a âthis is it, just take itâ, but that would be a bit unfair. A more fair alternative is to understand that time is scarce and sometimes we just do not have the available energy to provide all clarifications on demand right at that point. > > Please letâs focus on building things together, even if there are misunderstandings or seaming differences in opinion. We need everyoneâs energy. > > Cheers, > Doru > > >> On Sep 8, 2016, at 9:53 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >> >> Nice to know something good came out after taking all the heat. In my case I learn about licensing with the reasons behind and not "just take it!"... >> My sources of information, the main spec.st site, made my mistake about dual license a valid misinterpretation and even the idea that there are other non-viral licenses: LGPL, 3 clause BSD, public domain that can integrated in a MIT licensed project, with the rationale behind [1], seems a good thing to make explicit >> [1] http://etoileos.com/dev/licensing/ >> Kind of down though, after seeing how a community leader can go after other people who don't share his views/knowledge and is just trying to contribute, understand and be part of the community. Today would be a slow day for me in Smalltak... maybe is time to take a walk a leave it for a time. >> >> Cheers, >> >> Offray >> >> On 08/09/16 06:00, HernÃ¡n Morales Durand wrote: >>> >>> I consider GNU AGPL v3 a fair license choice which protects somehow authors. After some talks with friends today, I began to consider it useless for a niche community like Smalltalk *and* solo projects. I then read all your mails, many posts in other communities, and finally asked for advices. Conclusion: The ideal license option for me was not yet invented. >>> >>> Now about parasite behavior and easy living for freeloaders. >>> >>> - I doubt Smalltalkers are in position for doing anything valuable against parasites. GPL scares a niche community. All of us having MIT code published can be stealed and we have no legal options to defend our work/authorship. That should be addressed one day. >>> >>> - However, I would like one day to read people releasing software under whatever license they want and not to be pointed them. That's a matter of freedom. I feel we are far away from there. >>> >>> - I hope we can talk about interesting Territorial features, what do you need, what could be modeled better, etc. Licensing is boring, really. >>> >>> I re-licensed Territorial to MIT for the nice Pharo people, for the nice Smalltalkers, people who helped me here in mailing lists, or sending supportive private messages, and for cool users with nice intentions. >>> >>> HernÃ¡n >>> >>> PS: Updated User Manual: http://bit.ly/2c4RrCJ >>> >>> >>> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > > >

Sept. 8, 2016

Re: [Pharo-users] [ANN] Territorial Re-Licensing

by PBKResearch

Well did he? All I saw was an attempt to justify what he had said, in terms of the difficult history etc. Forceful argument is fine, but a personal attack like the one Offray quoted is unforgiveable. It could be put to bed if Stef would just say âsorryâ for that. But Iâm not holding my breath. Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Dimitris Chloupis Sent: 08 September 2016 13:18 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] [ANN] Territorial Re-Licensing well he did apologize

Sept. 8, 2016

Re: [Pharo-users] SpecBooklet: Strange behavior of ProtocolBrowser

by Johan Fabry

Thanks Stef ! There will be a new chapter for you to review soon ;-) -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Sep 8, 2016, at 04:39, stepharo <stepharo(a)free.fr> wrote: > > Johan > > > let me know if there is anything that I should do. > > > Stef >

Sept. 8, 2016

Re: [Pharo-users] SpecBooklet: Strange behavior of ProtocolBrowser

by Matteo

thanks Jhoan for the explanation! Do you know some technique to intercept this kind bug? (...or to avoid them?) thanks Matteo On 08/09/16 01:11, Johan Fabry wrote: > Excellent, you found a bug in my code! > > What happens is that when one item is selected in a list, in the other list the currently selected item is de-selected. This causes *both* blocks (whenAPIChanged: and whenEventChanged:) to be executed, and depending on what order they are executed the behavior is different. (A classical concurrent programming problem.) This order apparently changes depending on how many windows you have open, et cetera, I guess because of how the announcement system is implemented. > > So, yes the easiest solution is to remove both ifNil: [â¦] lines. The UI will not work as cleanly, but it is a quick fix. Alternatively, and a bit more complicated, is to check if the selection in the other list is also empty before setting the text to the empty string. > > For the sake of the example, I will simply remove both ifNil: [â¦] lines from the documentation. > > Thanks for reporting this, and if you have further issues do not hesitate to tell us! > > -- > Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > >> On Sep 7, 2016, at 19:51, Matteo <matteob8(a)yahoo.it> wrote: >> >> Hello Johan, >> I've coded all the examples manually, changing the names to avoid >> any conflict with the ProtocolBrowser "bundled" in the Pharo 5 image >> (i.e. instead of "ProtocolBrowser" I've named my class as "ProtcolFlipper"). >> But the result is the same. >> >> Things improve if all the "ifNil: [ text text: '' ]" get removed from >> the ProtcolFlipper>>initializePresenter method. >> Obviously the text pane is no more "cleaned" when deselecting an "api" >> or "api-event" row. >> >> I've tried to substitute the "ifNil: [ text text: '' ]" with "ifNil: [ >> text text: 'api' ] and ifNil: [ text text: 'api-events' ] , respectively >> on the "api" and "event" instances, in the ProtocolBrowser >> >> initializePresenter method. >> In this way I found that "ifNil:" message is sent improperly, i.e. when >> a "api-event" row is selected then the message "ifNil:" of the "api" >> instance is triggered, and vice-versa. >> In some way this is correct: when a "api-event" row is selected then >> none of the "api" rows are selected... >> >> However I'm puzzled by the fact that the behavior seems random: creating >> 3 instances I can get 3 different behaviors. >> >> have you never experienced this? >> >> Maybe I'll check again my code... >> >> thanks, >> Matteo >

Sept. 8, 2016

Moving from Slack to Discord

by Dimitris Chloupis

I have been aware about Discord for some time now , but I never used it because both Pharo and Unreal channels are on Slack. From my small experience with it, it seemed much more superior to Slack with added bonus that is completely free (open source ) and with no restrictions unlike Slack. But something happened suddenly yesterday, I opened Unreal in Slack and it was gone with a notification that they moved to Discord. So I grabbed this opportunity to create a Pharo server you can join here https://discord.gg/F6nAd Discord works as web apps but also you can download as an app for Windows, Macos , iOS and Android. I will be around in Discord because I generally browser Unreal channels. The nice thing about Discord also is that it offers both audio and video chat for free which can work great for Pharo sprints. Anyway there is no harm on testing it.

Sept. 8, 2016

Re: [Pharo-users] [ANN] Territorial Re-Licensing

by Offray Vladimir Luna CÃ¡rdenas

Please let's move on. My motivation was trying to see the logic behind licenses in Pharo (not on popularity of GPL vs MIT), raised by a valid concern on free riding, enclosure of the commons and reciprocity, which is a hot topic with a lot of debate in free culture/knowledge communities. I learned about why MIT an alike are better in the context of image based systems, Territorial was relicensed. Some people apologized and some others went "+1". On personal attacks and rant reactions, I think that, as a community, we can also learn from that a try to minimize them. It was another day in the community. With that cleared, let's move. Cheers, Offray On 08/09/16 14:17, Dimitris Chloupis wrote: > well he did apologize > > And these things do happen in all communities, I cannot begin to > describe the poison I have received in the #common-lisp irc channel. > One time also in their mailing list , some old member got annoyed for > small reason with a begineer and he gave him code to delete his hard > drive, fortunately other members replied immediately after warning the > beginner not to execute the code. > > License wise MIT/BSD are by far the top most popular license , they > got so popular that FSF was forced to release LGPL to compete with > them but at the same time not upsetting too much their GPL supporters. > > So as you can see Pharo is no exception, its actually the rule. Also > other licenses are very close to MIT/BSD making MIT almost a monopoly > on open source software. > > Don't believe me ? Here are the top trending github repos that contain > a code license ( creative commons applies not to code but mainly to > assets, music, sound, text, graphics, fonts, etc) > > https://github.com/facebook/zstd > https://github.com/tensorflow/tensorflow > https://github.com/vuejs/vue > https://github.com/camwiegert/in-view > https://github.com/nasa/openmct > https://github.com/baidu/Paddle > https://github.com/facebookresearch/fastText > https://github.com/david-gpu/srez > https://github.com/quilljs/quill > https://github.com/shekhargulati/52-technologies-in-2016 > > Mostly they are MIT , others are MIT like licenses like Apache and > BSD, only one is a custom made one still similar to MIT. None GPL not > even LGPL. > > https://github.com/trending?since=monthly > > Actually you can continued down the list and I am sure will take you > even more time to find a GPL or even LGPL licensed open source project. > > On Thu, Sep 8, 2016 at 1:23 PM Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > Hi Tudor, > > I recognize the impedance with mail as an expression medium and > most of > the time it was like you said, except when Stef addressed to me with > "It is amazing how you like talking" (is this some kind of > invitation to > "just shut up!"? Is that a "remainder" I have not written enough > code to > have a valid voice here?). > > For me, if someone has no the time for a detailed response, going > with: > "GPL is a plague", "You can argue I don't care" or "Pharo is MIT. > Period.", or fighting the person instead of fighting the argument, > makes > more harm that good. No clarification, because lack of energy or time, > seems better that these alternative "clarifications". Not all the > people > is trying to start a holy war anytime makes a suggestion or shows a > different position. Sometimes we're just trying to contribute and > understand, even when we come from different places, interests and > life > paths. > > Thanks for pointing the LGPL issue (so, 3 BSD, MIT, public domain > are a > good fit). At least I made my contribution by pointing the Etoile > place > where there is a *rationale* behind a license choosing that makes this > licensing issues clearer for newcomers. > > Energy is low today, but putting things in perspective, most of > the time > community is welcoming, even if particular interactions among > people are > not. > > Cheers, > > Offray > > > On 08/09/16 11:40, Tudor Girba wrote: > > Hi Offray, > > > > I am sorry you feel down. > > > > The wording of Stef did appear strong. However, please keep in > mind that email is a terrible medium for expressing and > transmitting feelings. I would kindly ask you to reconsider the > emails and focus on the content and you will see that the wording > was not about the external project but about the decisions that > relate to the licensing of Pharo itself. As Esteban and I > clarified, Pharo is MIT and will remain MIT. There is a long > history of why this is so and a huge amount of effort to make it > clean MIT. To keep it clean we have to be aware of the > implications of another kind of a license, and our clarifications > were about how we, those that work on the main Pharo code, will > not touch a GPL code and that this might have a counter productive > impact on the originator of the code in question (due to a lack of > engagement from other people). > > > > Please also keep in mind that we do not want to prevent people > from choosing their own licenses. The decision of the license > belongs exclusively to the creators of the code. We are only > looking for the interests of the core of Pharo to make sure that > you will continue to have whatever options you choose on top of > it. And you will always be free to choose what you want for your > projects. > > > > Just a note about other licenses you mentioned: in the context > of Pharo, LGPL has the same effect as GPL given that there is no > concept of binary reusability in our system. So, for that purpose, > we also do not touch LGPL. > > > > A final point: when someone says that "we decided something a > long time agoâ, it is easy to take it as a âthis is it, just take > itâ, but that would be a bit unfair. A more fair alternative is to > understand that time is scarce and sometimes we just do not have > the available energy to provide all clarifications on demand right > at that point. > > > > Please letâs focus on building things together, even if there > are misunderstandings or seaming differences in opinion. We need > everyoneâs energy. > > > > Cheers, > > Doru > > > > > >> On Sep 8, 2016, at 9:53 AM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > >> > >> Nice to know something good came out after taking all the heat. > In my case I learn about licensing with the reasons behind and not > "just take it!"... > >> My sources of information, the main spec.st <http://spec.st> > site, made my mistake about dual license a valid misinterpretation > and even the idea that there are other non-viral licenses: LGPL, 3 > clause BSD, public domain that can integrated in a MIT licensed > project, with the rationale behind [1], seems a good thing to make > explicit > >> [1] http://etoileos.com/dev/licensing/ > >> Kind of down though, after seeing how a community leader can go > after other people who don't share his views/knowledge and is just > trying to contribute, understand and be part of the community. > Today would be a slow day for me in Smalltak... maybe is time to > take a walk a leave it for a time. > >> > >> Cheers, > >> > >> Offray > >> > >> On 08/09/16 06:00, HernÃ¡n Morales Durand wrote: > >>> I consider GNU AGPL v3 a fair license choice which protects > somehow authors. After some talks with friends today, I began to > consider it useless for a niche community like Smalltalk *and* > solo projects. I then read all your mails, many posts in other > communities, and finally asked for advices. Conclusion: The ideal > license option for me was not yet invented. > >>> > >>> Now about parasite behavior and easy living for freeloaders. > >>> > >>> - I doubt Smalltalkers are in position for doing anything > valuable against parasites. GPL scares a niche community. All of > us having MIT code published can be stealed and we have no legal > options to defend our work/authorship. That should be addressed > one day. > >>> > >>> - However, I would like one day to read people releasing > software under whatever license they want and not to be pointed > them. That's a matter of freedom. I feel we are far away from there. > >>> > >>> - I hope we can talk about interesting Territorial features, > what do you need, what could be modeled better, etc. Licensing is > boring, really. > >>> > >>> I re-licensed Territorial to MIT for the nice Pharo people, > for the nice Smalltalkers, people who helped me here in mailing > lists, or sending supportive private messages, and for cool users > with nice intentions. > >>> > >>> HernÃ¡n > >>> > >>> PS: Updated User Manual: http://bit.ly/2c4RrCJ > >>> > >>> > >>> > > -- > > www.tudorgirba.com <http://www.tudorgirba.com> > > www.feenk.com <http://www.feenk.com> > > > > "Next time you see your life passing by, say 'hi' and get to > know her." > > > > > > > > > > > > > >

Sept. 8, 2016

Re: [Pharo-users] [ANN] Territorial Re-Licensing

by Dimitris Chloupis

well he did apologize And these things do happen in all communities, I cannot begin to describe the poison I have received in the #common-lisp irc channel. One time also in their mailing list , some old member got annoyed for small reason with a begineer and he gave him code to delete his hard drive, fortunately other members replied immediately after warning the beginner not to execute the code. License wise MIT/BSD are by far the top most popular license , they got so popular that FSF was forced to release LGPL to compete with them but at the same time not upsetting too much their GPL supporters. So as you can see Pharo is no exception, its actually the rule. Also other licenses are very close to MIT/BSD making MIT almost a monopoly on open source software. Don't believe me ? Here are the top trending github repos that contain a code license ( creative commons applies not to code but mainly to assets, music, sound, text, graphics, fonts, etc) https://github.com/facebook/zstd https://github.com/tensorflow/tensorflow https://github.com/vuejs/vue https://github.com/camwiegert/in-view https://github.com/nasa/openmct https://github.com/baidu/Paddle https://github.com/facebookresearch/fastText https://github.com/david-gpu/srez https://github.com/quilljs/quill https://github.com/shekhargulati/52-technologies-in-2016 Mostly they are MIT , others are MIT like licenses like Apache and BSD, only one is a custom made one still similar to MIT. None GPL not even LGPL. https://github.com/trending?since=monthly Actually you can continued down the list and I am sure will take you even more time to find a GPL or even LGPL licensed open source project. On Thu, Sep 8, 2016 at 1:23 PM Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > Hi Tudor, > > I recognize the impedance with mail as an expression medium and most of > the time it was like you said, except when Stef addressed to me with > "It is amazing how you like talking" (is this some kind of invitation to > "just shut up!"? Is that a "remainder" I have not written enough code to > have a valid voice here?). > > For me, if someone has no the time for a detailed response, going with: > "GPL is a plague", "You can argue I don't care" or "Pharo is MIT. > Period.", or fighting the person instead of fighting the argument, makes > more harm that good. No clarification, because lack of energy or time, > seems better that these alternative "clarifications". Not all the people > is trying to start a holy war anytime makes a suggestion or shows a > different position. Sometimes we're just trying to contribute and > understand, even when we come from different places, interests and life > paths. > > Thanks for pointing the LGPL issue (so, 3 BSD, MIT, public domain are a > good fit). At least I made my contribution by pointing the Etoile place > where there is a *rationale* behind a license choosing that makes this > licensing issues clearer for newcomers. > > Energy is low today, but putting things in perspective, most of the time > community is welcoming, even if particular interactions among people are > not. > > Cheers, > > Offray > > > On 08/09/16 11:40, Tudor Girba wrote: > > Hi Offray, > > > > I am sorry you feel down. > > > > The wording of Stef did appear strong. However, please keep in mind that > email is a terrible medium for expressing and transmitting feelings. I > would kindly ask you to reconsider the emails and focus on the content and > you will see that the wording was not about the external project but about > the decisions that relate to the licensing of Pharo itself. As Esteban and > I clarified, Pharo is MIT and will remain MIT. There is a long history of > why this is so and a huge amount of effort to make it clean MIT. To keep it > clean we have to be aware of the implications of another kind of a license, > and our clarifications were about how we, those that work on the main Pharo > code, will not touch a GPL code and that this might have a counter > productive impact on the originator of the code in question (due to a lack > of engagement from other people). > > > > Please also keep in mind that we do not want to prevent people from > choosing their own licenses. The decision of the license belongs > exclusively to the creators of the code. We are only looking for the > interests of the core of Pharo to make sure that you will continue to have > whatever options you choose on top of it. And you will always be free to > choose what you want for your projects. > > > > Just a note about other licenses you mentioned: in the context of Pharo, > LGPL has the same effect as GPL given that there is no concept of binary > reusability in our system. So, for that purpose, we also do not touch LGPL. > > > > A final point: when someone says that "we decided something a long time > agoâ, it is easy to take it as a âthis is it, just take itâ, but that would > be a bit unfair. A more fair alternative is to understand that time is > scarce and sometimes we just do not have the available energy to provide > all clarifications on demand right at that point. > > > > Please letâs focus on building things together, even if there are > misunderstandings or seaming differences in opinion. We need everyoneâs > energy. > > > > Cheers, > > Doru > > > > > >> On Sep 8, 2016, at 9:53 AM, Offray Vladimir Luna CÃ¡rdenas < > offray.luna(a)mutabit.com> wrote: > >> > >> Nice to know something good came out after taking all the heat. In my > case I learn about licensing with the reasons behind and not "just take > it!"... > >> My sources of information, the main spec.st site, made my mistake > about dual license a valid misinterpretation and even the idea that there > are other non-viral licenses: LGPL, 3 clause BSD, public domain that can > integrated in a MIT licensed project, with the rationale behind [1], seems > a good thing to make explicit > >> [1] http://etoileos.com/dev/licensing/ > >> Kind of down though, after seeing how a community leader can go after > other people who don't share his views/knowledge and is just trying to > contribute, understand and be part of the community. Today would be a slow > day for me in Smalltak... maybe is time to take a walk a leave it for a > time. > >> > >> Cheers, > >> > >> Offray > >> > >> On 08/09/16 06:00, HernÃ¡n Morales Durand wrote: > >>> I consider GNU AGPL v3 a fair license choice which protects somehow > authors. After some talks with friends today, I began to consider it > useless for a niche community like Smalltalk *and* solo projects. I then > read all your mails, many posts in other communities, and finally asked for > advices. Conclusion: The ideal license option for me was not yet invented. > >>> > >>> Now about parasite behavior and easy living for freeloaders. > >>> > >>> - I doubt Smalltalkers are in position for doing anything valuable > against parasites. GPL scares a niche community. All of us having MIT code > published can be stealed and we have no legal options to defend our > work/authorship. That should be addressed one day. > >>> > >>> - However, I would like one day to read people releasing software > under whatever license they want and not to be pointed them. That's a > matter of freedom. I feel we are far away from there. > >>> > >>> - I hope we can talk about interesting Territorial features, what do > you need, what could be modeled better, etc. Licensing is boring, really. > >>> > >>> I re-licensed Territorial to MIT for the nice Pharo people, for the > nice Smalltalkers, people who helped me here in mailing lists, or sending > supportive private messages, and for cool users with nice intentions. > >>> > >>> HernÃ¡n > >>> > >>> PS: Updated User Manual: http://bit.ly/2c4RrCJ > >>> > >>> > >>> > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > > > > > > > > > > > >

Sept. 8, 2016

Re: [Pharo-users] Profiling

by Sven Van Caekenberghe

> On 08 Sep 2016, at 14:01, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > > Thanks for the answers! > > If this is time spent on I/O it is really strange. I am consuming the Twitter API and it don't get so much time like this to get a response. Besides, while those profiles were made at a Windows 10 local machine, the same code on a Pharo 5 (get.pharo.org) deployed on a linux deploy on Digital Ocean takes ~6 seconds, which means that a lot less time is spent on I/O. Isn't that Strange? I will try to spin up a local linux machine with both a headfull and headless Pharo to see if this time changes. > > Is there a way to profile a remote image? I would like to see what is happening in the Digital Ocean deploy. Maybe put the headless Pharo there in profiling mode? > > Ben: this is a heavy json parser procedure, I would expect to NeoJson to take some time. Perhaps there is a way to optimize this, but what catch my attention was the huge amount of time spent on the idleProcess. Been that I/O wait, it shouldn't be like this. Why not ? You are doing (lot's of) network I/O. It is normal that your image code has to wait from time to time for data to come in from the network. By definition that is slow (in CPU terms). The Digital Ocean instance is probably faster in that respect. Also, having the IDE UI with lot's of tools open might influence things. Best do some more experiments. But benchmarking is very tricky. > Thanks, > Vitor > > On Thu, Sep 8, 2016 at 4:42 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > On Thu, Sep 8, 2016 at 3:44 AM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Hello, > > While profiling some I/O code that takes ~20 seconds to execute under my local image, the report says that about ~13 seconds is waste on OtherProcesses -> ProcessorScheduler class>>idleProcess. I could not understand what this idleProcess do by looking at the code. First I thought this could be time waiting the I/O operation to terminate, but that don't make much sense because I have the same code on a Digital Ocean Doplet and it takes ~6 seconds to execute. > > Can someone help me understand what does this time on idleProcess means? > > The VM is not event-driven. Hence when all the processes are suspended or terminated, the VM falls back to the idle process. The idle process waits for 1ms, checks if any event has occurred and/or if a process can restart, and if not waits for 1 more ms to check again. That's kind of dumb but it works and we need both time and funds to make the VM event-driven (in the latter case the VM restarts directly when an event happens, instead of checking at the next ms). > > Basically the idle process profiled time is the time where Pharo has nothing to do because all processes are terminated or suspended. You can say that it is the time spent in I/O operations + the time before Pharo notices the I/O operation is terminated, which can be up to 1ms. > > > > The full report is: > > - 18407 tallies, 18605 msec. > > **Tree** > -------------------------------- > Process: (40s) Morphic UI Process: nil > -------------------------------- > 25.1% {4663ms} UndefinedObject>>DoIt > 25.1% {4663ms} TweetsServiceRestConsumer(TweetsService)>>hashesTop:usingLastTweetsUpTo:fromHandler: > 25.0% {4656ms} TweetsServiceRestConsumer>>fetchLastTweetsUpTo:fromHandler: > 14.3% {2653ms} OAuthProvider>>httpGet: > |14.3% {2653ms} ZnOAuth1Service>>httpGet:using: > | 14.3% {2653ms} ZnOAuth1Service>>executeRequest:token: > | 14.3% {2653ms} ZnOAuth1Service>>executeRequest:token:followRedirects: > | 14.2% {2646ms} ZnClient>>execute > | 14.2% {2646ms} ZnClient>>withProgressDo: > | 14.2% {2646ms} ZnSignalProgress class(DynamicVariable class)>>value:during: > | 14.2% {2646ms} ZnSignalProgress(DynamicVariable)>>value:during: > | 14.2% {2646ms} BlockClosure>>ensure: > | 14.2% {2646ms} ZnSignalProgress(DynamicVariable)>>value:during: > | 14.2% {2646ms} ZnClient>>withProgressDo: > | 14.2% {2646ms} ZnClient>>execute > | 14.2% {2646ms} ZnClient>>executeWithTimeout > | 14.2% {2646ms} ZnClient>>withTimeoutDo: > | 14.2% {2646ms} ZnConnectionTimeout class(DynamicVariable class)>>value:during: > | 14.2% {2646ms} ZnConnectionTimeout(DynamicVariable)>>value:during: > | 14.2% {2646ms} BlockClosure>>ensure: > | 14.2% {2646ms} ZnConnectionTimeout(DynamicVariable)>>value:during: > | 14.2% {2646ms} ZnClient>>withTimeoutDo: > | 14.2% {2646ms} ZnClient>>executeWithTimeout > | 14.2% {2646ms} BlockClosure>>on:do: > | 14.2% {2646ms} ZnClient>>executeWithTimeout > | 14.2% {2646ms} ZnClient>>executeWithRetriesRemaining: > | 14.2% {2644ms} BlockClosure>>on:do: > | 14.2% {2644ms} ZnClient>>executeWithRetriesRemaining: > | 14.2% {2644ms} ZnClient>>executeWithRedirectsRemaining: > | 14.2% {2641ms} ZnClient>>getConnectionAndExecute > | 13.8% {2569ms} BlockClosure>>ensure: > | 13.8% {2569ms} ZnClient>>getConnectionAndExecute > | 13.8% {2569ms} ZnClient>>executeRequestResponse > | 13.8% {2569ms} ZnClient>>readResponse > | 13.8% {2569ms} ZnResponse class(ZnMessage class)>>readFrom: > | 13.8% {2569ms} ZnResponse(ZnMessage)>>readFrom: > | 13.8% {2559ms} ZnResponse>>readEntityFrom: > | 13.8% {2559ms} ZnResponse(ZnMessage)>>readEntityFrom: > | 13.8% {2559ms} ZnEntityReader>>readEntity > | 13.8% {2559ms} ZnEntityReader>>readEntityFromStream > | 13.7% {2555ms} ZnEntityReader>>readFrom:usingType:andLength: > | 13.7% {2555ms} ZnEntity class>>readFrom:usingType:andLength: > | 13.7% {2555ms} ZnStringEntity>>readFrom: > | 13.7% {2550ms} BlockClosure>>on:do: > | 13.7% {2550ms} ZnStringEntity>>readFrom: > | 13.7% {2550ms} ZnUTF8Encoder>>readInto:startingAt:count:fromStream: > | 13.7% {2550ms} ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream: > | 13.7% {2550ms} ZnLimitedReadStream>>readInto:startingAt:count: > | 13.7% {2547ms} ZdcSecureSocketStream(ZdcOptimizedSocketStream)>>readInto:startingAt:count: > | 13.7% {2547ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > | 9.0% {1669ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > | |5.8% {1076ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > | | |3.6% {671ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > | | | |1.8% {337ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > | | | | |1.2% {225ms} BlockClosure>>on:do: > | | | | | 1.2% {225ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > | | | | | 1.2% {225ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData > | | | | | 1.2% {225ms} Socket>>waitForDataFor: > | | | | | 1.2% {225ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: > | | | | | 1.2% {225ms} Semaphore>>waitTimeoutMSecs: > | | | | | 1.2% {225ms} DelayWaitTimeout>>wait > | | | | | 1.2% {225ms} BlockClosure>>ensure: > | | | | | 1.2% {225ms} DelayWaitTimeout>>wait > | | | | | 1.1% {196ms} DelayWaitTimeout(Delay)>>unschedule > | | | | | 1.1% {196ms} DelayExperimentalSpinScheduler>>unschedule: > | | | |1.8% {335ms} BlockClosure>>on:do: > | | | | 1.8% {335ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > | | | | 1.8% {335ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData > | | | | 1.8% {335ms} Socket>>waitForDataFor: > | | | | 1.8% {335ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: > | | | | 1.8% {335ms} Semaphore>>waitTimeoutMSecs: > | | | | 1.8% {335ms} DelayWaitTimeout>>wait > | | | | 1.8% {335ms} BlockClosure>>ensure: > | | | | 1.8% {335ms} DelayWaitTimeout>>wait > | | | | 1.5% {273ms} DelayWaitTimeout(Delay)>>unschedule > | | | | 1.5% {273ms} DelayExperimentalSpinScheduler>>unschedule: > | | |2.2% {405ms} BlockClosure>>on:do: > | | | 2.2% {405ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > | | | 2.2% {405ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData > | | | 2.2% {405ms} Socket>>waitForDataFor: > | | | 2.2% {405ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: > | | | 2.2% {405ms} Semaphore>>waitTimeoutMSecs: > | | | 2.2% {405ms} DelayWaitTimeout>>wait > | | | 2.2% {405ms} BlockClosure>>ensure: > | | | 2.2% {405ms} DelayWaitTimeout>>wait > | | | 1.7% {314ms} DelayWaitTimeout(Delay)>>unschedule > | | | 1.7% {314ms} DelayExperimentalSpinScheduler>>unschedule: > | |3.2% {592ms} BlockClosure>>on:do: > | | 3.2% {592ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > | | 3.2% {592ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData > | | 3.2% {592ms} Socket>>waitForDataFor: > | | 3.2% {592ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: > | | 3.2% {592ms} Semaphore>>waitTimeoutMSecs: > | | 3.2% {592ms} DelayWaitTimeout>>wait > | | 3.2% {592ms} BlockClosure>>ensure: > | | 3.2% {592ms} DelayWaitTimeout>>wait > | | 2.3% {429ms} DelayWaitTimeout(Delay)>>unschedule > | | 2.3% {429ms} DelayExperimentalSpinScheduler>>unschedule: > | 4.7% {876ms} BlockClosure>>on:do: > | 4.7% {876ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > | 4.7% {876ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData > | 4.7% {876ms} Socket>>waitForDataFor: > | 4.7% {876ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: > | 4.7% {876ms} Semaphore>>waitTimeoutMSecs: > | 4.7% {876ms} DelayWaitTimeout>>wait > | 4.7% {876ms} BlockClosure>>ensure: > | 4.7% {876ms} DelayWaitTimeout>>wait > | 2.9% {532ms} DelayWaitTimeout(Delay)>>unschedule > | |2.9% {532ms} DelayExperimentalSpinScheduler>>unschedule: > | 1.4% {268ms} primitives > 10.8% {2002ms} NeoJSONObject class>>fromString: > 10.8% {2002ms} NeoJSONReader>>next > 10.8% {2002ms} NeoJSONReader>>parseValue > 10.8% {2002ms} NeoJSONReader>>parseList > 10.8% {2002ms} Array class(SequenceableCollection class)>>streamContents: > 10.8% {2002ms} Array class(SequenceableCollection class)>>new:streamContents: > 10.8% {2002ms} NeoJSONReader>>parseList > 10.8% {2002ms} NeoJSONReader>>parseListElementsDo: > 10.8% {2002ms} NeoJSONReader>>parseListDo: > 10.8% {2002ms} NeoJSONReader>>parseListElementsDo: > 10.8% {2002ms} NeoJSONReader>>parseValue > 10.8% {2002ms} NeoJSONReader>>parseMap > 10.8% {2002ms} NeoJSONReader>>parseMapKeysAndValuesDo: > 10.8% {2002ms} NeoJSONReader>>parseMapKeysDo: > 10.8% {2002ms} NeoJSONReader>>parseMapDo: > 10.7% {1994ms} NeoJSONReader>>parseMapKeysDo: > 9.6% {1785ms} NeoJSONReader>>parseMapKeysAndValuesDo: > |9.2% {1717ms} NeoJSONReader>>parseValue > | 8.6% {1600ms} NeoJSONReader>>parseMap > | 8.6% {1600ms} NeoJSONReader>>parseMapKeysAndValuesDo: > | 8.6% {1600ms} NeoJSONReader>>parseMapKeysDo: > | 8.6% {1600ms} NeoJSONReader>>parseMapDo: > | 8.5% {1577ms} NeoJSONReader>>parseMapKeysDo: > | 6.4% {1187ms} NeoJSONReader>>parseMapKeysAndValuesDo: > | |5.6% {1041ms} NeoJSONReader>>parseValue > | | 3.8% {708ms} NeoJSONReader>>parseList > | | 3.8% {706ms} Array class(SequenceableCollection class)>>streamContents: > | | 3.8% {706ms} Array class(SequenceableCollection class)>>new:streamContents: > | | 3.7% {693ms} NeoJSONReader>>parseList > | | 3.7% {693ms} NeoJSONReader>>parseListElementsDo: > | | 3.7% {693ms} NeoJSONReader>>parseListDo: > | | 3.7% {689ms} NeoJSONReader>>parseListElementsDo: > | | 3.7% {689ms} NeoJSONReader>>parseValue > | | 3.7% {687ms} NeoJSONReader>>parseMap > | | 3.7% {687ms} NeoJSONReader>>parseMapKeysAndValuesDo: > | | 3.7% {687ms} NeoJSONReader>>parseMapKeysDo: > | | 3.7% {687ms} NeoJSONReader>>parseMapDo: > | | 3.6% {672ms} NeoJSONReader>>parseMapKeysDo: > | | 3.0% {550ms} NeoJSONReader>>parseMapKeysAndValuesDo: > | | 2.6% {486ms} NeoJSONReader>>parseValue > | | 1.5% {285ms} NeoJSONReader>>parseMap > | | 1.5% {285ms} NeoJSONReader>>parseMapKeysAndValuesDo: > | | 1.5% {285ms} NeoJSONReader>>parseMapKeysDo: > | | 1.5% {285ms} NeoJSONReader>>parseMapDo: > | | 1.5% {285ms} NeoJSONReader>>parseMapKeysDo: > | | 1.4% {252ms} NeoJSONReader>>parseMapKeysAndValuesDo: > | | 1.3% {236ms} NeoJSONReader>>parseValue > | | 1.0% {193ms} NeoJSONReader>>parseMap > | | 1.0% {193ms} NeoJSONReader>>parseMapKeysAndValuesDo: > | | 1.0% {193ms} NeoJSONReader>>parseMapKeysDo: > | | 1.0% {188ms} NeoJSONReader>>parseMapDo: > | 1.9% {347ms} NeoJSONReader>>parsePropertyName > | 1.1% {196ms} NeoJSONReader>>parseValue > | 1.0% {189ms} NeoJSONReader>>parseString > 1.0% {189ms} NeoJSONReader>>parsePropertyName > -------------------------------- > Process: other processes > -------------------------------- > 73.2% {13628ms} ProcessorScheduler class>>startUp > |73.2% {13628ms} ProcessorScheduler class>>idleProcess > 1.4% {259ms} WeakArray class>>restartFinalizationProcess > 1.4% {259ms} WeakArray class>>finalizationProcess > 1.4% {257ms} primitives > **Leaves** > 73.3% {13631ms} ProcessorScheduler class>>idleProcess > 10.0% {1861ms} DelayExperimentalSpinScheduler>>unschedule: > 3.1% {581ms} DelayWaitTimeout>>wait > 1.4% {257ms} WeakArray class>>finalizationProcess > 1.0% {191ms} WeakSet>>scanFor: > > **Memory** > old +16,777,216 bytes > young -17,303,480 bytes > used -526,264 bytes > free +17,303,480 bytes > > **GCs** > full 1 totalling 247ms (1.0% uptime), avg 247.0ms > incr 127 totalling 199ms (1.0% uptime), avg 2.0ms > tenures 480,033 (avg 0 GCs/tenure) > root table 0 overflows > > > Thanks in advance, > Vitor > >

Sept. 8, 2016

Re: [Pharo-users] Profiling

by Vitor Medina Cruz

Thanks for the answers! If this is time spent on I/O it is really strange. I am consuming the Twitter API and it don't get so much time like this to get a response. Besides, while those profiles were made at a Windows 10 local machine, the same code on a Pharo 5 (get.pharo.org) deployed on a linux deploy on Digital Ocean takes ~6 seconds, which means that a lot less time is spent on I/O. Isn't that Strange? I will try to spin up a local linux machine with both a headfull and headless Pharo to see if this time changes. Is there a way to profile a remote image? I would like to see what is happening in the Digital Ocean deploy. Maybe put the headless Pharo there in profiling mode? Ben: this is a heavy json parser procedure, I would expect to NeoJson to take some time. Perhaps there is a way to optimize this, but what catch my attention was the huge amount of time spent on the idleProcess. Been that I/O wait, it shouldn't be like this. Thanks, Vitor On Thu, Sep 8, 2016 at 4:42 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > On Thu, Sep 8, 2016 at 3:44 AM, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > >> Hello, >> >> While profiling some I/O code that takes ~20 seconds to execute under my >> local image, the report says that about ~13 seconds is waste on >> OtherProcesses -> ProcessorScheduler class>>idleProcess. I could not >> understand what this idleProcess do by looking at the code. First I thought >> this could be time waiting the I/O operation to terminate, but that don't >> make much sense because I have the same code on a Digital Ocean Doplet and >> it takes ~6 seconds to execute. >> >> Can someone help me understand what does this time on idleProcess means? >> > > The VM is not event-driven. Hence when all the processes are suspended or > terminated, the VM falls back to the idle process. The idle process waits > for 1ms, checks if any event has occurred and/or if a process can restart, > and if not waits for 1 more ms to check again. That's kind of dumb but it > works and we need both time and funds to make the VM event-driven (in the > latter case the VM restarts directly when an event happens, instead of > checking at the next ms). > > Basically the idle process profiled time is the time where Pharo has > nothing to do because all processes are terminated or suspended. You can > say that it is the time spent in I/O operations + the time before Pharo > notices the I/O operation is terminated, which can be up to 1ms. > > >> >> The full report is: >> >> - 18407 tallies, 18605 msec. >> >> **Tree** >> -------------------------------- >> Process: (40s) Morphic UI Process: nil >> -------------------------------- >> 25.1% {4663ms} UndefinedObject>>DoIt >> 25.1% {4663ms} TweetsServiceRestConsumer(Twee >> tsService)>>hashesTop:usingLastTweetsUpTo:fromHandler: >> 25.0% {4656ms} TweetsServiceRestConsumer>>fet >> chLastTweetsUpTo:fromHandler: >> 14.3% {2653ms} OAuthProvider>>httpGet: >> |14.3% {2653ms} ZnOAuth1Service>>httpGet:using: >> | 14.3% {2653ms} ZnOAuth1Service>>executeRequest:token: >> | 14.3% {2653ms} ZnOAuth1Service>>executeReques >> t:token:followRedirects: >> | 14.2% {2646ms} ZnClient>>execute >> | 14.2% {2646ms} ZnClient>>withProgressDo: >> | 14.2% {2646ms} ZnSignalProgress class(DynamicVariable >> class)>>value:during: >> | 14.2% {2646ms} ZnSignalProgress(DynamicVariab >> le)>>value:during: >> | 14.2% {2646ms} BlockClosure>>ensure: >> | 14.2% {2646ms} ZnSignalProgress(DynamicVariab >> le)>>value:during: >> | 14.2% {2646ms} ZnClient>>withProgressDo: >> | 14.2% {2646ms} ZnClient>>execute >> | 14.2% {2646ms} ZnClient>>executeWithTimeout >> | 14.2% {2646ms} ZnClient>>withTimeoutDo: >> | 14.2% {2646ms} ZnConnectionTimeout >> class(DynamicVariable class)>>value:during: >> | 14.2% {2646ms} >> ZnConnectionTimeout(DynamicVariable)>>value:during: >> | 14.2% {2646ms} >> BlockClosure>>ensure: >> | 14.2% {2646ms} >> ZnConnectionTimeout(DynamicVariable)>>value:during: >> | 14.2% {2646ms} >> ZnClient>>withTimeoutDo: >> | 14.2% {2646ms} >> ZnClient>>executeWithTimeout >> | 14.2% {2646ms} >> BlockClosure>>on:do: >> | 14.2% {2646ms} >> ZnClient>>executeWithTimeout >> | 14.2% {2646ms} >> ZnClient>>executeWithRetriesRemaining: >> | 14.2% {2644ms} >> BlockClosure>>on:do: >> | 14.2% {2644ms} >> ZnClient>>executeWithRetriesRemaining: >> | 14.2% {2644ms} >> ZnClient>>executeWithRedirectsRemaining: >> | 14.2% {2641ms} >> ZnClient>>getConnectionAndExecute >> | 13.8% >> {2569ms} BlockClosure>>ensure: >> | 13.8% >> {2569ms} ZnClient>>getConnectionAndExecute >> | 13.8% >> {2569ms} ZnClient>>executeRequestResponse >> | 13.8% >> {2569ms} ZnClient>>readResponse >> | >> 13.8% {2569ms} ZnResponse class(ZnMessage class)>>readFrom: >> | >> 13.8% {2569ms} ZnResponse(ZnMessage)>>readFrom: >> | >> 13.8% {2559ms} ZnResponse>>readEntityFrom: >> | >> 13.8% {2559ms} ZnResponse(ZnMessage)>>readEntityFrom: >> | >> 13.8% {2559ms} ZnEntityReader>>readEntity >> | >> 13.8% {2559ms} ZnEntityReader>>readEntityFromStream >> | >> 13.7% {2555ms} ZnEntityReader>>readFrom:usingType:andLength: >> | >> 13.7% {2555ms} ZnEntity class>>readFrom:usingType:andLength: >> | >> 13.7% {2555ms} ZnStringEntity>>readFrom: >> | >> 13.7% {2550ms} BlockClosure>>on:do: >> | >> 13.7% {2550ms} ZnStringEntity>>readFrom: >> | >> 13.7% {2550ms} ZnUTF8Encoder>>readInto:starti >> ngAt:count:fromStream: >> | >> 13.7% {2550ms} ZnUTF8Encoder>>optimizedReadIn >> to:startingAt:count:fromStream: >> | >> 13.7% {2550ms} ZnLimitedReadStream>>readInto: >> startingAt:count: >> | >> 13.7% {2547ms} ZdcSecureSocketStream(ZdcOptim >> izedSocketStream)>>readInto:startingAt:count: >> | >> 13.7% {2547ms} ZdcSecureSocketStream(ZdcSimpl >> eSocketStream)>>fillReadBuffer >> | >> 9.0% {1669ms} ZdcSecureSocketStream(ZdcSimpl >> eSocketStream)>>fillReadBuffer >> | >> |5.8% {1076ms} ZdcSecureSocketStream(ZdcSimpl >> eSocketStream)>>fillReadBuffer >> | >> | |3.6% {671ms} ZdcSecureSocketStream(ZdcSimpl >> eSocketStream)>>fillReadBuffer >> | >> | | |1.8% {337ms} >> ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer >> | >> | | | |1.2% {225ms} BlockClosure>>on:do: >> | >> | | | | 1.2% {225ms} >> ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer >> | >> | | | | 1.2% {225ms} >> ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData >> | >> | | | | 1.2% {225ms} >> Socket>>waitForDataFor: >> | >> | | | | 1.2% {225ms} >> Socket>>waitForDataFor:ifClosed:ifTimedOut: >> | >> | | | | 1.2% {225ms} >> Semaphore>>waitTimeoutMSecs: >> | >> | | | | 1.2% {225ms} >> DelayWaitTimeout>>wait >> | >> | | | | 1.2% {225ms} >> BlockClosure>>ensure: >> | >> | | | | 1.2% {225ms} >> DelayWaitTimeout>>wait >> | >> | | | | 1.1% {196ms} >> DelayWaitTimeout(Delay)>>unschedule >> | >> | | | | 1.1% {196ms} >> DelayExperimentalSpinScheduler>>unschedule: >> | >> | | |1.8% {335ms} BlockClosure>>on:do: >> | >> | | | 1.8% {335ms} >> ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer >> | >> | | | 1.8% {335ms} >> ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData >> | >> | | | 1.8% {335ms} >> Socket>>waitForDataFor: >> | >> | | | 1.8% {335ms} >> Socket>>waitForDataFor:ifClosed:ifTimedOut: >> | >> | | | 1.8% {335ms} >> Semaphore>>waitTimeoutMSecs: >> | >> | | | 1.8% {335ms} >> DelayWaitTimeout>>wait >> | >> | | | 1.8% {335ms} >> BlockClosure>>ensure: >> | >> | | | 1.8% {335ms} >> DelayWaitTimeout>>wait >> | >> | | | 1.5% {273ms} >> DelayWaitTimeout(Delay)>>unschedule >> | >> | | | 1.5% {273ms} >> DelayExperimentalSpinScheduler>>unschedule: >> | >> | |2.2% {405ms} BlockClosure>>on:do: >> | >> | | 2.2% {405ms} >> ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer >> | >> | | 2.2% {405ms} >> ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData >> | >> | | 2.2% {405ms} Socket>>waitForDataFor: >> | >> | | 2.2% {405ms} >> Socket>>waitForDataFor:ifClosed:ifTimedOut: >> | >> | | 2.2% {405ms} >> Semaphore>>waitTimeoutMSecs: >> | >> | | 2.2% {405ms} >> DelayWaitTimeout>>wait >> | >> | | 2.2% {405ms} >> BlockClosure>>ensure: >> | >> | | 2.2% {405ms} >> DelayWaitTimeout>>wait >> | >> | | 1.7% {314ms} >> DelayWaitTimeout(Delay)>>unschedule >> | >> | | 1.7% {314ms} >> DelayExperimentalSpinScheduler>>unschedule: >> | >> |3.2% {592ms} BlockClosure>>on:do: >> | >> | 3.2% {592ms} ZdcSecureSocketStream(ZdcSimpl >> eSocketStream)>>fillReadBuffer >> | >> | 3.2% {592ms} >> ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData >> | >> | 3.2% {592ms} Socket>>waitForDataFor: >> | >> | 3.2% {592ms} >> Socket>>waitForDataFor:ifClosed:ifTimedOut: >> | >> | 3.2% {592ms} >> Semaphore>>waitTimeoutMSecs: >> | >> | 3.2% {592ms} >> DelayWaitTimeout>>wait >> | >> | 3.2% {592ms} >> BlockClosure>>ensure: >> | >> | 3.2% {592ms} >> DelayWaitTimeout>>wait >> | >> | 2.3% {429ms} >> DelayWaitTimeout(Delay)>>unschedule >> | >> | 2.3% {429ms} >> DelayExperimentalSpinScheduler>>unschedule: >> | >> 4.7% {876ms} BlockClosure>>on:do: >> | >> 4.7% {876ms} ZdcSecureSocketStream(ZdcSimpl >> eSocketStream)>>fillReadBuffer >> | >> 4.7% {876ms} ZdcSecureSocketStream(ZdcAbstr >> actSocketStream)>>socketWaitForData >> | >> 4.7% {876ms} Socket>>waitForDataFor: >> | >> 4.7% {876ms} >> Socket>>waitForDataFor:ifClosed:ifTimedOut: >> | >> 4.7% {876ms} >> Semaphore>>waitTimeoutMSecs: >> | >> 4.7% {876ms} DelayWaitTimeout>>wait >> | >> 4.7% {876ms} BlockClosure>>ensure: >> | >> 4.7% {876ms} >> DelayWaitTimeout>>wait >> | >> 2.9% {532ms} >> DelayWaitTimeout(Delay)>>unschedule >> | >> |2.9% {532ms} >> DelayExperimentalSpinScheduler>>unschedule: >> | >> 1.4% {268ms} primitives >> 10.8% {2002ms} NeoJSONObject class>>fromString: >> 10.8% {2002ms} NeoJSONReader>>next >> 10.8% {2002ms} NeoJSONReader>>parseValue >> 10.8% {2002ms} NeoJSONReader>>parseList >> 10.8% {2002ms} Array class(SequenceableCollection >> class)>>streamContents: >> 10.8% {2002ms} Array class(SequenceableCollection >> class)>>new:streamContents: >> 10.8% {2002ms} NeoJSONReader>>parseList >> 10.8% {2002ms} NeoJSONReader>>parseListElementsDo: >> 10.8% {2002ms} NeoJSONReader>>parseListDo: >> 10.8% {2002ms} NeoJSONReader>>parseListElemen >> tsDo: >> 10.8% {2002ms} NeoJSONReader>>parseValue >> 10.8% {2002ms} NeoJSONReader>>parseMap >> 10.8% {2002ms} >> NeoJSONReader>>parseMapKeysAndValuesDo: >> 10.8% {2002ms} >> NeoJSONReader>>parseMapKeysDo: >> 10.8% {2002ms} >> NeoJSONReader>>parseMapDo: >> 10.7% {1994ms} >> NeoJSONReader>>parseMapKeysDo: >> 9.6% {1785ms} >> NeoJSONReader>>parseMapKeysAndValuesDo: >> |9.2% {1717ms} >> NeoJSONReader>>parseValue >> | 8.6% {1600ms} >> NeoJSONReader>>parseMap >> | 8.6% {1600ms} >> NeoJSONReader>>parseMapKeysAndValuesDo: >> | 8.6% {1600ms} >> NeoJSONReader>>parseMapKeysDo: >> | 8.6% {1600ms} >> NeoJSONReader>>parseMapDo: >> | 8.5% {1577ms} >> NeoJSONReader>>parseMapKeysDo: >> | 6.4% {1187ms} >> NeoJSONReader>>parseMapKeysAndValuesDo: >> | |5.6% {1041ms} >> NeoJSONReader>>parseValue >> | | 3.8% {708ms} >> NeoJSONReader>>parseList >> | | 3.8% {706ms} >> Array class(SequenceableCollection class)>>streamContents: >> | | 3.8% >> {706ms} Array class(SequenceableCollection class)>>new:streamContents: >> | | 3.7% >> {693ms} NeoJSONReader>>parseList >> | | 3.7% >> {693ms} NeoJSONReader>>parseListElementsDo: >> | | 3.7% >> {693ms} NeoJSONReader>>parseListDo: >> | | >> 3.7% {689ms} NeoJSONReader>>parseListElementsDo: >> | | >> 3.7% {689ms} NeoJSONReader>>parseValue >> | | >> 3.7% {687ms} NeoJSONReader>>parseMap >> | | >> 3.7% {687ms} NeoJSONReader>>parseMapKeysAndValuesDo: >> | | >> 3.7% {687ms} NeoJSONReader>>parseMapKeysDo: >> | | >> 3.7% {687ms} NeoJSONReader>>parseMapDo: >> | | >> 3.6% {672ms} NeoJSONReader>>parseMapKeysDo: >> | | >> 3.0% {550ms} NeoJSONReader>>parseMapKeysAndValuesDo: >> | | >> 2.6% {486ms} NeoJSONReader>>parseValue >> | | >> 1.5% {285ms} NeoJSONReader>>parseMap >> | | >> 1.5% {285ms} NeoJSONReader>>parseMapKeysAndValuesDo: >> | | >> 1.5% {285ms} NeoJSONReader>>parseMapKeysDo: >> | | >> 1.5% {285ms} NeoJSONReader>>parseMapDo: >> | | >> 1.5% {285ms} NeoJSONReader>>parseMapKeysDo: >> | | >> 1.4% {252ms} NeoJSONReader>>parseMapKeysAnd >> ValuesDo: >> | | >> 1.3% {236ms} NeoJSONReader>>parseValue >> | | >> 1.0% {193ms} NeoJSONReader>>parseMap >> | | >> 1.0% {193ms} NeoJSONReader>>parseMapKeysAnd >> ValuesDo: >> | | >> 1.0% {193ms} NeoJSONReader>>parseMapKeysDo: >> | | >> 1.0% {188ms} NeoJSONReader>>parseMapDo: >> | 1.9% {347ms} >> NeoJSONReader>>parsePropertyName >> | 1.1% {196ms} >> NeoJSONReader>>parseValue >> | 1.0% {189ms} >> NeoJSONReader>>parseString >> 1.0% {189ms} >> NeoJSONReader>>parsePropertyName >> -------------------------------- >> Process: other processes >> -------------------------------- >> 73.2% {13628ms} ProcessorScheduler class>>startUp >> |73.2% {13628ms} ProcessorScheduler class>>idleProcess >> 1.4% {259ms} WeakArray class>>restartFinalizationProcess >> 1.4% {259ms} WeakArray class>>finalizationProcess >> 1.4% {257ms} primitives >> **Leaves** >> 73.3% {13631ms} ProcessorScheduler class>>idleProcess >> 10.0% {1861ms} DelayExperimentalSpinScheduler>>unschedule: >> 3.1% {581ms} DelayWaitTimeout>>wait >> 1.4% {257ms} WeakArray class>>finalizationProcess >> 1.0% {191ms} WeakSet>>scanFor: >> >> **Memory** >> old +16,777,216 bytes >> young -17,303,480 bytes >> used -526,264 bytes >> free +17,303,480 bytes >> >> **GCs** >> full 1 totalling 247ms (1.0% uptime), avg 247.0ms >> incr 127 totalling 199ms (1.0% uptime), avg 2.0ms >> tenures 480,033 (avg 0 GCs/tenure) >> root table 0 overflows >> >> >> Thanks in advance, >> Vitor >> > >

Sept. 8, 2016

Re: [Pharo-users] [ANN] Territorial Re-Licensing

by Offray Vladimir Luna CÃ¡rdenas

Hi Tudor, I recognize the impedance with mail as an expression medium and most of the time it was like you said, except when Stef addressed to me with "It is amazing how you like talking" (is this some kind of invitation to "just shut up!"? Is that a "remainder" I have not written enough code to have a valid voice here?). For me, if someone has no the time for a detailed response, going with: "GPL is a plague", "You can argue I don't care" or "Pharo is MIT. Period.", or fighting the person instead of fighting the argument, makes more harm that good. No clarification, because lack of energy or time, seems better that these alternative "clarifications". Not all the people is trying to start a holy war anytime makes a suggestion or shows a different position. Sometimes we're just trying to contribute and understand, even when we come from different places, interests and life paths. Thanks for pointing the LGPL issue (so, 3 BSD, MIT, public domain are a good fit). At least I made my contribution by pointing the Etoile place where there is a *rationale* behind a license choosing that makes this licensing issues clearer for newcomers. Energy is low today, but putting things in perspective, most of the time community is welcoming, even if particular interactions among people are not. Cheers, Offray On 08/09/16 11:40, Tudor Girba wrote: > Hi Offray, > > I am sorry you feel down. > > The wording of Stef did appear strong. However, please keep in mind that email is a terrible medium for expressing and transmitting feelings. I would kindly ask you to reconsider the emails and focus on the content and you will see that the wording was not about the external project but about the decisions that relate to the licensing of Pharo itself. As Esteban and I clarified, Pharo is MIT and will remain MIT. There is a long history of why this is so and a huge amount of effort to make it clean MIT. To keep it clean we have to be aware of the implications of another kind of a license, and our clarifications were about how we, those that work on the main Pharo code, will not touch a GPL code and that this might have a counter productive impact on the originator of the code in question (due to a lack of engagement from other people). > > Please also keep in mind that we do not want to prevent people from choosing their own licenses. The decision of the license belongs exclusively to the creators of the code. We are only looking for the interests of the core of Pharo to make sure that you will continue to have whatever options you choose on top of it. And you will always be free to choose what you want for your projects. > > Just a note about other licenses you mentioned: in the context of Pharo, LGPL has the same effect as GPL given that there is no concept of binary reusability in our system. So, for that purpose, we also do not touch LGPL. > > A final point: when someone says that "we decided something a long time agoâ, it is easy to take it as a âthis is it, just take itâ, but that would be a bit unfair. A more fair alternative is to understand that time is scarce and sometimes we just do not have the available energy to provide all clarifications on demand right at that point. > > Please letâs focus on building things together, even if there are misunderstandings or seaming differences in opinion. We need everyoneâs energy. > > Cheers, > Doru > > >> On Sep 8, 2016, at 9:53 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >> >> Nice to know something good came out after taking all the heat. In my case I learn about licensing with the reasons behind and not "just take it!"... >> My sources of information, the main spec.st site, made my mistake about dual license a valid misinterpretation and even the idea that there are other non-viral licenses: LGPL, 3 clause BSD, public domain that can integrated in a MIT licensed project, with the rationale behind [1], seems a good thing to make explicit >> [1] http://etoileos.com/dev/licensing/ >> Kind of down though, after seeing how a community leader can go after other people who don't share his views/knowledge and is just trying to contribute, understand and be part of the community. Today would be a slow day for me in Smalltak... maybe is time to take a walk a leave it for a time. >> >> Cheers, >> >> Offray >> >> On 08/09/16 06:00, HernÃ¡n Morales Durand wrote: >>> I consider GNU AGPL v3 a fair license choice which protects somehow authors. After some talks with friends today, I began to consider it useless for a niche community like Smalltalk *and* solo projects. I then read all your mails, many posts in other communities, and finally asked for advices. Conclusion: The ideal license option for me was not yet invented. >>> >>> Now about parasite behavior and easy living for freeloaders. >>> >>> - I doubt Smalltalkers are in position for doing anything valuable against parasites. GPL scares a niche community. All of us having MIT code published can be stealed and we have no legal options to defend our work/authorship. That should be addressed one day. >>> >>> - However, I would like one day to read people releasing software under whatever license they want and not to be pointed them. That's a matter of freedom. I feel we are far away from there. >>> >>> - I hope we can talk about interesting Territorial features, what do you need, what could be modeled better, etc. Licensing is boring, really. >>> >>> I re-licensed Territorial to MIT for the nice Pharo people, for the nice Smalltalkers, people who helped me here in mailing lists, or sending supportive private messages, and for cool users with nice intentions. >>> >>> HernÃ¡n >>> >>> PS: Updated User Manual: http://bit.ly/2c4RrCJ >>> >>> >>> > -- > www.tudorgirba.com > www.feenk.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > > >

Sept. 8, 2016