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

Re: [Pharo-dev] About better communication in the community

by stepharo

Definitively :) I started to do that when I discovered Smalltalk. I wanted to learn and I read the submissions of people and try to understand and comment. And I learned a lot about the system, about myself, about quality. Stef Le 25/8/16 Ã 17:31, Gour a Ã©crit : > On Thu, 25 Aug 2016 09:05:45 +0200 > stepharo <stepharo(a)free.fr> wrote: > >> Yes but we cannot do much > OK. I got it...do you believe it makes sense for a noob to create acount > in case there are some low-hanging fruits to pick? > > > Sincerely, > Gour >

Aug. 26, 2016

help needed to avoid komitter to crash

by stepharo

Hi guys I need your wise point of view on my fix https://pharo.fogbugz.com/f/cases/18983/Kommitter-is-not-working-when-invok… Stef (dead after intense ESUG)

Aug. 26, 2016

Re: [Pharo-dev] About better communication in the community

by stepharo

> > About GT I have some concerns too now I see also a lot of > improvements. I love GTInspector and we should remove EyeInspector. > > I want to have once brick is out another minimal environment not > based on anything so that we can have a back-door to debug when > the other tools have a problems. > > > Cool you are considering this situation. We **always** considered it because we aim at building minimal kernels but if Pharo would be only about that then nobody would use it. In PetitsBazars/Ondo is a little try I did to understand what I wanted. And we are not just considering it. We should have it. Now I was waiting for better widgets because I started to hate pluggable* Now if you have the code of the old inspector at hand package it and we will include it and remove the eyeinspector. > > Now some answers: > > > > I'm afraid my english is good enough to provide clear feedback. I try > to do my best without offending anyone (see below) I understand really well what you mean. :) Now the key points is how can we turn things positively. Sorry but > > - you would be surprised by how many people would vote to get > GT tools inside Pharo :) > > > In my opinion is because it is biased by the same people who is > behind, or invested time testing/fixing it, and we are few to have a > valuable N. This will never be fair, newbies will ignore the old > inspector/explorer (yes, the old one from Squeak) was just fine and > was easily understandable and extensible just adding a few methods. > And, I repeat in my opinion, a new inspector isn't really a high > priority for our world problems (big data is, for example), much less > a framework.... So that's my view on it. > > But that's all, decision was taken. Now we have to move on. No I want a basic inspector in the system :) > > - then I do not know what to tell you because I'm quite sure > that Apache or Mozilla are not managed by vote of people. > > > Just a few references you, or the board, may consider for the future : > > Python: https://www.python.org/psf/membership/#who-is-allowed-to-vote > <https://www.python.org/psf/membership/#who-is-allowed-to-vote> > KDE : " A "KDE Core Team" uses a democratic voting procedure to > resolve important issues " > Apache HTTPD : " Proposed changes are voted upon via mailing list; 3 > yes votes with no vetos are required to commit a change " > Mozilla : "A review and super-review process is required for most code > changes." > > http://flosshub.org/sites/flosshub.org/files/HalloranScherlis.pdf > <http://flosshub.org/sites/flosshub.org/files/HalloranScherlis.pdf> > > "It is important to keep users involved in the process and not treat > them as second-class citizens." > Richard P. Gabriel > http://www.dreamsongs.com/IHE/IHE-52.html > <http://www.dreamsongs.com/IHE/IHE-52.html> We are not treating people as second citizens. > > > > To be clear, it's not against GT specifically (I don't like it, too > slow, takes too much space, etc) but the integration process behind, > where the board delivered it and seemed to said f**ck you this must be > loved, deal with it if don't. But then we don't have an easy way too > uninstall it, I have to spend days investigating how to remove it > disabling settings in specific order, and without leaving obsolete > instances all around. So what's my proposal for a next release? Can you publish the unload process? > Respect the freedom of choice for people which is not obligated to > love all your tools, by providing an uninstall option (if the tool is > not really essential) I agree about the Unload.... Joseph Pelrine always told me that we are only done when we can upload and that the system is in a good shape. You may not know it because I spent days working on configuration of RB and friends The problems is that it is a hell to keep them up to date (because of our image). We should have a building process from a seed. Because like that you experiment every single day that you loading script. Now we did not stress enough the unload of Metacello. Now you see Pharo cannot be an empty shell. Because what will happen if we are always listening to someone that does not like something. Now I strongly encourage you to watch the esug talk about bootstrap because with it and all the work of Pavel to define configurations for all the part of the system so people will be able to build their solutions when the official version does not suite their needs. > >> >> I would love to have the time to invite you, or any GT developer, >> to work with me just one week with real DNA data, and see how >> well GT goes... > > Please do a skype sharing session with Andrei and Doru. I'm sure > that they will love to do it. > So I take your words and urge you do it. > It will help you to get out your frsutration and I'm sure that GT > will improve. > So a clear win/win situation. > > > This is hard for me because I'm sure at this point Andrei and Doru > should be angry with me for ciriticizing their work. No I do not think so :) I criticized their tools too. > But I will try to make some use cases these days and share with you so > I can show you specifically what I'm talking about. Excellent! >> Understood, what makes me most sad is users almost accepted they >> cannot do better and if they do, their work will never be >> integrated by default. > No do better. > Why I started Spec when ther was Glamour. Why Alain was working on > Calipso? > I would love that someone comes and tell me: take XX it is super > hyper cool UI Builder. > > > Me too, and by this point we should really ask ourselves why we don't > have yet a cool UI Builder. Because nobody did it in a way that we can use it. One guy worked alone on a private project long time ago. We could not give him any feedback because he wanted to have it perfect in the first place. He stoped to work on it because of bad table support. I looked at it once he opened-source it and you would not like to have the code in Pharo. Stef > > HernÃ¡n > >> Instead, non-voters decisions discourages users to be rewarded >> for their creativity, and imposes many others to work free >> "supporting" tools which were imposed de facto. >> >> So again, I cannot stress this enough: Is my job to say no. I >> know I hurt some people but social development is complicated. >> I do not think I do a bad job :) >> >> >> Me neither, but you cannot expect conformity from all of us. >> >> HernÃ¡n >> >> cheers! >> Esteban >> >>> On 24 Aug 2016, at 09:38, stepharo <stepharo(a)free.fr >>> <mailto:stepharo@free.fr>> wrote: >>> >>> Hi Hernan >>> >>> First thanks for your email because we may disagree but we >>> often agree. :) so this is an email for me. >>>> Hi Stef, >>>> >>>> Good communication implies being clear when writing about >>>> sensitive topics, especially when communicating through >>>> virtual channels. I am not in Europe, so I cannot discuss >>>> these things with you face to face. >>> This is what we want to change with montly videos meeting. >>>> Therefore is not clear to me (and others) what are your >>>> policies in many subjects. Lately I also delayed the >>>> release of packages because my lack of motivation around >>>> this community, specially when discussions exists around >>>> three or fourth topics for months. >>> >>> Like what? >>> Let us know because we do not >>>> Another "motivational" case for me. I stopped to report >>>> bugs in fogbuz because I felt there was too much "Won't >>>> fix" for me (specifically by a person but I won't go >>>> there...) even in cases where it was ilogical. Then I felt >>>> tired of reading "It's like that. Invalid". >>> This is a pity. >>> I know the feeling because some of mine are close too. You >>> are not the only victim of the "Issue closing syndrom" ;). >>> And I would like the syndrome to be more human friendly. >>> Thanks for raising this point. >>> >>> Now two points >>> - You should always send a mail to the mailing-list and >>> that we discuss your points. >>> >>> - Now what will happen if we all open bugs and none of >>> us works on the open bugs. >>> So what is the solution for you. I mean it concretely. How >>> to deal with dying >>> >>> Looking at bugs is really difficult. There are not enough >>> people looking and fixing bugs. >>> >>>> About features. >>>> >>>> What's the policy about voting for default features in next >>>> Pharo images? Let's suppose I am a VM/core Pharo maintainer >>>> and I want to include MySuperPackage into a Pharo release, >>>> which nobody needs (and I don't care), but it is useful to >>>> me.... there will ever be voting there? (note it doesn't >>>> makes sense if you are a group of 50 always supporting your >>>> work) >>> >>> It does not really work because engineers are paid for >>> certain task. >>>> Images are becoming huge (at least for my workflows). There >>>> will be (more) packages included by default (for promotion?) ? >>> Thanks to raise this point because I mentioned it also to >>> the board. So I like when I'm not alone. >>> Now we should not see look only at the size. Doing nothing >>> is size zero :) >>> The point is what are the functionalities delivered. >>> >>> Three points: >>> - what are the key things we want? >>> keybinding, settings, cool inspector cool.... >>> >>> - how many duplicated functionality can we remove: >>> for example I want to merge MCDefinitions with >>> Ring with RBDefinition >>> we removed pseudo* >>> but this is a lot of work >>> >>> The goal is to throw many system when bloc and >>> brick are ready >>> >>> - what is the list of things that you would remove? >>> >>> - with the bootstrap and all the packages of the image >>> managed with Cargo plus the git management >>> we believe that we will be able to manage a set of >>> images with minimal images. >>> - this is several years that we are working on >>> this goal. >>> Believe me this is the vision document not for >>> the sake of it. >>> >>>> How do you plan to manage if some people want the Tests be >>>> removed from the official Image? (Personally I never run them) >>> - then you use a jenkins job to produce your image where >>> you unload the tests. >>> >>>> Another example, what happens if another research group >>>> came with a better alternative to Calypso, Brick, >>>> Telescope, Bloc. Would you integrate first your tool to >>>> mark territory? >>> >>> No this is not a question of territory. Doru and GT does >>> not do that in that spirit. >>> RMOD too. We do something when we think that this is >>> better. >>> For example Epicea is three years of work of Martin, >>> Fuel was so nice that we could not lose it. >>> You see Ghost got changed by denis, Seamless got >>> rewritten from scratch. >>> >>>> Who decides? For example (IIRC) TxText and Twisty. >>> Igor looked at Twisty seriously and I do not think that >>> it could handle large cobol files. >>> >>> (you see funnily denis is doing the same with Seamless - >>> He rewrote it from scratch while >>> nick worked on it for several years). >>> >>> Igor wanted to have a stream-based API that could work >>> on modern command-oriented videos card framework. >>> My team (on our own money if you understand what it means) >>> paid Igor to build TxText (and I can tell you that I >>> would have prefered him to do something else). >>> >>> >>>> The same applies if anyone came with another rewrite of >>>> classic Smalltalk Workspace, Debugger and Inspector tools, >>>> what would you do with GT? GT stays because it came before >>>> and others would be optional? >>> No this is not like that. >>> If you are better or answer better needs. >>> >>>> There will be anything like PEPs? >>> I would love but will people have the energy to >>> implement them? >>> I would definitively encourage you as a community to >>> raise points on what you need. >>> >>>> If someone can answer me I think that would be an example >>>> of good communication. >>> Hernan I always answered your emails. I always consider >>> your work (and you know it for other reasons and by my >>> facts) after I'm not always in agreement as I'm not always >>> in agreement with other board members and this is how live >>> happens. >>> What is clear is that the most important aspects is to >>> continue to communicate. This is why the board is launching >>> this initiative and I would love to see it taken by >>> people even for their projects. >>> >>> >>>> >>>> HernÃ¡n >>>> >>>> >>>> 2016-08-24 1:51 GMT-03:00 stepharo <stepharo(a)free.fr >>>> <mailto:stepharo@free.fr>>: >>>> >>>> Hi guys >>>> >>>> the board got a good discussion at ESUG about how to >>>> improve and a lot of the discussion turned around >>>> improving communication. We got some ideas that we will >>>> propose soon but I would like to get *your* ideas. >>>> >>>> If you have idea about improving communication around >>>> pharo please tell us. >>>> >>>> >>>> Stef >>>> >>>> >>>> >>> >> >> > >

