Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted
There were an addon named DontModeMeIn for VisualWorks browser which I believe did the same thing. It was written by Vasilii Bykov and there was an article on it in his blog, but I can't find that blog in the new Cincom's site, and can't find that article in WaybackMachine either… The only reference I can find is here [ http://scg.unibe.ch/download/wasdett/wasdett2008-paper03.pdf]. Hopefully, the addon is still in Cincom's Public Repository… -- Best regards, Dennis Schetinin 2013/9/4 Norbert Hartl norb...@hartl.name Am 03.09.2013 um 15:07 schrieb Igor Stasenko siguc...@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. Norbert
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 03/09/2013 21:04, Camillo Bruni a écrit : On 2013-09-03, at 09:36, Goubier Thierry thierry.goub...@cea.fr wrote: And I would probably have to come and try to maintain your fork because you wouldn't be using it and let it be deprecated for pharo 4 or 5... exactly, and for each Pharo version there is a different branch of OSProcess. Sometimes, you just have to go with how the software you are using and updating is handling this adaptation... If it's something by you, I won't hesitate to branch and fork :) well, once you start working on git you see the advantages of branches ;) too bad that the monticello tools do not properly support this feature. Yes, I was thinking of how to use git branches for gitfiletree:// repositories and couldn't find a right way to integrate it into Monticello, apart from displaying the current branch when browsing a git repository. 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
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 04/09/2013 08:38, Marcus Denker a écrit : On Sep 4, 2013, at 4:52 AM, David T. Lewis le...@mail.msen.com wrote: On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. 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. 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
Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted
Here's [ http://www.cincomsmalltalk.com/publicRepository/VB-Sketch-DontModeMeIn.html] the description: An experimental tweak of the Refactoring Browser to support modeless editing. With this installed, it is possible to go to a different method or class within the same browser. while a method is being edited The postponed edit appears as an icon at the bottom of the browser. Clicking it will jump back to the edit in progress. NOTE: Close all browser windows before or immediately after loading this package. This package is currently unloadable and is should not be loaded into image that has RB_Tabs loaded (or vice versa). -- Best regards, Dennis Schetinin 2013/9/4 Dennis Schetinin chae...@gmail.com There were an addon named DontModeMeIn for VisualWorks browser which I believe did the same thing. It was written by Vasilii Bykov and there was an article on it in his blog, but I can't find that blog in the new Cincom's site, and can't find that article in WaybackMachine either… The only reference I can find is here [ http://scg.unibe.ch/download/wasdett/wasdett2008-paper03.pdf]. Hopefully, the addon is still in Cincom's Public Repository… -- Best regards, Dennis Schetinin 2013/9/4 Norbert Hartl norb...@hartl.name Am 03.09.2013 um 15:07 schrieb Igor Stasenko siguc...@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. Norbert
Re: [Pharo-dev] OSProcess for Pharo3.0
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). 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. right now, there are 3 bugs reported for Pharo 2.0: https://pharo.fogbugz.com/f/filters/8/2-0-Work-Needed none of which is fixed in Pharo3 yet. 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? Marcus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted
On Sep 3, 2013, at 9:27 PM, Stéphane Ducasse stephane.duca...@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 siguc...@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.
Re: [Pharo-dev] OSProcess for Pharo3.0
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? 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. I'm OK with that. It's just that I'm updating a fix for a bug on both Pharo2 and Pharo3 by myself just to be able to open a file browser and get correct file permissions. I'm also unable to be sympathetic to a situation where I have two versions of a code just because when deprecating ensureDeleted in 3.0, nobody thought usefull to backport ensureDelete so that we could ensure that code using ensureDelete could work on both versions. 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. 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
Re: [Pharo-dev] OSProcess for Pharo3.0
On Sep 4, 2013, at 10:00 AM, Goubier Thierry thierry.goub...@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? Marcus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 04/09/2013 10:06, Marcus Denker a écrit : On Sep 4, 2013, at 10:00 AM, Goubier Thierry thierry.goub...@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
[Pharo-dev] Interesting regression on 30366
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
Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted
On 4 September 2013 08:38, Norbert Hartl norb...@hartl.name wrote: Am 03.09.2013 um 15:07 schrieb Igor Stasenko siguc...@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.
Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted
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 tu...@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 esteba...@gmail.comwrote: On Sep 3, 2013, at 9:27 PM, Stéphane Ducasse stephane.duca...@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 siguc...@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.
Re: [Pharo-dev] Sound on Ubuntu Problems
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 s...@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
Re: [Pharo-dev] Interesting regression on 30366
Hmm, and somewhat later the image freezes
Re: [Pharo-dev] OSProcess for Pharo3.0
On Sep 4, 2013, at 10:18 AM, Goubier Thierry thierry.goub...@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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Sound on Ubuntu Problems
On Sep 4, 2013, at 11:22 AM, J.F. Rick s...@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 s...@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 signature.asc Description: Message signed with OpenPGP using GPGMail
[Pharo-dev] [About Documentation] Teach, Don't Tell / Steve Losh
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
Re: [Pharo-dev] Interesting regression on 30366
On Sep 4, 2013, at 10:59 AM, Stephan Eggermont step...@stack.nl wrote: When running Pharo 30366 tests on Pharo VM 6.0-pre (21.0) on a 10.6.8 mac I really need to deprecate that number (6.0-pre (21.0)) and replace it for the git commit number... it does not says anything to me now :S Basically... I don't know which VM are you using :) Can you paste the result of: Smalltalk vm version please? 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
Re: [Pharo-dev] Sound on Ubuntu Problems
Hi! If the modules are not printed, that probably means that they cannot be loaded :). (Bah, I assume that by looking at the vm code that does that [1]). So, first thing you can do is to see the output of stderr. Second, you can try to do an ldd [2] to the vm-sound-ALSA.so library to check the dependencies and try to get them installed via ap-tget. Keep us informed :) Cheers, Guille [1] https://github.com/pharo-project/pharovm/blob/e4ccdb38e01578e3569c9c42d2199682584772ec/platforms/unix/vm/sqUnixMain.c#L965 [2] http://man.yolinux.com/cgi-bin/man2html?cgi_command=ldd On Wed, Sep 4, 2013 at 11:32 AM, Marcus Denker marcus.den...@inria.frwrote: On Sep 4, 2013, at 11:22 AM, J.F. Rick s...@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 s...@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
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 04/09/2013 11:27, Marcus Denker a écrit : On Sep 4, 2013, at 10:18 AM, Goubier Thierry thierry.goub...@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. You're arguing the extreme there :) Forced march to 3.0 seems difficult and counter productive to me, that's all. 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! ? I'm sure you are good enough to convince people to switch to 3.0 even if 2.0 has no bugs. And there will still be new things for 4.0, 5.0, 6.0, ... Many things in store for 3.0 are very interesting and motivating; it's just that, given the state of things, I have to wait and get 2.0 fixed as well as possible. And get ready to transition to 3.0 as smoothly as possible (and repeat for the next version)... 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? That's the point :) 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
Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted
Doru 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. +1 And with the current state of technology, probably 2 interfaces. One for large screen devices and one for small screens. Igor wrote: But as to me it is quite simple feature, and in right hands (pointing at Ben ;), it can be implemented quite easily. I'd suggest doing something simpler: add an Open what you clicked on in a new browser as an extra option in the dialog. Making modeless editing work well, is anything but trivial, and our track record at cleaning up the UI still has some room for improvement http://forum.world.st/Nautilus-look-amp-feel-td4634990.html Stephan
Re: [Pharo-dev] OSProcess for Pharo3.0
I don't understand where the tragedy is.. you want your production code to work in Pharo 2.0? Write it to work well in 2.0, don't care about 3.0 or any other future possible changes. Want your code to work on bleeding-edge 3.0 image? Refactor/do the changes to make it work.. leave 2.0 behind. You want both? So, keep 2 separate versions for each version of system. You just have to accept that there is no code which will magically stay compatible with all old and all possible future versions without any changes. On 4 September 2013 11:27, Marcus Denker marcus.den...@inria.fr wrote: On Sep 4, 2013, at 10:18 AM, Goubier Thierry thierry.goub...@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 -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Sound on Ubuntu Problems
Thanks. When trying to load the ALSA sound, stderr just reports could not find module vm-sound-ALSA. Doing an ldd on the vm-sound-ALSA.so included with the Pharo VM, I get: linux-gate.so.1 = (0xf76e9000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf7515000) /lib/ld-linux.so.2 (0xf76ea000) Doing an ldd on the vm-sound-ALSA.so included with the Squeak VM, I get: linux-vdso.so.1 = (0x7fffbdbfe000) libasound.so.2 = /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x7f3c507ba000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f3c503f3000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f3c500ee000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3c4feea000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f3c4fccd000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f3c4fac4000) /lib64/ld-linux-x86-64.so.2 (0x7f3c50cca000) There doesn't seem to be anything clearly missing. Doing an ldd on the vm-sound-pulse.so included with the Squeak VM, I get: linux-gate.so.1 = (0xf7721000) libpulse-simple.so.0 = not found libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf754f000) /lib/ld-linux.so.2 (0xf7722000) I did try to install the libpulse package (apt-get install libpulse-dev) but that file is still missing. Weirdly enough, doing an ldd on the vm-sound-null.so included with Pharo, I get: linux-gate.so.1 = (0xf774c000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf757c000) /lib/ld-linux.so.2 (0xf774d000) which is the exact same thing as for vm-sound-ALSA.so. So, I would imagine that if the one worked than the other would. Cheers, Jeff On Wed, Sep 4, 2013 at 11:48 AM, Guillermo Polito guillermopol...@gmail.com wrote: Hi! If the modules are not printed, that probably means that they cannot be loaded :). (Bah, I assume that by looking at the vm code that does that [1]). So, first thing you can do is to see the output of stderr. Second, you can try to do an ldd [2] to the vm-sound-ALSA.so library to check the dependencies and try to get them installed via ap-tget. Keep us informed :) Cheers, Guille [1] https://github.com/pharo-project/pharovm/blob/e4ccdb38e01578e3569c9c42d2199682584772ec/platforms/unix/vm/sqUnixMain.c#L965 [2] http://man.yolinux.com/cgi-bin/man2html?cgi_command=ldd On Wed, Sep 4, 2013 at 11:32 AM, Marcus Denker marcus.den...@inria.frwrote: On Sep 4, 2013, at 11:22 AM, J.F. Rick s...@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 s...@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 -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Re: [Pharo-dev] specialSelectors
As I see it, there is around a hundred kBytes gain overall, maybe more in a production image full of add-on classes. Not that much nowadays, but since we cannot remove the complexity, it's still worth to select the selectors with most references. 2013/9/4 Igor Stasenko siguc...@gmail.com i think you can feel the difference while running interpreter. With JIT it makes little sense to have special selectors imo. On 4 September 2013 12:31, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: Agree, My point was to ensure there was no speedup, so it's only a space optimization (1 slot saved from literals, times 5000 senders or so per selector plus maybe a byte for the send bytecode ?). However the arithmetic ops, comparisons, bit ops, at: at:put:, == and class special selectors still have some specific speed up, especially in COG, so we cannot get rid of specialSelectors alltogether... 2013/9/4 Marcus Denker marcus.den...@inria.fr On Sep 4, 2013, at 12:08 AM, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I note that #class was removed from specialSelectors (nilled entry) so as to not use the VM hack which fetches the class without sending a message. Pharo prefers the regular message send. But next to that entry, there is #blockCopy: which was formerly used for blue book BlockContext. BlockContext was removed from Pharo... So that makes two available slots for optimizing most used (sent) messages... We might choose some candidates and test on some macro benchmark if ever that really makes a difference. I am not sure if optimizations on that level make sense… Marcus -- Best regards, Igor Stasenko.
Re: [Pharo-dev] specialSelectors
In JIT, it makes sense because there are special handling for well known special selectors (#+ #at: # etc...). 2013/9/4 Igor Stasenko siguc...@gmail.com i think you can feel the difference while running interpreter. With JIT it makes little sense to have special selectors imo. On 4 September 2013 12:31, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: Agree, My point was to ensure there was no speedup, so it's only a space optimization (1 slot saved from literals, times 5000 senders or so per selector plus maybe a byte for the send bytecode ?). However the arithmetic ops, comparisons, bit ops, at: at:put:, == and class special selectors still have some specific speed up, especially in COG, so we cannot get rid of specialSelectors alltogether... 2013/9/4 Marcus Denker marcus.den...@inria.fr On Sep 4, 2013, at 12:08 AM, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I note that #class was removed from specialSelectors (nilled entry) so as to not use the VM hack which fetches the class without sending a message. Pharo prefers the regular message send. But next to that entry, there is #blockCopy: which was formerly used for blue book BlockContext. BlockContext was removed from Pharo... So that makes two available slots for optimizing most used (sent) messages... We might choose some candidates and test on some macro benchmark if ever that really makes a difference. I am not sure if optimizations on that level make sense… Marcus -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Sound on Ubuntu Problems
I'd say it's pretty strange that the vm-sound-ALSA needs almost nothing... From the code I'd think It'd need to bind against asound [1], as the squeak vm says in libasound.so.2 = /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x7f3c507ba000) [1] https://github.com/pharo-project/pharovm/blob/master/platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c#L34 On Wed, Sep 4, 2013 at 12:37 PM, J.F. Rick s...@je77.com wrote: Thanks. When trying to load the ALSA sound, stderr just reports could not find module vm-sound-ALSA. Doing an ldd on the vm-sound-ALSA.so included with the Pharo VM, I get: linux-gate.so.1 = (0xf76e9000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf7515000) /lib/ld-linux.so.2 (0xf76ea000) Doing an ldd on the vm-sound-ALSA.so included with the Squeak VM, I get: linux-vdso.so.1 = (0x7fffbdbfe000) libasound.so.2 = /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x7f3c507ba000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f3c503f3000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f3c500ee000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3c4feea000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f3c4fccd000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f3c4fac4000) /lib64/ld-linux-x86-64.so.2 (0x7f3c50cca000) There doesn't seem to be anything clearly missing. Doing an ldd on the vm-sound-pulse.so included with the Squeak VM, I get: linux-gate.so.1 = (0xf7721000) libpulse-simple.so.0 = not found libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf754f000) /lib/ld-linux.so.2 (0xf7722000) I did try to install the libpulse package (apt-get install libpulse-dev) but that file is still missing. Weirdly enough, doing an ldd on the vm-sound-null.so included with Pharo, I get: linux-gate.so.1 = (0xf774c000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf757c000) /lib/ld-linux.so.2 (0xf774d000) which is the exact same thing as for vm-sound-ALSA.so. So, I would imagine that if the one worked than the other would. Cheers, Jeff On Wed, Sep 4, 2013 at 11:48 AM, Guillermo Polito guillermopol...@gmail.com wrote: Hi! If the modules are not printed, that probably means that they cannot be loaded :). (Bah, I assume that by looking at the vm code that does that [1]). So, first thing you can do is to see the output of stderr. Second, you can try to do an ldd [2] to the vm-sound-ALSA.so library to check the dependencies and try to get them installed via ap-tget. Keep us informed :) Cheers, Guille [1] https://github.com/pharo-project/pharovm/blob/e4ccdb38e01578e3569c9c42d2199682584772ec/platforms/unix/vm/sqUnixMain.c#L965 [2] http://man.yolinux.com/cgi-bin/man2html?cgi_command=ldd On Wed, Sep 4, 2013 at 11:32 AM, Marcus Denker marcus.den...@inria.frwrote: On Sep 4, 2013, at 11:22 AM, J.F. Rick s...@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 s...@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 -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Re: [Pharo-dev] Sound on Ubuntu Problems
Indeed. Yet the Squeak version does not load either. Cheers, Jeff On Wed, Sep 4, 2013 at 12:49 PM, Guillermo Polito guillermopol...@gmail.com wrote: I'd say it's pretty strange that the vm-sound-ALSA needs almost nothing... From the code I'd think It'd need to bind against asound [1], as the squeak vm says in libasound.so.2 = /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x7f3c507ba000) [1] https://github.com/pharo-project/pharovm/blob/master/platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c#L34 On Wed, Sep 4, 2013 at 12:37 PM, J.F. Rick s...@je77.com wrote: Thanks. When trying to load the ALSA sound, stderr just reports could not find module vm-sound-ALSA. Doing an ldd on the vm-sound-ALSA.so included with the Pharo VM, I get: linux-gate.so.1 = (0xf76e9000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf7515000) /lib/ld-linux.so.2 (0xf76ea000) Doing an ldd on the vm-sound-ALSA.so included with the Squeak VM, I get: linux-vdso.so.1 = (0x7fffbdbfe000) libasound.so.2 = /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x7f3c507ba000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f3c503f3000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f3c500ee000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3c4feea000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f3c4fccd000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f3c4fac4000) /lib64/ld-linux-x86-64.so.2 (0x7f3c50cca000) There doesn't seem to be anything clearly missing. Doing an ldd on the vm-sound-pulse.so included with the Squeak VM, I get: linux-gate.so.1 = (0xf7721000) libpulse-simple.so.0 = not found libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf754f000) /lib/ld-linux.so.2 (0xf7722000) I did try to install the libpulse package (apt-get install libpulse-dev) but that file is still missing. Weirdly enough, doing an ldd on the vm-sound-null.so included with Pharo, I get: linux-gate.so.1 = (0xf774c000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf757c000) /lib/ld-linux.so.2 (0xf774d000) which is the exact same thing as for vm-sound-ALSA.so. So, I would imagine that if the one worked than the other would. Cheers, Jeff On Wed, Sep 4, 2013 at 11:48 AM, Guillermo Polito guillermopol...@gmail.com wrote: Hi! If the modules are not printed, that probably means that they cannot be loaded :). (Bah, I assume that by looking at the vm code that does that [1]). So, first thing you can do is to see the output of stderr. Second, you can try to do an ldd [2] to the vm-sound-ALSA.so library to check the dependencies and try to get them installed via ap-tget. Keep us informed :) Cheers, Guille [1] https://github.com/pharo-project/pharovm/blob/e4ccdb38e01578e3569c9c42d2199682584772ec/platforms/unix/vm/sqUnixMain.c#L965 [2] http://man.yolinux.com/cgi-bin/man2html?cgi_command=ldd On Wed, Sep 4, 2013 at 11:32 AM, Marcus Denker marcus.den...@inria.frwrote: On Sep 4, 2013, at 11:22 AM, J.F. Rick s...@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 s...@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 -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Re: [Pharo-dev] OSProcess for Pharo3.0
Le 04/09/2013 11:52, Igor Stasenko a écrit : I don't understand where the tragedy is.. you want your production code to work in Pharo 2.0? Write it to work well in 2.0, don't care about 3.0 or any other future possible changes. Want your code to work on bleeding-edge 3.0 image? Refactor/do the changes to make it work.. leave 2.0 behind. It's very tempting to do that, effectively. Want SmaCC on 3.0? Sorry, I'm only using 2.0, so you're on your own :( Want smart suggestions in Nautilus in 2.0? Sorry, not implemented. You want both? So, keep 2 separate versions for each version of system. And appreciate how the attitude makes it more complex than it has to be. You just have to accept that there is no code which will magically stay compatible with all old and all possible future versions without any changes. Yes, and its hard enough for people to appreciate any effort made in helping smooth out the transition. 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
Re: [Pharo-dev] OSProcess for Pharo3.0
Thanks Henry for the correction. Should I prepare an OSProcess version with all the changes necessary for Pharo3 ? Thierry Le 04/09/2013 04:51, David T. Lewis a écrit : On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major = 3 ]]]. ^false Dave platformName After Squeak version 3.6, #platformName was moved to SmalltalkImage Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages. Then Pharo moved away from OSPlatform and deprecated its use. self platformName self isPharo3AndLater ifTrue: [ ^ Smalltalk os name ]. ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #platformName]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) platformName Thanks! Dave Dave -- 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 -- 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 -- 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
Re: [Pharo-dev] Interesting regression on 30366
'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Sep 3 2013 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Sep 3 2013 g...@github.com:pharo-project/pharovm.git Commit: 581a11414063fec0e53f047ca90de5e1b6d3b188 Date: 2013-08-28 15:11:08 +0200 By: GuillePolito guillermopol...@gmail.com Jenkins build #14636 ' Does it different Open test browser, run selected tests: 11287 run, 11258 passes, 12 skipped, 26 expected failures, 3 failures, 0 errors, 0 unexpected passes Failures: ReleaseTest#testUnknownProcesses NetNameResolverTest#testLocalHostName ProcessTest#testHighPriorityOverridesWaitTime Errors: After save-and-quit rerun: 11287 run, 11254 passes, 12 skipped, 26 expected failures, 7 failures, 0 errors, 0 unexpected passes Failures: DelayTest#testSemaphore ReleaseTest#testUnknownProcesses DelayTest#testMultiProcessWaitOnSameDelay NetNameResolverTest#testLocalHostName ReleaseTest#testObsoleteBehaviors ReleaseTest#testObsoleteClasses ProcessTest#testHighPriorityOverridesWaitTime Errors:
Re: [Pharo-dev] Sound on Ubuntu Problems
Do you have libasound installed for i386? cause the one that outputs ldd looks like in folder for x86_64 On Wed, Sep 4, 2013 at 1:06 PM, J.F. Rick s...@je77.com wrote: Indeed. Yet the Squeak version does not load either. Cheers, Jeff On Wed, Sep 4, 2013 at 12:49 PM, Guillermo Polito guillermopol...@gmail.com wrote: I'd say it's pretty strange that the vm-sound-ALSA needs almost nothing... From the code I'd think It'd need to bind against asound [1], as the squeak vm says in libasound.so.2 = /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x7f3c507ba000) [1] https://github.com/pharo-project/pharovm/blob/master/platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c#L34 On Wed, Sep 4, 2013 at 12:37 PM, J.F. Rick s...@je77.com wrote: Thanks. When trying to load the ALSA sound, stderr just reports could not find module vm-sound-ALSA. Doing an ldd on the vm-sound-ALSA.so included with the Pharo VM, I get: linux-gate.so.1 = (0xf76e9000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf7515000) /lib/ld-linux.so.2 (0xf76ea000) Doing an ldd on the vm-sound-ALSA.so included with the Squeak VM, I get: linux-vdso.so.1 = (0x7fffbdbfe000) libasound.so.2 = /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x7f3c507ba000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f3c503f3000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f3c500ee000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3c4feea000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f3c4fccd000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f3c4fac4000) /lib64/ld-linux-x86-64.so.2 (0x7f3c50cca000) There doesn't seem to be anything clearly missing. Doing an ldd on the vm-sound-pulse.so included with the Squeak VM, I get: linux-gate.so.1 = (0xf7721000) libpulse-simple.so.0 = not found libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf754f000) /lib/ld-linux.so.2 (0xf7722000) I did try to install the libpulse package (apt-get install libpulse-dev) but that file is still missing. Weirdly enough, doing an ldd on the vm-sound-null.so included with Pharo, I get: linux-gate.so.1 = (0xf774c000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf757c000) /lib/ld-linux.so.2 (0xf774d000) which is the exact same thing as for vm-sound-ALSA.so. So, I would imagine that if the one worked than the other would. Cheers, Jeff On Wed, Sep 4, 2013 at 11:48 AM, Guillermo Polito guillermopol...@gmail.com wrote: Hi! If the modules are not printed, that probably means that they cannot be loaded :). (Bah, I assume that by looking at the vm code that does that [1]). So, first thing you can do is to see the output of stderr. Second, you can try to do an ldd [2] to the vm-sound-ALSA.so library to check the dependencies and try to get them installed via ap-tget. Keep us informed :) Cheers, Guille [1] https://github.com/pharo-project/pharovm/blob/e4ccdb38e01578e3569c9c42d2199682584772ec/platforms/unix/vm/sqUnixMain.c#L965 [2] http://man.yolinux.com/cgi-bin/man2html?cgi_command=ldd On Wed, Sep 4, 2013 at 11:32 AM, Marcus Denker marcus.den...@inria.frwrote: On Sep 4, 2013, at 11:22 AM, J.F. Rick s...@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 s...@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 -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Re: [Pharo-dev] Sound on Ubuntu Problems
Well. I'm not that familiar with these C dependency things. It seems like the i386 ones were not installed. I did sudo apt-get install libasound2:i386 and sudo apt-get install libasound2-dev:i386 and sudo apt-get install libasound2-plugins:i386 to install it. While that seems to have worked to install it, ldd still reports the same dependencies for the *.so files. How do I get it to point to the i386 version? Cheers, Jeff On Wed, Sep 4, 2013 at 1:41 PM, Guillermo Polito guillermopol...@gmail.comwrote: Do you have libasound installed for i386? cause the one that outputs ldd looks like in folder for x86_64 On Wed, Sep 4, 2013 at 1:06 PM, J.F. Rick s...@je77.com wrote: Indeed. Yet the Squeak version does not load either. Cheers, Jeff On Wed, Sep 4, 2013 at 12:49 PM, Guillermo Polito guillermopol...@gmail.com wrote: I'd say it's pretty strange that the vm-sound-ALSA needs almost nothing... From the code I'd think It'd need to bind against asound [1], as the squeak vm says in libasound.so.2 = /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x7f3c507ba000) [1] https://github.com/pharo-project/pharovm/blob/master/platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c#L34 On Wed, Sep 4, 2013 at 12:37 PM, J.F. Rick s...@je77.com wrote: Thanks. When trying to load the ALSA sound, stderr just reports could not find module vm-sound-ALSA. Doing an ldd on the vm-sound-ALSA.so included with the Pharo VM, I get: linux-gate.so.1 = (0xf76e9000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf7515000) /lib/ld-linux.so.2 (0xf76ea000) Doing an ldd on the vm-sound-ALSA.so included with the Squeak VM, I get: linux-vdso.so.1 = (0x7fffbdbfe000) libasound.so.2 = /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x7f3c507ba000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f3c503f3000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f3c500ee000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3c4feea000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f3c4fccd000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f3c4fac4000) /lib64/ld-linux-x86-64.so.2 (0x7f3c50cca000) There doesn't seem to be anything clearly missing. Doing an ldd on the vm-sound-pulse.so included with the Squeak VM, I get: linux-gate.so.1 = (0xf7721000) libpulse-simple.so.0 = not found libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf754f000) /lib/ld-linux.so.2 (0xf7722000) I did try to install the libpulse package (apt-get install libpulse-dev) but that file is still missing. Weirdly enough, doing an ldd on the vm-sound-null.so included with Pharo, I get: linux-gate.so.1 = (0xf774c000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf757c000) /lib/ld-linux.so.2 (0xf774d000) which is the exact same thing as for vm-sound-ALSA.so. So, I would imagine that if the one worked than the other would. Cheers, Jeff On Wed, Sep 4, 2013 at 11:48 AM, Guillermo Polito guillermopol...@gmail.com wrote: Hi! If the modules are not printed, that probably means that they cannot be loaded :). (Bah, I assume that by looking at the vm code that does that [1]). So, first thing you can do is to see the output of stderr. Second, you can try to do an ldd [2] to the vm-sound-ALSA.so library to check the dependencies and try to get them installed via ap-tget. Keep us informed :) Cheers, Guille [1] https://github.com/pharo-project/pharovm/blob/e4ccdb38e01578e3569c9c42d2199682584772ec/platforms/unix/vm/sqUnixMain.c#L965 [2] http://man.yolinux.com/cgi-bin/man2html?cgi_command=ldd On Wed, Sep 4, 2013 at 11:32 AM, Marcus Denker marcus.den...@inria.fr wrote: On Sep 4, 2013, at 11:22 AM, J.F. Rick s...@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 s...@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.
Re: [Pharo-dev] [About Documentation] Teach, Don't Tell / Steve Losh
I really liked it! thanks for the link :) On 2013-09-04, at 06:34, Sven Van Caekenberghe s...@stfx.eu wrote: 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] OSProcess for Pharo3.0
On Tue, Sep 03, 2013 at 10:51:33PM -0400, David T. Lewis wrote: On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major = 3 ]]]. ^false I am also checking the platform subtype implementation (OSProcess platformSubtype). In Pharo: Smalltalk os subtype == 'i686' This reflects the processor type, not the os subtype (it should be 'x86_64' on my PC). Is this intentional? Dave
Re: [Pharo-dev] OSProcess for Pharo3.0
On Sep 4, 2013, at 2:13 PM, David T. Lewis le...@mail.msen.com wrote: On Tue, Sep 03, 2013 at 10:51:33PM -0400, David T. Lewis wrote: On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major = 3 ]]]. ^false I am also checking the platform subtype implementation (OSProcess platformSubtype). In Pharo: Smalltalk os subtype == 'i686' This reflects the processor type, not the os subtype (it should be 'x86_64' on my PC). Is this intentional? I don't think so. Marcus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] [About Documentation] Teach, Don't Tell / Steve Losh
+1 Doru On Wed, Sep 4, 2013 at 2:13 PM, Camillo Bruni camillobr...@gmail.comwrote: I really liked it! thanks for the link :) On 2013-09-04, at 06:34, Sven Van Caekenberghe s...@stfx.eu wrote: 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 -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [Pharo-users] Pharo Sprint in Buenos Aires
So it looks like we are going to do the Pharo sprint in Buenos Aires Saturday, the 14th of September. The question is now where do we meet? The original idea was to reserver a room at the UBA, but that is not possible the weekend. Any suggestions? On 2013-09-03, at 09:05, Mariano Martinez Peck marianop...@gmail.com wrote: Cool. I'll be there, of course! Keep us informed. Cheers, On Mon, Sep 2, 2013 at 10:42 PM, Camillo Bruni camillobr...@gmail.comwrote: everything is open so far, guido had the idea of reserving a room at the UBA, we will have more details tomorrow :) On 2013-09-02, at 21:24, Gisela Decuzzi giseladecu...@gmail.com wrote: Great! The idea is to spend the full day? Or do you have any planed time? 2013/9/2 Camillo Bruni camillobr...@gmail.com I spend a month in Buenos Aires working together with Guido Chari @ the UBA, we take this opportunity to organize a Pharo sprint outside France ;) We are in early preparation phase and the date nor location isn't fixed yet, so if you are motivated to join, can mark possible dates on this doodle: http://doodle.com/qey7iieqm5yr4wwy cheers, camillo -- Mariano http://marianopeck.wordpress.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] [Pharo-users] Pharo Sprint in Buenos Aires
Probably UTN? On Wed, Sep 4, 2013 at 2:45 PM, Camillo Bruni camillobr...@gmail.comwrote: So it looks like we are going to do the Pharo sprint in Buenos Aires Saturday, the 14th of September. The question is now where do we meet? The original idea was to reserver a room at the UBA, but that is not possible the weekend. Any suggestions? On 2013-09-03, at 09:05, Mariano Martinez Peck marianop...@gmail.com wrote: Cool. I'll be there, of course! Keep us informed. Cheers, On Mon, Sep 2, 2013 at 10:42 PM, Camillo Bruni camillobr...@gmail.com wrote: everything is open so far, guido had the idea of reserving a room at the UBA, we will have more details tomorrow :) On 2013-09-02, at 21:24, Gisela Decuzzi giseladecu...@gmail.com wrote: Great! The idea is to spend the full day? Or do you have any planed time? 2013/9/2 Camillo Bruni camillobr...@gmail.com I spend a month in Buenos Aires working together with Guido Chari @ the UBA, we take this opportunity to organize a Pharo sprint outside France ;) We are in early preparation phase and the date nor location isn't fixed yet, so if you are motivated to join, can mark possible dates on this doodle: http://doodle.com/qey7iieqm5yr4wwy cheers, camillo -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Interesting regression on 30366
Triangulating... 14636, 14632, 14620 Both older versions have problems with cleaning up after NB, all three have problems with high prio process, the newest two with localhostname blockclosures. Stephan And an even older version: 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Jul 31 2013 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Jul 31 2013 git://gitorious.org/cogvm/blessed.git Commit: 2214cee58a5c5266b8ab2322b98471553b1b11c2 Date: 2013-07-31 15:32:06 +0200 By: Esteban Lorenzano esteba...@gmail.com Jenkins build #14620 ' 11287 run, 11257 passes, 12 skipped, 26 expected failures, 4 failures, 0 errors, 0 unexpected passes Failures: ProcessTest#testHighPriorityOverridesWaitTime ReleaseTest#testObsoleteBehaviors DelayTest#testMultiProcessWaitOnSameDelay ReleaseTest#testUnknownProcesses Errors: 11287 run, 11234 passes, 12 skipped, 26 expected failures, 4 failures, 23 errors, 0 unexpected passes Failures: DelayTest#testMultiProcessWaitOnSameDelay ReleaseTest#testObsoleteBehaviors ProcessTest#testHighPriorityOverridesWaitTime ReleaseTest#testUnknownProcesses 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
Re: [Pharo-dev] [tlp] Re: [Pharo-users] Pharo Sprint in Buenos Aires
On the 4th floor there's some stable connection. Also if we are not too much people we could use the teacher's room at Systems Department... Or one of the laboratories in the 3rd floor (the yellow one would be nice). On 4 September 2013 10:32, Nicolas Passerini npasser...@gmail.com wrote: I think UTN is not a good idea for a Pharo sprint, because we will need a good Internet connection and that can not be guaranteed here. (Or correct me and tell me that Internet connection is not a must, so we can meet here at UTN without problems). How much people is coming to the Sprint? On Wed, Sep 4, 2013 at 10:12 AM, Sebastian Tleye stl...@gmail.com wrote: The Pabellon 1 is closed on saturdays afternoon, but have you asked for Pabellon 2? I think it's open on saturdays (i don't know if it is possible to book a room) 2013/9/4 Guillermo Polito guillermopol...@gmail.com Probably UTN? On Wed, Sep 4, 2013 at 2:45 PM, Camillo Bruni camillobr...@gmail.comwrote: So it looks like we are going to do the Pharo sprint in Buenos Aires Saturday, the 14th of September. The question is now where do we meet? The original idea was to reserver a room at the UBA, but that is not possible the weekend. Any suggestions? On 2013-09-03, at 09:05, Mariano Martinez Peck marianop...@gmail.com wrote: Cool. I'll be there, of course! Keep us informed. Cheers, On Mon, Sep 2, 2013 at 10:42 PM, Camillo Bruni camillobr...@gmail.comwrote: everything is open so far, guido had the idea of reserving a room at the UBA, we will have more details tomorrow :) On 2013-09-02, at 21:24, Gisela Decuzzi giseladecu...@gmail.com wrote: Great! The idea is to spend the full day? Or do you have any planed time? 2013/9/2 Camillo Bruni camillobr...@gmail.com I spend a month in Buenos Aires working together with Guido Chari @ the UBA, we take this opportunity to organize a Pharo sprint outside France ;) We are in early preparation phase and the date nor location isn't fixed yet, so if you are motivated to join, can mark possible dates on this doodle: http://doodle.com/qey7iieqm5yr4wwy cheers, camillo -- Mariano http://marianopeck.wordpress.com -- You received this message because you are subscribed to the Google Groups Taller de Lenguajes de Programación group. To unsubscribe from this group and stop receiving emails from it, send an email to tlp-utn-2012+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Pharo-dev] Monticello Zinc Socket timeout
We have this strange bug again that we get timeouts on the Squeaksource, I thought the Sven fixed it, but it still persists in the latest image. I reopened https://pharo.fogbugz.com/default.asp?6923 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] [Pharo-users] Pharo Sprint in Buenos Aires
I think UTN is not a good idea for a Pharo sprint, because we will need a good Internet connection and that can not be guaranteed here. (Or correct me and tell me that Internet connection is not a must, so we can meet here at UTN without problems). How much people is coming to the Sprint? On Wed, Sep 4, 2013 at 10:12 AM, Sebastian Tleye stl...@gmail.com wrote: The Pabellon 1 is closed on saturdays afternoon, but have you asked for Pabellon 2? I think it's open on saturdays (i don't know if it is possible to book a room) 2013/9/4 Guillermo Polito guillermopol...@gmail.com Probably UTN? On Wed, Sep 4, 2013 at 2:45 PM, Camillo Bruni camillobr...@gmail.comwrote: So it looks like we are going to do the Pharo sprint in Buenos Aires Saturday, the 14th of September. The question is now where do we meet? The original idea was to reserver a room at the UBA, but that is not possible the weekend. Any suggestions? On 2013-09-03, at 09:05, Mariano Martinez Peck marianop...@gmail.com wrote: Cool. I'll be there, of course! Keep us informed. Cheers, On Mon, Sep 2, 2013 at 10:42 PM, Camillo Bruni camillobr...@gmail.com wrote: everything is open so far, guido had the idea of reserving a room at the UBA, we will have more details tomorrow :) On 2013-09-02, at 21:24, Gisela Decuzzi giseladecu...@gmail.com wrote: Great! The idea is to spend the full day? Or do you have any planed time? 2013/9/2 Camillo Bruni camillobr...@gmail.com I spend a month in Buenos Aires working together with Guido Chari @ the UBA, we take this opportunity to organize a Pharo sprint outside France ;) We are in early preparation phase and the date nor location isn't fixed yet, so if you are motivated to join, can mark possible dates on this doodle: http://doodle.com/qey7iieqm5yr4wwy cheers, camillo -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] [tlp] Re: [Pharo-users] Pharo Sprint in Buenos Aires
If you say so... The Systems Department won't be open on Saturday afternoon, but we could reserve a lab. On Wed, Sep 4, 2013 at 10:39 AM, Clara Allende clari.alle...@gmail.comwrote: On the 4th floor there's some stable connection. Also if we are not too much people we could use the teacher's room at Systems Department... Or one of the laboratories in the 3rd floor (the yellow one would be nice). On 4 September 2013 10:32, Nicolas Passerini npasser...@gmail.com wrote: I think UTN is not a good idea for a Pharo sprint, because we will need a good Internet connection and that can not be guaranteed here. (Or correct me and tell me that Internet connection is not a must, so we can meet here at UTN without problems). How much people is coming to the Sprint? On Wed, Sep 4, 2013 at 10:12 AM, Sebastian Tleye stl...@gmail.comwrote: The Pabellon 1 is closed on saturdays afternoon, but have you asked for Pabellon 2? I think it's open on saturdays (i don't know if it is possible to book a room) 2013/9/4 Guillermo Polito guillermopol...@gmail.com Probably UTN? On Wed, Sep 4, 2013 at 2:45 PM, Camillo Bruni camillobr...@gmail.comwrote: So it looks like we are going to do the Pharo sprint in Buenos Aires Saturday, the 14th of September. The question is now where do we meet? The original idea was to reserver a room at the UBA, but that is not possible the weekend. Any suggestions? On 2013-09-03, at 09:05, Mariano Martinez Peck marianop...@gmail.com wrote: Cool. I'll be there, of course! Keep us informed. Cheers, On Mon, Sep 2, 2013 at 10:42 PM, Camillo Bruni camillobr...@gmail.comwrote: everything is open so far, guido had the idea of reserving a room at the UBA, we will have more details tomorrow :) On 2013-09-02, at 21:24, Gisela Decuzzi giseladecu...@gmail.com wrote: Great! The idea is to spend the full day? Or do you have any planed time? 2013/9/2 Camillo Bruni camillobr...@gmail.com I spend a month in Buenos Aires working together with Guido Chari @ the UBA, we take this opportunity to organize a Pharo sprint outside France ;) We are in early preparation phase and the date nor location isn't fixed yet, so if you are motivated to join, can mark possible dates on this doodle: http://doodle.com/qey7iieqm5yr4wwy cheers, camillo -- Mariano http://marianopeck.wordpress.com -- You received this message because you are subscribed to the Google Groups Taller de Lenguajes de Programación group. To unsubscribe from this group and stop receiving emails from it, send an email to tlp-utn-2012+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Taller de Lenguajes de Programación group. To unsubscribe from this group and stop receiving emails from it, send an email to tlp-utn-2012+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Pharo-dev] specialSelectors
On Wed, Sep 4, 2013 at 3:35 AM, Igor Stasenko siguc...@gmail.com wrote: i think you can feel the difference while running interpreter. With JIT it makes little sense to have special selectors imo. There are two advantages. Space; special selectors encode a message send in 1 byte, instead of 1 byte for the send bytecode + 4 bytes for the literal selector. Optimization; the JIT (as does the interpreter) inlines +,-,*,/ etc for SmallInteger and then does even more inlining for ,,=,=,== when they're followed by a jump. As far as space goes, now that the system is 32-bit, and especially if it is 64-bit there is an opportunity to add 256 special selectors and use a two-byte special selector bytecode, 2 1 + 4. VisualWorks does this. There are problems though; over time the most statically frequent selectors can change as the library changes (e.g. blockCopy: is no longer used). On 4 September 2013 12:31, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: Agree, My point was to ensure there was no speedup, so it's only a space optimization (1 slot saved from literals, times 5000 senders or so per selector plus maybe a byte for the send bytecode ?). However the arithmetic ops, comparisons, bit ops, at: at:put:, == and class special selectors still have some specific speed up, especially in COG, so we cannot get rid of specialSelectors alltogether... 2013/9/4 Marcus Denker marcus.den...@inria.fr On Sep 4, 2013, at 12:08 AM, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: I note that #class was removed from specialSelectors (nilled entry) so as to not use the VM hack which fetches the class without sending a message. Pharo prefers the regular message send. But next to that entry, there is #blockCopy: which was formerly used for blue book BlockContext. BlockContext was removed from Pharo... So that makes two available slots for optimizing most used (sent) messages... We might choose some candidates and test on some macro benchmark if ever that really makes a difference. I am not sure if optimizations on that level make sense… Marcus -- Best regards, Igor Stasenko. -- best, Eliot
Re: [Pharo-dev] [About Documentation] Teach, Don't Tell / Steve Losh
On 04 Sep 2013, at 21:54, Stéphane Ducasse stephane.duca...@inria.fr wrote: I have the impression that the Deep into Pharo book is going in that direction. Rest assured that all the work that you and others are doing with regards to the different books is absolutely in the right direction ! Two/three years ago, the Pharo by Example and Seaside book were really important to me, heck they still are, especially the real paper versions. These did indeed 'teach'. So thank you and please continue. I know it is hard work, but is does make a real difference, I am sure to many people. 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
Re: [Pharo-dev] [About Documentation] Teach, Don't Tell / Steve Losh
I have the impression that the Deep into Pharo book is going in that direction. 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
Re: [Pharo-dev] OSProcess for Pharo3.0
On Wed, Sep 04, 2013 at 02:17:29PM +0200, Marcus Denker wrote: On Sep 4, 2013, at 2:13 PM, David T. Lewis le...@mail.msen.com wrote: On Tue, Sep 03, 2013 at 10:51:33PM -0400, David T. Lewis wrote: On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: Le 03/09/2013 13:36, David T. Lewis a ?crit : Can you post the method here first? I'd like to check it on some Squeak images before it goes into the repository. Here it is (at least an example): in OSProcess class isPharo3AndLater Test if we are on Pharo 3.0 ^ (Smalltalk classNamed: 'SystemVersion') ifNil: [ false ] ifNotNil: [ :v | v current type = 'Pharo' and: [ v current major = 3 ] ] The idea is right, but the details can be a PITA ;-) - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. I did not check the other Pharo versions. Something like this might work: isPharo3AndLater Smalltalk at: #SystemVersion ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) ifTrue: [^ cls current type = 'Pharo' and: [ cls current major = 3 ]]]. ^false I am also checking the platform subtype implementation (OSProcess platformSubtype). In Pharo: Smalltalk os subtype == 'i686' This reflects the processor type, not the os subtype (it should be 'x86_64' on my PC). Is this intentional? I don't think so. Marcus Thanks Goubier and Marcus, I made the updates to OSProcess and CommandShell to handle system version and subtype in Pharo 3.0. I did not yet update ConfigurationOfOSProcess or ConfigurationOfCommandShell, but the latest versions for Squeak/Pharo are in OSProcess-dtl.83 and CommandShell-dtl.73 in the SqueakSource repositories. Dave
Re: [Pharo-dev] OSProcess for Pharo3.0
On Wed, Sep 04, 2013 at 08:38:04AM +0200, Marcus Denker wrote: 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 do not think that there is any right or wrong answer to this, it is perhaps a matter of personal perspective. For me, much of my professional experience is related to supporting manufacturing operations for a large commercial company. In this environment, the ability to engineer solutions to new problems without disrupting existing operations is critical. To me, a failure related to software changes is not just a red mark on a unit test, it is a significant emotional event if I cause a manufacturing plant to stop production (thankfully this has rarely happened in my career so far, knock wood). So maybe this makes me conservative, but from my point of view the ability to deliver future versions of software that work without breaking older versions is a matter of good engineering discipline, and I stand by that as a matter of principle. Dave
