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

Re: [Pharo-dev] NativeBoost String Handling Bug?

by Igor Stasenko

On 3 December 2013 00:32, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > sound really as some bug.. and similar to system() call. > my versions is: > - it could be that strings are expected to be 16-byte aligned > - that there's some bug with converting to null-terminated C string > > > Great! It's be nice to get this and system calls working in one shot... > how do we proceed? How do we test? I'm willing to help... > if there some bug, it must be in NBExternalString which responsible for marshalling strings. try to change the alignment for the pointer and see how it goes in reserveStackBytes: numBytesOrBlock andStoreAddrTo: aTemp because right now it aligns the total space to reserve on stack (amount to subtract from SP), but not SP itself alignment should use powers of 2 , of course. Cheers, Sean ------------------------------ View this message in context: Re: NativeBoost String Handling Bug?<http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726878.html> Sent from the Pharo Smalltalk Developers mailing list archive<http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html>at Nabble.com. -- Best regards, Igor Stasenko.

Dec. 3, 2013

Re: [Pharo-dev] NativeBoost String Handling Bug?

by Sean P. DeNigris

sound really as some bug.. and similar to system() call. my versions is: Â - it could be that strings are expected to be 16-byte aligned Â - that there's some bug with converting to null-terminated C string Great! It's be nice to get this and system calls working in one shot... how do we proceed? How do we test? I'm willing to help... ----- Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726878.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2013

Re: [Pharo-dev] NativeBoost String Handling Bug?

by Igor Stasenko

On 2 December 2013 22:31, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I'm tearing my hair out wrapping FMOD! I finally isolated the Mac > VM-crashing > bug (works in Windows) to: > > The reason I suspect NB is that I made a simple Xcode C project which (I > think) does the exact same thing, which works perfectly. I uploaded it to > https://github.com/seandenigris/FMODExample . > To use it, just change SOUND_FILE_PATH in main.c to the location of the > included "train whistle.mp3" file > >From Pharo, however, it only works if the path to the mp3 is: > - *exactly* "/Volumes/NO NAME/Smalltalk/Working Images/Salty > Dog/Sounds/train whistle.mp3". No other combination seems to work on my > machine - even direct parents and subdirectories of that one! WTH!! > - or apparently a path without spaces > > sound really as some bug.. and similar to system() call. my versions is: - it could be that strings are expected to be 16-byte aligned - that there's some bug with converting to null-terminated C string > The thing that has me scratching my head is that even with spaces it works > from Xcode! > > To see the error from Pharo: > > 1. Gofer it > smalltalkhubUser: 'SeanDeNigris' project: 'FMOD'; > package: 'FMOD'; > load. > > 2. Copy the "FMOD Programmers API" folder from the C Sample into the image > folder. > > 3. FmodLibrary exampleFmodStylePlaying: '/path/to/train whistle.mp3'. > > I'd reaaaally appreciate Igor or another NB guru (if there is such a thing, > lol) to take a look. I've spent days chasing this down, and I'm out of > ideas... Thanks. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Best regards, Igor Stasenko.

Dec. 2, 2013

NativeBoost String Handling Bug?

by Sean P. DeNigris

I'm tearing my hair out wrapping FMOD! I finally isolated the Mac VM-crashing bug (works in Windows) to: The reason I suspect NB is that I made a simple Xcode C project which (I think) does the exact same thing, which works perfectly. I uploaded it to https://github.com/seandenigris/FMODExample . To use it, just change SOUND_FILE_PATH in main.c to the location of the included "train whistle.mp3" file >From Pharo, however, it only works if the path to the mp3 is: - *exactly* "/Volumes/NO NAME/Smalltalk/Working Images/Salty Dog/Sounds/train whistle.mp3". No other combination seems to work on my machine - even direct parents and subdirectories of that one! WTH!! - or apparently a path without spaces The thing that has me scratching my head is that even with spaces it works from Xcode! To see the error from Pharo: 1. Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'FMOD'; package: 'FMOD'; load. 2. Copy the "FMOD Programmers API" folder from the C Sample into the image folder. 3. FmodLibrary exampleFmodStylePlaying: '/path/to/train whistle.mp3'. I'd reaaaally appreciate Igor or another NB guru (if there is such a thing, lol) to take a look. I've spent days chasing this down, and I'm out of ideas... Thanks. ----- Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2013

