April 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] What's new on Pillar ?

by Ben Coman

On Fri, Apr 24, 2015 at 6:26 PM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > into your Pillar file, that will include the content of test.pillar. > I recommend for now to use it at the root of the pillar file and not > inside a paragraph. That still needs some improvement. > > > --> We now have a transformer which adds an anchor after each title. > The anchor will have the text of the title. > This still needs some improvement, it's really simple for now. For > exemple we need to consider the case where we have 2 titles with the > same text (like 'introduction'). > > --> Now you can add 'lineNumber=true' as parameter for a Script. This > will add a numerotation at your script, usefull if we want to explain > a long code. > > --> I did some refactorisation on the parameters used by pillar to > clean the code. > > --> I did some refactorisation of the template system, the old one was > really ugly and changed the baseDirectory. Now template are managed by > a stream and not a file. > Looks like useful stuff. Thanks Cyril. cheers -ben

April 24, 2015

What's new on Pillar ?

by Cyril Ferlicot

Hi everyone ! I'm currently working on Pillar ! It's been a little while now so I wanted to share what's new. --> First of all, with Stephane we created a new project, Cocoon, based on the configuration system of Pillar. And now Pillar uses Cocoon for his configurations. http://smalltalkhub.com/#!/~PharoExtras/Cocoon --> Pillar unit tests weren't working on Windows before --> With Damien we also added two new abstractions: --> The transformers: They take the Pillar tree and modify it. For exemple we have a transformer which evaluates the scripts with a "eval=true" parameter. --> The annotations: They let the writer specify many different things in their document using just 1 syntax (see below for an example) --> We now have our first annotation tag: the inclusion tag ! If you add this: ${inputFile:test.pillar}$ or ${inputFile:folder/test.pillar}$ into your Pillar file, that will include the content of test.pillar. I recommend for now to use it at the root of the pillar file and not inside a paragraph. That still needs some improvement. --> We now have a transformer which adds an anchor after each title. The anchor will have the text of the title. This still needs some improvement, it's really simple for now. For exemple we need to consider the case where we have 2 titles with the same text (like 'introduction'). --> Now you can add 'lineNumber=true' as parameter for a Script. This will add a numerotation at your script, usefull if we want to explain a long code. --> I did some refactorisation on the parameters used by pillar to clean the code. --> I did some refactorisation of the template system, the old one was really ugly and changed the baseDirectory. Now template are managed by a stream and not a file. --> I improved a little the configuration --> Now if you want to change the baseDirectory you can pass a FileReference, a relative path or an absolute path. --> Now we look for the inputFiles from the baseDirectory and not the working directory like before. You can also pass a FileReference, a relative path or an absolute path. --> I added some tests to Pillar. --> I added some doc to EnterprisePharo https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… --> To help the users I improved the error reports. Before we had really few errors specific to Pillar. For this one you can help me ! If you found a weird error or something really not easy to deal with, send me your problem ! -- Cheers Cyril Ferlicot

April 24, 2015

Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4

by Esteban Lorenzano

