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

Re: [Pharo-dev] Strange behavior of blocks

by ClÃ©ment Bera

2014-08-01 22:40 GMT+02:00 stepharo <stepharo(a)free.fr>: > thanks clement! > Could you also have a look at the suggestions henrik mentioned? > I'll have a look on monday. > Stef > > > On 1/8/14 16:43, ClÃ©ment Bera wrote: > > Hello, > > Nice way to reproduce easily the SmallInteger bug :) > > | state values | > values := (1 to: 100000) collect: [ :t | state := { t . t + 1 . t + 2 }]. > values select: [ :e | e isInteger ] > > This bug was present in some VMs and it is fixed in the latest VMs. > > The stable Mac VM still have the bug. > > If you need a VM without the bug, go there: > > http://files.pharo.org/vm/pharo/30/ > > Click on your OS, then select the zip file named 'latest.zip' and > download it. > > The latest VM does not have the bug. > > > > 2014-08-01 15:20 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > >> Dear all, >> >> using Sci-Smalltalk, we found with Natalia that sometimes blocks have >> strange behavior : >> https://groups.google.com/forum/#!topic/scismalltalk/HmGpTkzLOdQ >> >> I was able to create a more simpler example using only Pharo. >> If you try, the following expression, there is no problem: >> >> |state values | >> values := (1 to: 10000) collect: [ : t| state := { t. t+1. t+2.}]. >> (1 to: 10000) do:[:i | (values at:i) at:2]. >> >> and you do more iterations, an error appears (Instances of >> SmallInteger are not indexable), >> because from time to time, an array is replaced by an integer: >> >> |state values | >> values := (1 to: 100000) collect: [ : t| state := { t. t+1. t+2.}]. >> (1 to: 100000) do:[:i | (values at:i) at:2]. >> >> and if you move the state variable inside the block, it works again : >> >> | values | >> values := (1 to: 100000) collect: [ : t| |state| state := { t. t+1. >> t+2.}]. >> (1 to: 100000) do:[:i | (values at:i) at:2]. >> >> Same problem in Pharo 3.0 or Pharo 4.0 >> >> Regards, >> -- >> Serge Stinckwich >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ >> >> > >

Aug. 2, 2014

Re: [Pharo-dev] Pharo image corruption and fatal VM error with Roassal

by volkert＠nivoba.de