Aug. 26, 2016

Bloc question

by Alexandre Bergel

Hi! In the class BlElement, what are the meaning of the variables: misc cursor ? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 26, 2016

[ANN] TaskIt v0.2

by Guille Polito

Hi all, With Santi we wanted to share a new release of TaskIt, a concurrency management library for Pharo. TaskIt development is done entirely in github, using iceberg. Works like a charm. Please find below attached the changes log with more information. Cheers, Guille & Santi TaskIt https://github.com/sbragagnolo/taskit TaskIt is a library that ease Process usage in Pharo. It provides abstractions to execute and synchronize concurrent tasks, and several pre-built mechanisms that are useful for many application developers. This chapter explores starts by familiarizing the reader with TaskIt's abstractions, guided by examples and code snippets. At the end, we discuss TaskIt extension points and possible customizations. ChangesLog TaskIt v0.2 Major Features * Task Runners o NewProcessTaskRunner o LocalProcessTaskRunner o Worker o WorkerPool * Futures with callbacks * Future combinators * Future synchronous access * Services Infrastructure * Travis CIhttps://travis-ci.org/sbragagnolo/taskit * Documentationhttps://github.com/sbragagnolo/taskit/blob/master/README.md Minor changes log (from commits) * Enhanced class comments * TKTWorker processes are terminated in case the worker is collected. See Issues#8 <https://github.com/sbragagnolo/taskit/issues/8>and#5 <https://github.com/sbragagnolo/taskit/issues/5> * Process Dashboard. - Adds TKTTaskItProcessProvider by default with the extension package - Hides job and task fields since there are not reachable any more.

