- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] WAV support in Pharo

by Merwan Ouddane

Retry now, I forgot to update the configuration On 23/08/2015 18:41, Dimitris Chloupis wrote: > it gives me MNU OpenAL class>>isAvailable > > On Sun, Aug 23, 2015 at 5:56 PM Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > On Sun, Aug 23, 2015 at 10:02 PM, Merwan Ouddane > <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> wrote: > > Hi, > > > > I made a WAV parser, so now we can play music in Pharo :) > > > > I made an example using OpenAL's binding from Ronnie. > > > > You can try it with this piece of code : > > > > Gofer new > > smalltalkhubUser: 'MerwanOuddane' project: 'WAVParser'; > > package: 'ConfigurationOfWAVParser'; > > load. > > (Smalltalk at: #ConfigurationOfWAVParser) loadBleedingEdge. > > (Smalltalk at: #ALExamplesWAV) exampleBirdChirping > > > > Merwan > > > > This is great! I never pushed at trying sound since I had the > impression there were issues on some platforms and it hadn't been > critical for me, but trying your example worked out of the box in > build 50264 on OSX Mavericks. Actually it took me a few moments to > notice it was the playback and not some birds outside. Made me grin > from ear to ear. > > Probably not critical, but I get informed "Information - The size in > the header do not match the real size. The file may be corrupted." > In WavParser>>sanityCheckFileSize... > stream size --> 215608 > header fileSize -> 215600 > > cheers -ben >

Aug. 23, 2015

Re: [Pharo-dev] [Moose-dev] Re: Object new foo

by Vincent BLONDEAU

Hi Eliot, Thanks for your help. The problem has been resolved! In fact a class was removed or renamed in Pharo, and the Moose debugger calls it just before the opening. So it created an infinite loop, because the class wasnât understood by the system, so it opened another debugger, etcâ¦. Do you think something can be made to not break the image and so to break this infinite loop? A solution may to open either another registered debugger, or the emergency debugger? I can create an image with the problem if needed. Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Eliot Miranda EnvoyÃ© : jeudi 20 aoÃ»t 2015 22:13 Ã : Pharo Development List Cc : Moose-related development; Squeak Virtual Machine Development Discussion Objet : Re: [Pharo-dev] [Moose-dev] Re: Object new foo Hi Vincent, does the image lock up when you execute Exception signal? The two functions you see looping are part of the implementation of primitives 195 & 196, findNextUnwindContextUpTo: (primitiveFindNextUnwindContext) & terminateTo: (primitiveTerminateTo). So if the image locks up the question is, is what is creating a circular structure of contexts, the VM or the image? I am willing to take a look at an image that contains the case. If you can create an image which enters the lop on start-up without my having to do anything I'm happy to take a look. On Wed, Aug 19, 2015 at 3:22 PM, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net <mailto:vincent.blondeau@polytech-lille.net> > wrote: Hi, On last Moose image, I debugged the VM and executed âException signalâ. I paused the VM and saw that 2 methods are looping together in gcc3x-cointerp.c: static sqInt findMethodWithPrimitiveFromContextUpToContext(sqInt primitive, sqInt senderContext, sqInt homeContext); static sqInt findMethodWithPrimitiveFromFPUpToContext(sqInt primitive, char *startFP, sqInt homeContext); The image is looping only when the debugger is launch on Error (not by launching it by the script below). Maybe someone on the Pharo mailing list knows what is happening? Thanks in advance, Cheers, Vincent De : moose-dev-bounces(a)iam.unibe.ch <mailto:moose-dev-bounces@iam.unibe.ch> [mailto:moose-dev-bounces@iam.unibe.ch <mailto:moose-dev-bounces@iam.unibe.ch> ] De la part de Andrei Chis EnvoyÃ© : mardi 18 aoÃ»t 2015 10:53 Ã : Moose-related development Objet : [Moose-dev] Re: Object new foo Hi Vincent, You example will also kill the Pharo debugger :) The issue is that you pass 'Processor activeProcess' which gets terminated when you close the debugger. When you open the debugger you need to make sure the process on which it is opened is suspended and can get terminated with no problem. A different way to redo the example would be: context := Context sender: nil receiver: {1 . 2 . 2} method: (OrderedCollection>>#add:) arguments: #(10). process := Process forContext: context priority: Processor userInterruptPriority. GTGenericStackDebugger openOn: (DebugSession process: process context: context). There is a basic test for opening the debugger in GTGenericStackDebuggerSmokeTest but more could help. Cheers, Andrei On Mon, Aug 17, 2015 at 11:53 PM, Vincent BLONDEAU <vincent.blondeau(a)polytech-lille.net <mailto:vincent.blondeau@polytech-lille.net> > wrote: Indeed. Maybe some tests has to be added.. But for now, it seems that the debugger is crashing the imageâ¦ Not just by launching it: GTGenericStackDebugger openOn: (DebugSession process: Processor activeProcess context: (Context sender: nil receiver: {1 . 2 . 2} method: (OrderedCollection>>#add: ) arguments: #(10))) But when an exception is thrown, its seems that we fall into an infinite loop around the primitive 199. Maybe the context is not well set? Cheers, Vincent De : moose-dev-bounces(a)iam.unibe.ch <mailto:moose-dev-bounces@iam.unibe.ch> [mailto:moose-dev-bounces@iam.unibe.ch <mailto:moose-dev-bounces@iam.unibe.ch> ] De la part de Alexandre Bergel EnvoyÃ© : lundi 17 aoÃ»t 2015 13:26 Ã : Moose-related development Objet : [Moose-dev] Re: Object new foo This is weird that such bug can be introduced and no alarm is raised Alexandre Le 17 aoÃ»t 2015 Ã 08:03, Jan KurÅ¡ <kurs(a)iam.unibe.ch <mailto:kurs@iam.unibe.ch> > a Ã©crit : Yep I had this problem (falled back to previous version), I suspected debugger being the reason. Cheers Jan On Sun, 16 Aug 2015 03:05 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com> > wrote: in Moose 6.0 simply freezes. Anyone else sees this? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,,,^..^,,,_ best, Eliot

