- Pharo-dev - lists.pharo.org

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

by HernÃ¡n Morales Durand

Hi, Esteban, Please don't take this personal, but we have differences :) 2016-08-24 5:06 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > > I want to point just a couple of things: > > 1. You may feel hurt, but is my job to say no. If you think Iâm doing a > bad job, is your right to discuss, but do not expect that what you consider > a bad design decision would be shared by the board (and me as executor of > board policies). > > Then it makes no sense raise any form of criticism, or the board, if by definition lobby groups silence any possible mistake. > 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. In the end, time will tell, but can you cite another successful open source project with such "model"? > 3. TxText vs. Twisty is a bad example (or a good example of how people can > interpret things that does not know in a complete missed directionâ¦ our > fault, this has to be communicated better)â¦ what actually happened is that > Igor and Denis discussed the design and they had a disagreement, but Denis > shared the vision of Igorâ¦ just no time to wait for it because he was > working pressures, so he delivered Twistyâ¦ I love twisty and I use it a lot > in my personal projects, but this was like thatâ¦ also, not all useful > things needs to be inside Pharoâ¦ > > 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. 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... 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. > What we will do is to iterate over it until we have a version that > satisfies most people and hopefully you tooâ¦ but this is like that, GT > tools is our vision for the future development tools and it will stayâ¦ > improved, of course. > Which also means that we will not accept the inclusion of alternative > tools. like another workspace or browserâ¦ Thierry did an excellent job > with his AltBrowser, and we look a lot at it to take ideas, but we will not > include it either and that does not means we have a problem with himâ¦ What > we want it more people helping us to improve the GT tools and just asking > for removal does not help. > > 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. 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 >> >> >> > > >

Aug. 24, 2016

Re: [Pharo-dev] The OpenCL bindings/VirtualGPU has been updated to the uFFI

by Ronie Salgado

Here it is: http://smalltalkhub.com/#!/~ronsaldo/VirtualGPU 2016-08-24 15:37 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > Thank you Ronie. I will try and do a report to you before the end of ESUG > ;-) > Where is the repository ? > > > On Wed, Aug 24, 2016 at 3:19 PM, Ronie Salgado <roniesalg(a)gmail.com> > wrote: > > Hi, > > > > I have just finished updating the OpenCL bindings and the VirtualGPU to > use > > the UnifiedFFI in Pharo 5. All of the examples have been tested in Mac > OS X > > El Capitan 10.11.6. > > > > Best regards, > > Ronie > > > > P.S: Do not confuse the VirtualGPU with the AbstractGPU. The AbstractGPU > is > > an abstraction layer above Vulkan, Direct3D 12 and Metal. The > AbstractGPU is > > used as the foundation for Woden 2. > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

Aug. 24, 2016

Re: [Pharo-dev] The OpenCL bindings/VirtualGPU has been updated to the uFFI

by Serge Stinckwich

Thank you Ronie. I will try and do a report to you before the end of ESUG ;-) Where is the repository ? On Wed, Aug 24, 2016 at 3:19 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hi, > > I have just finished updating the OpenCL bindings and the VirtualGPU to use > the UnifiedFFI in Pharo 5. All of the examples have been tested in Mac OS X > El Capitan 10.11.6. > > Best regards, > Ronie > > P.S: Do not confuse the VirtualGPU with the AbstractGPU. The AbstractGPU is > an abstraction layer above Vulkan, Direct3D 12 and Metal. The AbstractGPU is > used as the foundation for Woden 2. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Aug. 24, 2016

The OpenCL bindings/VirtualGPU has been updated to the uFFI

by Ronie Salgado

Hi, I have just finished updating the OpenCL bindings and the VirtualGPU to use the UnifiedFFI in Pharo 5. All of the examples have been tested in Mac OS X El Capitan 10.11.6. Best regards, Ronie P.S: Do not confuse the VirtualGPU with the AbstractGPU. The AbstractGPU is an abstraction layer above Vulkan, Direct3D 12 and Metal. The AbstractGPU is used as the foundation for Woden 2.