I had the same problem today on W8.1 x64 :-( BW, Volkert Am 31.07.2014 um 10:50 schrieb Blondeau Vincent: > > Hi, > > Yesterday, I was using GraphET (a part of Roassal) to do some charts > and, today, when I wanted to reopen the image. > > And I got that : > > It is **very** unpleasantâ¦ > > To reproduce the bug: > > 1 - You can do either: > > | builder | > > builder := GET2Line data: (0 to: 100) . > > builder > > y: [ :x | x*x ]. > > builder open. > > Or > > WorldMenu -> Roassal examples -> choose an item -> click on a graph . > A TRMorph should be opened. > > 2 - donât close the graph and save the pharo image. > > 3 â Close the pharo image > > 4 - Reopen it > > I am under W7 x64 with the latest moose image and the VM available on > the pharo.org website > (http://files.pharo.org/platform/Pharo3.0-win.zip) from the 10 july. > > You will find the crash dump attached. > > Thankfully, I managed to open the image with a latest VM > (http://www.mirandabanda.org/files/Cog/VM/VM.r3056/cogwin-14.29.3056.zip) > > > Thanks a lot Eliot ! :) > > And I got this: > > Thanks in advance > > Cheers, > > Vincent BLONDEAU > > > ------------------------------------------------------------------------ > > 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. -- www.nivoba.de "The more complex an object, the larger the investment in learning to use it, and the greater the resistance to abandon it.", NW

Aug. 2, 2014

fresh image with dirty packages

by Nicolai Hess

Loading and starting a fresh image (Pharo 40148) shows some dirty package in monticello. (KernelTests, CollectionsTests, ...) Comparing those packages with pharo40inbox shows no changes except for NativeBoost-Core Athens-Cairo and AST-Core what happened?

Aug. 1, 2014

Test Coverage easy to use in Pharo

by Alexandre Bergel

Hi! We are actively working on S2py, the nice successor of Spy1. S2py is a profiler framework: it allows one to easily build dynamic analysis. Hapao, shipped with S2py, is a test coverage tool. Here is how to use it: First, you need free type font: http://bit.ly/installingFreeTypeFont Then, you need Roassal2 and S2py -=-=-=-=-=-=-=-=-=-= Gofer new smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; package: 'ConfigurationOfRoassal2'; load. (Smalltalk at: #ConfigurationOfRoassal2) loadBleedingEdge. Gofer new smalltalkhubUser: 'ObjectProfile' project: 'S2py'; package: 'S2py'; load. -=-=-=-=-=-=-=-=-=-= Here is a screenshot of the coverage of Nautilus: Run "Hapao @ Class" and "Hapao @ Class â¦â from the World menu. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 1, 2014

Todo: Athens (Pharo image corruption and fatal VM error with Roassal)

by Nicolai Hess

2014-08-01 13:09 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > Someone working on this? > > > igor but he got burned out on that. > > > What are the next steps to make the system fully athens based? > > we need > - to update all the drawon: methods (arghhhhh) > No, this can make fun! What is needed? For all drawOn: implement a drawOnAthensCanvas: and test if they work on an AthensWrapMorph? > - get a texteditor working (so far it is working but no tab support) > where? I this in any way related to the work done for Rubric and/or TxText? > > > We can organize a skype meetings with people willing to help. > > > Stef > >

Aug. 1, 2014

Re: [Pharo-dev] Has someone ever built a "sort block generator"

by Nicolas Cellier

2014-08-01 16:50 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 01 Aug 2014, at 4:47 , Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > On Fri, Aug 1, 2014 at 11:31 AM, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > >> Y asked for the same thing a few days ago in >> http://forum.world.st/Multiple-sorting-helper-td4770613.html >> >> Something like: >> sorter := MultipleSortCriteria new >> add: #lastName; >> add: [:each | each personalInfo age ] ascending: false. >> aCollection asSortedCollection: sorter. >> >> > Exactly!!! > And... what is most important for me, is that to the MultipleSortCriteria > I would like to ask #sortBlock :) > > Thanks Esteban for better explaining what I was looking for ;) > > > I always liked this approach: > http://objology.blogspot.no/2010/11/tag-sortfunctions-redux.html > > Donât think anyoneâs ported it to Pharo yet though. > > Cheers, > Henry > +1 Note that I have a public experimental port to Pharo in SmalltalkHub that I already announced once (in http://smalltalkhub.com/#!/~nice/NiceVMExperiments <http://smalltalkhub.com/#%21/%7Enice/NiceVMExperiments/versions/VMMaker.osc…> but I can't tell exactly the package name TagSortFunction or something like that, the web interface of SmalltalkHub is currently showing me a debugger with nil does not understand #data). Yes, I know VM-experiments is not the right place for such package, but at the time I didn't find where to create a new project... Since I got absolutely zero feedback after a long thread, I assumed it was not interesting anybody... But my personal opinion differs: this should be included in each and every Smalltalk.

Aug. 1, 2014

Re: [Pharo-dev] Floating point literals in debugger

by stepharo

could you add a bug entry with the discussion because else this will be lost. Stef On 1/8/14 17:58, Natalia Tymchuk wrote: > Thank you. > I donât need it, because I know what is written in my code, but it can > be the problem for users and I think that it will good to fix it. > Best regards, > Natalia > > On Aug 1, 2014, at 5:07 PM, ClÃ©ment Bera <bera.clement(a)gmail.com > <mailto:bera.clement@gmail.com>> wrote: > >> Hello, >> >> Natalia I don't think this is a known bug (few people use Float and >> Fraction in Pharo). >> >> The RBParser parse your floating pointers as Fraction and not as >> Float (I don't know why). >> >> In the debugger the bytecode pc to source code pointer is mapped by >> printing the AST. In this case, the AST node (RBLiteralNode) for your >> float holds a Fraction. The code to print a literal node is as follow: >> >> visitLiteralNode: aLiteralNode >> aLiteralNode value isLiteral >> ifFalse: [ self writeString: '''<an unprintable nonliteral value>''' ] >> ifTrue: [ self writeString: aLiteralNode token storeString ] >> >> and isLiteral answers always false for a Fraction. >> >> A temporary patch consists in adding the method >> >> Fraction>>isLiteral >> ^ true >> >> Then you can debug your code. >> >> However, I think a real patch would consists in adding the method >> isLiteral in Fraction but with correct code to answer true only if >> the fraction can be a literal. Something similar to Float>>#isLiteral. >> >> >> 2014-08-01 15:40 GMT+02:00 Serge Stinckwich >> <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>>: >> >> Yes, I see also the same problem. >> >> I didn't realize until now that : 1-1e-6 >> is printed as a fraction (try print-it): >> (999999/1000000) >> >> A little bit strange, no ? >> >> On Fri, Aug 1, 2014 at 3:05 PM, Natalia Tymchuk >> <natalia.tymchuk(a)unikernel.net >> <mailto:natalia.tymchuk@unikernel.net>> wrote: >> > Hello. >> > When I have the following expression >> > {1-1e-6. 1e-6. 0} >> > in the code and then I debug it I get >> > {(1 - '<an unprintable nonliteral value>'). >> > '<an unprintable nonliteral value>'. >> > 0}. >> > >> > Is it a known problem or should I report an issue on debug tracker? >> > >> > Best regards, >> > Natalia >> > >> >> >> >> -- >> Serge Stinckwich >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ >> >> >

Aug. 1, 2014

Re: [Pharo-dev] Strange behavior of blocks

by stepharo

thanks clement! Could you also have a look at the suggestions henrik mentioned? Stef On 1/8/14 16:43, ClÃ©ment Bera wrote: > Hello, > > Nice way to reproduce easily the SmallInteger bug :) > > | state values | > values := (1 to: 100000) collect: [ :t | state := { t . t + 1 . t + 2 }]. > values select: [ :e | e isInteger ] > > This bug was present in some VMs and it is fixed in the latest VMs. > > The stable Mac VM still have the bug. > > If you need a VM without the bug, go there: > > http://files.pharo.org/vm/pharo/30/ > > Click on your OS, then select the zip file named 'latest.zip' and > download it. > > The latest VM does not have the bug. > > > > 2014-08-01 15:20 GMT+02:00 Serge Stinckwich > <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>>: > > Dear all, > > using Sci-Smalltalk, we found with Natalia that sometimes blocks have > strange behavior : > https://groups.google.com/forum/#!topic/scismalltalk/HmGpTkzLOdQ > <https://groups.google.com/forum/#%21topic/scismalltalk/HmGpTkzLOdQ> > > I was able to create a more simpler example using only Pharo. > If you try, the following expression, there is no problem: > > |state values | > values := (1 to: 10000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 10000) do:[:i | (values at:i) at:2]. > > and you do more iterations, an error appears (Instances of > SmallInteger are not indexable), > because from time to time, an array is replaced by an integer: > > |state values | > values := (1 to: 100000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > and if you move the state variable inside the block, it works again : > > | values | > values := (1 to: 100000) collect: [ : t| |state| state := { t. > t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > Same problem in Pharo 3.0 or Pharo 4.0 > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

