Re: [Pharo-users] ViDI error: variable named aModuleName in NativeBoost#loadModule:
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.le...@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.
Re: [Pharo-users] ViDI error: variable named aModuleName in NativeBoost#loadModule:
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.tymc...@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.le...@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.
Re: [Pharo-users] SoundSystem subclassing
2015-04-23 19:18 GMT+02:00 Mark Rizun mri...@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.
[Pharo-users] SoundSystem subclassing
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 -- 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.
Re: [Pharo-users] tinychat
great! Stef Le 21/4/15 17:02, Sean P. DeNigris a écrit : stepharo wrote Yes it is in FunWithPharo on github and thanks for the editing pass. No problem. I just committed the fixes. - Cheers, Sean -- View this message in context: http://forum.world.st/tinychat-tp4820781p4820832.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4
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 steph...@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
Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4
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
Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4
I do not understand how “having a modular tool in the image ” (that does not add dependencies to anything) makes the system less modular. Especially if the price we pay for that is a system where good tools are available, but nobody uses them. 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. Marcus
Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4
Stef, where is the tool? Norbert Am 23.04.2015 um 08:01 schrieb stepharo steph...@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 steph...@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
Re: [Pharo-users] Time traveling Pharo
fixed On 21 Apr 2015, at 19:11, Marcus Denker marcus.den...@inria.fr wrote: This is not correct… can you enter an issue? On 21 Apr 2015, at 19:07, Johan Fabry jfa...@dcc.uchile.cl wrote: Hi all, finally having some time to develop again, I downloaded the 4.0 image sources and vm (http://files.pharo.org/get-files/40/pharo.zip et cetera) through the links on the downloads page. It’s a bit strange that the image version is 5000, but OK I can understand it. More funny is the time traveling behavior that occurs when doing World-System-About. It says: Pharo5.0 Latest update: #5 […] Time-traveling from next year back to today! Wow! :-P --- Save our in-boxes! http://emailcharter.org --- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4
Hi Cyril, Your problem is caused because abstract methods should be marked with subclassResponsibility and not shouldBeImplemented. - shouldBeImplemented means this is a method I did not implement yet, I should replace *this* method with another implementation - subclassResponsibility means my subclasses should implement a method with this same selector The tools recognize the first as a normal concrete method and the second as an abstract method. El jue., 23 de abr. de 2015 a la(s) 10:15 a. m., Norbert Hartl norb...@hartl.name escribió: Stef, where is the tool? Norbert Am 23.04.2015 um 08:01 schrieb stepharo steph...@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 steph...@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
Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4
I changed that but i still have the warning from quality assistant. On 23 April 2015 at 12:44, Cyril Ferlicot cyril.ferli...@gmail.com wrote: Oh, ok ! Thank you Guillermo ! On 23 April 2015 at 11:58, Guillermo Polito guillermopol...@gmail.com wrote: Hi Cyril, Your problem is caused because abstract methods should be marked with subclassResponsibility and not shouldBeImplemented. - shouldBeImplemented means this is a method I did not implement yet, I should replace *this* method with another implementation - subclassResponsibility means my subclasses should implement a method with this same selector The tools recognize the first as a normal concrete method and the second as an abstract method. El jue., 23 de abr. de 2015 a la(s) 10:15 a. m., Norbert Hartl norb...@hartl.name escribió: Stef, where is the tool? Norbert Am 23.04.2015 um 08:01 schrieb stepharo steph...@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 steph...@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 -- Cheers Cyril Ferlicot -- Cheers Cyril Ferlicot
[Pharo-users] Versionner repository moved to PharoExtras
Hi, I just moved the Versionner repository from http://smalltalkhub.com/#!/~demarey/Versionner/ to http://smalltalkhub.com/#!/~PharoExtras/Versionner/. It will ease contributions and it will be easier to find with other tools / library of Pharo. Regards, Christophe. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-users] [Pharo-dev] QualityAssistant v0.4
Hi Cyril, I’ve checked the problem. It could be indeed easier if the rule pointed to it :). So you have PRFileInclusionreplace: and it is identical (not taking empty lines into account) to PRTransformerreplace:. So the rule is correct. You override a method with an identical method. Uko On 23 Apr 2015, at 12:48, Cyril Ferlicot cyril.ferli...@gmail.com wrote: I changed that but i still have the warning from quality assistant. On 23 April 2015 at 12:44, Cyril Ferlicot cyril.ferli...@gmail.com wrote: Oh, ok ! Thank you Guillermo ! On 23 April 2015 at 11:58, Guillermo Polito guillermopol...@gmail.com wrote: Hi Cyril, Your problem is caused because abstract methods should be marked with subclassResponsibility and not shouldBeImplemented. - shouldBeImplemented means this is a method I did not implement yet, I should replace *this* method with another implementation - subclassResponsibility means my subclasses should implement a method with this same selector The tools recognize the first as a normal concrete method and the second as an abstract method. El jue., 23 de abr. de 2015 a la(s) 10:15 a. m., Norbert Hartl norb...@hartl.name escribió: Stef, where is the tool? Norbert Am 23.04.2015 um 08:01 schrieb stepharo steph...@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 steph...@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 -- Cheers Cyril Ferlicot -- Cheers Cyril Ferlicot