> On 24 Apr 2015, at 08:41, stepharo <stepharo(a)free.fr> wrote: > > I understand the point of marcus but still it is unclear why certain tools should be in and not others. > Now I would prefer that we have a process that > > 1 := take a miniimage AND load the tools > check that we can unload them (just to check) > and only then declare > > pharo := 1. > > Now we will face the problem of ok we do a change and it touches such loaded tools (see the other thread) > Read the Pharo vision paper. we will have it. Iâm slowly (very slowly) working on that. > > Stef > > > Le 23/4/15 10:53, Yuriy Tymchuk a Ã©crit : >> I totally agree with Stef that we should be able to do a rock solid setup of what tools we want to use in our everyday image. >> >> But on the other hand we have to design what Pharo is. Because we can even go Ruby style and say that debugger is not a part of the main system, but I see that our strength is to provide people with ultimate tools for development (although we cannot put everything inside). And I think that dependency browser is important and I will continue to convince people that quality of code is important and that we should use quality tools in our daily work. Maybe now QualityAssistant is not mature enough, but at some point it will be :). >> >> Cheers. >> Uko >> >> >> P.S. at the moment we are loosing competition to JetBrains tools because they give you live feedback about code critics. >> >> >>> On 23 Apr 2015, at 09:04, stepharo <stepharo(a)free.fr> wrote: >>> >>> >>> >>> Le 23/4/15 09:05, Marcus Denker a Ã©crit : >>>> I do not understand how âhaving a modular tool in the image â (that does not add dependencies to anything) >>>> makes the system less modular. >>> Then why the dependency Browser was not integrated? Why roassal for drawing dependencies >>> and other aspects of the system? Because dependency browser as well as roassal are really useful, >>> well packaged, What about pillar? Because it would be cool to have beautiful class comments in the future. The point is how and in which process. >>> In addition what are the criteria? Feelings or criteria? Oh this tool is cool but this one less cool. >>> Strange for scientific people no? >>> I think that we should have a building process that load tools. >>> We will not be able to put everything in the image: >>> Did you look at the dependencies between RB, nautilus, history, EyeInspector? >>> I did because it was getting the mess. My energy is cheap and infinite so I can spend 8 hours >>> fixing configurations that nobody use or look at. But you see this period is ***over***. >>> >>>>> So to me it simply means that we are not serious and convinced about modularity. >>>>> >>>>> But this is great, I'm reconsidering what I will do in Pharo so you give me good indication >>>>> that I should not continue the way I was thinking. And no need to think that I'm emotional >>>>> I'm not. I'm thinking about why hell I'm doing all this. >>>>> >>>> You always directly go and argue by âI am now sadâ purely emotional level. >>>> This is not good. >>> Read what you want to read. But my energy in neither cheap nor infinite anymore. >>> This is not a feeling but just a mere fact. >>> >>>> >>>> Marcus >>>> >>>> >>>> >>> >> >> > >

April 24, 2015

Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4

by Henrik Johansen

> On 24 Apr 2015, at 8:41 , stepharo <stepharo(a)free.fr> wrote: > > I understand the point of marcus but still it is unclear why certain tools should be in and not others. > Now I would prefer that we have a process that > > 1 := take a miniimage AND load the tools > check that we can unload them (just to check) > and only then declare > > pharo := 1. > > Now we will face the problem of ok we do a change and it touches such loaded tools (see the other thread) > Read the Pharo vision paper. > > Stef The problem with Pharo-Dev in olden days wasn't that no one used the image, but that there was no good process for pushing required updates to "external" packages, so it was more convenient to just develop in the Core image, and leave the other packages for their maintainers to update at the end of a cycle. I don't think the best answer is to pull more and more packages into the Pharo "Core" repository and effectively do double versioning, as seems to be the trend lately... Why not require write access to repositories of external projects that are included in a Pharo-Dev image? Then you can have the Pharo team responsible for a (currently) #Pharo5 symbolic version in the Configuration. Then, when merging slices, push updates to external repos as appropriate (updating #Pharo5 version in Conf), and build new Dev image from a list of such approved Configurations. Lets the external developer do improvements against a static version, and merge with latest non-release when appropriate without leaving the comfort of a single repository. Cheers, Henry

April 24, 2015

Re: [Pharo-users] ViDI error: variable named "aModuleName" in NativeBoost>>#loadModule:

by Rafael Luque

