September 2013 - Pharo-dev - lists.pharo.org

[About Documentation] Teach, Don't Tell / Steve Losh

by Sven Van Caekenberghe

Pretty well written piece about real documentation: http://stevelosh.com/blog/2013/09/teach-dont-tell/ Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

Sept. 4, 2013

Re: [Pharo-dev] Sound on Ubuntu Problems

by Marcus Denker

On Sep 4, 2013, at 11:22 AM, J.F. Rick <self(a)je77.com> wrote: > Hmm. Did this get sent or was it filtered? It doesn't seem to be in my inbox for the pharo-dev list. > It arrivedâ¦ > Cheers, > > Jeff > > > On Tue, Sep 3, 2013 at 5:03 PM, J.F. Rick <self(a)je77.com> wrote: > I'm using Pharo 2.0 on Ubuntu 13.10 and I can't seem to get sound working. Getting sound to work on Linux seems to be a common problem. While I've checked the archive for solutions, none of them work for me. I've investigated a bit and here's what I've found: > > Inside of the /usr/lib/pharo-vm directory, I see the following: > vm-sound-ALSA.so > vm-sound-null.so > vm-sound-pulse.so (I added that based on an archive post that this would work) > > When I do "pharo -vm-sound-null pharo.image", it works correctly. > When I do "pharo -vm-sound-ALSA pharo.image", it gives me an error that "could not find module vm-sound-ALSA". > > When I do "pharo-help", I find that the only sound driver available is "vm-sound-null", though the others are clearly there in the directory. Is there anything I can do to make the VM acknowledge that the other files are there? > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick

Sept. 4, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Marcus Denker

On Sep 4, 2013, at 10:18 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> >>>> But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. >>>> But nevertheless, all show-stopping bugs should be fixed. >>> >>> >>>> In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? >>> >>> I can undestand that. >>> >>> I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. >>> >>> But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. >>> >> >> What is a solution other than stopping development and declaring Pharo as finished as it is? > > No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around, that 2.0 is the main development platform for Pharo users, 3.0 is where you make interesting stuff. > Yes, and the whole moving forward vs. stability is a real, classical tragedy: there is no solution other than minimizing the pain. Whatever we do it will be wrong. The only "solution" is to stop doing, then the pain stops but there will be no future. e.g. imagine we would say: "Yes, you convinced us to stop. Pharo is finished". Then someone else would develop "SuperSmalltalk" which is more or less what Pharo 6 would have been, and it's even released around that time. What will the reactions of the Pharo users be? -> "I will not use it because I argued that Pharo is perfect and finished and I now will support those people who gave up on their future for my needs 4 years ago!" ? > And that Pharo users are at least one version behind you, and that they would like a bit of smoothness in the way it evolves... 3.0 gives directions; but a bit of backport to help with the transition would be, what, just friendly to your users. > > For example, for things I am aware of: > - backport ensureDelete to 2.0 > - backport the replacement of Keymapping on:do: Ok, then lets move forward with these. In the grand scheme of things, this is not that much work to fix. > > You have 2.0 users who have things to say and who are able to correct things as well; don't belittle them by saying "All software development should be done on 3.0" [Camillo Bruni]. > Yes, there are many people in Pharo and everyone has their own opinion, and this is good. But why would we maintain 2.0 if nobody is suppose to use it? Marcus

Sept. 4, 2013

Re: [Pharo-dev] Sound on Ubuntu Problems

by J.F. Rick

Hmm. Did this get sent or was it filtered? It doesn't seem to be in my inbox for the pharo-dev list. Cheers, Jeff On Tue, Sep 3, 2013 at 5:03 PM, J.F. Rick <self(a)je77.com> wrote: > I'm using Pharo 2.0 on Ubuntu 13.10 and I can't seem to get sound working. > Getting sound to work on Linux seems to be a common problem. While I've > checked the archive for solutions, none of them work for me. I've > investigated a bit and here's what I've found: > > Inside of the /usr/lib/pharo-vm directory, I see the following: > vm-sound-ALSA.so > vm-sound-null.so > vm-sound-pulse.so (I added that based on an archive post that this would > work) > > When I do "pharo -vm-sound-null pharo.image", it works correctly. > When I do "pharo -vm-sound-ALSA pharo.image", it gives me an error that > "could not find module vm-sound-ALSA". > > When I do "pharo-help", I find that the only sound driver available is > "vm-sound-null", though the others are clearly there in the directory. Is > there anything I can do to make the VM acknowledge that the other files are > there? > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Sept. 4, 2013

Re: [Pharo-dev] Interesting regression on 30366

