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

WideString and commits

by Cyril Ferlicot Delbecque

Hi! I opened an issue month ago on fogbugs because I could not commit some packages. I didn't get time to investigate it and nobody could. With Guille we found that the problem is that the code contained a special character. It contains a â¥... And we cannot commit specials character anymore on Monticello and I think that it is the same with Ã©Ã¨Ã ÃÃ¡Ã²... Unfortunately I don't know enough this part of Pharo and I do not have the time to look at it for now. I just wanted to bring some light on the issue because there was no activity on the bug since month and I think that this is pretty important. If someone know how to fix it or know some pointers this is welcome. :) The bug repport: https://pharo.fogbugz.com/f/cases/18711/Cannot-commit-a-special-character-i… -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Aug. 25, 2016

Re: [Pharo-dev] [ann] Lam Research evaluates Pharo

by Ben Coman

On Thu, Aug 25, 2016 at 4:50 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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 Great to hear of this - particularly since I guess some(much?) of it was dealing with proprietary systems. I'll understand if you can't answer the following questions in detail. I'm interested in: * what model was the single board computers? Or what were its specs/price? Or how much of your experience might carry over to a board like the BeagleBone Black, particularly wrt to embedded control via it Programmable Real-time Unit. * did the communication component involve a proprietary protocol? Or one of the industry standard "process automation" protocols listed here[1] ? [1] https://en.wikipedia.org/wiki/List_of_automation_protocols cheers -ben

Aug. 25, 2016

Re: [Pharo-dev] problem with Epicea and #name

by Tudor Girba

Hi Martin, Thanks a lot for the quick response. As Andrei said, please do not feel sorry. Epicea is an important new core component and just because it is a core one every tiny error will appear as a large problem. But, we are all humans here, and it should be expected that we make errors :). Cheers, Doru > On Aug 25, 2016, at 1:19 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi Martin, > > To reproduce the error execute the code below. The first part does some cleanups needed to remove the code. The second part attempts to remove two packages and seems to go into a recursion. If you interrupt the execution with cmd+. you'll see a lot of Context>>#handleSignal:. If you right click on one and select 'Peel to first like this' it will find the original context that triggered the error. > > Don't worry there is no inconvenience :). > Thanks for looking into this. > > GTExampleOrganizer instance reset. > GTExampleOrganizer instance stopThoroughly. > GTExampleOrganizer stop. > Smalltalk garbageCollect. > self assert: GTExample allSubInstances isEmpty. > self assert: GTExampleMethod allSubInstances isEmpty. > > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-Core'; > package: 'GT-Inspector'; > load. > > Cheers, > Andrei > > On Thu, Aug 25, 2016 at 1:00 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi Andrei, there is an open issue that involves #name in category removal whose fix is ready in bleeding edge and only waits that i release the new stable version. But this is about category removal, not class removal. This night I will take a look on the code of class removal... however, could you send a stack trace, please? > I'm sorry for the inconvenience. > MartÃn > > > El 25/8/2016 7:18, "Andrei Chis" <chisvasileandrei(a)gmail.com> escribiÃ³: > Hi, > > When trying to load a new version of the GTInspector in the latest Pharo image I get an infinite recursion. It seems that the problem is appears because a class is removed, which at a certain point calls #asEpiceaRingDefinition. This does then 'self superclass name', however, the superclass is nil and UndefinedObject>>#name is called, which is deprecated. This should open a warning window and but it leads to an infinite recursion. Know problem or should I opened an issues? > > Cheers, > Andrei > -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

Aug. 25, 2016

Re: [Pharo-dev] problem with Epicea and #name

by Andrei Chis

Hi Martin, To reproduce the error execute the code below. The first part does some cleanups needed to remove the code. The second part attempts to remove two packages and seems to go into a recursion. If you interrupt the execution with cmd+. you'll see a lot of Context>>#handleSignal:. If you right click on one and select 'Peel to first like this' it will find the original context that triggered the error. Don't worry there is no inconvenience :). Thanks for looking into this. GTExampleOrganizer instance reset. GTExampleOrganizer instance stopThoroughly. GTExampleOrganizer stop. Smalltalk garbageCollect. self assert: GTExample allSubInstances isEmpty. self assert: GTExampleMethod allSubInstances isEmpty. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Core'; package: 'GT-Inspector'; load. Cheers, Andrei On Thu, Aug 25, 2016 at 1:00 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi Andrei, there is an open issue that involves #name in category removal > whose fix is ready in bleeding edge and only waits that i release the new > stable version. But this is about category removal, not class removal. This > night I will take a look on the code of class removal... however, could you > send a stack trace, please? > I'm sorry for the inconvenience. > MartÃn > > El 25/8/2016 7:18, "Andrei Chis" <chisvasileandrei(a)gmail.com> escribiÃ³: > >> Hi, >> >> When trying to load a new version of the GTInspector in the latest Pharo >> image I get an infinite recursion. It seems that the problem is appears >> because a class is removed, which at a certain point calls >> #asEpiceaRingDefinition. This does then 'self superclass name', however, >> the superclass is nil and UndefinedObject>>#name is called, which is >> deprecated. This should open a warning window and but it leads to an >> infinite recursion. Know problem or should I opened an issues? >> >> Cheers, >> Andrei >> >

Aug. 25, 2016

Re: [Pharo-dev] problem with Epicea and #name

by Martin Dias

