- Pharo-users - lists.pharo.org

Re: [Pharo-users] Moving from Slack to Discord

by Dimitris Chloupis

Thanks all of the people who joined us we are already 14 members including 2 administrators me and Esteban. Discord has passed this daily test, it supports markup which means you can paste Pharo code with Smalltalk syntax highlighting, it previews links, edit messages, has YouTube and Twitch integrations. I also tested the mobile clients for iOS and android. Everything looks like it works fine, a search facility is missing but this is to be added by the development team later on. Now what remains is to test twitch and YouTube integration and also video and voice chat. Talking about twitch I decided to make screencasts for Pharo , probably one hour long. The advantage over YouTube tutorials is that it's real time so we can make the lesson interactive and you can ask me questions and chat with me during the screencast. I will alert when the screencast will take place with a later post. On Thu, 8 Sep 2016 at 15:42, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > 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] SpecBooklet: Strange behavior of ProtocolBrowser

by Johan Fabry

Thanks for your kind words and also for the report of the issues, I will take care of that ASAP! -- 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 11:24, Matteo <matteob8(a)yahoo.it> wrote: > > Hi Jhoan, > > Does static typing could fix these kind of bugs? > [hahaha, just kidding ;) ] > > > About the SpecBooklet, for now there's only 3 (really) small issues: > > at page 3 --> the phrase "You could can use the rest..." should be fixed; > > at page 5 --> to let the code work I had to substitute "self iconNamed: > #thumbsUp" with "(Smalltalk ui icons iconNamed: #thumbsUp)",and so on > for the other buttons. Is it a problem of my image? > > at page 14 --> there's a " ' " missing from the "instanceVariableNames:" > of the #ProtocolMethodList subclassing message. > > > Just a note to say that I'm very happy with the SpecBooklet: it would > be **very** difficult to figure out how to effectively use Spec by > simply reading the code. > > Further it is really well written, and contains a lot of > useful/fundamental information: evidence of the great effort the Authors > have spent to write it. > > Congrats for the very good job! > > thanks, > Matteo > > > > > > On 08/09/16 15:28, Johan Fabry wrote: >> Hi Matteo, >> >> glad to be of help. And sorry but these kinds of concurrency bugs are the hardest to catch, there is no straightforward solution. >> >> -- >> 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 10:13, Matteo <matteob8(a)yahoo.it> wrote: >>> >>> thanks Jhoan for the explanation! >>> Do you know some technique to intercept this kind bug? (...or to avoid >>> them?) >>> >>> thanks >>> Matteo >> > >

Sept. 8, 2016

Re: [Pharo-users] Profiling

by Vitor Medina Cruz

> > 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. > But only the wait time corresponds to 73% (~13 seconds in no CPU time) of the entire procedure, which is taking ~18 seconds total. In the remote server the same procedure takes only ~6 seconds, supposing it still takes 73% in waiting it would give us ~4 seconds in wait time. I think 4 seconds to 13 seconds of difference for wait time is too much, it is not? The maximum I/O calls I am doing is ten. It is like it takes more than one second waiting for response, which does not seems right. I will do additional tests. > Also, having the IDE UI with lot's of tools open might influence things. > Best do some more experiments. But benchmarking is very tricky. Yes, I will try doing different stuff here! Thanks! Vitor On Thu, Sep 8, 2016 at 9:09 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > 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] difficult to kill objects - pesky hanging pointersTo

by Damien Pollet

On 7 September 2016 at 20:45, stepharo <stepharo(a)free.fr> wrote: > And wht I learned is that we should do > > > ClassOfObjectsThatMustDie allInstances first become: nil > but really String new. > But why a two-way become and not a becomeForward?

Sept. 8, 2016

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

by HernÃ¡n Morales Durand

Hi Offray Ad hominem comments never help. But we all make mistakes, we are not experts in Argumentation Theory, but I think we are learning from every discussion. Licensing has black void holes. I would prefer to read "GPL could result in lower feedback for your projects, because community size is really small compared to other OSS projects" and other factors. Or even better, we can try to build something from the discussion, like a licensing chapter with key points. HernÃ¡n 2016-09-08 7:22 GMT-03:00 Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com>: > 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] SpecBooklet: Strange behavior of ProtocolBrowser

by Matteo

Hi Jhoan, Does static typing could fix these kind of bugs? [hahaha, just kidding ;) ] About the SpecBooklet, for now there's only 3 (really) small issues: at page 3 --> the phrase "You could can use the rest..." should be fixed; at page 5 --> to let the code work I had to substitute "self iconNamed: #thumbsUp" with "(Smalltalk ui icons iconNamed: #thumbsUp)",and so on for the other buttons. Is it a problem of my image? at page 14 --> there's a " ' " missing from the "instanceVariableNames:" of the #ProtocolMethodList subclassing message. Just a note to say that I'm very happy with the SpecBooklet: it would be **very** difficult to figure out how to effectively use Spec by simply reading the code. Further it is really well written, and contains a lot of useful/fundamental information: evidence of the great effort the Authors have spent to write it. Congrats for the very good job! thanks, Matteo On 08/09/16 15:28, Johan Fabry wrote: > Hi Matteo, > > glad to be of help. And sorry but these kinds of concurrency bugs are the hardest to catch, there is no straightforward solution. > > -- > 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 10:13, Matteo <matteob8(a)yahoo.it> wrote: >> >> thanks Jhoan for the explanation! >> Do you know some technique to intercept this kind bug? (...or to avoid >> them?) >> >> thanks >> Matteo >

Sept. 8, 2016

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

by Dimitris Chloupis

Yes he did after my reply "So sorry to be rude but I'm ***REALLY*** busy. Much more than you can imagine. Even more. And I feel responsible. " So let us move on :) On Thu, 8 Sep 2016 at 16:19, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > 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] [Pharo-dev] Small OS-... project addition

by Esteban Lorenzano

> On 08 Sep 2016, at 15:55, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Pretty cool! > Is it available from the catalog? > > Alexandre > > >> On Sep 8, 2016, at 4:06 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> Hi, >> >> now also the OSX project in the OS series [1] has support to >> >> - directly open a terminal >> - directly open a file browser (Finder) on the working directory >> >> right from the Pharo tools menu. See attached screenshot. >> >> Depending on your platform just load >> >> - OSOSX >> - OSWindows >> - OSLinuxUbuntu >> - OSLinuxCentOS >> >> from catalog. ^ this :) >> >> Bye >> T. >> >> >> [1] http://smalltalkhub.com/#!/~OS<OSMenu.png> > >

Sept. 8, 2016

Re: [Pharo-users] Small OS-... project addition

by Alexandre Bergel

Pretty cool! Is it available from the catalog? Alexandre > On Sep 8, 2016, at 4:06 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > now also the OSX project in the OS series [1] has support to > > - directly open a terminal > - directly open a file browser (Finder) on the working directory > > right from the Pharo tools menu. See attached screenshot. > > Depending on your platform just load > > - OSOSX > - OSWindows > - OSLinuxUbuntu > - OSLinuxCentOS > > from catalog. > > Bye > T. > > > [1] http://smalltalkhub.com/#!/~OS<OSMenu.png>

Sept. 8, 2016

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

by Johan Fabry

Hi Matteo, glad to be of help. And sorry but these kinds of concurrency bugs are the hardest to catch, there is no straightforward solution. -- 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 10:13, Matteo <matteob8(a)yahoo.it> wrote: > > thanks Jhoan for the explanation! > Do you know some technique to intercept this kind bug? (...or to avoid > them?) > > thanks > Matteo

Sept. 8, 2016