- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Way to see diffs between different builds?

by StÃ©phane Ducasse

We should have a database with ring objects and perform queries. I know that hernan and ezequiel are working on that. Stef >> Hi, >> >> Is there a way to see the diffs (in terms of changes to image) between one >> 2.0 build number and another? I don't see any obvious link on the CI server >> to it, and the github export seems to be done in a way that makes the diffs >> enourmous. > > you can use the git repos and filter out non-st methods: > git diff $VERSION_A $VERSION_B -- $(git diff --name-only $VERSION_A $VERSION_B | grep .st) > > Git even has a utility to find the version that introduced a certain bug :) > http://incitecode.com/2009/10/13/finding-bugs-with-git-bisect/ > > >> If not, is there a way to do it in image? I can only see changes for >> individual MC packages, not a more system level diff to see exactly what >> changed from one build to another. > > We should have a global Pharo MC Package which has all other packages as > dependencies, that would simplify quite a few things here... > > Otherwise you're stuck with downloading the image for a specific version > which might be corrupted, and thus leaves you without any chance of > inspecting the changes... > > >> I was starting to dig into the metacello bootstrapping problem in 2.0 and >> became clear to me it'd help me a lot if I could more easily follow the >> diffs. >> >> Thanks, >> Patrik > >

July 26, 2012

Re: [Pharo-project] assertion failed using NBFFI call

by Lawson English

Doh, as you point out, I renamed the parameter... Thanks. L On 7/26/12 9:47 AM, Igor Stasenko wrote: > On 26 July 2012 18:22, Lawson English <lenglish5(a)cox.net> wrote: >> >> I'm getting an assertion failed error in NBFFICallout >> >> The debugger is point to this line: >> >> self assert: type loader notNil. >> <==========AssertionFailure:AssertionFailed >> ^ type >> > check that argument name is one of the method's arguments or instance variables. > this error happens when NB cannot associate an argument name in > function signature with any variable in method's scope (or it's class > scope) > >> when I run this code: >> >> >> >> +++++++++++++++ >> myBytes := ByteArray new: 20. >> (GMPfrWrapper new) test4: myBytes withLength: 20. >> >> >> ++++++++++++++++ >> GMPfrWrapper>> test4:bytes withLength: length >> >> >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >> >> ^ NBFFICallout cdecl: #( int _ByteTest(ulong length, NBByteArrayPtr >> byteArray) ) >> module: >> '/Users/lawsonenglish/Library/Developer/Xcode/DerivedData/Mandelbrot_Set-budpkxrcvoxdiocqojopadbgogzi/Build/Products/Debug/libMandelDraw.dylib' >> ++++++++++++++++++ >> >> I'ved checked with nm >> "/Users/lawsonenglish/Library/Developer/Xcode/DerivedData/Mandelbrot_Set-budpkxrcvoxdiocqojopadbgogzi/Build/Products/Debug/libMandelDraw.dylib" >> >> and get: >> >> 00000e30 T _ByteTest >> ... >> >> >> I can load the file by doing: >> >> string := FileStream >> readOnlyFileNamed:'/Users/lawsonenglish/Library/Developer/Xcode/DerivedData/Mandelbrot_Set-budpkxrcvoxdiocqojopadbgogzi/Build/Products/Debug/libMandelDraw.dylib' >> do: [:stream| >> stream binary. >> stream contents]. >> >> >> >> >> Suggestions? >> >> >> Thanks, >> >> >> L >> >> >> >> >> >> -- >> Squeak from the very start (introduction to Squeak and Pharo Smalltalk for >> the (almost) complete and compleate beginner). >> https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all >> > > -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all

July 26, 2012

[Pharo-project] assertion failed using NBFFI call

by Lawson English

I'm getting an assertion failed error in NBFFICallout The debugger is point to this line: self assert: type loader notNil. <==========AssertionFailure:AssertionFailed ^ type when I run this code: +++++++++++++++ myBytes := ByteArray new: 20. (GMPfrWrapper new) test4: myBytes withLength: 20. ++++++++++++++++ GMPfrWrapper>> test4:bytes withLength: length <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ NBFFICallout cdecl: #( int _ByteTest(ulong length, NBByteArrayPtr byteArray) ) module: '/Users/lawsonenglish/Library/Developer/Xcode/DerivedData/Mandelbrot_Set-budpkxrcvoxdiocqojopadbgogzi/Build/Products/Debug/libMandelDraw.dylib' ++++++++++++++++++ I'ved checked with nm "/Users/lawsonenglish/Library/Developer/Xcode/DerivedData/Mandelbrot_Set-budpkxrcvoxdiocqojopadbgogzi/Build/Products/Debug/libMandelDraw.dylib" and get: 00000e30 T _ByteTest ... I can load the file by doing: string := FileStream readOnlyFileNamed:'/Users/lawsonenglish/Library/Developer/Xcode/DerivedData/Mandelbrot_Set-budpkxrcvoxdiocqojopadbgogzi/Build/Products/Debug/libMandelDraw.dylib' do: [:stream| stream binary. stream contents]. Suggestions? Thanks, L -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all

July 26, 2012

Re: [Pharo-project] ODBC on W7 and Pharo 1.4

by Friedrich Dominicus

"Torsten Bergmann" <astares(a)gmx.de> writes: >>So to me it seems this is a problem in the ODBC Driver vor Access, but I >>could not imagine that no-one ever have treated Doubles while trying to >>access MS Access with Pharo. > > Maybe you should try the newest runtime for Access 2010: I don't think you can expect that an Access runtime 2010 can handle an access 2003 application. That's not very likely. > > to see if it is really a ODBC driver problem. > > According to [1] and [2] this should be 15 instead of 53 > for SQL_DOUBLE. Correct? Yes. I tested this result also with an C programm and yes indeed it is 53 and this is wront. It probably is the number of bit sin the mantissa of a Double. A work around may be not to use this query of the column but "hack" it that it just picks 15 bytes. I guess it tries to load all the 53 bits and well, who knows what bits pattern there may be around a Double... Hardly anything meaningful.