Aug. 24, 2016

Re: [Pharo-dev] About Pharo 60

by Peter UhnÃ¡k

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. Peter On Wed, Aug 24, 2016 at 6:59 AM, stepharo <stepharo(a)free.fr> wrote: > Hi > > We have some ideas (because people are working on items) for the Pharo 6 > roadmap > > and we will consolidate them soon and propose them to you. > > but I would like to know two kinds of points > > - what are the points you are working on and that would deserve more > focus and help from the community? > > (these points are important because like that you could go faster > and this is a good feeling to get done for example) > > - what would be points where (if magically we would get more resources > - to not dream if this is not you > > there is a high chance that we will not make it) it would be nice > to get some changes > > > Please pay attention that if you type too fast and come up with a > christmas list well it will stay a christmas list and will just make the > thread larger for nothing. > > Stef > > >

Aug. 24, 2016

Re: [Pharo-dev] [Pharo-users] websockets in pharo?

by Guillaume Larcheveque

Yes and it works very well!! (I'm using it for Telescope) There is a chapter in the pharo for enterprise book about websockets 2016-08-24 14:28 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Zinc-WebSocket-* packages in the repository http://mc.stfx.eu/ > ZincHTTPComponents > > -- Pavel > > 2016-08-24 14:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> Can anyone tell me if there is a Websocket implementation for Pharo? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "From an abstract enough point of view, any two things are similar." >> >> >> >> >> >> > -- *Guillaume Larcheveque*

Aug. 24, 2016

Re: [Pharo-dev] websockets in pharo?

by Pavel Krivanek

Zinc-WebSocket-* packages in the repository http://mc.stfx.eu/ZincHTTPComponents -- Pavel 2016-08-24 14:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Can anyone tell me if there is a Websocket implementation for Pharo? > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "From an abstract enough point of view, any two things are similar." > > > > > >

Aug. 24, 2016

websockets in pharo?

by Tudor Girba

Hi, Can anyone tell me if there is a Websocket implementation for Pharo? Cheers, Doru -- www.tudorgirba.com www.feenk.com "From an abstract enough point of view, any two things are similar."

Aug. 24, 2016

Re: [Pharo-dev] Having fun with Pharo

by webwarrior

Aliaksei Syrel wrote > Hi > > Did you know that `2 * 10.2` is two times slower than `2 asFloat * 10.2`? > > Here is performance test (inspect result, takes ~10s to complete): > http://ws.stfx.eu/4T0CR23OURZW > > Who knows how performance can be improved with this knowledge... > > Cheers, > Alex And on pre-Spur VM it's like 6 or 7 times slower. More interesting fact is that (float * int) gets optimized, but (int * float) doesn't. It would be cool to have an up-to-date document explaining preformance characteristics of Pharo code and optimizations done by compiler/JIT. Right now only source of such stuff seems to be the blog of ClÃ©ment BÃ©ra (https://clementbera.wordpress.com/) -- View this message in context: http://forum.world.st/Having-fun-with-Pharo-tp4912104p4912472.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 24, 2016

Call for Papers: Object Oriented Programming Languages and Systems @ SAC 2017, April 3-7, 2017

by Nick Papoylias

************************************************** OOPS 2017 Call for Papers Object-Oriented Programming Languages and Systems http://oops.disi.unige.it/OOPS17 ************************************************** Technical Track at the 32nd ACM Symposium on Applied Computing, SAC 2017 http://www.acm.org/conferences/sac/sac2017 April 3 - 7, 2017 Marrakesh, Morocco - Important Dates Submission of regular papers and SRC abstracts September 15, 2016 Paper and SRC notifications November 10, 2016 Paper and SRC camera-ready copies November 25, 2016 Author registration December 10, 2016 SAC 2017 April 3 - 7, 2017 - Track Chair Davide Ancona (davide.ancona(a)unige.it) DIBRIS, University of Genova, Italy - SAC 2017 For the past thirty one years, the ACM Symposium on Applied Computing (SAC) has been a primary gathering forum for applied computer scientists, computer engineers, software engineers, and application developers from around the world. SAC 2017 is sponsored by the ACM Special Interest Group on Applied Computing (SIGAPP) and is hosted by the University of Quebec at Montreal, Canada; University Cadi Ayyad (UCA) of Marrakech, Morocco; National School of Engineering in Rabat (EMI), Rabat, Morocco; and National School of Applied Sciences (ENSA) of Kenitra, Morocco. - Call For Student Research Abstracts Graduate students seeking feedback from the scientific community on their research ideas are invited to submit original abstracts of their research work in areas of experimental computing and application development related to SAC 2017 Tracks. The Student Research Competition (SRC) Program is designed to provide graduate students the opportunity to meet and exchange ideas with researchers and practitioners in their areas of interest. - OOPS Track: Aims and Topics Object-oriented programming (OOP) has become the mainstream programming paradigm for developing complex software systems in most application domains. However, existing OO languages and platforms need to evolve to meet the continuous demand for new abstractions, features, and tools able to reduce the time, effort, and cost of creating object-oriented software systems, and improving their performance, quality and usability. To this aim, OOPS is seeking for research advances bringing benefits in all those typical aspects of software development, such as modeling, prototyping, design, implementation, concurrency and distribution, code generation, analysis, verification, testing, debugging, evaluation, deployment, maintenance, reuse, and software evolution and adaptation. The specific topics of interest for the OOPS track include, but are not limited to, the following: * Aspects and components * Code generation, and optimization, just-in-time compilation * Context-oriented programming * Databases and persistence * Distribution and concurrency * Dynamic and scripting languages * Evaluation * Feature Oriented Software Development and Programming * Formal verification * Internet of Things technology and programming * Integration with other paradigms * Interoperability, versioning and software evolution and adaptation * Language design and implementation * Modular and generic programming * Reflection, meta-programming * Runtime verification * Secure and dependable software * Static analysis * Testing and debugging * Type systems and type inference * Virtual machines OOPS offers a great opportunity to the OOP community to gain visibility, and to exploit the inter-disciplinary nature of SAC. - Submission Instructions Prospective papers should be submitted to the track in pdf format using the START submission system for regular and SRC papers available through the SAC 2017 home page. Submission of the same paper to multiple tracks is not allowed; all papers should represent original and previously unpublished works that are currently not under review in any conference or journal. Both basic and applied research papers are welcome. SAC 2017 will use double-blind reviewing; to facilitate this, author name(s) and institution(s) must be omitted, and references to authors' own related work should be in the third person. The format of the paper must adhere to the sig-alternate style. Full papers are limited to 6 pages with the option for up to 2 additional pages (max of 8 pages) at extra charge (80 USD per page). Posters are limited to 3 pages with the option for up to 1 additional page (max of 4 pages) at extra charge (80 USD). The length of the SRC abstracts is 2 pages with no additional pages at extra charge. Papers that fall short the above requirements are subjected to rejection. All papers must be submitted by September 15, 2016. For more information please visit the SAC 2017 home page. - Proceedings Accepted papers will be published by ACM in the annual conference proceedings. Accepted posters will be published as extended abstracts in the same proceedings. Paper registration is required, allowing the inclusion of the paper/poster in the conference proceedings. An author or a proxy attending SAC MUST present the paper. This is a requirement for the paper/poster to be included in the ACM/IEEE digital library. No-show of scheduled papers and posters will result in excluding them from the ACM/IEEE digital library. Student registration is only intended to encourage student attendance and does not cover inclusion of papers/posters in the conference proceedings. Finally, following the tradition of the past OOPS editions, depending on the quality and the overall number of accepted papers, authors of selected papers will be invited to submit an extended version for a journal special issue, after the conference.

Aug. 24, 2016