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

[pharo-project/pharo-core] 4e94db: 40399

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 4e94db5d93bc17024a1017215f62aae5e4f265bc https://github.com/pharo-project/pharo-core/commit/4e94db5d93bc17024a101721… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-04 (Thu, 04 Dec 2014) Changed paths: M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/helper/newBytecodeGen.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script399.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40399.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40399 14570 OCBytecodeGeneratorTest using hardcoded bytecode generator https://pharo.fogbugz.com/f/cases/14570 http://files.pharo.org/image/40/40399.zip

Dec. 4, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Thierry Goubier

2014-12-04 9:44 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 04 Dec 2014, at 09:24, Norbert Hartl <norbert(a)hartl.name> wrote: > > We need a better-than-git Smalltalk thing :) > > > yeah, we need a lot of things. > But who will put the bell on the cat's neck? > just dreaming of what we *could* have will make us never have anything... is > not that horizons are bad, they are needed to show the path to follow. > But not to accept the small improvements in the name of some super-goal we > are never close (because, of course, horizons move constantly) is prone to > immobility. > Honestly, in that particular case, I really had the feeling for some time that Pharo had chosen the super-goal instead of the incremental improvement. It changed with the focus on libgit2, luckily :) If I want to troll again :):) (beware) I'm interested by the Nautilus vs OmniBrowser decision. I have an hypothesis that this decision has value for anything looking like a Moldable, Glamour-based, Browser . Because in my mind, the OB gui framework and Glamour are along the same lines, and the OB GUI framework was missing something which pushed Nautilus forward[1]. So, for those who have used OB and Nautilus, or are using Squeak (where OB is still in use) and Pharo, what do you think? [1] http://marianopeck.wordpress.com/2012/02/26/nautilus-the-reborn-of-the-syst… Thierry > > Esteban >

Dec. 4, 2014

[ANN] Pharo Consortium New Academic Partner Univ. Prague

by Marcus Denker

The Pharo Consortium is very happy to announce that the Faculty of Information Technology of the Czech Technical University in Prague has joined the Consortium as an Academic Partner. About - Czech Technical University in Prague, Faculty of Information Technology: http://www.fit.cvut.cz/en - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

Dec. 4, 2014

Re: [Pharo-dev] Code retrieval on primitive failed

by ClÃ©ment Bera