Aug. 26, 2016

Re: [Pharo-dev] About Pharo 60

by phil＠highoctane.be

List: * image size management under control * no more gradients in that UI (even in the light theme) * modern "Material style" UI * FASTER Nautilus * better console support (in/out) * Pharo VM as something I can embed in other programs * something like npm.js for the packages list along with external package manager to build my images * integration with Hadoop ecosystem * super easy to write REST clients and servers (including Swagger support) Phil On Fri, Aug 26, 2016 at 10:15 AM, stepharo <stepharo(a)free.fr> wrote: > Thanks Peter > > I cannot find the list, but there were some things we discussed during > consortium call a month or so ago. Maybe Esteban can find it? > > I want for Christmas > > * Better Spec > * Roadmap so we know where we are going, > * with clean API, > * so we can build really live UIs (where you can drag windows around, > close them, dock them, etc. > * so we are ready for Bloc (can be for Easter too :)) > * Stability > * I crash daily > > Obviously I can and I try to help with Spec, but I do not have the time or > resources to lead it, and since we don't have any roadmap it's hard to go > forward. > > > I should say that I'm a bit stuck to understand where to start and > what we want to achieve. > The firs things I would do > - Reading all the code to get a feel. > - I would like to rename the class consistently a Model should be > named Presenter and the Model whose name do not contain Model should still > be renamed to contain Presenter. > > I need to review the changes made by marion and that have been > published. > > Stef > > > > > > >

Aug. 26, 2016

Re: [Pharo-dev] About asClass and friend

by phil＠highoctane.be