Thank you! I'm looking forward to hearing from you about the new version. 2015-04-24 9:52 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Ok, I found the problem. Some Spec api changed. I stable version will work > at least on Mac quite soon. :) > > Uko > > > > On 23 Apr 2015, at 17:46, Rafael Luque <rafael.luque.leiva(a)gmail.com> > wrote: > > I'd like to use it in a Linux box, but as you told me Linux is not yet > supported, I'm using a Mac OS X Yosemite (version 10.10.2). > > Thanks > > 2015-04-23 17:37 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > >> Hi Rafael, >> >> I will take a look. Which operating system are you using? >> >> Uko >> >> On 23 Apr 2015, at 17:30, Rafael Luque <rafael.luque.leiva(a)gmail.com> >> wrote: >> >> Hi, >> >> I installed ViDI on Pharo 4 following the project instructions detailed >> in its GitHub page: >> >> Gofer new >> smalltalkhubUser: 'YuriyTymchuk' >> project: 'Configuration'; >> configurationOf: 'Vidi'; >> load. >> #ConfigurationOfVidi asClass loadStable >> >> When I launch a review session over any package I always get the >> following error: >> >> "Could not find accesor for variable named "aModuleName" in >> NativeBoost>>#loadModule:" >> >> I'm very interested in this kind of quality assurance tools, so any help >> will be very welcomed. >> >> Thank you. >> >> >> > >

April 24, 2015

Re: [Pharo-users] ViDI error: variable named "aModuleName" in NativeBoost>>#loadModule:

by Yuriy Tymchuk

Ok, I found the problem. Some Spec api changed. I stable version will work at least on Mac quite soon. :) Uko > On 23 Apr 2015, at 17:46, Rafael Luque <rafael.luque.leiva(a)gmail.com> wrote: > > I'd like to use it in a Linux box, but as you told me Linux is not yet supported, I'm using a Mac OS X Yosemite (version 10.10.2). > > Thanks > > 2015-04-23 17:37 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Hi Rafael, > > I will take a look. Which operating system are you using? > > Uko > >> On 23 Apr 2015, at 17:30, Rafael Luque <rafael.luque.leiva(a)gmail.com <mailto:rafael.luque.leiva@gmail.com>> wrote: >> >> Hi, >> >> I installed ViDI on Pharo 4 following the project instructions detailed in its GitHub page: >> >> Gofer new >> smalltalkhubUser: 'YuriyTymchuk' >> project: 'Configuration'; >> configurationOf: 'Vidi'; >> load. >> #ConfigurationOfVidi asClass loadStable >> >> When I launch a review session over any package I always get the following error: >> >> "Could not find accesor for variable named "aModuleName" in NativeBoost>>#loadModule:" >> >> I'm very interested in this kind of quality assurance tools, so any help will be very welcomed. >> >> Thank you. > >

April 24, 2015

Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4

by Guillermo Polito

