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

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Esteban Lorenzano

Hi Doru, We are working hard to try to fix the vm stability issues and users help is the only way we can have enough crash cases to debug. Sending a mail to the list with a reproducible case is the best way to help up fix the vm. Any report is welcomed :) Esteban On Mar 12, 2013, at 9:20 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Great. > > Is there anything I can do to help fixing the problem? (my problem is that I do not even know where to start) > > As you can imagine this is an important blocker for the Moose team. > > Cheers, > Doru > > > > > On Mon, Mar 11, 2013 at 9:58 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > thanks doru! > > > > Hi, > > > > Where should I report Pharo VM crashes with Pharo 2.0? > > here first :) > > > > > In particular, I wanted to report the problem related to running Moose tests from the command line: > > > > --- > > You can reproduce it on Mac, quite consistently: just run the attached script (you need to have wget installed), or do it manually: > > > > 1. download and unzip the latest Moose 4.8: > > https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastSuccessfulBuild/arti… > > 2. download and unzip the latest Pharo VM: > > http://pharo.gforge.inria.fr/ci/vm/pharo/mac/pharo-mac-latest.zip > > 3. execute: > > ./Pharo.app/Contents/MacOS/Pharo ./Moose-latest-dev-4.8.image moosetest > > > > The VM crashes, but there is no trace of the error. > > --- > > > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "It's not what we do that matters most, it's how we do it." > > > > <crasher.sh> > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

March 12, 2013

Re: [Pharo-project] [Moose-dev] Re: where to report vm crashes? (while running Moose tests)

by Tudor Girba

It would be good to have a parallel job, but the problem is that you will get a message saying that the VM is too old for the Pharo 2.0 image. Cheers, Doru On Tue, Mar 12, 2013 at 9:05 AM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: > Doru, > > In the meantime, can we revert to CogVM because currently we cannot see > the status of fixes and we cannot go any further with Moose 4.8 or may be > create parallel jobs on Cog and Pharo vms ? > > > > On Mon, Mar 11, 2013 at 9:53 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> Where should I report Pharo VM crashes with Pharo 2.0? >> >> In particular, I wanted to report the problem related to running Moose >> tests from the command line: >> >> --- >> You can reproduce it on Mac, quite consistently: just run the attached >> script (you need to have wget installed), or do it manually: >> >> 1. download and unzip the latest Moose 4.8: >> >> https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastSuccessfulBuild/arti… >> 2. download and unzip the latest Pharo VM: >> http://pharo.gforge.inria.fr/ci/vm/pharo/mac/pharo-mac-latest.zip >> 3. execute: >> ./Pharo.app/Contents/MacOS/Pharo ./Moose-latest-dev-4.8.image moosetest >> >> The VM crashes, but there is no trace of the error. >> --- >> >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "It's not what we do that matters most, it's how we do it." >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- www.tudorgirba.com "Every thing has its own flow"

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Tudor Girba

Great. Is there anything I can do to help fixing the problem? (my problem is that I do not even know where to start) As you can imagine this is an important blocker for the Moose team. Cheers, Doru On Mon, Mar 11, 2013 at 9:58 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > thanks doru! > > > > Hi, > > > > Where should I report Pharo VM crashes with Pharo 2.0? > > here first :) > > > > > In particular, I wanted to report the problem related to running Moose > tests from the command line: > > > > --- > > You can reproduce it on Mac, quite consistently: just run the attached > script (you need to have wget installed), or do it manually: > > > > 1. download and unzip the latest Moose 4.8: > > > https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastSuccessfulBuild/arti… > > 2. download and unzip the latest Pharo VM: > > http://pharo.gforge.inria.fr/ci/vm/pharo/mac/pharo-mac-latest.zip > > 3. execute: > > ./Pharo.app/Contents/MacOS/Pharo ./Moose-latest-dev-4.8.image moosetest > > > > The VM crashes, but there is no trace of the error. > > --- > > > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "It's not what we do that matters most, it's how we do it." > > > > <crasher.sh> > > > -- www.tudorgirba.com "Every thing has its own flow"

March 12, 2013

Re: [Pharo-project] Code review tools?

by Igor Stasenko