Aug. 23, 2015

Re: [Pharo-dev] WAV support in Pharo

by Dimitris Chloupis

it gives me MNU OpenAL class>>isAvailable On Sun, Aug 23, 2015 at 5:56 PM Ben Coman <btc(a)openinworld.com> wrote: > On Sun, Aug 23, 2015 at 10:02 PM, Merwan Ouddane > <merwanouddane(a)gmail.com> wrote: > > Hi, > > > > I made a WAV parser, so now we can play music in Pharo :) > > > > I made an example using OpenAL's binding from Ronnie. > > > > You can try it with this piece of code : > > > > Gofer new > > smalltalkhubUser: 'MerwanOuddane' project: 'WAVParser'; > > package: 'ConfigurationOfWAVParser'; > > load. > > (Smalltalk at: #ConfigurationOfWAVParser) loadBleedingEdge. > > (Smalltalk at: #ALExamplesWAV) exampleBirdChirping > > > > Merwan > > > > This is great! I never pushed at trying sound since I had the > impression there were issues on some platforms and it hadn't been > critical for me, but trying your example worked out of the box in > build 50264 on OSX Mavericks. Actually it took me a few moments to > notice it was the playback and not some birds outside. Made me grin > from ear to ear. > > Probably not critical, but I get informed "Information - The size in > the header do not match the real size. The file may be corrupted." > In WavParser>>sanityCheckFileSize... > stream size --> 215608 > header fileSize -> 215600 > > cheers -ben > >

Aug. 23, 2015

Re: [Pharo-dev] WAV support in Pharo

by Vincent BLONDEAU

Thanks! It is working better now! Nice tool! Do you plan to add Mp3? (because it is the current format now ;)). Vincent -----Message d'origine----- De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Merwan Ouddane EnvoyÃ© : dimanche 23 aoÃ»t 2015 17:43 Ã : Pharo Development List Objet : Re: [Pharo-dev] WAV support in Pharo Yes you have to download OpenAL for the openAL binding to work :p The name of the dll is OpenAL32.dll On 23/08/2015 17:25, Vincent BLONDEAU wrote: > Hi, > > It does not work under windows.. Should I download a specific .dll ? > > Cheers, > Vincent > > -----Message d'origine----- > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part > de Merwan Ouddane EnvoyÃ© : dimanche 23 aoÃ»t 2015 16:02 Ã : Pharo > Development List Objet : [Pharo-dev] WAV support in Pharo > > Hi, > > I made a WAV parser, so now we can play music in Pharo :) > > I made an example using OpenAL's binding from Ronnie. > > You can try it with this piece of code : > > Gofer new > smalltalkhubUser: 'MerwanOuddane' project: 'WAVParser'; > package: 'ConfigurationOfWAVParser'; > load. > (Smalltalk at: #ConfigurationOfWAVParser) loadBleedingEdge. > (Smalltalk at: #ALExamplesWAV) exampleBirdChirping > > Merwan > > >

Aug. 23, 2015

Re: [Pharo-dev] issue with large file path on windows

by Nicolai Hess

And If you want to review the changes: https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lo… 2015-08-23 13:44 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > For those who had problems with pharo on windows and github based > repositories, > I built a windows vm with support for long paths: > > > https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… > > > For browsing directories with large paths (FileList or Inspect), > you may need one additional change in the image (But I am not really sure > about that) : > > DiskStore>>initialize > super initialize. > maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ]. > > > please test and give feedback. > > This wasn't as easy as I thought, and I had to make some more changes > for the file permissions (the stat-functions don't work for files with > long paths). > Please test other file/folder operations. > > > nicolai > > > >

Aug. 23, 2015

Re: [Pharo-dev] VoyageMongo "Could not resolve: GT-Inspector [GT-Inspector-SeanDeNigris.308]"

by Tudor Girba