Aug. 1, 2014

Re: [Pharo-dev] where the...

by Torsten Bergmann

Aug. 1, 2014

Re: [Pharo-dev] where the...

by ClÃ©ment Bera

2014-08-01 18:23 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > On Thu, Jul 31, 2014 at 11:52 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> Eliot Miranda wrote: >> >> >> >> >> On Thu, Jul 31, 2014 at 9:48 PM, stepharo <stepharo(a)free.fr> wrote: >> >>> I can tell you that I do not like jenkins but we have it, it works and >>> it is maintained. So I lobotomize myself when I use it and it looks ok :) >>> >> >> I like it very much. But there's a lot of freedom to design the server >> and make it easier to find results, etc. For example at Cadence Bob >> Westergaard has put a lot of effort into our Jenkins server with tabs >> grouping different build tasks by VM, Newspeak, Spur, etc. So I find it >> easier to navigate than the Pharo one. In particular it would be great if >> thee were pointers to the latest build artifacts on >> https://ci.inria.fr/pharo/job/Pharo-4.0/. Is that possible? >> >> >> I think the philosophy was to avoid the CI server also being a file sever >> - but perhaps the job result could provide a link to the associated >> uploaded http://files.pharo.org/image/40/xxxxx.zip >> > > Ok, if one should go to files.pharo.org then there should be as many > links to files.pharo.org in obvious places as possible. But if I, as an > outside, think to myself "nbow where would I find the most recent build of > Pharo 4?", I would go to the CI server. > > For me, philosophically, a CI server /is/ a server, of build artifacts, > test results and benchmarks. > > I keep that link in my bookmarks to download the latest Pharo 4: https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-4-Publish/ However, to avoid the server to be overloaded (because there are many people downloading Pharo every day), it is better to use files.pharo.org . > >> cheers -ben >> >> >> Stef >>> >>> On 1/8/14 01:36, Eliot Miranda wrote: >>> >>>> *&^% do I find build artifacts for >>>> https://ci.inria.fr/pharo/job/Pharo-4.0/lastSuccessfulBuild/? There's >>>> no pointer to an image/changes combo I can see. >>>> -- >>>> Aloha, >>>> Eliot >>> >>> -- >> Aloha, >> Eliot >> >> -- > Aloha, > Eliot >

Aug. 1, 2014