On 11 March 2013 22:06, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 11 March 2013 19:00, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 11 March 2013 19:06, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> On 11 March 2013 17:54, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> pff... really people... i am thinking how to streamline our existing >>>> development process.. >>>> and instead i hear once again about git. >>> >>> Camillo needs to hit you around the head with a command line. You >>> haven't used it. You've heard several people who have used both >>> Monticello and git extensively say that git beats the crap out of >>> Monticello. Go and learn git properly. THEN come back and maybe we can >>> have a conversation. >>> >> I always using git from command line. And let me remind you it was me who >> created Cog mirrors on gitorious.. so, you shoot into the sky here. >> But i want more than that.. and why i happy to see that github proposes more >> on top, i do not really see how you can integrate that with usual >> workflow of smalltalk developer >> (means navigating/debugging living code in image). > > OK, fair enough. I had indeed forgotten about your gitorious work, and > in fact if I recall correctly you tried to pushed the VM folk into > moving from subversion to git. My apologies. > >>>> okay, lets throw away MC & stuff, migrate everything on file-based >>>> file-per-method git repository >>>> and then navigate diffs on github, and trying to find senders or >>>> implementors of selector using web browser . >>> >>> I do believe you ought to take a moment and go read the archives. >>> Also, I happen to nearly violently disagree with the file-per-method >>> approach, but that's an entirely different kettle of fish. >>> >>> But you know what, just forget it. It's not your problem, other people >>> are already solving the problem, and one day hopefully you'll forget >>> all about this while quietly your tools happily use git under the >>> hood, where you neither know nor care. >>> >> I actually don't care where files stored , in what format and what >> service it using. >> I want to make my life easier integrating those services with image, >> so i could, without switching >> contexts (like between image/web browser), do my work faster and more efficient. > > Yes, agreed. > > So if I can summarise, > > * git is not an answer for you because you don't care about the format > source is stored in. > * git is an answer for me because it immediately gives you a fantastic > user interface and hooks into just about everything. > * github is not an answer for you because it doesn't provide you with > any tools more advanced than a diff > * github is an answer for me because you can always implement your own > hooks for triggering CI, arbitrary code analysis, etc. Github's commit > API will let you give the green light or red light to any commit so > you can see at a glance how good a pull request is. > So, lets get back to the topic. Right now we have more or less same with MC + jenkins.. yes.. it may be ugly and inferior etc.. but if we compare human resources.. But see, the model right now is that to review the code, i must go to bug tracker/git (or if it is commit in some other project, go to that project repo) and manually load code from there.. and then after i loaded it into image, fun begins.. except that after review i have few choices: - send mail to author that his work sucks - say, code is fine and go back to web page, click here and there and mark it as OK.. now what i want is a tool which could help me to put a comments as i looking at code and then when i done, package that and upload where i want.. then other guy can load it into image and see my remarks.. yes, maybe it is too complicated/idealistic .. propose yours. > But of course there's nothing stopping one using github OR an-image > tools. (Or tools that produce custom images based on github commits > that run analyses and then persist somewhere so you can (a) see the > analyses immediately and (b) play around with the code. > > Mainly I think it's a mistake to reinvent tech _just because_ you > simply must work in an image. That's the core behind my moaning. (And > yes, I am working on addressing these issues, so I'm not _just_ > moaning.) > Yes, please.. but i hope you agree with me, that reviewing smalltalk code on web page or in text/diff viewer is not something you can do, if you wanna do it for real, not just looking for typos :) For doing it for real, you need an image. > frank > -- Best regards, Igor Stasenko.

March 12, 2013

[Pharo-project] new Cog VMs available

by Eliot Miranda

at http://www.mirandabanda.org/files/Cog/VM/VM.r2701/. CogVM binaries as per VMMaker.oscog-eem.272/r2701. Fix unknownBytecode processing to leave pc at unknown bytecode. Fix case of process switch to an interior frame. Fix some assert function signatures in the stack vm. Use symbols for types instead of strings in stack page funcs. Fix the become issue where methods that are identical are failing the code test because their penultimate literals are different objects. Add a flag "cmUsesPenultimateLit" to jitted methods, stealing bits from stackCheckOffset (which was way larger than needed). Shrink stackCheckOffset to 12 bits (still an order of magnitude larger than needed) and add an error check on assigning it. Also add a check for max method size (2^16-1 bytes) and refuse to jit a method that generates too much code. When comparing code, use the cmUsesPenultimateLit flag to decide if comparison includes penultimate lit or not. This is mildly insane, but the VM really doesn't know about the penultimate literal and it shouldn't depend on knowing it can be ignored. Note that the CoInterpreter knows about the last literal; it uses this in supersends. With this hack, Pharo's condenseSources works. -- best, Eliot

March 12, 2013

Re: [Pharo-project] Strange behaviour of dictionary

by Sven Van Caekenberghe

On 11 Mar 2013, at 22:40, "jannik.laval" <jannik.laval(a)gmail.com> wrote: > Hi all, > > There is something that I do not understand in Dictionary. > I am not sure this is what we want. > > The following code: > === > Dictionary new addAll: > {#a -> #b. > #c -> #d }; yourself > === > returns "a Dictionary(1->#a->#b 2->#c->#d )" > > where I would like to have "a Dictionary(#a->#b #c->#d )". > > Ok, I do > === > {#a -> #b. > #c -> #d } asDictionary > === > and it works. > > Jannik Cool, I never saw that, the #asDictionary, very handy. I often use #newFromPairs: You can also write: Dictionary newFrom: { #foo->1. #bar->2 }. For some reason, Dictionary>>#add: takes an association as argument, while Dictionary>>#addAll: takes a keyed collection. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 11, 2013

[Pharo-project] Strange behaviour of dictionary

by jannik.laval

Hi all, There is something that I do not understand in Dictionary. I am not sure this is what we want. The following code: === Dictionary new addAll: {#a -> #b. #c -> #d }; yourself === returns "a Dictionary(1->#a->#b 2->#c->#d )" where I would like to have "a Dictionary(#a->#b #c->#d )". Ok, I do === {#a -> #b. #c -> #d } asDictionary === and it works. Jannik

March 11, 2013

Re: [Pharo-project] Menu :)

by Fernando Olivero

PUAJ!!!!! Direct references to the World and its submorphs => secondary effects Not popping the menu if the items are empty => lost visual feedback etcâ¦ On Mon, Mar 11, 2013 at 9:57 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I'm sure that we can do better... > > > popUpAt: aPoint forHand: hand in: aWorld allowKeyboard: aBoolean > "Present this menu at the given point under control of the given > hand." > | evt | > aWorld submorphs > select: [ :each | (each isKindOf: MenuMorph) > and: [each stayUp not]] > thenCollect: [ :menu | menu delete]. > > self items isEmpty > ifTrue: [^ self]. > > (self submorphs > select: [:m | m isKindOf: UpdatingMenuItemMorph]) > do: [:m | m updateContents]. > self layoutItems. > "precompute width" > self > positionAt: aPoint > relativeTo: (selectedItem > ifNil: [self items first]) > inWorld: aWorld. > aWorld addMorphFront: self. > "Acquire focus for valid pop up behavior" > hand newMouseFocus: self. > aBoolean > ifTrue: [hand newKeyboardFocus: self]. > evt := hand lastEvent. > (evt isKeyboard > or: [evt isMouse > and: [evt anyButtonPressed not]]) > ifTrue: ["Select first item if button not down" > self moveSelectionDown: 1 event: evt]. > self updateColor. > self changed >

March 11, 2013

Re: [Pharo-project] Code review tools?

by Esteban A. Maringolo

I love happy endings. :)

March 11, 2013

Re: [Pharo-project] Help with MenuMorph

by stephane ducasse

The problem is that selectedValue will not work on other menuItem :) So I'm playing with something like that. setFFTSize "Set the size of the FFT used for frequency analysis." | aMenu sz on | aMenu := MenuMorph new title: ('FFT size (currently {1})' translated format:{fft n}). ((7 to: 10) collect: [:n | 2 raisedTo: n]) do: [ :r | aMenu add: r printString value: r]. sz := (aMenu invokeAt: World activeHand position in: World allowKeyboard: true) selectedValue. sz ifNil: [^ self]. on := soundInput isRecording. self stop. fft := FFT new: sz. self resetDisplay. on ifTrue: [self start]. it means that probably we should rethink the protocol between the menu and the menuItem. I do not like my code. Especially that line above. Now going to sleep in this freezing time. Stef

March 11, 2013