Then the name is misleading :) The dependency to Glamour should go through the #stable version. This is the one that gets maintained. The blocks inside versions are meant for describing variations between environment versions, but I do not want to go there. Doru On Sun, Aug 23, 2015 at 5:26 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Tudor Girba-2 wrote > > MagritteGlamourForPharo40 should ideally not > > depend on GT-Inspector > > It's purpose is to depend on GT-Inspector :) It's a hack to get a few > enhancements loadable in Pharo 4.0. It seemed like I had to do it this way > because IIUC Glamour has declared subsequent versions with fixes for Pharo > 5.0, but there are no #pharo40 and #pharo50 blocks in the config - only > #common. If I am wrong, I'd much rather to it the proper way. Please > advise... > > BTW this should be fixed. Let me know if it works. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/VoyageMongo-Could-not-resolve-GT-Inspector-GT-Inspect… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 23, 2015

Re: [Pharo-dev] WAV support in Pharo

by Merwan Ouddane

Yes you have to download OpenAL for the openAL binding to work :p The name of the dll is OpenAL32.dll On 23/08/2015 17:25, Vincent BLONDEAU wrote: > Hi, > > It does not work under windows.. Should I download a specific .dll ? > > Cheers, > Vincent > > -----Message d'origine----- > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Merwan Ouddane > EnvoyÃ© : dimanche 23 aoÃ»t 2015 16:02 > Ã : Pharo Development List > Objet : [Pharo-dev] WAV support in Pharo > > Hi, > > I made a WAV parser, so now we can play music in Pharo :) > > I made an example using OpenAL's binding from Ronnie. > > You can try it with this piece of code : > > Gofer new > smalltalkhubUser: 'MerwanOuddane' project: 'WAVParser'; > package: 'ConfigurationOfWAVParser'; > load. > (Smalltalk at: #ConfigurationOfWAVParser) loadBleedingEdge. > (Smalltalk at: #ALExamplesWAV) exampleBirdChirping > > Merwan > > >

Aug. 23, 2015

Re: [Pharo-dev] VoyageMongo "Could not resolve: GT-Inspector [GT-Inspector-SeanDeNigris.308]"

by Yuriy Tymchuk

Yes, it works, thanks! > On 23 Aug 2015, at 18:26, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tudor Girba-2 wrote >> MagritteGlamourForPharo40 should ideally not >> depend on GT-Inspector > > It's purpose is to depend on GT-Inspector :) It's a hack to get a few > enhancements loadable in Pharo 4.0. It seemed like I had to do it this way > because IIUC Glamour has declared subsequent versions with fixes for Pharo > 5.0, but there are no #pharo40 and #pharo50 blocks in the config - only > #common. If I am wrong, I'd much rather to it the proper way. Please > advise... > > BTW this should be fixed. Let me know if it works. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/VoyageMongo-Could-not-resolve-GT-Inspector-GT-Inspect… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 23, 2015

Re: [Pharo-dev] WAV support in Pharo

by Merwan Ouddane

Oh yeah, my bad, when they say fileSize, they meant the size of the file - the number of bytes already read ^^' Thanks :) On 23/08/2015 16:55, Ben Coman wrote: > On Sun, Aug 23, 2015 at 10:02 PM, Merwan Ouddane > <merwanouddane(a)gmail.com> wrote: >> Hi, >> >> I made a WAV parser, so now we can play music in Pharo :) >> >> I made an example using OpenAL's binding from Ronnie. >> >> You can try it with this piece of code : >> >> Gofer new >> smalltalkhubUser: 'MerwanOuddane' project: 'WAVParser'; >> package: 'ConfigurationOfWAVParser'; >> load. >> (Smalltalk at: #ConfigurationOfWAVParser) loadBleedingEdge. >> (Smalltalk at: #ALExamplesWAV) exampleBirdChirping >> >> Merwan >> > This is great! I never pushed at trying sound since I had the > impression there were issues on some platforms and it hadn't been > critical for me, but trying your example worked out of the box in > build 50264 on OSX Mavericks. Actually it took me a few moments to > notice it was the playback and not some birds outside. Made me grin > from ear to ear. > > Probably not critical, but I get informed "Information - The size in > the header do not match the real size. The file may be corrupted." > In WavParser>>sanityCheckFileSize... > stream size --> 215608 > header fileSize -> 215600 > > cheers -ben >

Aug. 23, 2015

Re: [Pharo-dev] VoyageMongo "Could not resolve: GT-Inspector [GT-Inspector-SeanDeNigris.308]"

by Yuriy Tymchuk

Well, you can do Metacello new baseline: #RenrakuServer; repository: 'github://Uko/Renraku-Server:v1.3.0'; load It depends on VoyageMongo. Uko > On 23 Aug 2015, at 18:11, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sean P. DeNigris wrote >> I'll take a look this morning > > BTW how do I reproduce the error? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/VoyageMongo-Could-not-resolve-GT-Inspector-GT-Inspect… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 23, 2015