On Fri, Aug 26, 2016 at 10:07 AM, Guille Polito <guillermopolito(a)gmail.com> wrote: > Hi! > > 1) I think we are failing also at communicating one point better. It is > not that people is arguing against #asClass because it's ugly and bad and a > terrible villain. Ok, maybe a bit, but also: > > The point is that #asClass, as it looks handy and easy to use, it may > not work in the future. > > Why? > > Because if you imaging a Pharo with modules, explicit imports, and even > namespaces, then you may have several classes with the same name. And then > you may have name clashes. And #asClass will not have a single obvious > result. And that makes #asClass both impractical and with no sense at the > same time. > > One other reality: > > - We are thinking about a problem we do not yet have... :) > > 2) Then, I agree with Doru, with Luc and with (E)(Ste(f|ban)). But I also > agree with Phil and myself. And my position says: > > - Let the kernel be clean. There should not be an #asClass or similar > implementation as part of the kernel. This extension should exist not as > part of the kernel but as part of other package (I'd vote for > ScriptingExtensions for example). > > - Let the kernel be clean (bis). We should not have users of such > *scripting nicety* inside the kernel. We should put in place a lint rule to > validate that. > 100% agreeing with that. I understand that concern. Not a stranger to Java ClassLoading madness in JEE, well, yeah. > > - But we should let people use #asClass if they want in their code! And > thus we should not deprecate it. We should not control what Phil does to > get business. I agree that Pharo itself should not use #asClass, but also > that (a good implementation of) #asClass or similar should be available for > him. At the end, there will be so many packages and libraries out there > that we have to realize we can only guarantee that Pharo gives you an > empowering environment and people will use it and do whatever they want :). > One reason I like Pharo is also that I can work *without* all of that package annoying concern in my user level code. Just one flat namespace, easy to deal with. VisualWorks does something like that with a default namespace as it seems. Now, namespaced packages are good, but only if one needs them. Comparing the Pharo with the Java codebases I've got here, well, navigating Pharo is much easier and one can really grok a good amount of stuff. The kernel and user space separation has been somewhat there for ages. Unix anyone? I don't care about how the kernel is done as long as I have my API available and I can load the .so I need. > > I updated the issue with some of these ideas > > https://pharo.fogbugz.com/f/cases/18987/Extract-asClass-and- > friends-in-a-separate-package-and-deprecate > > Guille > > -------- Original Message -------- > >> Hi, >> >> On Aug 26, 2016, at 9:10 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >>> On 26 Aug 2016, at 08:49, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> My point of view is: >>>> >>>> 1) in code/core, we should use (we already said that with Camille in >>>> the past ;-)): >>>> >>>> self environmentAt: #Blah >>>> >>>> Object>>environmentAt: aSymbol >>>> ^ self class environmentAt: aSymbol >>>> >>>> Object class>>environmentAt: aSymbol >>>> ... >>>> >>>> The idea is that we can then customize name resolution, per object, per >>>> class and per module in the future. >>>> >>> +1 >>> >>> 2) For scripting purpose, asClass is indeed useful (GTInspector, ...). >>>> I would start simple as said before, re-package it and add a rule as >>>> suggested by Denis. >>>> Now, I am not sure that making asClass supporting name resolution in >>>> another environment is really useful. >>>> And if we do it using thisContext, some developers may use that instead >>>> of "obj environmentAt: XXX" which would be bad. >>>> >>> I dislike a lot the thisContext resolution idea. >>> If is bad is badâ¦ and it will be bad also for scripting. I know, now it >>> does not looks like adding value, but think about: #asClass is monolithic >>> and #asClass with thisContext âlooks monolithicâ, IMO promoting a bad way >>> of thinking problems in Pharo thus inducing confusion for non expert users. >>> >> No problem from my side. It was a proposal. I wanted to learn a bit and I >> was looking for concrete arguments to learn from because I am likely >> missing something. I still do not know why it is bad, but it is really not >> important for the current issue. >> >> So, we agree that: >> - move asClass together with all other in a separate package. >> - introduce deprecation. >> >> I created an issue: >> https://pharo.fogbugz.com/f/cases/18987/Extract-asClass-and- >> friends-in-a-separate-package-and-deprecate >> >> Doru >> >> >> >> Esteban >>> >>> my 2KÄ, >>>> >>>> #Luc >>>> >>>> 2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>> Hi, >>>> >>>> >>>> >>>> On Aug 26, 2016, at 6:37 AM, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> Thanks doru. >>>>> >>>>> I do not like when people think that we are complaining just because >>>>> something changes. >>>>> >>>>> It should change for the better and we all agree on that. >>>>> >>>> Certainly. There are many points of view and many constraints. This is >>>> why it is so important that we all bring forward those constraints because >>>> only like this we can reach a global maximum. >>>> >>>> So, about asClass, everyone agrees that it should be moved to another >>>> package. The open questions are: >>>> - do we add an automatic deprecation for those that use it in code, or >>>> - do we make use of thisContext to retrieve the environment? >>>> (or both) >>>> >>>> Also, what about the asClassInEnvironment: method? Can it be used in >>>> code, or do we better discourage its usage altogether? I am thinking that >>>> if we have to write: >>>> #MyClass asClassInEnvironment: self class environment >>>> is even longer than: >>>> self environment at: #MyClass >>>> so, I think there is little point to it. >>>> >>>> In fact, for scripting what I find useful is not so much less >>>> characters, but the lack of parentheses, hence unary methods. That is why >>>> asClass is worth being salvaged for scripting (even with a solution that is >>>> slower with thisContext), but the rest maybe can be removed. What do you >>>> think? >>>> >>>> Cheers, >>>> Doru >>>> >>>> Stef >>>>> >>>>> >>>>> Hi, >>>>>>>>>> >>>>>>>>>> There exists already a method for that: >>>>>>>>>> Symbol>>asClassInEnvironment: >>>>>>>>>> >>>>>>>>>> But, what if we introduce: >>>>>>>>>> >>>>>>>>>> Symbol>>asClassFrom: anObject >>>>>>>>>> ^ self asClassInEnvironment: anObject class environment >>>>>>>>>> >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>> The problem is asClass unary. >>>>>>>>> >>>>>>>>> All the tools should be parametrized by an environment. >>>>>>>>> >>>>>>>> Yes, but asClassFrom: would not be unary but would save us from >>>>>>>> typing an extra "class environment" :). >>>>>>>> >>>>>>> Yes I see. >>>>>>> But inside Pharo core tools we are ready to type >>>>>>> environment as a message that dispatch to something else than a >>>>>>> symbol. >>>>>>> >>>>>> Sure. >>>>>> >>>>>> This would allow us to still script and be dynamic. >>>>>>>>>> >>>>>>>>>> Furthermore, as #asClass is meant to be mainly used for >>>>>>>>>> convenience, not performance, I would also propose to make it lookup in >>>>>>>>>> thisContext and take the environment from there. I know that his might >>>>>>>>>> sound like magic, but it would be the default that we are looking for (to >>>>>>>>>> always lookup through the current environment dynamically). >>>>>>>>>> >>>>>>>>> argh I will die....:) >>>>>>>>> No use of thisContext or only in the scripting package. >>>>>>>>> :D >>>>>>>>> >>>>>>>>> Yes, yes. I just talked with Guille. Moving these scripting >>>>>>>>> methods outside of the Kernel is clearly a must. >>>>>>>>> >>>>>>>> I think that each time you use them we will preempt cross >>>>>>> compilation and others. >>>>>>> >>>>>> Yes, we agree that this method should not be used inside code. >>>>>> >>>>>> I was just thinking that we can make it so that we do not break any >>>>>>>>> code while still making it dynamic. >>>>>>>>> >>>>>>>> I do not like your definition of dynamic. Sending a message to an >>>>>>> object is dynamic. >>>>>>> What you imply is compact. I can understand it when typing in >>>>>>> playground. >>>>>>> >>>>>> By dynamic I meant the dispatch through âself class environmentâ or >>>>>> âself environmentâ which is what people will use by default. >>>>>> >>>>>> >>>>>> Like with scripting solutions there is a performance penalty, but >>>>>>>>> that is fine if people choose to pay it (like in the case of >>>>>>>>> Symbol>>#value:). >>>>>>>>> >>>>>>>> Yes for scripts. Not for core code. >>>>>>> Since people tend to be a bit lazy I think that having rules will >>>>>>> make sense. >>>>>>> >>>>>> Definitely. >>>>>> >>>>>> Doru >>>>>> >>>>>> Cheers, >>>>>>>>> Doru >>>>>>>>> >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Doru >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Aug 25, 2016, at 8:34 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Just my 2 cents: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> instead of >>>>>>>>>>> >>>>>>>>>>> #name asClass >>>>>>>>>>> >>>>>>>>>>> we have to use >>>>>>>>>>> >>>>>>>>>>> self class environment at: #name. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Maybe instead of #at: we can have #classNamed:? Or something >>>>>>>>>>> similar? Because 1) itâs not obvious that the method will give you a class, >>>>>>>>>>> what if in the future and environment can also have a mapping of something >>>>>>>>>>> else like packages? >>>>>>>>>>> >>>>>>>>>>> Uko >>>>>>>>>>> >>>>>>>>>>> On 25 Aug 2016, at 07:21, stepharo <stepharo(a)free.fr> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi guys >>>>>>>>>>>> >>>>>>>>>>>> We got a meeting at ESUG with all the compiler guys and james >>>>>>>>>>>> from gemstone. >>>>>>>>>>>> >>>>>>>>>>>> Our goal is to have a full tool suite that can be parametrized >>>>>>>>>>>> by environments (so that >>>>>>>>>>>> >>>>>>>>>>>> we can compile code in other space, or compile other code >>>>>>>>>>>> inside pharo). >>>>>>>>>>>> >>>>>>>>>>>> I personnally started this effort one decade ago. Now the >>>>>>>>>>>> introduction >>>>>>>>>>>> >>>>>>>>>>>> of #asClass and friend is simply destroying all our efforts. >>>>>>>>>>>> There was a discussion >>>>>>>>>>>> >>>>>>>>>>>> in the past but we are not listened. >>>>>>>>>>>> >>>>>>>>>>>> We will >>>>>>>>>>>> >>>>>>>>>>>> - packaged these extensions in a separate package >>>>>>>>>>>> >>>>>>>>>>>> - add rules to ban the use of such method in Pharo >>>>>>>>>>>> >>>>>>>>>>>> - fix all the use (again) to use the correct way to do it. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I can understand that for scripting this is easier but it >>>>>>>>>>>> cannot be at that cost and impact. >>>>>>>>>>>> >>>>>>>>>>>> I hope that we will understand but we have to do something else >>>>>>>>>>>> than >>>>>>>>>>>> >>>>>>>>>>>> fixing code that breaks our effort. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Stef, Marcus, Guille and Luc >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>> www.tudorgirba.com >>>>>>>>>> www.feenk.com >>>>>>>>>> >>>>>>>>>> "It's not what we do that matters most, it's how we do it." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> www.feenk.com >>>>>>>> >>>>>>>> "Quality cannot be an afterthought." >>>>>>>> >>>>>>> -- >>>>>> www.tudorgirba.com >>>>>> www.feenk.com >>>>>> >>>>>> "Every thing has its own flow." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Every thing should have the right to be different." >>>> >>> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> >> >> >> >> > > >