July 26, 2012

[Pharo-project] ODBC on W7 and Pharo 1.4

by Torsten Bergmann

>So to me it seems this is a problem in the ODBC Driver vor Access, but I >could not imagine that no-one ever have treated Doubles while trying to >access MS Access with Pharo. Maybe you should try the newest runtime for Access 2010: http://www.microsoft.com/en-us/download/details.aspx?id=10910 (for instance in a www.virtualbox.org installation). to see if it is really a ODBC driver problem. According to [1] and [2] this should be 15 instead of 53 for SQL_DOUBLE. Correct? Bye T. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms716289(v=vs.85).a… [2] http://msdn.microsoft.com/en-us/library/windows/desktop/ms711786(v=vs.85).a…

July 26, 2012

Re: [Pharo-project] ODBC on W7 and Pharo 1.4

by Friedrich Dominicus

"Torsten Bergmann" <astares(a)gmx.de> writes: >>But it does not declare anything which is needed e.g for >>understanding SQLDouble and the like. > > Because FFI is a general callout mechanism for native APIs > and the ODBC package is just implemented on top of it. You are right, but it does not declare the handling of pointer or I have not understand it. > Just by looking at the code, maybe > - #initializeDataTypes has a wrong definition > - maybe the ODBCConstants definition is wrong > - maybe #initializeResultSet:number: has a problem Well I did exactly what you suggested and the problem is very likely in here: checkSQLReturn: (ODBCLibrary default sqlDescribeCol: resultSetHandle columnNumber: number columnName: columnName bufferLength: BUFFERSIZE nameLength: nameLenght dataType: columDataType columnSize: columnSize decimalDigits: decimalDigits nullable: columnNullable) The problem here is that columnSize gives 53 with Access 2003. and this surely is wrong it may even be a problem in Access for ages because I found a hotfix for it for Access 2007 http://www.everythingaccess.com/tutorials.asp?ID=The-lowdown-on-Access-2007 I guess this may explain my problem. Anyway I'm not sure about it. So to me it seems this is a problem in the ODBC Driver vor Access, but I could not imagine that no-one ever have treated Doubles while trying to access MS Access with Pharo. > >>Sorry, does that mean the name I gave to the Data source must be placed >>in host? > > Yes, that worked for me. "host" is a bit misleading - for an > SQLite connection it can be the local path, for ODBC its the DSN name > for a network database it is the hostname or IP address. Sorry having a Database name in host is all but obvious. Regards Friedrich

July 26, 2012

Re: [Pharo-project] RPackage registration mess

by Camillo Bruni

On 2012-07-26, at 13:24, Guillermo Polito wrote: > My bad :/. > > BTW, we have to introduce one method to restore the system subscriptions to > a good state whatever was the state before. And that way we do not mess it > so easily again. but the strange part is, that this cannot be caused by tests... I saw that some tests did it wrong. still strange that it popped up again :/

July 26, 2012

Re: [Pharo-project] RPackage registration mess

by Guillermo Polito

My bad :/. BTW, we have to introduce one method to restore the system subscriptions to a good state whatever was the state before. And that way we do not mess it so easily again. On Thu, Jul 26, 2012 at 1:17 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > so once again rpackage is registered to the wrong announcer... > > I figured out that update 20200 first introduced this bug by wrongly > resetting RPackage: > > http://code.google.com/p/pharo/issues/detail?id=6326 > > It registered RPackageOrganizer to MCWorkingCopy announcer but > > SystemAnnouncer announcer == MCWorkingCopy announcer > > and by default RPackageOrganizer registers to SystemAnnouncer > privateAnnouncer. > > obviously we got a double registration of RPackageOrganizer after this. > Which can be easily fixed by doing: > > RPackageOrganizer registerInterestToSystemAnnouncement. > > The invariant that should hold is > > > self assert: SystemAnnouncer announcer hasSubscriber: > RPackageOrganizer default = false. > self assert: SystemAnnouncer privateAnnouncer hasSubscriber: > RPackageOrganizer default. > > however I still can't figure out where the damn bug got introduced again... > until a few updates ago, the RPackage tests were not restoring the SystemAnnouncer correctly on tearDown. Probably it was in there...

July 26, 2012

Re: [Pharo-project] RPackage registration mess

by Damien Cassou

On Thu, Jul 26, 2012 at 1:17 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > self assert: SystemAnnouncer announcer hasSubscriber: RPackageOrganizer default = false. this expression is probably incorrect as #= is sent to (RPackageOrganizer default) -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 26, 2012

[Pharo-project] RPackage registration mess

by Camillo Bruni

so once again rpackage is registered to the wrong announcer... I figured out that update 20200 first introduced this bug by wrongly resetting RPackage: http://code.google.com/p/pharo/issues/detail?id=6326 It registered RPackageOrganizer to MCWorkingCopy announcer but SystemAnnouncer announcer == MCWorkingCopy announcer and by default RPackageOrganizer registers to SystemAnnouncer privateAnnouncer. obviously we got a double registration of RPackageOrganizer after this. Which can be easily fixed by doing: RPackageOrganizer registerInterestToSystemAnnouncement. The invariant that should hold is self assert: SystemAnnouncer announcer hasSubscriber: RPackageOrganizer default = false. self assert: SystemAnnouncer privateAnnouncer hasSubscriber: RPackageOrganizer default. however I still can't figure out where the damn bug got introduced again...

July 26, 2012