- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Sound on Ubuntu Problems

by Guillermo Polito

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 (0x00007f3c507ba000) [1] https://github.com/pharo-project/pharovm/blob/master/platforms/unix/vm-soun… On Wed, Sep 4, 2013 at 12:37 PM, J.F. Rick <self(a)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 => (0x00007fffbdbfe000) > libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 > (0x00007f3c507ba000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3c503f3000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3c500ee000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3c4feea000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x00007f3c4fccd000) > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3c4fac4000) > /lib64/ld-linux-x86-64.so.2 (0x00007f3c50cca000) > 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 < > guillermopolito(a)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/e4ccdb38e01578e3569c9c42d2199… >> [2] http://man.yolinux.com/cgi-bin/man2html?cgi_command=ldd >> >> >> On Wed, Sep 4, 2013 at 11:32 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> >>> On Sep 4, 2013, at 11:22 AM, J.F. Rick <self(a)je77.com> wrote: >>> >>> Hmm. Did this get sent or was it filtered? It doesn't seem to be in my >>> inbox for the pharo-dev list. >>> >>> >>> It arrivedâ¦ >>> >>> >>> Cheers, >>> >>> Jeff >>> >>> >>> On Tue, Sep 3, 2013 at 5:03 PM, J.F. Rick <self(a)je77.com> wrote: >>> >>>> I'm using Pharo 2.0 on Ubuntu 13.10 and I can't seem to get sound >>>> working. Getting sound to work on Linux seems to be a common problem. While >>>> I've checked the archive for solutions, none of them work for me. I've >>>> investigated a bit and here's what I've found: >>>> >>>> Inside of the /usr/lib/pharo-vm directory, I see the following: >>>> vm-sound-ALSA.so >>>> vm-sound-null.so >>>> vm-sound-pulse.so (I added that based on an archive post that this >>>> would work) >>>> >>>> When I do "pharo -vm-sound-null pharo.image", it works correctly. >>>> When I do "pharo -vm-sound-ALSA pharo.image", it gives me an error that >>>> "could not find module vm-sound-ALSA". >>>> >>>> When I do "pharo-help", I find that the only sound driver available is >>>> "vm-sound-null", though the others are clearly there in the directory. Is >>>> there anything I can do to make the VM acknowledge that the other files are >>>> there? >>>> >>>> Cheers, >>>> >>>> Jeff >>>> >>>> -- >>>> Jochen "Jeff" Rick, Ph.D. >>>> http://www.je77.com/ >>>> Skype ID: jochenrick >>>> >>> >>> >>> >>> -- >>> Jochen "Jeff" Rick, Ph.D. >>> http://www.je77.com/ >>> Skype ID: jochenrick >>> >>> >>> >> > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick >

Sept. 4, 2013

Re: [Pharo-dev] specialSelectors

by Nicolas Cellier

In JIT, it makes sense because there are special handling for well known special selectors (#+ #at: #< etc...). 2013/9/4 Igor Stasenko <siguctua(a)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.nice(a)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.denker(a)inria.fr> >> >>> >>> On Sep 4, 2013, at 12:08 AM, Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)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. >

Sept. 4, 2013

Re: [Pharo-dev] specialSelectors

by Nicolas Cellier

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 <siguctua(a)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.nice(a)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.denker(a)inria.fr> >> >>> >>> On Sep 4, 2013, at 12:08 AM, Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)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. >

Sept. 4, 2013

Re: [Pharo-dev] Sound on Ubuntu Problems

by J.F. Rick

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 => (0x00007fffbdbfe000) libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f3c507ba000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3c503f3000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3c500ee000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3c4feea000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3c4fccd000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3c4fac4000) /lib64/ld-linux-x86-64.so.2 (0x00007f3c50cca000) 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 <guillermopolito(a)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/e4ccdb38e01578e3569c9c42d2199… > [2] http://man.yolinux.com/cgi-bin/man2html?cgi_command=ldd > > > On Wed, Sep 4, 2013 at 11:32 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> On Sep 4, 2013, at 11:22 AM, J.F. Rick <self(a)je77.com> wrote: >> >> Hmm. Did this get sent or was it filtered? It doesn't seem to be in my >> inbox for the pharo-dev list. >> >> >> It arrivedâ¦ >> >> >> Cheers, >> >> Jeff >> >> >> On Tue, Sep 3, 2013 at 5:03 PM, J.F. Rick <self(a)je77.com> wrote: >> >>> I'm using Pharo 2.0 on Ubuntu 13.10 and I can't seem to get sound >>> working. Getting sound to work on Linux seems to be a common problem. While >>> I've checked the archive for solutions, none of them work for me. I've >>> investigated a bit and here's what I've found: >>> >>> Inside of the /usr/lib/pharo-vm directory, I see the following: >>> vm-sound-ALSA.so >>> vm-sound-null.so >>> vm-sound-pulse.so (I added that based on an archive post that this would >>> work) >>> >>> When I do "pharo -vm-sound-null pharo.image", it works correctly. >>> When I do "pharo -vm-sound-ALSA pharo.image", it gives me an error that >>> "could not find module vm-sound-ALSA". >>> >>> When I do "pharo-help", I find that the only sound driver available is >>> "vm-sound-null", though the others are clearly there in the directory. Is >>> there anything I can do to make the VM acknowledge that the other files are >>> there? >>> >>> Cheers, >>> >>> Jeff >>> >>> -- >>> Jochen "Jeff" Rick, Ph.D. >>> http://www.je77.com/ >>> Skype ID: jochenrick >>> >> >> >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> >> >> > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Sept. 4, 2013

Re: [Pharo-dev] specialSelectors

by Igor Stasenko

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.nice(a)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.denker(a)inria.fr> > >> >> On Sep 4, 2013, at 12:08 AM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)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.

Sept. 4, 2013

Re: [Pharo-dev] specialSelectors

by Nicolas Cellier

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.denker(a)inria.fr> > > On Sep 4, 2013, at 12:08 AM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)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 >

Sept. 4, 2013

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

by Goubier Thierry

Le 04/09/2013 11:27, Marcus Denker a Ã©crit : > > On Sep 4, 2013, at 10:18 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >>>> >>>>> But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. >>>>> But nevertheless, all show-stopping bugs should be fixed. >>>> >>>> >>>>> In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? >>>> >>>> I can undestand that. >>>> >>>> I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. >>>> >>>> But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. >>>> >>> >>> What is a solution other than stopping development and declaring Pharo as finished as it is? >> >> No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around, that 2.0 is the main development platform for Pharo users, 3.0 is where you make interesting stuff. >> > Yes, and the whole moving forward vs. stability is a real, classical tragedy: there is no solution other than minimizing the pain. Whatever we do it will be wrong. The only "solution" is > to stop doing, then the pain stops but there will be no future. 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

Sept. 4, 2013

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

by Igor Stasenko

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

Sept. 4, 2013

Re: [Pharo-dev] Sound on Ubuntu Problems

by Guillermo Polito

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

Sept. 4, 2013

Re: [Pharo-dev] Interesting regression on 30366

by Stephan Eggermont

Smalltalk vm version 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Aug 15 2013 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Aug 15 2013 git@github.com:pharo-project/pharovm.git Commit: f3829e469232daefcacf69ee778f98f81a3e2e94 Date: 2013-08-15 14:52:36 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14632 '

Sept. 4, 2013