Aug. 26, 2016

Re: [Pharo-dev] About asClass and friend

by phil＠highoctane.be

On Fri, Aug 26, 2016 at 9:10 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 26 Aug 2016, at 08:49, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > Hi, > > My point of view is: > > 1) in code/core, we should use (we already said that with Camille in the > past ;-)): > > self environmentAt: #Blah > > Object>>environmentAt: aSymbol > ^ self class environmentAt: aSymbol > > Object class>>environmentAt: aSymbol > ... > > The idea is that we can then customize name resolution, per object, per > class and per module in the future. > > > +1 > > > 2) For scripting purpose, asClass is indeed useful (GTInspector, ...). > I would start simple as said before, re-package it and add a rule as > suggested by Denis. > Now, I am not sure that making asClass supporting name resolution in > another environment is really useful. > And if we do it using thisContext, some developers may use that instead of > "obj environmentAt: XXX" which would be bad. > > > I dislike a lot the thisContext resolution idea. > If is bad is badâ¦ and it will be bad also for scripting. I know, now it > does not looks like adding value, but think about: #asClass is monolithic > and #asClass with thisContext âlooks monolithicâ, IMO promoting a bad way > of thinking problems in Pharo thus inducing confusion for non expert users. > This makes me think about DynamicVariables for some reason. Will we get interference in that "context" ? Phil > > Esteban > > > my 2KÄ, > > #Luc > > 2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> >> >> > On Aug 26, 2016, at 6:37 AM, stepharo <stepharo(a)free.fr> wrote: >> > >> > Thanks doru. >> > >> > I do not like when people think that we are complaining just because >> something changes. >> > >> > It should change for the better and we all agree on that. >> >> Certainly. There are many points of view and many constraints. This is >> why it is so important that we all bring forward those constraints because >> only like this we can reach a global maximum. >> >> So, about asClass, everyone agrees that it should be moved to another >> package. The open questions are: >> - do we add an automatic deprecation for those that use it in code, or >> - do we make use of thisContext to retrieve the environment? >> (or both) >> >> Also, what about the asClassInEnvironment: method? Can it be used in >> code, or do we better discourage its usage altogether? I am thinking that >> if we have to write: >> #MyClass asClassInEnvironment: self class environment >> is even longer than: >> self environment at: #MyClass >> so, I think there is little point to it. >> >> In fact, for scripting what I find useful is not so much less characters, >> but the lack of parentheses, hence unary methods. That is why asClass is >> worth being salvaged for scripting (even with a solution that is slower >> with thisContext), but the rest maybe can be removed. What do you think? >> >> Cheers, >> Doru >> >> > >> > Stef >> > >> > >> >>>>>> Hi, >> >>>>>> >> >>>>>> There exists already a method for that: >> >>>>>> Symbol>>asClassInEnvironment: >> >>>>>> >> >>>>>> But, what if we introduce: >> >>>>>> >> >>>>>> Symbol>>asClassFrom: anObject >> >>>>>> ^ self asClassInEnvironment: anObject class environment >> >>>>>> >> >>>>>> ? >> >>>>> The problem is asClass unary. >> >>>>> >> >>>>> All the tools should be parametrized by an environment. >> >>>> Yes, but asClassFrom: would not be unary but would save us from >> typing an extra "class environment" :). >> >>> Yes I see. >> >>> But inside Pharo core tools we are ready to type >> >>> environment as a message that dispatch to something else than a >> symbol. >> >> Sure. >> >> >> >>>>>> This would allow us to still script and be dynamic. >> >>>>>> >> >>>>>> Furthermore, as #asClass is meant to be mainly used for >> convenience, not performance, I would also propose to make it lookup in >> thisContext and take the environment from there. I know that his might >> sound like magic, but it would be the default that we are looking for (to >> always lookup through the current environment dynamically). >> >>>>> argh I will die....:) >> >>>>> No use of thisContext or only in the scripting package. >> >>>>> :D >> >>>>> >> >>>>> Yes, yes. I just talked with Guille. Moving these scripting methods >> outside of the Kernel is clearly a must. >> >>> I think that each time you use them we will preempt cross compilation >> and others. >> >> Yes, we agree that this method should not be used inside code. >> >> >> >>>>> I was just thinking that we can make it so that we do not break any >> code while still making it dynamic. >> >>> I do not like your definition of dynamic. Sending a message to an >> object is dynamic. >> >>> What you imply is compact. I can understand it when typing in >> playground. >> >> By dynamic I meant the dispatch through âself class environmentâ or >> âself environmentâ which is what people will use by default. >> >> >> >> >> >>>>> Like with scripting solutions there is a performance penalty, but >> that is fine if people choose to pay it (like in the case of >> Symbol>>#value:). >> >>> Yes for scripts. Not for core code. >> >>> Since people tend to be a bit lazy I think that having rules will >> make sense. >> >> Definitely. >> >> >> >> Doru >> >> >> >>>>> Cheers, >> >>>>> Doru >> >>>>> >> >>>>> >> >>>>>> What do you think? >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Doru >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>>> On Aug 25, 2016, at 8:34 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> wrote: >> >>>>>>> >> >>>>>>> Just my 2 cents: >> >>>>>>> >> >>>>>>> >> >>>>>>> instead of >> >>>>>>> >> >>>>>>> #name asClass >> >>>>>>> >> >>>>>>> we have to use >> >>>>>>> >> >>>>>>> self class environment at: #name. >> >>>>>>> >> >>>>>>> >> >>>>>>> Maybe instead of #at: we can have #classNamed:? Or something >> similar? Because 1) itâs not obvious that the method will give you a class, >> what if in the future and environment can also have a mapping of something >> else like packages? >> >>>>>>> >> >>>>>>> Uko >> >>>>>>> >> >>>>>>>> On 25 Aug 2016, at 07:21, stepharo <stepharo(a)free.fr> wrote: >> >>>>>>>> >> >>>>>>>> Hi guys >> >>>>>>>> >> >>>>>>>> We got a meeting at ESUG with all the compiler guys and james >> from gemstone. >> >>>>>>>> >> >>>>>>>> Our goal is to have a full tool suite that can be parametrized >> by environments (so that >> >>>>>>>> >> >>>>>>>> we can compile code in other space, or compile other code inside >> pharo). >> >>>>>>>> >> >>>>>>>> I personnally started this effort one decade ago. Now the >> introduction >> >>>>>>>> >> >>>>>>>> of #asClass and friend is simply destroying all our efforts. >> There was a discussion >> >>>>>>>> >> >>>>>>>> in the past but we are not listened. >> >>>>>>>> >> >>>>>>>> We will >> >>>>>>>> >> >>>>>>>> - packaged these extensions in a separate package >> >>>>>>>> >> >>>>>>>> - add rules to ban the use of such method in Pharo >> >>>>>>>> >> >>>>>>>> - fix all the use (again) to use the correct way to do it. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> I can understand that for scripting this is easier but it cannot >> be at that cost and impact. >> >>>>>>>> >> >>>>>>>> I hope that we will understand but we have to do something else >> than >> >>>>>>>> >> >>>>>>>> fixing code that breaks our effort. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Stef, Marcus, Guille and Luc >> >>>>>>>> >> >>>>>>>> >> >>>>>> -- >> >>>>>> www.tudorgirba.com >> >>>>>> www.feenk.com >> >>>>>> >> >>>>>> "It's not what we do that matters most, it's how we do it." >> >>>>>> >> >>>>>> >> >>>>>> >> >>>> -- >> >>>> www.tudorgirba.com >> >>>> www.feenk.com >> >>>> >> >>>> "Quality cannot be an afterthought." >> >> -- >> >> www.tudorgirba.com >> >> www.feenk.com >> >> >> >> "Every thing has its own flow." >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every thing should have the right to be different." >> >> >> >> >> >> > >

