- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 3 December 2013 03:17, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Hooray! How can I patch to see if it fixes my problem? > > just update your inbox. and see my other post :) > > > -------- Original message -------- > From: "Igor Stasenko [via Smalltalk]" <[hidden email]<http://user/SendEmail.jtp?type=node&node=4726889&i=0>> > > Date: 12/02/2013 8:31 PM (GMT-05:00) > To: "Sean P. DeNigris" <[hidden email]<http://user/SendEmail.jtp?type=node&node=4726889&i=1>> > > Subject: Re: NativeBoost String Handling Bug? > > > nevermind, i think i found the cause. > (system call now is working) > > > On 3 December 2013 02:08, Igor Stasenko <[hidden email]<http://user/SendEmail.jtp?type=node&node=4726884&i=0> > > wrote: > > >> >> >> On 3 December 2013 00:32, Sean P. DeNigris <[hidden email]<http://user/SendEmail.jtp?type=node&node=4726884&i=1> >> > 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. >> > > > > -- > Best regards, > Igor Stasenko. > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726884.html > To unsubscribe from NativeBoost String Handling Bug?, click here. > NAML<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > Cheers, > Sean > > ------------------------------ > View this message in context: Re: NativeBoost String Handling Bug?<http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726889.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] transcript is plain bad

by Igor Stasenko

On 3 December 2013 02:59, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2013/12/2 Sean P. DeNigris <sean(a)clipperadams.com>: > > EstebanLM wrote > >> yes, the transcript is ThreadSafeTranscript > > > > Does "ThreadSafe" mean I don't have to wrap all my debug logging in > > "WorldState addDeferredUIMessage: [ Transcript... ]? That would save a > lot > > of time :) > > According to the implementation it means there is a Mutex stopping > multiple processes from doing operations (#nextPut:, #nextPutAll:) at > the same time. It is... who sends the message first will be received > happily, whoever is second will have to wait in a semaphore :D > > Funny outputs might happen if two different senders use #nextPut: > intertwined. > (other frameworks only left "complete line" outputs to loggers, to > avoid this kind of scenarios). > > imo this is exactly the case when for 0.00001% of chance that it will be required once, you spend tons of effort to make it work, means: overengineering. And, btw, good luck with solving the Halting problem along the way when you will be implementing this 'complete line' (when multiple threads sending output, but don't allowed to mix the lines) -- Best regards, Igor Stasenko.

Dec. 3, 2013

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

by Sean P. DeNigris

Hooray! How can I patch to see if it fixes my problem? -------- Original message -------- From: "Igor Stasenko [via Smalltalk]" <ml-node+s1294792n4726884h92(a)n4.nabble.com> Date: 12/02/2013 8:31 PM (GMT-05:00) To: "Sean P. DeNigris" <sean(a)clipperadams.com> Subject: Re: NativeBoost String Handling Bug? nevermind, i think i found the cause. (system call now is working) On 3 December 2013 02:08, Igor Stasenko <[hidden email]> wrote: On 3 December 2013 00:32, Sean P. DeNigris <[hidden email]> 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? Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko. If you reply to this email, your message will be added to the discussion below: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726884.html To unsubscribe from NativeBoost String Handling Bug?, click here. NAML ----- Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726889.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 3, 2013

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

by Igor Stasenko

Name: NativeBoost-Core-IgorStasenko.140 Name: NativeBoost-Tests-IgorStasenko.75 try and see if it works for you (and try syscall too, if yes then i think we can finally close the bug entry). P.S. thanks for being persistent on this one.

Dec. 3, 2013

Re: [Pharo-dev] transcript is plain bad

by Esteban A. Maringolo

2013/12/2 Sean P. DeNigris <sean(a)clipperadams.com>: > EstebanLM wrote >> yes, the transcript is ThreadSafeTranscript > > Does "ThreadSafe" mean I don't have to wrap all my debug logging in > "WorldState addDeferredUIMessage: [ Transcript... ]? That would save a lot > of time :) According to the implementation it means there is a Mutex stopping multiple processes from doing operations (#nextPut:, #nextPutAll:) at the same time. It is... who sends the message first will be received happily, whoever is second will have to wait in a semaphore :D Funny outputs might happen if two different senders use #nextPut: intertwined. (other frameworks only left "complete line" outputs to loggers, to avoid this kind of scenarios). Regards!

Dec. 3, 2013

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

by Igor Stasenko

nevermind, i think i found the cause. (system call now is working) On 3 December 2013 02:08, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > 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. > -- Best regards, Igor Stasenko.

Dec. 3, 2013

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. 3, 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