by Stephan Eggermont

Hmm, and somewhat later the image freezes

Sept. 4, 2013

Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted

by Igor Stasenko

Yes, systematical approach matters :) But as to me it is quite simple feature, and in right hands (pointing at Ben ;), it can be implemented quite easily. In Nautilus there as many features which has similar concepts (need to change browser's context) - like navigation history. I guess combining it with unaccepted edits won't take much effort to implement. On 4 September 2013 10:40, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I have a different opinion. This modality issue is not something we fix as > a bug. Of course, we can put in place a patch that somehow makes it work in > the current browser, but the core problem is a conceptual one. And that > requires a redesign of the user interface. > > If we have a problem with a code model, we do not just put an if to patch > the thing. Ok, sometimes we do that just because we cannot see a different > solution, but we are not comfortable with it. We have to treat the user > interface in the same way. > > Doru > > > On Wed, Sep 4, 2013 at 9:56 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> >> On Sep 3, 2013, at 9:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >> > agreed we should change that since years. >> > Some days we should stop and fix all the glitches that give us these >> hiccups. >> >> ... and that day is around october, when we freeze pharo3 and start to >> fix bugs :) >> >> Esteban >> >> > >> > stef >> > >> > On Sep 3, 2013, at 3:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> > >> >> >> >> this is most annoying to me, that UI interrupts you in very strange >> manner >> >> and asks you to make a decision: >> >> - accept, or discard the method, or cancel the action. >> >> >> >> often, you are in the middle of typing new stuff and source code >> >> can be even not syntactically correct.. so, you have to discard or die >> :) >> >> >> >> what i think the solution could be is that browser should allow you to >> switch contexts >> >> at any moment without asking you anything.Instead it should remember >> your >> >> unsaved changes in special 'drafts' collection, which later you can >> get back on, >> >> when you finish what you wanted to do. >> >> >> >> And the only time when you want unaccepted edits to not get lost >> forever is when you closing >> >> a browser window.. (but of course, drafts can be stored globally >> somewhere, >> >> then it also not a big deal, since you can simply return to your draft >> in different window). >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> > >> > >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- Best regards, Igor Stasenko.

Sept. 4, 2013

Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted

by Igor Stasenko

On 4 September 2013 08:38, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 03.09.2013 um 15:07 schrieb Igor Stasenko <siguctua(a)gmail.com>: > > > > > this is most annoying to me, that UI interrupts you in very strange > manner > > and asks you to make a decision: > > - accept, or discard the method, or cancel the action. > > > > often, you are in the middle of typing new stuff and source code > > can be even not syntactically correct.. so, you have to discard or die :) > > > > what i think the solution could be is that browser should allow you to > switch contexts > > at any moment without asking you anything.Instead it should remember your > > unsaved changes in special 'drafts' collection, which later you can get > back on, > > when you finish what you wanted to do. > > > > And the only time when you want unaccepted edits to not get lost forever > is when you closing > > a browser window.. (but of course, drafts can be stored globally > somewhere, > > then it also not a big deal, since you can simply return to your draft > in different window). > > We have method versions. I don't see a reason why uncommited methods can > not go just on the list. They could be marked as unsaved/unommited (in fact > they are not compiled so different per se) or even better the method > version list should be a timeline where the current version is the present > and everything else is a past or a potential future version. > > you forgetting that user may decide to create new method in code pane, instead of editing existing one. and only when users asks to compile the code (by accepting it) you know where it goes, but making any categorization before, as to me, looks counterproductive. i think that drafts should be stored in separate collection, not related to versions. > Norbert > -- Best regards, Igor Stasenko.

Sept. 4, 2013

Interesting regression on 30366

by Stephan Eggermont