Re: [Pharo-dev] Roassal Bug related to Athens?

by kilon alios

and how exactly you expect that people would know what a session is ? or why that would be an issue with nativeboost or Athens ? I did not even know that there was a tutorial included about it in the Athens tutorial which is package that existing in the smalltalkhub repo of Athens in smalltalkhub for some strange reason the tutorial is not included with the standard distribution of Pharo 3 even though Athens suppose to play a huge role for Pharo in the future replacing all drawings. I have even purchased both Pharo books and they don't mention this. You cant blame him for not knowing or not googling about it. You cant google what you are not aware of. And you cant be aware if you dont have some sort of documentation in front of you. And no a maiing is not documentation. The least you could do is at smalltalkhub description tell to people to go fetch the Athens-Tutorial package and learn from it. At least that would save you a substantial amount of replies in the near future. From the tutorial alone he would have learned about the session issue and he would not have to ask and that would save him time and you. I love your work and appreciate your effort but whether we like it or not, these things are very important. On Mon, Dec 2, 2013 at 11:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 2 December 2013 17:14, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > >> Hello Igor, >> >> Moose 5.0 is using Athens as default canvas for Roassal and we have bug >> with Roassal that seems to be related to Athens. >> http://code.google.com/p/moose-technology/issues/detail?id=1019 >> >> I think it is related to the fact that we create a surface in the OS with >> Athens and once we quit the image, the surface is destroyed as well. So, >> when image is restarted with the visualization trying to use the surface, >> we get the error. >> >> right. > > >> Could you point to what possibly can be done to avoid this error? Merely >> checking the existence of an appropriate drawing surface in Athens every >> time visualization is drawn, would it suffice? >> >> yes.. i explained and given examples multiple times both for NB and > Athens (and last time it was like couple weeks ago). > > http://lmgtfy.com/?q=nativeboost+session+aware&l=1 > > regards, >> >> Usman >> > > > > -- > Best regards, > Igor Stasenko. >

Dec. 2, 2013

Re: [Pharo-dev] Roassal Bug related to Athens?

by Usman Bhatti

On Mon, Dec 2, 2013 at 10:12 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > http://code.google.com/p/nativeboost/wiki/SessionManagement > This one's much more helpful. > > > > On 2 December 2013 22:02, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 2 December 2013 17:14, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: >> >>> Hello Igor, >>> >>> Moose 5.0 is using Athens as default canvas for Roassal and we have bug >>> with Roassal that seems to be related to Athens. >>> http://code.google.com/p/moose-technology/issues/detail?id=1019 >>> >>> I think it is related to the fact that we create a surface in the OS >>> with Athens and once we quit the image, the surface is destroyed as well. >>> So, when image is restarted with the visualization trying to use the >>> surface, we get the error. >>> >>> right. >> >> >>> Could you point to what possibly can be done to avoid this error? Merely >>> checking the existence of an appropriate drawing surface in Athens every >>> time visualization is drawn, would it suffice? >>> >>> yes.. i explained and given examples multiple times both for NB and >> Athens (and last time it was like couple weeks ago). >> >> http://lmgtfy.com/?q=nativeboost+session+aware&l=1 >> >> regards, >>> >>> Usman >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. >

Dec. 2, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Sean P. DeNigris

