- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About asClass and friend

by Tudor Girba

Hi, > On Aug 25, 2016, at 9:52 AM, stepharo <stepharo(a)free.fr> wrote: > > >> 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" :). >> 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 was just thinking that we can make it so that we do not break any code while still making it dynamic. 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:). 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."

Aug. 25, 2016

Re: [Pharo-dev] About asClass and friend

by stepharo

> 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. > 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. > > 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." > > >

Aug. 25, 2016

Re: [Pharo-dev] About asClass and friend

by stepharo

Le 25/8/16 Ã 08:34, Yuriy Tymchuk a Ã©crit : > 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:? Why not if it helps people :) > 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 >> >> > >

Aug. 25, 2016

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

by stepharo

> Let us know because we do not > > > I don't get why we don't have more discussions about end-developer > tools : XML, i18n, GIS, simulation & expert systems, big data, > reporting... Yes the idea is that we would like to try a process for Pharo and that such process can be used by other projects such as Moose. > > I think you could implement some reward system for devs with more bug > fixes: Interviews, consortium membership, maybe voting on some issues...? I wanted to have something like the bug fixers of the month but my plate is fuller than people can imagine. Now we pay really attention that work of many contributors/fixers get really reviewed fast. And this is a way to thank them for their energy and contributions. > >> About features > > > To me there a couple of things which must have two versions > (considering we lack a sub-image where to do image repairing). > > - Inspector: > -- One cool (this seems will ever be GT) > -- One bullet-proof very very limited (to repair GT when broken, or > minimal image) Definitively. Why don't you help me remove EyeInspector and build such low level inspector. > - System Browser > -- One cool (like Nautilus) > -- One standard (to not have an unusable image if the cool one gets > broken) Same here. I started to write one that is really really minimal two panes :) but I want real widgets. > > I see, never tried Jenkins for real (but maybe rethorical question: is > that true users need all the Tests in the image? To test a package > like Graphics-Test?) - No users do not need that but we do not want to have to load them when we need them. We can offer a jenkins account to you and you can build your image without any problem. They will even show up in PharoLauncher. >> 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). > > > So the money decides :) Not only, energy too. If you propose a basic inspector we will integrate it. When I said to inria give an engineer for doing X and X is key for the future of Pharo (put Athens, TxText, VM build, Package, Bootstrap....) I cannot ask two times so it has to be done. >> 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. > > > I would write a "PEP" if someone from the board seriously considers to > review it and integrate it (or not) with a clear communication. What do you mean integrate it. A PEP is first a description and then after we decide. We cannot give a free check but please write a PEP One page max. > 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. > > > Thank you Stef for raising this space to consider both good and > uncomfortable things. Thank. You see I think that the board was not communicating within itself too and we should address this. We cannot be all running like hamsters :) > I believe one day we -pharo users- have to take the world and show > what's happening here. Time passes and we have an unique chance of > changing the world through Pharo, our beloved self-convinced > textual-relational world. Pharo technology is designed to push limits, > so let's do things differently once. Yes > One thing that could change the world: Let's browse Java/Python code > directly from Nautilus. You can do it in Moose :) > >> >> 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. 25, 2016

Re: [Pharo-dev] Refactoring HelpTopic (needs review)

by Nicolai Hess

2016-08-25 7:13 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > Le 24/8/16 Ã 11:20, Nicolai Hess a Ã©crit : > > > > 2016-08-24 6:49 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Hi nicolai >> >> I remember that I read everything and fix typos. Did you got my review or >> did I suuceed to lose it ;). >> > > No, I think it was lost :-/ > > > oops did you check if it is not in the inbox repo? > Do you have the name of the package so that I check if I have it on my > machine? > Nothing in inbox for 6.0, besides my own slices for issue 18829. The packages are Refactoring-Help and Refactoring-Core > > >> Stef >> > > But the helpl is now in (60192), but it is still not finished, only a > start, needs more examples and maybe better class comments. > Everyone who wants to help, just try it out > > HelpBrowser openOn:RefactoringHelp > > read it and give feedback. > > If you find any typos, wrong or unclear information just report back, and > I'll fix it. > > we need more and better docs > we need more and better docs > and it would help if we have > more and better docs :-) > > > :) > > >

Aug. 25, 2016

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

by stepharo

> Hello, > >> Looking at bugs is really difficult. There are not enough people >> looking and fixing bugs. > just a short note from a Pharo noob...it is, imho, very strange that one > cannot even take a look at bugs *without* creating account at tracker. We know. Now the company offered us a professional service (cost around 25$ per month per user) for free. And also to maintain it. We do not want to spend our resources on maintaining... Then we migrating with pain from the google service. > By having ability to, at least, skim at bugs and see if there are some > low-hanging fruits to tackle, maybe more work could be accomplished? > > Having issue tracker closed for the public emits, imho, not very > friendly signal to potential contributors. Yes but we cannot do much Stef

Aug. 25, 2016

Re: [Pharo-dev] About asClass and friend

by philippe.back＠highoctane.be

Le 25 aoÃ»t 2016 08:53, "Tudor Girba" <tudor(a)tudorgirba.com> a Ã©crit : > > Hi, > > There exists already a method for that: > Symbol>>asClassInEnvironment: > > But, what if we introduce: > > Symbol>>asClassFrom: anObject > ^ self asClassInEnvironment: anObject class environment > > ? > > 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). > > What do you think? Great. Makes sense. Can always monkey patch my way anyway. "Pharo is yours" someone said. But I am not feeling the pain of getting things running in Gemstone from wild Pharo so, ... Phil > > 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." > >

Aug. 25, 2016

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

by Tudor Girba