Congratulations :-) Editing images with hexadecimal editors is the way real men program :-). 2014-12-04 16:39 GMT+01:00 Blondeau Vincent <vincent.blondeau(a)worldline.com> : > Finally, I succeeded to retrieve my code ! > > > > I tried with the Cog VM Simulator to open my image. > > It opened my crashed image in the simulator without any problem (it seems > that the failing primitive has been caught). > > But I cannot interact with the image through the simulator workspace and > the morph. > > It seems that you can launch some code by doit to export a package named > MyPackage: > > > > cos systemAttributes > > at: 2 put: '-doit'; > > at: 3 put: (âRPackage > named:ââMYPackageâ) fileout â] > > > > But this did not work because my code contains shared pools and it cannot > be filed outâ¦ > > > > > > In parallel, I tried the other solution of Clement by changing the > bytecode in the .image itself. > > > > If the problem comes from a native boost primitive, you should use a cogvm > : (e.g. > http://www.mirandabanda.org/files/Cog/VM/VM.r3056/cogwin-14.29.3056.zip) > to launch the failing image. > > After that, you should see the crash log and see which are the code that > is failing (apparently one of the top method in the stack). > > The best is to have the Smalltalk code of this method because you have to > retrieve the associated bytecode. Else either you try to remember exactly > the content of the method or you take another method in the stack where you > have the code. > > > > Once you have identified the method, extract the bytecode: > > on Pharo4 with the right click on the method name and by printing âself > bytecode hexâ > > on Pharo3 inspect the class containing the method, find the right compiled > method and print âself bytecode hexâ > > > > After that open the broken image with a hexadecimal editor (I use HxD > under w7) (do a COPY before). > > Find the bytecode of the method and replace it by several 120 (78 in hex). > > As the bytecodes are not unique, it is possible to do several > replacements. If you donât want that, you can find another bytecode > available in the stack trace. Longest is the bytecode, less will be the > number of finding matches. > > > > Try to reopen your image with the cogwm. If it doesnât work either you > broke a critical method of your image (so try again with another bytecode) > either you have another failure so you start again to find the good method. > > > > Once you can open it. Save your code!!! > > The file out didnât work for me so I commited with Monticello in local and > it worked! > > > > So donât forget to commit! > > > > Vincent > > > > > > *De :* Blondeau Vincent > *EnvoyÃ© :* mercredi 3 dÃ©cembre 2014 18:41 > *Ã :* Pharo Development List > *Objet :* RE: [Pharo-dev] Code retrieval on primitive failed > > > > > > > > *De :* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] *De la part de* ClÃ©ment Bera > *EnvoyÃ© :* mercredi 3 dÃ©cembre 2014 17:54 > *Ã :* Pharo Development List > *Objet :* Re: [Pharo-dev] Code retrieval on primitive failed > > > > Please send the full stack trace. You don't have only three lines, do you ? > > > > No, indeed (the full stack is attached). > > > > There's one solution that Igor does sometimes that you can try...For that > you need to remember what code you changed that now crashes the image in > smalltalk. Do you know what code crash your image ? > > Could you rewrite it (exactly the same code) in a fresh image ? > > If so the process is as follow: > > - rewrite the crashing code in a fresh image > > - extract the bytecode from the compiled method > > - open a copy of your image with an hexadecimal editor, look for the > bytecode pattern, replace it by returnself (byte 120 the number of times > needed) > > - try open your copy. Do as little things as possible (typically, only > file out your packages, monticello will most probably not work) > > > > Ok I will try this but this is more a generic printing method that is the > problem (see trace)â¦ And not a specific methodâ¦ > > I tried but it seems not adapted to my caseâ¦ > > > > The alternative is to open your image on top of the cog simulator. Word > has been that there's a Pharo 3 image running the cog simulator, you can > use that to debug the code and fix it. Alternatively use a squeak vmmaker > image that you can build with this script: > > $ svn co http://www.squeakvm.org/svn/squeak/branches/Cog/image > > $ cd ./image > > $ ./buildsqueaktrunkvmmakerimage.sh > > You put a halt on the implementation of primitive 117 in the simulator > (named primitives call such as NB calls) to catch the crash and fix it from > there in the simulator. > > > > That seems better ! I am trying this way. > > > > Good luck and have fun :-) > > > > Thanks :) > > > > > > 2014-12-03 17:04 GMT+01:00 Blondeau Vincent < > vincent.blondeau(a)worldline.com>: > > Hello everyone, > > > > I am doing some developments with NativeBoost and unfortunaly I succeed to > save my image in a unstable state. > > I am using the last moose image i.e.: Pharo3.0 - Latest update: #30860. > > > > So when I want to launch my image, I get a primitive faillure. > > The interesting part of the stack trace is : > > Stack backtrace: > > [07EE7A1B] ??? + 0 in (null) > > [00539AB5] ??? + 1284789 in Pharo.exe > > > > Smalltalk stack dump: > > 0x2410b8 M NBFFICallout class(NBNativeCodeGen class)>retrySend: > 0x4c70b4c: a(n) NBFFICallout class > > 0x2410ec I NBFFICallout class(NBNativeCodeGen class)>retrySend: > 0x4c70b4c: a(n) NBFFICallout class > > 0x78a0d90 s RDoubleVector(OrderedCollection)>at: > > > > Then I wanted to retrieve my changes on a new image but, as the doIts are > not recorded, I have neither the method deletions nor all the operations on > classes nor the trait methods that are recorded as Doits with preamble: > Trait method. > > > > I tried to launch my image with squeak (which doesnât support NativeBoost) > to hope saving or commit my code. But as I am calling a primitive at > startup of the image to initialize the external environement. I got the > following trace : > > [31m==== Startup Error: PrimitiveFailed: primitive #isEnabled in > NativeBoost class failed > > [0mNativeBoost class(Object)>>primitiveFailed: > > NativeBoost class(Object)>>primitiveFailed > > NativeBoost class>>isEnabled > > NativeBoost class>>forCurrentPlatform > > NativeBoost class>>loadSymbol:fromModule: > > RSession class(Object)>>nbGetSymbolAddress:module: > > > > So what can I do to retrieve all my code without loose a day to rewrite it? > > > > Thanks in advance > > > > Vincent > > > > > ------------------------------ > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > > > > ------------------------------ > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. >

Dec. 4, 2014

Re: [Pharo-dev] Duration year

by Hilaire

Indeed! Thanks Le 04/12/2014 16:28, James Foster a Ã©crit : > >> On Dec 3, 2014, at 12:33 PM, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> Le 02/12/2014 17:34, Sean P. DeNigris a Ã©crit : >>> One solution (just ignore the source ha ha) - >>> http://msdn.microsoft.com/en-us/library/system.datetime.addyears%28v=vs.110… >>> >> >> Something like ? >> >> Date>>addYears: integer >> ^ Date >> year: self year + integer >> month: self monthIndex >> day: ((self dayOfMonth = 29 >> and: [(Year isLeapYear: self year + integer) not >> and: [Year isLeapYear: self year]]) >> ifTrue: [ 28 ] >> ifFalse: [ self dayOfMonth]) > > From a brief read of the code it looks like the day formula should have a check for monthIndex == 2. Otherwise, January 29 can turn in to January 28. > -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Dec. 4, 2014

Re: [Pharo-dev] Code retrieval on primitive failed

by Blondeau Vincent

Finally, I succeeded to retrieve my code ! I tried with the Cog VM Simulator to open my image. It opened my crashed image in the simulator without any problem (it seems that the failing primitive has been caught). But I cannot interact with the image through the simulator workspace and the morph. It seems that you can launch some code by doit to export a package named MyPackage: cos systemAttributes at: 2 put: '-doit'; at: 3 put: (âRPackage named:ââMYPackageâ) fileout â] But this did not work because my code contains shared pools and it cannot be filed outâ¦ In parallel, I tried the other solution of Clement by changing the bytecode in the .image itself. If the problem comes from a native boost primitive, you should use a cogvm : (e.g. http://www.mirandabanda.org/files/Cog/VM/VM.r3056/cogwin-14.29.3056.zip) to launch the failing image. After that, you should see the crash log and see which are the code that is failing (apparently one of the top method in the stack). The best is to have the Smalltalk code of this method because you have to retrieve the associated bytecode. Else either you try to remember exactly the content of the method or you take another method in the stack where you have the code. Once you have identified the method, extract the bytecode: on Pharo4 with the right click on the method name and by printing âself bytecode hexâ on Pharo3 inspect the class containing the method, find the right compiled method and print âself bytecode hexâ After that open the broken image with a hexadecimal editor (I use HxD under w7) (do a COPY before). Find the bytecode of the method and replace it by several 120 (78 in hex). As the bytecodes are not unique, it is possible to do several replacements. If you donât want that, you can find another bytecode available in the stack trace. Longest is the bytecode, less will be the number of finding matches. Try to reopen your image with the cogwm. If it doesnât work either you broke a critical method of your image (so try again with another bytecode) either you have another failure so you start again to find the good method. Once you can open it. Save your code!!! The file out didnât work for me so I commited with Monticello in local and it worked! So donât forget to commit! Vincent De : Blondeau Vincent EnvoyÃ© : mercredi 3 dÃ©cembre 2014 18:41 Ã : Pharo Development List Objet : RE: [Pharo-dev] Code retrieval on primitive failed De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de ClÃ©ment Bera EnvoyÃ© : mercredi 3 dÃ©cembre 2014 17:54 Ã : Pharo Development List Objet : Re: [Pharo-dev] Code retrieval on primitive failed Please send the full stack trace. You don't have only three lines, do you ? No, indeed (the full stack is attached). There's one solution that Igor does sometimes that you can try...For that you need to remember what code you changed that now crashes the image in smalltalk. Do you know what code crash your image ? Could you rewrite it (exactly the same code) in a fresh image ? If so the process is as follow: - rewrite the crashing code in a fresh image - extract the bytecode from the compiled method - open a copy of your image with an hexadecimal editor, look for the bytecode pattern, replace it by returnself (byte 120 the number of times needed) - try open your copy. Do as little things as possible (typically, only file out your packages, monticello will most probably not work) Ok I will try this but this is more a generic printing method that is the problem (see trace)â¦ And not a specific methodâ¦ I tried but it seems not adapted to my caseâ¦ The alternative is to open your image on top of the cog simulator. Word has been that there's a Pharo 3 image running the cog simulator, you can use that to debug the code and fix it. Alternatively use a squeak vmmaker image that you can build with this script: $ svn co http://www.squeakvm.org/svn/squeak/branches/Cog/image $ cd ./image $ ./buildsqueaktrunkvmmakerimage.sh You put a halt on the implementation of primitive 117 in the simulator (named primitives call such as NB calls) to catch the crash and fix it from there in the simulator. That seems better ! I am trying this way. Good luck and have fun :-) Thanks :) 2014-12-03 17:04 GMT+01:00 Blondeau Vincent <vincent.blondeau(a)worldline.com<mailto:vincent.blondeau@worldline.com>>: Hello everyone, I am doing some developments with NativeBoost and unfortunaly I succeed to save my image in a unstable state. I am using the last moose image i.e.: Pharo3.0 - Latest update: #30860. So when I want to launch my image, I get a primitive faillure. The interesting part of the stack trace is : Stack backtrace: [07EE7A1B] ??? + 0 in (null) [00539AB5] ??? + 1284789 in Pharo.exe Smalltalk stack dump: 0x2410b8 M NBFFICallout class(NBNativeCodeGen class)>retrySend: 0x4c70b4c: a(n) NBFFICallout class 0x2410ec I NBFFICallout class(NBNativeCodeGen class)>retrySend: 0x4c70b4c: a(n) NBFFICallout class 0x78a0d90 s RDoubleVector(OrderedCollection)>at: Then I wanted to retrieve my changes on a new image but, as the doIts are not recorded, I have neither the method deletions nor all the operations on classes nor the trait methods that are recorded as Doits with preamble: Trait method. I tried to launch my image with squeak (which doesnât support NativeBoost) to hope saving or commit my code. But as I am calling a primitive at startup of the image to initialize the external environement. I got the following trace : [31m==== Startup Error: PrimitiveFailed: primitive #isEnabled in NativeBoost class failed [0mNativeBoost class(Object)>>primitiveFailed: NativeBoost class(Object)>>primitiveFailed NativeBoost class>>isEnabled NativeBoost class>>forCurrentPlatform NativeBoost class>>loadSymbol:fromModule: RSession class(Object)>>nbGetSymbolAddress:module: So what can I do to retrieve all my code without loose a day to rewrite it? Thanks in advance Vincent ________________________________ Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ________________________________ Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Dec. 4, 2014

Re: [Pharo-dev] Duration year

by James Foster

> On Dec 3, 2014, at 12:33 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > > Le 02/12/2014 17:34, Sean P. DeNigris a Ã©crit : >> One solution (just ignore the source ha ha) - >> http://msdn.microsoft.com/en-us/library/system.datetime.addyears%28v=vs.110… >> > > Something like ? > > Date>>addYears: integer > ^ Date > year: self year + integer > month: self monthIndex > day: ((self dayOfMonth = 29 > and: [(Year isLeapYear: self year + integer) not > and: [Year isLeapYear: self year]]) > ifTrue: [ 28 ] > ifFalse: [ self dayOfMonth]) >From a brief read of the code it looks like the day formula should have a check for monthIndex == 2. Otherwise, January 29 can turn in to January 28.

Dec. 4, 2014

Re: [Pharo-dev] GTInspector and huge arrays issue

by Ben Coman

Sven Van Caekenberghe wrote: >> On 04 Dec 2014, at 11:45, phil(a)highoctane.be wrote: >> >> But further than that I want to edit values in inspectors. > > Yes ! > > And auto refresh ! > > Both of these could be depending on presentation, so that heavy presentations can opt out. > > > > It would be good if there was some visual indication of which presentations auto-refreshed - like a drop pin looking like its "stuck-in" when not-auto-refreshing. A user might even be able to change the state of the pin, with the just the default dependent on type of presentation. cheers -ben

Dec. 4, 2014

Re: [Pharo-dev] GTPlayground cache

by Marcus Denker

> On 04 Dec 2014, at 15:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 04 Dec 2014, at 15:42, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >> >> Aha. So, that's a bug, right? >> > > I think Playground needs to be resetted on #cleanUpForRelease. > > Else the image on the server thinks that it already has a playground file. Add to GTPlayBook cleanUp self reset Then this will be called on the build server. Marcus

Dec. 4, 2014

Re: [Pharo-dev] failing test in writing files

by Ben Coman

Sven Van Caekenberghe wrote: > self assert: (file species isKindOf: FileStream) > > But that is a weird test. What is the point ? > > You have to test behaviour, like write a file and see if it was written. Testing types is very seldom done, because this is an implementation detail. > Thanks Sheri and Sven. I learnt a new aspect of design philosophy today. Thats one thing I like about contributing to open source - the opportunity for learning, especially from the questions that other people ask. cheers -ben >> On 04 Dec 2014, at 01:32, sheridan(a)sheridan-mahoney.com wrote: >> >> Hi there, >> >> I have a failing test and was wondering if anyone would have a sense as to why: >> >> | testString filename file | >> testString := 'ascii String'. >> filename := 'test-file-' , 99 atRandom printString , '.txt'. >> filename asFileReference ensureDelete. >> file := filename asFileReference >> writeStreamDo: [ :stream | >> stream >> nextPutAll: testString; >> crlf ]. >> self assert: file species = FileStream. >> >> >> Many thanks, >> >> Sheri >> >> >> >> > > > Step into #writeStreamDo: ...

Dec. 4, 2014