When running Pharo 30366 tests on Pharo VM 6.0-pre (21.0) on a 10.6.8 mac I get different results when I open the image and run the tests compared to when I saved and quit the image and then re-run the tests. 2nd time results: 11287 run, 11232 passes, 12 skipped, 26 expected failures, 6 failures, 23 errors, 0 unexpected passes Failures: DelayTest>>#testMultiProcessWaitOnSameDelay ReleaseTest>>#testUnknownProcesses NetNameResolverTest>>#testLocalHostName ProcessTest>>#testHighPriorityOverridesWaitTime BlockClosureTest>>#testTrace ReleaseTest>>#testObsoleteBehaviors Errors: NBPointerArgumentsTests>>#testEnumCase1ByteArray NBPointerArgumentsTests>>#testEnumCase1ExternalAddress NBPointerArgumentsTests>>#testEnumCase2ByteArray NBPointerArgumentsTests>>#testEnumCase2ExternalAddress NBPointerArgumentsTests>>#testEnumCase3ByteArray NBPointerArgumentsTests>>#testEnumCase3ExternalAddress NBPointerArgumentsTests>>#testEnumCase4ByteArray NBPointerArgumentsTests>>#testEnumCase4ExternalAddress NBPointerArgumentsTests>>#testIntCase1ByteArray NBPointerArgumentsTests>>#testIntCase1ExternalAddress NBPointerArgumentsTests>>#testIntCase2ByteArray NBPointerArgumentsTests>>#testIntCase2ExternalAddress NBPointerArgumentsTests>>#testIntCase3ByteArray NBPointerArgumentsTests>>#testIntCase3ExternalAddress NBPointerArgumentsTests>>#testIntCase4ByteArray NBPointerArgumentsTests>>#testStructCase1ByteArray NBPointerArgumentsTests>>#testStructCase1ExternalAddress NBPointerArgumentsTests>>#testStructCase2ByteArray NBPointerArgumentsTests>>#testStructCase2ExternalAddress NBPointerArgumentsTests>>#testStructCase3ByteArray NBPointerArgumentsTests>>#testStructCase3ExternalAddress NBPointerArgumentsTests>>#testStructCase4ByteArray NBPointerArgumentsTests>>#testStructCase4ExternalAddress

Sept. 4, 2013

Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted

by Tudor Girba

I have a different opinion. This modality issue is not something we fix as a bug. Of course, we can put in place a patch that somehow makes it work in the current browser, but the core problem is a conceptual one. And that requires a redesign of the user interface. If we have a problem with a code model, we do not just put an if to patch the thing. Ok, sometimes we do that just because we cannot see a different solution, but we are not comfortable with it. We have to treat the user interface in the same way. Doru On Wed, Sep 4, 2013 at 9:56 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On Sep 3, 2013, at 9:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > agreed we should change that since years. > > Some days we should stop and fix all the glitches that give us these > hiccups. > > ... and that day is around october, when we freeze pharo3 and start to fix > bugs :) > > Esteban > > > > > stef > > > > On Sep 3, 2013, at 3:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > >> > >> this is most annoying to me, that UI interrupts you in very strange > manner > >> and asks you to make a decision: > >> - accept, or discard the method, or cancel the action. > >> > >> often, you are in the middle of typing new stuff and source code > >> can be even not syntactically correct.. so, you have to discard or die > :) > >> > >> what i think the solution could be is that browser should allow you to > switch contexts > >> at any moment without asking you anything.Instead it should remember > your > >> unsaved changes in special 'drafts' collection, which later you can get > back on, > >> when you finish what you wanted to do. > >> > >> And the only time when you want unaccepted edits to not get lost > forever is when you closing > >> a browser window.. (but of course, drafts can be stored globally > somewhere, > >> then it also not a big deal, since you can simply return to your draft > in different window). > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 4, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Goubier Thierry

Le 04/09/2013 10:06, Marcus Denker a Ã©crit : > > On Sep 4, 2013, at 10:00 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 04/09/2013 09:40, Marcus Denker a Ã©crit : >>>>>> >>>>> >>>>> Why do you need to support Squeak 3.8? This is how many years old? >>>>> >>>>> I really do not understand this idea to be compatible to all old versions ever. >>>> >>>> I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works. >>>> >>>>> In the end it will just make sure that no progress is possible at all. >>>> >>>> I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well. >>> >>> Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially >>> not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these >>> tend to introduce new problems, making it very hard to stabilize). >> >> Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3? > > No, I am afraid that the improvements add more bugs. This is in the end why there are Problems in Pharo3. If we do > what we did in Pharo3 in Pharo2, then these Problems are in Pharo2. > >> >>> But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. >>> But nevertheless, all show-stopping bugs should be fixed. >> >> >>> In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? >> >> I can undestand that. >> >> I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. >> >> But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. >> > > What is a solution other than stopping development and declaring Pharo as finished as it is? No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around, that 2.0 is the main development platform for Pharo users, 3.0 is where you make interesting stuff. And that Pharo users are at least one version behind you, and that they would like a bit of smoothness in the way it evolves... 3.0 gives directions; but a bit of backport to help with the transition would be, what, just friendly to your users. For example, for things I am aware of: - backport ensureDelete to 2.0 - backport the replacement of Keymapping on:do: You have 2.0 users who have things to say and who are able to correct things as well; don't belittle them by saying "All software development should be done on 3.0" [Camillo Bruni]. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 4, 2013