- Pharo-dev - lists.pharo.org

[ann] GTExamples alpha

by Tudor Girba

Hi, Over the last coupe of years Stefan Reichhart and the rest of the GT team worked on an implementation of examples. The work is inspired from previous work done by Markus Gaelli and Adrian Kuhn. As one of the goals of GT is to offer a live programming environment, one important issue is how to move from the static code to live objects as fast as possible. That is why we worked on this library as a solution to provide a link between the static code and live objects. Furthermore, this examples library also enables the definition of assertions on the examples, and this provides the possibility of rethinking the way we construct tests throughout our system. Tests are great as they help us create live objects and then to assert live properties. However, they do not allow us to leverage the objects we create, and this can be a tremendous resource for understanding systems. In our vision, examples should be everywhere and they should be explicitly linked to the static code they exemplify. That is why the library comes with an initial integration in existing tools (such as Nautilus, Spotter, Inspector). The current solution works well and it is the result of several rewrites. We think that the solution is complete in terms of features, but there are still several things to improve and iterate on. To this end, I kindly ask you to take a look at it while distinguishing between the concrete implementation choice (e.g., the current extensive use of pragmas) and the conceptual benefits of the approach. To ease the discussion, we put together a short documentation: http://gtoolkit.org/doc/Examples/examples.html That being said, you can get it with the full GToolkit in Pharo 6.0: http://gtoolkit.org/#install (easiest is to download the ready made image for now) For those that are at ESUG, I will try to provide a short overview during the Show Us Your Project session from today. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

Aug. 25, 2016

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

by philippe.back＠highoctane.be

A chance of this working under Windows 8.1 ? Phil Le 24 aoÃ»t 2016 15:20, "Ronie Salgado" <roniesalg(a)gmail.com> a Ã©crit : > 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. 25, 2016

Re: [Pharo-dev] About asClass and friend

by philippe.back＠highoctane.be

Ah, I am using that a lot to parametrize software. On one hand Pharo is breaking with the past, on the other one it sticks with it as much as possible? #MeConfused asHell. #SomeSymbol asClass looks very practical and cleaner that looking the class dictionary with at: #SomeSymbol Phil Phil Le 25 aoÃ»t 2016 07:22, "stepharo" <stepharo(a)free.fr> a Ã©crit : > 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 asClass and friend

by Yuriy Tymchuk

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

Aug. 25, 2016

About asClass and friend

by stepharo

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] Refactoring HelpTopic (needs review)

by stepharo

Le 24/8/16 Ã 11:20, Nicolai Hess a Ã©crit : > > > 2016-08-24 6:49 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@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? > > 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 HernÃ¡n Morales Durand

Now I will try to be more positive. 2016-08-24 4:38 GMT-03:00 stepharo <stepharo(a)free.fr>: > 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. > Good initiative, thanks! > 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 > I don't get why we don't have more discussions about end-developer tools : XML, i18n, GIS, simulation & expert systems, big data, reporting... > 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. > > I think you could implement some reward system for devs with more bug fixes: Interviews, consortium membership, maybe voting on some issues...? > 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? > > 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) - System Browser -- One cool (like Nautilus) -- One standard (to not have an unusable image if the cool one gets broken) - 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. > > 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?) > 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 :) > 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. > 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. > > Thank you Stef for raising this space to consider both good and uncomfortable things. 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. One thing that could change the world: Let's browse Java/Python code directly from Nautilus. 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. 25, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60193 Home: https://github.com/pharo-project/pharo-core

Aug. 25, 2016

[pharo-project/pharo-core] 62e440: 60193

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 62e440f8faffb82bfd0e2cfd9b15de5a30a6e1e1 https://github.com/pharo-project/pharo-core/commit/62e440f8faffb82bfd0e2cfd… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-25 (Thu, 25 Aug 2016) Changed paths: M AST-Core.package/RBLiteralArrayToken.class/README.md M AST-Core.package/RBMultiKeywordLiteralToken.class/README.md M AST-Core.package/RBNumberLiteralToken.class/README.md M AST-Core.package/RBShortAssignmentToken.class/README.md M ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/symbolic versions/stable_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/versions/versionv3%5F2%5F5_.st A QualityAssistant.package/QARubMenuItemMorph.class/instance/accessing/hasIconOrMarker.st R QualityAssistant.package/extension/CompiledMethod/instance/gtInspectorCritiquesIn_.st R QualityAssistant.package/extension/TBehavior/instance/gtInspectorCritiquesIn_.st M Renraku.package/extension/CompiledMethod/instance/critiques.st A Renraku.package/extension/Object/instance/gtInspectorEProportiesIn_.st M Renraku.package/extension/RBInstVarInSubclassesRule/instance/check_forCritiquesDo_.st A Renraku.package/extension/RBInstVarInSubclassesRule/instance/critiqueFor_.st M Renraku.package/extension/RBProgramNode/instance/nodeAtTraversalIndex_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60192.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60193.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60192.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60193.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/menu/addNavigationMenuItemsTo_.st A Tool-CriticBrowser.package/extension/Behavior/instance/populateCBMenu_.st A Tool-CriticBrowser.package/extension/CompiledMethod/instance/populateCBMenu_.st A Tool-CriticBrowser.package/extension/Object/instance/populateCBMenu_.st A Tool-CriticBrowser.package/extension/TraitBehavior/instance/populateCBMenu_.st Log Message: ----------- 60193 18980 QA v3.2.5 https://pharo.fogbugz.com/f/cases/18980 18903 CriticBrowser browser senders broken https://pharo.fogbugz.com/f/cases/18903 18970 Add missing class comments for some RBToken classes https://pharo.fogbugz.com/f/cases/18970 http://files.pharo.org/image/60/60193.zip

Aug. 25, 2016

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

by Serge Stinckwich

Apparently its works again on my mac :-) I was able to run an extension done of my student in CC do add GPU support to HoneyGinger of Tomo. Thank you ! 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