Hi, Thanks Stef for the reply. I completely concur. @HernÃ¡n: About the issues with GT: please do get in touch. We have asked for it several times, and we are still here. If you have concrete issues, please raise them but focus on how to improve concretely. At the same time, also keep in mind that the overall decisions have to take into account other peopleâs constraints. That is why we need to iterate, and just because some requests do not make it, it does not mean that we do not care, but that we could not find a better solution to accommodate all wishes within the given time frame. We would certainly welcome help especially when that help aims to understand the full picture. The IDE is not a straightforward domain and we still have much to learn. Please, letâs work together and remember to have fun in the process :). Cheers, Doru > On Aug 25, 2016, at 8:48 AM, stepharo <stepharo(a)free.fr> wrote: > > Hi hernan > Could you reply to my mail? Because what is important is how we can make progres. > > 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. > Now some answers: >> >> >> Then it makes no sense raise any form of criticism, or the board, if by definition lobby groups silence any possible mistake. > No this is wrong. You can criticize as I criticize but you should give clear actionable points. > Else this is Oh XX is bad. > Tell us how we can address your problems and we will try. > Without clear feedback we cannot act. > >> 2. Features that goes inside Pharo are not decided by vote. They have to add value and share the Pharo vision (pointed in the vision document who is not slightly updated but still guides our steps). We try to reach consensus and if it is not possible, then we decide. Yes, is like thatâ¦ Iâm sorry for not being perfect democratic but this was never the idea of Pharo (it *has* a benevolent dictatorâ¦ who by the way is not me but a group, the board). >> >> >> Ok, now people can see one reason why Pharo is light years from the popularity of other OSS. I don't get how do you expect success with Pharo if you never change your mindset... I read a lot of papers and see KDE, gcc, Linux, NetBeans, Python, Mozilla, Apache collaboration models... never *ever* read something like that, specially now where OSS literature is considering distributed democracy. > Sorry but > - you would be surprised by how many people would vote to get GT tools inside Pharo :) > - 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. > >> In the end, time will tell, but can you cite another successful open source project with such "model"? > Sorry I do not have the time to know. > We want an doit model: doing in things should be more important than suh having needs (even if clients and users are important) >> 4. You have a very negative opinion about our design choices. Thatâs ok, but we are not going to remove GT just because you dislike it. >> >> It's not because of just my dislike. It's because it was never proposed for inclusion (it was just decided), it is because you make it almost impossible to uninstall it, and because it was integrated very early like an enhacement/future/vision set of tools without any votes, or high-resistance policy like many Open-Source projects, and judging by the volume of mails it required a lot of of time of beta-testing by many users. > You mean beside me someone was not really happy? > Seriously? > Now you can not use Spotter so I do not see the problem. > The Debugger is working well. > Playground looks like a default workspace. > Then GTInspector works perfectly for me. >> >> 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. >> >> Maybe I should be sorry for not being as obedient and blindly accepting all board decisions as the word of God, as many on this list. > Can you imagine one moment that people like it? > >> >> >> 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. > >> 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> 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>: >>>> 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 >>>> >>>> >>>> >>> >> >> > -- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."

Aug. 25, 2016

Re: [Pharo-dev] About asClass and friend

by Tudor Girba

Hi, There exists already a method for that: Symbol>>asClassInEnvironment: But, what if we introduce: Symbol>>asClassFrom: anObject ^ self asClassInEnvironment: anObject class environment ? 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). 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."

Aug. 25, 2016

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

by stepharo

Hi hernan Could you reply to my mail? Because what is important is how we can make progres. 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. Now some answers: > > > Then it makes no sense raise any form of criticism, or the board, if > by definition lobby groups silence any possible mistake. No this is wrong. You can criticize as I criticize but you should give clear actionable points. Else this is Oh XX is bad. Tell us how we can address your problems and we will try. Without clear feedback we cannot act. > 2. Features that goes inside Pharo are not decided by vote. They > have to add value and share the Pharo vision (pointed in the > vision document who is not slightly updated but still guides our > steps). We try to reach consensus and if it is not possible, then > we decide. Yes, is like thatâ¦ Iâm sorry for not being perfect > democratic but this was never the idea of Pharo (it *has* a > benevolent dictatorâ¦ who by the way is not me but a group, the > board). > > > Ok, now people can see one reason why Pharo is light years from the > popularity of other OSS. I don't get how do you expect success with > Pharo if you never change your mindset... I read a lot of papers and > see KDE, gcc, Linux, NetBeans, Python, Mozilla, Apache collaboration > models... never *ever* read something like that, specially now where > OSS literature is considering distributed democracy. Sorry but - you would be surprised by how many people would vote to get GT tools inside Pharo :) - 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. > In the end, time will tell, but can you cite another successful open > source project with such "model"? Sorry I do not have the time to know. We want an doit model: doing in things should be more important than suh having needs (even if clients and users are important) > > 4. You have a very negative opinion about our design choices. > Thatâs ok, but we are not going to remove GT just because you > dislike it. > > > It's not because of just my dislike. It's because it was never > proposed for inclusion (it was just decided), it is because you make > it almost impossible to uninstall it, and because it was integrated > very early like an enhacement/future/vision set of tools without any > votes, or high-resistance policy like many Open-Source projects, and > judging by the volume of mails it required a lot of of time of > beta-testing by many users. You mean beside me someone was not really happy? Seriously? Now you can not use Spotter so I do not see the problem. The Debugger is working well. Playground looks like a default workspace. Then GTInspector works perfectly for me. > > 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. > > Maybe I should be sorry for not being as obedient and blindly > accepting all board decisions as the word of God, as many on this list. Can you imagine one moment that people like it? > > > 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. > 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. 25, 2016