Hi Andrei, there is an open issue that involves #name in category removal whose fix is ready in bleeding edge and only waits that i release the new stable version. But this is about category removal, not class removal. This night I will take a look on the code of class removal... however, could you send a stack trace, please? I'm sorry for the inconvenience. MartÃn El 25/8/2016 7:18, "Andrei Chis" <chisvasileandrei(a)gmail.com> escribiÃ³: > Hi, > > When trying to load a new version of the GTInspector in the latest Pharo > image I get an infinite recursion. It seems that the problem is appears > because a class is removed, which at a certain point calls > #asEpiceaRingDefinition. This does then 'self superclass name', however, > the superclass is nil and UndefinedObject>>#name is called, which is > deprecated. This should open a warning window and but it leads to an > infinite recursion. Know problem or should I opened an issues? > > Cheers, > Andrei >

Aug. 25, 2016

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

by Guille Polito

Hi! Hola! I would like to help with some of this, so I sorted a bit the ideas in the previous emails to see if we can extract some concrete actions to apply. So I'll make a step back and put some titles to the topics of discussion: !Human/Social/Politics stuff 1) Policies - Deciding about what goes inside - And what does not - e.g., what is the official IDE? What is a valid issue? - And what is necessary or useful for the community Well, on the one hand Esteban and Steph answered to this already I think. At least about how this works in reality. I have however two remarks on this: - First, I think that all accepted issues should be aligned with Pharo's vision. And this means first that this vision must be well documented and updated. Second, it means that people should know and read that vision document (and not get mad if ). But also, this "alignment" is kind of subjective: there is somebody that decides if this happens or not. And this happens to be the board who does it... - Second, I do not really care what the heck is the process to decide this. But I believe that documenting it is nothing but a good move. (And this is related to the PEPs Hernan named and I talk about below...) 2) Discussion around the same topics for months - can we have some examples about these? From the top of my head I can think about * <example> * Logging * ? Well, I see also sometimes that we have long-running discussions that go nowhere... But: - First, I take them as people is learning. In Pharo-dev people discuss sometimes about things they are not sure of or maybe they want to share and change. And maybe they are discussing to explore new ideas. So, please do not ban these discussions, I thing that we have to encourage them. Also, the traffic in Pharo-dev is so high that if something is not interesting to us, we have to either learn to filter that out, or follow other lower-traffic options such as pharo-users or pharo's new newsletter. - Second, please, if you feel that you have something to propose, drop it in the mailing list! But as you make it public, do not expect that everybody will agree :). Also, as you have noticed, many people in this list have really strong opinions, so we have to understand and continue pushing. 3) PEPs (Pharo Enhancement Proposals?) Well, this is an interesting idea. I think it is important to document well - the integration process - the decision process - the release process - the proposal process (which BTW I really, since to propose some enhancement you need to really describe and design it and not just say "mine is cooler!") - Coding idioms and styles (maybe we can autogenerate this from lint rules???? Invoking Yuriy here!!) A question I would pose is - where should this be? a wiki somewhere? some part inside the pharo site? !Technical stuff, about Big images, modularization, removing tests Hernan, I am really interested in your use case where having the image tests is really bothering. We are working on modularizing it, yes, but we also believe the default environment should contain tests to guarantee some quality => otherwise, breaking the system would be far much easier! But if you are interested in modular images just drop me (and Christophe, and Pavel) an email and we can see how we can collaborate. And also, Hernan, what would you collaborate with? Because in your email I had the impression that you "expect" something from people: to accept your issues, to fix your issues, to communicate with you, but it's fuzzy what you're doing also to make that happen. This is maybe just an email miscommunication, just take this as a proposal to really move your ideas forward (with your help, of course). Guille -------- Original Message -------- > > >> 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

problem with Epicea and #name

by Andrei Chis

Hi, When trying to load a new version of the GTInspector in the latest Pharo image I get an infinite recursion. It seems that the problem is appears because a class is removed, which at a certain point calls #asEpiceaRingDefinition. This does then 'self superclass name', however, the superclass is nil and UndefinedObject>>#name is called, which is deprecated. This should open a warning window and but it leads to an infinite recursion. Know problem or should I opened an issues? Cheers, Andrei

Aug. 25, 2016

[ann] seaside gtdebugger

by Tudor Girba

Hi, As presented at ESUG on Monday, we now have a custom GTDebugger for Seaside. This was built by Andrei as an initial experiment. As we do not know much about Seaside-specific debugging problems, we asked a couple of Seaside users to describe issues that would be useful to be addressed in the debugger, and Andrei allocated some 4h to construct some of these in an custom debugger for Seaside. Two of the issues that popped up are: - get a quick view of the current request context - get an overview of the current component nesting They are now addressed like depicted in the screenshot below. You should look at this debugger as a beginning. Beside the current basic extensions one added value is that we now have the scaffolding to build more. Please take a look at it and letâs try to identify more concrete issues that might be addressed. It would be great if this would be taken over by the Seaside community. The debugger can be loaded on top of a Pharo 6.0 with Seaside inside like this: Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-SeasideDebugger'; load. #GTSeasideDebugger asClass register Cheers, Doru -- www.tudorgirba.com www.feenk.com "The coherence of a trip is given by the clearness of the goal."

Aug. 25, 2016

Re: [Pharo-dev] [ann] Lam Research evaluates Pharo

by phil＠highoctane.be

Wonderful news. That may turn to be a real turning point for our beloved platform. Kudos to you people!!!! Phil On Thu, Aug 25, 2016 at 10:50 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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] [ann] Lam Research evaluates Pharo

by Alexandre Bergel

Excellent!!!! Keep going guys! You are impacting state of the art of software engineering! Alexandre > On Aug 25, 2016, at 10:50 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 25, 2016