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

[ann] Lam Research evaluates Pharo

by Tudor Girba

Hi, We are very happy to make the following announcement: Lam Research, a leading supplier of wafer fabrication equipment and services to the global semiconductor industry, is an experienced user of the Smalltalk programming language. Smalltalk is a key component in Lam's software control system for a broad range of the equipment it manufactures. Tudor Girba is a leading member of the tools and environment development effort in Pharo, having architected the Glamorous Toolkit for live programming. Eliot Miranda is author of the Cog virtual machine that underlies Pharo and other Smalltalk dialects. Lam has engaged Tudor and Eliot to explore potential enhancements in Lam's use of Smalltalk. These enhancements range from running highly optimized Smalltalk on low cost, single board computers, to enhancing Lam's Smalltalk development practices with state-of-the-art live programming. During the engagement, Tudor and Eliot successfully moved a key communication component of the control system to Pharo. It was a challenging task aimed at extending the reach of Lamâs system to the Pharo world including the option of executing on ARM processors. Cheers, Tudor Girba, Eliot Miranda and Chris Thorgrimsson

Aug. 25, 2016

[ann] Lam Research evaluates Pharo

by Tudor Girba

Hi, We are very happy to make the following announcement: Lam Research, a leading supplier of wafer fabrication equipment and services to the global semiconductor industry, is an experienced user of the Smalltalk programming language. Smalltalk is a key component in Lam's software control system for a broad range of the equipment it manufactures. Tudor Girba is a leading member of the tools and environment development effort in Pharo, having architected the Glamorous Toolkit for live programming. Eliot Miranda is author of the Cog virtual machine that underlies Pharo and other Smalltalk dialects. Lam has engaged Tudor and Eliot to explore potential enhancements in Lam's use of Smalltalk. These enhancements range from running highly optimized Smalltalk on low cost, single board computers, to enhancing Lam's Smalltalk development practices with state-of-the-art live programming. During the engagement, Tudor and Eliot successfully moved a key communication component of the control system to Pharo. It was a challenging task aimed at extending the reach of Lamâs system to the Pharo world including the option of executing on ARM processors. Cheers, Tudor Girba, Eliot Miranda and Chris Thorgrimsson

Aug. 25, 2016

Re: [Pharo-dev] About asClass and friend

by Denis Kudriashov

Hi 2016-08-25 8:52 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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). We could also make #asClass as "always deprecated" method with automatic rewriting. So in tools people will always see that it is better to not use it. But for scripting it will work normally. Also if people will commit such code it will become dirty very fast and always. And they will need to fix it

Aug. 25, 2016

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