Attila Magyar wrote > The reason for having the base class is to verify the expectations at the > end of the tests automatically. Doing this manually is possible (context > assertSatisfied), but probably people would forget it without this > automatic mechanism. In Java for example, mock libraries use custom JUnit > runners to do this, but I haven't found something like this in SUnit. If > there is a better way to do this please let me know. I understand the motivation. My question is how do we create appropriate hooks so that we don't get into these conflicts? I made a few enhancements to BabyMock: - anyArgument now inst var of BabyMockTestCase, similar to BmAnyMessage - #does: now optionally takes arguments The second one turns: handle := FMOD_SYSTEM new. library should receive: #FMOD_System_Create:; with: [ :a | a = handle ifTrue: [ handle := a. handle handle: 20. true ] ifFalse: [ false ] ]; answer: 0. library should receive: #FMOD_System_Init:; with: [ :a | a = handle ]; answers: 0. ...into: library should receive: #FMOD_System_Create:; with: FMOD_SYSTEM new; does: [ :h | h handle: 20. 0 ]. library should receive: #FMOD_System_Init:; with: [ :a | a handle = 20 ]; answers: 0. ... eliminating the temporary, and the separate #with: and #answer: send in the first expectation. I pushed them to http://smalltalkhub.com/mc/SeanDeNigris/FMOD/main/ since that's where I was using them, but if you give me access to the BM repo and you like the changes, I will clean them up and push there. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787p4726855.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2013

Re: [Pharo-dev] Roassal Bug related to Athens?

by Igor Stasenko

http://code.google.com/p/nativeboost/wiki/SessionManagement On 2 December 2013 22:02, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 2 December 2013 17:14, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > >> Hello Igor, >> >> Moose 5.0 is using Athens as default canvas for Roassal and we have bug >> with Roassal that seems to be related to Athens. >> http://code.google.com/p/moose-technology/issues/detail?id=1019 >> >> I think it is related to the fact that we create a surface in the OS with >> Athens and once we quit the image, the surface is destroyed as well. So, >> when image is restarted with the visualization trying to use the surface, >> we get the error. >> >> right. > > >> Could you point to what possibly can be done to avoid this error? Merely >> checking the existence of an appropriate drawing surface in Athens every >> time visualization is drawn, would it suffice? >> >> yes.. i explained and given examples multiple times both for NB and > Athens (and last time it was like couple weeks ago). > > http://lmgtfy.com/?q=nativeboost+session+aware&l=1 > > regards, >> >> Usman >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Dec. 2, 2013

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by Mariano Martinez Peck

On Mon, Dec 2, 2013 at 6:03 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Stef wrote: > >Do you think that if an external library redefines the semantics of > #class, it will be a Pharo bug? > > I donât know. I know I have 35 implementers of #packages in my Moose > image, and 191 senders. > You will only have problems with class side #packages. Are all those 35 class side? Cheers, > And I know that in Magritte 3 we changed from using #description to > #magritteDescription to avoid > polluting the namespace with a word that is commonly used for other > things. At the same time > I donât exactly enjoy adding prefixes everywhere. DeprecationFinder tells > me there are 60 projects > on smalltalkhub using #packages. And I know I have to be careful about > where I use #name. > > And when taking a look at the problem, I immediately run into lots of > methods flagged #todo, a.o. > (CompiledMethod>packageFromOrganizer:) that seems to suggest a different > solution. > > I can imagine a more effective way of convincing Grease maintainers that > they should switch API :) > > Stephan > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2013

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by Stephan Eggermont

Stef wrote: >Do you think that if an external library redefines the semantics of #class, it will be a Pharo bug? I donât know. I know I have 35 implementers of #packages in my Moose image, and 191 senders. And I know that in Magritte 3 we changed from using #description to #magritteDescription to avoid polluting the namespace with a word that is commonly used for other things. At the same time I donât exactly enjoy adding prefixes everywhere. DeprecationFinder tells me there are 60 projects on smalltalkhub using #packages. And I know I have to be careful about where I use #name. And when taking a look at the problem, I immediately run into lots of methods flagged #todo, a.o. (CompiledMethod>packageFromOrganizer:) that seems to suggest a different solution. I can imagine a more effective way of convincing Grease maintainers that they should switch API :) Stephan

Dec. 2, 2013