Aug. 26, 2016

Re: [Pharo-dev] About asClass and friend

by phil＠highoctane.be

On Fri, Aug 26, 2016 at 8:49 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Hi, > > My point of view is: > > 1) in code/core, we should use (we already said that with Camille in the > past ;-)): > > self environmentAt: #Blah > Makes sense, looks nice. > > Object>>environmentAt: aSymbol > ^ self class environmentAt: aSymbol > > Object class>>environmentAt: aSymbol > ... > > The idea is that we can then customize name resolution, per object, per > class and per module in the future. > > 2) For scripting purpose, asClass is indeed useful (GTInspector, ...). > I would start simple as said before, re-package it and add a rule as > suggested by Denis. > Now, I am not sure that making asClass supporting name resolution in > another environment is really useful. > For me, #Symbol asClass is really for yet unknown things with scripts (build or configuration). To avoid those pesky errors in the loading process. I just love being able to do (#ConfigurationOfXYZ asClass project ... ) load in an image building script that doesn't yet have a clue of ConfigurationOfXYZ b/c Gofer will load the packages. Same story when loading specific packages based on a configuration file symbol. config: Config equipmentSupportPackageSpec: #EquipmentXYZSupportPackage. Config>>equipmentSupportPackage ^ self equipmentSupportPackageSpec asClass new I can live with the new way but this just feels handy as hell. > And if we do it using thisContext, some developers may use that instead of > "obj environmentAt: XXX" which would be bad. > > > my 2KÄ, > Thanks for chiming in. Phil > > #Luc > > 2016-08-26 6:56 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> >> >> > On Aug 26, 2016, at 6:37 AM, stepharo <stepharo(a)free.fr> wrote: >> > >> > Thanks doru. >> > >> > I do not like when people think that we are complaining just because >> something changes. >> > >> > It should change for the better and we all agree on that. >> >> Certainly. There are many points of view and many constraints. This is >> why it is so important that we all bring forward those constraints because >> only like this we can reach a global maximum. >> >> So, about asClass, everyone agrees that it should be moved to another >> package. The open questions are: >> - do we add an automatic deprecation for those that use it in code, or >> - do we make use of thisContext to retrieve the environment? >> (or both) >> >> Also, what about the asClassInEnvironment: method? Can it be used in >> code, or do we better discourage its usage altogether? I am thinking that >> if we have to write: >> #MyClass asClassInEnvironment: self class environment >> is even longer than: >> self environment at: #MyClass >> so, I think there is little point to it. >> >> In fact, for scripting what I find useful is not so much less characters, >> but the lack of parentheses, hence unary methods. That is why asClass is >> worth being salvaged for scripting (even with a solution that is slower >> with thisContext), but the rest maybe can be removed. What do you think? >> >> Cheers, >> Doru >> >> > >> > Stef >> > >> > >> >>>>>> Hi, >> >>>>>> >> >>>>>> There exists already a method for that: >> >>>>>> Symbol>>asClassInEnvironment: >> >>>>>> >> >>>>>> But, what if we introduce: >> >>>>>> >> >>>>>> Symbol>>asClassFrom: anObject >> >>>>>> ^ self asClassInEnvironment: anObject class environment >> >>>>>> >> >>>>>> ? >> >>>>> The problem is asClass unary. >> >>>>> >> >>>>> All the tools should be parametrized by an environment. >> >>>> Yes, but asClassFrom: would not be unary but would save us from >> typing an extra "class environment" :). >> >>> Yes I see. >> >>> But inside Pharo core tools we are ready to type >> >>> environment as a message that dispatch to something else than a >> symbol. >> >> Sure. >> >> >> >>>>>> This would allow us to still script and be dynamic. >> >>>>>> >> >>>>>> Furthermore, as #asClass is meant to be mainly used for >> convenience, not performance, I would also propose to make it lookup in >> thisContext and take the environment from there. I know that his might >> sound like magic, but it would be the default that we are looking for (to >> always lookup through the current environment dynamically). >> >>>>> argh I will die....:) >> >>>>> No use of thisContext or only in the scripting package. >> >>>>> :D >> >>>>> >> >>>>> Yes, yes. I just talked with Guille. Moving these scripting methods >> outside of the Kernel is clearly a must. >> >>> I think that each time you use them we will preempt cross compilation >> and others. >> >> Yes, we agree that this method should not be used inside code. >> >> >> >>>>> I was just thinking that we can make it so that we do not break any >> code while still making it dynamic. >> >>> I do not like your definition of dynamic. Sending a message to an >> object is dynamic. >> >>> What you imply is compact. I can understand it when typing in >> playground. >> >> By dynamic I meant the dispatch through âself class environmentâ or >> âself environmentâ which is what people will use by default. >> >> >> >> >> >>>>> Like with scripting solutions there is a performance penalty, but >> that is fine if people choose to pay it (like in the case of >> Symbol>>#value:). >> >>> Yes for scripts. Not for core code. >> >>> Since people tend to be a bit lazy I think that having rules will >> make sense. >> >> Definitely. >> >> >> >> Doru >> >> >> >>>>> Cheers, >> >>>>> Doru >> >>>>> >> >>>>> >> >>>>>> What do you think? >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Doru >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>>> On Aug 25, 2016, at 8:34 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> wrote: >> >>>>>>> >> >>>>>>> Just my 2 cents: >> >>>>>>> >> >>>>>>> >> >>>>>>> instead of >> >>>>>>> >> >>>>>>> #name asClass >> >>>>>>> >> >>>>>>> we have to use >> >>>>>>> >> >>>>>>> self class environment at: #name. >> >>>>>>> >> >>>>>>> >> >>>>>>> Maybe instead of #at: we can have #classNamed:? Or something >> similar? Because 1) itâs not obvious that the method will give you a class, >> what if in the future and environment can also have a mapping of something >> else like packages? >> >>>>>>> >> >>>>>>> Uko >> >>>>>>> >> >>>>>>>> On 25 Aug 2016, at 07:21, stepharo <stepharo(a)free.fr> wrote: >> >>>>>>>> >> >>>>>>>> Hi guys >> >>>>>>>> >> >>>>>>>> We got a meeting at ESUG with all the compiler guys and james >> from gemstone. >> >>>>>>>> >> >>>>>>>> Our goal is to have a full tool suite that can be parametrized >> by environments (so that >> >>>>>>>> >> >>>>>>>> we can compile code in other space, or compile other code inside >> pharo). >> >>>>>>>> >> >>>>>>>> I personnally started this effort one decade ago. Now the >> introduction >> >>>>>>>> >> >>>>>>>> of #asClass and friend is simply destroying all our efforts. >> There was a discussion >> >>>>>>>> >> >>>>>>>> in the past but we are not listened. >> >>>>>>>> >> >>>>>>>> We will >> >>>>>>>> >> >>>>>>>> - packaged these extensions in a separate package >> >>>>>>>> >> >>>>>>>> - add rules to ban the use of such method in Pharo >> >>>>>>>> >> >>>>>>>> - fix all the use (again) to use the correct way to do it. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> I can understand that for scripting this is easier but it cannot >> be at that cost and impact. >> >>>>>>>> >> >>>>>>>> I hope that we will understand but we have to do something else >> than >> >>>>>>>> >> >>>>>>>> fixing code that breaks our effort. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Stef, Marcus, Guille and Luc >> >>>>>>>> >> >>>>>>>> >> >>>>>> -- >> >>>>>> www.tudorgirba.com >> >>>>>> www.feenk.com >> >>>>>> >> >>>>>> "It's not what we do that matters most, it's how we do it." >> >>>>>> >> >>>>>> >> >>>>>> >> >>>> -- >> >>>> www.tudorgirba.com >> >>>> www.feenk.com >> >>>> >> >>>> "Quality cannot be an afterthought." >> >> -- >> >> www.tudorgirba.com >> >> www.feenk.com >> >> >> >> "Every thing has its own flow." >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every thing should have the right to be different." >> >> >> >> >> >> >

Aug. 26, 2016

Re: [Pharo-dev] About Pharo 60

by stepharo

Thanks Peter > I cannot find the list, but there were some things we discussed during > consortium call a month or so ago. Maybe Esteban can find it? > > I want for Christmas > > * Better Spec > * Roadmap so we know where we are going, > * with clean API, > * so we can build really live UIs (where you can drag windows > around, close them, dock them, etc. > * so we are ready for Bloc (can be for Easter too :)) > * Stability > * I crash daily > > Obviously I can and I try to help with Spec, but I do not have the > time or resources to lead it, and since we don't have any roadmap it's > hard to go forward. I should say that I'm a bit stuck to understand where to start and what we want to achieve. The firs things I would do - Reading all the code to get a feel. - I would like to rename the class consistently a Model should be named Presenter and the Model whose name do not contain Model should still be renamed to contain Presenter. I need to review the changes made by marion and that have been published. Stef > >

Aug. 26, 2016