El vie., 24 de abr. de 2015 a la(s) 8:31 a. m., stepharo <stepharo(a)free.fr> escribiÃ³: > It is the configurationBrowser (but an old configuration) > DependencyAnalyser (guillermo I thought that I fixed the text: > deprecation but apparently not) > or in PharoExtras > Hey! It is fixed :) ! (just downloaded it 2 secs ago...) How did you load it? I did in latest pharo4 Configuration Browser > DependencyAnalizer > install stable > MCHttpRepository > location: > 'http://www.smalltalkhub.com/mc/PharoExtras/Tool-DependencyAnalyser/main' > user: '' > password: '' > > > > Le 23/4/15 11:14, Norbert Hartl a Ã©crit : > > Stef, > > > > where is "the tool"? > > > > Norbert > > > >> Am 23.04.2015 um 08:01 schrieb stepharo <stepharo(a)free.fr>: > >> > >> Two things: > >> > >> One: > >> We paid a guy to work on a tool to help us identifying dependencies, > The tool works well is fast. > >> if this tool would be in the image, everybody could check that there > are bad dependencies in his > >> code (and there are many around in nearly anybody's code). > >> No we prefer that me, pavel, and guille run it and fight with this > instead of making sure that > >> when you commit we get some feedback like: "oh strange that this > package is bound with this one". > >> This tool breaks when we do change in the image and I nicely (stupidly > I would say) maintain it. > >> > >> Two: > >> Our process is not great to manage external packages and we will add > more. > >> Sure it sounds like the right things to do, especially now. > >> > >> So to me it simply means that we are not serious and convinced about > modularity. > >> > >> But this is great, I'm reconsidering what I will do in Pharo so you > give me good indication > >> that I should not continue the way I was thinking. And no need to think > that I'm emotional > >> I'm not. I'm thinking about why hell I'm doing all this. > >> > >> Stef > >> > >> Le 22/4/15 21:27, Marcus Denker a Ã©crit : > >>>> On 22 Apr 2015, at 20:22, stepharo <stepharo(a)free.fr> wrote: > >>>> > >>>> > >>>> > >>>> Le 22/4/15 13:23, Esteban Lorenzano a Ã©crit : > >>>>> this is so good. > >>>>> what about integrate it to Pharo? > >>>> No. People should start to think modular. > >>>> No more external tools loaded by default. > >>>> Better invest in "add a startup preference" functionality in the > configurationBrowser. > >>>> > >>>> Why we do not integrate the excellent tool of baptiste that would > show to people > >>>> when they are creating package mess? Because of the same reason. > >>>> > >>> But the Pharo that we download should be the Pharo we use. > >>> > >>> We tried the other back in Pharo1.0: Do you remember how we fixed with > lots > >>> care all details, but then, everyone was using a different image, and > all the > >>> details there where not fixed and all work was done double? > >>> > >>> If we do not make the Pharo that is downloaded to be that was is used, > we will have > >>> that again. > >>> > >>> I donât want everything in the image, but what everyone is supposed to > be using should > >>> be there without needing an additional step. > >>> > >>> Marcus > >>> > >>> > >>> > >>> > >> > > > > > > >

April 24, 2015

Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4

by stepharo

I understand the point of marcus but still it is unclear why certain tools should be in and not others. Now I would prefer that we have a process that 1 := take a miniimage AND load the tools check that we can unload them (just to check) and only then declare pharo := 1. Now we will face the problem of ok we do a change and it touches such loaded tools (see the other thread) Read the Pharo vision paper. Stef Le 23/4/15 10:53, Yuriy Tymchuk a Ã©crit : > I totally agree with Stef that we should be able to do a rock solid setup of what tools we want to use in our everyday image. > > But on the other hand we have to design what Pharo is. Because we can even go Ruby style and say that debugger is not a part of the main system, but I see that our strength is to provide people with ultimate tools for development (although we cannot put everything inside). And I think that dependency browser is important and I will continue to convince people that quality of code is important and that we should use quality tools in our daily work. Maybe now QualityAssistant is not mature enough, but at some point it will be :). > > Cheers. > Uko > > > P.S. at the moment we are loosing competition to JetBrains tools because they give you live feedback about code critics. > > >> On 23 Apr 2015, at 09:04, stepharo <stepharo(a)free.fr> wrote: >> >> >> >> Le 23/4/15 09:05, Marcus Denker a Ã©crit : >>> I do not understand how âhaving a modular tool in the image â (that does not add dependencies to anything) >>> makes the system less modular. >> Then why the dependency Browser was not integrated? Why roassal for drawing dependencies >> and other aspects of the system? Because dependency browser as well as roassal are really useful, >> well packaged, What about pillar? Because it would be cool to have beautiful class comments in the future. The point is how and in which process. >> In addition what are the criteria? Feelings or criteria? Oh this tool is cool but this one less cool. >> Strange for scientific people no? >> I think that we should have a building process that load tools. >> We will not be able to put everything in the image: >> Did you look at the dependencies between RB, nautilus, history, EyeInspector? >> I did because it was getting the mess. My energy is cheap and infinite so I can spend 8 hours >> fixing configurations that nobody use or look at. But you see this period is ***over***. >> >>>> So to me it simply means that we are not serious and convinced about modularity. >>>> >>>> But this is great, I'm reconsidering what I will do in Pharo so you give me good indication >>>> that I should not continue the way I was thinking. And no need to think that I'm emotional >>>> I'm not. I'm thinking about why hell I'm doing all this. >>>> >>> You always directly go and argue by âI am now sadâ purely emotional level. >>> This is not good. >> Read what you want to read. But my energy in neither cheap nor infinite anymore. >> This is not a feeling but just a mere fact. >> >>> >>> Marcus >>> >>> >>> >> > >

April 24, 2015

Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4

by stepharo

It is the configurationBrowser (but an old configuration) DependencyAnalyser (guillermo I thought that I fixed the text: deprecation but apparently not) or in PharoExtras MCHttpRepository location: 'http://www.smalltalkhub.com/mc/PharoExtras/Tool-DependencyAnalyser/main' user: '' password: '' Le 23/4/15 11:14, Norbert Hartl a Ã©crit : > Stef, > > where is "the tool"? > > Norbert > >> Am 23.04.2015 um 08:01 schrieb stepharo <stepharo(a)free.fr>: >> >> Two things: >> >> One: >> We paid a guy to work on a tool to help us identifying dependencies, The tool works well is fast. >> if this tool would be in the image, everybody could check that there are bad dependencies in his >> code (and there are many around in nearly anybody's code). >> No we prefer that me, pavel, and guille run it and fight with this instead of making sure that >> when you commit we get some feedback like: "oh strange that this package is bound with this one". >> This tool breaks when we do change in the image and I nicely (stupidly I would say) maintain it. >> >> Two: >> Our process is not great to manage external packages and we will add more. >> Sure it sounds like the right things to do, especially now. >> >> So to me it simply means that we are not serious and convinced about modularity. >> >> But this is great, I'm reconsidering what I will do in Pharo so you give me good indication >> that I should not continue the way I was thinking. And no need to think that I'm emotional >> I'm not. I'm thinking about why hell I'm doing all this. >> >> Stef >> >> Le 22/4/15 21:27, Marcus Denker a Ã©crit : >>>> On 22 Apr 2015, at 20:22, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> >>>> >>>> Le 22/4/15 13:23, Esteban Lorenzano a Ã©crit : >>>>> this is so good. >>>>> what about integrate it to Pharo? >>>> No. People should start to think modular. >>>> No more external tools loaded by default. >>>> Better invest in "add a startup preference" functionality in the configurationBrowser. >>>> >>>> Why we do not integrate the excellent tool of baptiste that would show to people >>>> when they are creating package mess? Because of the same reason. >>>> >>> But the Pharo that we download should be the Pharo we use. >>> >>> We tried the other back in Pharo1.0: Do you remember how we fixed with lots >>> care all details, but then, everyone was using a different image, and all the >>> details there where not fixed and all work was done double? >>> >>> If we do not make the Pharo that is downloaded to be that was is used, we will have >>> that again. >>> >>> I donât want everything in the image, but what everyone is supposed to be using should >>> be there without needing an additional step. >>> >>> Marcus >>> >>> >>> >>> >> > >

April 24, 2015

Re: [Pharo-users] SoundSystem subclassing

by Nicolai Hess

2015-04-23 19:18 GMT+02:00 Mark Rizun <mrizun(a)gmail.com>: > Hi, > > I was investigating how to play sounds in Pharo, and found SoundSystem > class. > It is stated that you should subclass it, like DummySoundSystem does. > Is there any cool subclass (besides DummySoundSystem =D ) already > implemented so I can use it? > > Thanks, > Mark > BaseSoundSystem in PharoExtras/Sound (http://smalltalkhub.com/#!/~PharoExtras/Sound) > > > > -- > View this message in context: > http://forum.world.st/SoundSystem-subclassing-tp4821475.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 23, 2015