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

Re: [Pharo-project] rubric performace

by stephane ducasse

tx! On Apr 29, 2013, at 9:24 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I tried but could not :(. I tried multiple times to load the file and go around the "out of memory" limitation and then at some random point, Pharo crashed. I was on Mac when I did the experiment. If I get more info I will let you know. > > Doru > > > On Apr 29, 2013, at 8:44 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> doru can you reproduce your crash? >> Because igor asked and I did not see your answer. >> >> Stef >> >> On Apr 25, 2013, at 12:03 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> I did a little experiment to check the performance of Rubric when dealing with large content. And by large, I mean 45 MB or about 15 million lines of text. >>> >>> I opened the file in several other editors: >>> - TextMate: 10s + the text is wrapped and can be browsed smoothly >>> - Sublime Text 2: 10s + the text is wrapped and can be browsed smoothly >>> - Eclipse: 5s + browsing is very slow (so it is basically useless) >>> >>> How did Rubric perform: >>> - When opened with unwrapped lines: 33s + the text can be browsed smoothly >>> - When opened with wrapped lines -> Pharo crashed :( >>> >>> In any case, I think being 3 times slower (even if without wrapping) than TextMate is highly exciting. Great job Alain. >>> >>> If you want to reproduce the experiment, here is the Smalltalk snippet I used: >>> >>> --- >>> Gofer new >>> smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; >>> package: 'Rubric-AlainPlantec.26'; >>> load. >>> >>> [ >>> contents := ((FileSystem disk workingDirectory / 'src' / 'ArgoUML-0-34' / 'output.mse') readStreamDo: #contents). >>> (RubLipsumBasicExample >>> windowWithScrolledText: ( >>> RubLipsumBasicExample new >>> string: contents; >>> newScrolledTextNotWrapped)) >>> openInWorld >>> ] timeToRun >>> --- >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "What we can governs what we wish." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > >

April 29, 2013

Re: [Pharo-project] rubric performace

by Tudor Girba

Hi, I tried but could not :(. I tried multiple times to load the file and go around the "out of memory" limitation and then at some random point, Pharo crashed. I was on Mac when I did the experiment. If I get more info I will let you know. Doru On Apr 29, 2013, at 8:44 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > doru can you reproduce your crash? > Because igor asked and I did not see your answer. > > Stef > > On Apr 25, 2013, at 12:03 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> I did a little experiment to check the performance of Rubric when dealing with large content. And by large, I mean 45 MB or about 15 million lines of text. >> >> I opened the file in several other editors: >> - TextMate: 10s + the text is wrapped and can be browsed smoothly >> - Sublime Text 2: 10s + the text is wrapped and can be browsed smoothly >> - Eclipse: 5s + browsing is very slow (so it is basically useless) >> >> How did Rubric perform: >> - When opened with unwrapped lines: 33s + the text can be browsed smoothly >> - When opened with wrapped lines -> Pharo crashed :( >> >> In any case, I think being 3 times slower (even if without wrapping) than TextMate is highly exciting. Great job Alain. >> >> If you want to reproduce the experiment, here is the Smalltalk snippet I used: >> >> --- >> Gofer new >> smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; >> package: 'Rubric-AlainPlantec.26'; >> load. >> >> [ >> contents := ((FileSystem disk workingDirectory / 'src' / 'ArgoUML-0-34' / 'output.mse') readStreamDo: #contents). >> (RubLipsumBasicExample >> windowWithScrolledText: ( >> RubLipsumBasicExample new >> string: contents; >> newScrolledTextNotWrapped)) >> openInWorld >> ] timeToRun >> --- >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "What we can governs what we wish." >> >> >> >> > > -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

April 29, 2013

Re: [Pharo-project] State of PharoConf videos

by Christoph Wysseier

Am 29.04.13 17:41, schrieb Stephan Eggermont: > Chris wrote: >> I would like to show my talk ("Selling Pharo-based Solutions" at >> PharoConf) to my team and enhance it for the next time. Just out of >> curiosity: are you still working on those videos? Otherwise, would you >> mind to provide the video file somehow? > > Too many distractions, so not enough speed. > I'll put it up. No worries! Just asked out of curiosity... Cheers, Chris

April 29, 2013

Re: [Pharo-project] rubric performace

by stephane ducasse

doru can you reproduce your crash? Because igor asked and I did not see your answer. Stef On Apr 25, 2013, at 12:03 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I did a little experiment to check the performance of Rubric when dealing with large content. And by large, I mean 45 MB or about 15 million lines of text. > > I opened the file in several other editors: > - TextMate: 10s + the text is wrapped and can be browsed smoothly > - Sublime Text 2: 10s + the text is wrapped and can be browsed smoothly > - Eclipse: 5s + browsing is very slow (so it is basically useless) > > How did Rubric perform: > - When opened with unwrapped lines: 33s + the text can be browsed smoothly > - When opened with wrapped lines -> Pharo crashed :( > > In any case, I think being 3 times slower (even if without wrapping) than TextMate is highly exciting. Great job Alain. > > If you want to reproduce the experiment, here is the Smalltalk snippet I used: > > --- > Gofer new > smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; > package: 'Rubric-AlainPlantec.26'; > load. > > [ > contents := ((FileSystem disk workingDirectory / 'src' / 'ArgoUML-0-34' / 'output.mse') readStreamDo: #contents). > (RubLipsumBasicExample > windowWithScrolledText: ( > RubLipsumBasicExample new > string: contents; > newScrolledTextNotWrapped)) > openInWorld > ] timeToRun > --- > > Cheers, > Doru > > -- > www.tudorgirba.com > > "What we can governs what we wish." > > > >

April 29, 2013

Re: [Pharo-project] Generalizing Keymapping idea

by stephane ducasse

On Apr 29, 2013, at 9:24 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > Do you think about generalizing Keymapping idea on any event combinations (not just keyboard)? > So we can write code like > > morph on: Mouse click ctrl do: [] > morph on: $a click ctrl do: [] > morph on: Mouse move shift + $b do: [] > morph on: Gesture cicle shift + $x do: [] I like the idea but I would really like that we do not overload on:do: > I think with such approach we can remove all morph overrides like #mouseDown:, #mouseUp. And it will big cleanup of morphic code. You know how many equal methods we have for each kind of event (handlesMouseDown:, handleMouseDown:, mouseDown: , etc). > > Best regards, > Denis

April 29, 2013

[Pharo-project] Athens news :)

by StÃ©phane Ducasse

since I'm quite sure that you are happy to know that one guy is pushing Athens :) > From: Igor Stasenko <siguctua(a)gmail.com> > Subject: Re: [Lsehub-staff] [Mm10s] 2013-04-29 > Date: April 29, 2013 12:12:50 PM GMT+02:00 > To: RMoD private list <lsehub-staff(a)lists.gforge.inria.fr> > Reply-To: RMoD private list <lsehub-staff(a)lists.gforge.inria.fr> > > On 29 April 2013 07:00, <seaside(a)rmod.lille.inria.fr> wrote: >> Monday morning, time for the weekly mail meeting in 10 seconds! >> (just reply, inserting bullet points) >> >> ### Last week: >> > - implementing scene viewer in Athens. > - added bezier3 flattener > >> >> ### This week (starting 2013-04-29): >> > Athens: > - debug/fine tune bezier3 flattener > - add arc/elliptical arc tesseleration > - implement non-zero fill rule > Pharo: > - look at DateAndTime again > > -- > Best regards, > Igor Stasenko. >

April 29, 2013

Re: [Pharo-project] Spec LabelModel color

by Benjamin

You could load the latest Spec but it depends on some Morphic changes so :s Ben On Apr 29, 2013, at 4:12 PM, roberto.minelli(a)usi.ch wrote: > By the way I used a fresh Pharo 2.0 image and labels are still white :D > > Do I have to use Pharo 3.0 to have black labels? > > Cheers, > R > > On Apr 29, 2013, at 3:32 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > wrote: > >> I can't say because I never use Moose image >> >> Ben >> >> On Apr 29, 2013, at 3:07 PM, "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> wrote: >> >>> By the way.. I often use the Moose image hosted at >>> >>> http://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/artif… >>> >>> instead of the Pharo image.. And here Spec is not up to date. >>> >>> When I run the "System>Software Update" from the World menu, packages are not updated, right? >>> >>> I think it would be a nice-to-have. >>> >>> Cheers, >>> R >>> >>> >>> >>> On Apr 29, 2013, at 2:07 PM, roberto.minelli(a)usi.ch wrote: >>> >>>> Thanks for the answersâ¦ I will update to the last image ;) >>>> >>>> On Apr 29, 2013, at 1:38 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >>>> wrote: >>>> >>>>> In the latests image, it should be black :) >>>>> >>>>> Which image are you using ? >>>>> Ben >>>>> >>>>> On Apr 29, 2013, at 12:27 PM, roberto.minelli(a)usi.ch wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm building a small UI with spec and I have a problem with the LabelModel. >>>>>> >>>>>> Is there any way to change the default color (white) of the #text: in a LabelModel? >>>>>> >>>>>> Thanks, >>>>>> Roberto >>>>> >>>> >>>> >>> >>> >> > >

April 29, 2013

[Pharo-project] [update 3.0] #30074

by Marcus Denker

30074 ----- 10447 Sync Opal again with 3.0 https://pharo.fogbugz.com/f/cases/10447 10446 deprecate #parserClass https://pharo.fogbugz.com/f/cases/10446 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Regex-Tests-Core-MarcusDenke… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/System-FilePackage-MarcusDen… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/OpalCompiler-Tests-MarcusDen… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/OpalCompiler-Core-MarcusDenk… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Compiler-MarcusDenker.413

April 29, 2013

[Pharo-project] State of PharoConf videos

by Stephan Eggermont

Chris wrote: >I would like to show my talk ("Selling Pharo-based Solutions" at >PharoConf) to my team and enhance it for the next time. Just out of >curiosity: are you still working on those videos? Otherwise, would you >mind to provide the video file somehow? Too many distractions, so not enough speed. I'll put it up. Stephan

April 29, 2013

Re: [Pharo-project] Why keymap modifiers change receiver instead of return new instance?

by Igor Stasenko

On 28 April 2013 22:01, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/4/28 stephane ducasse <stephane.ducasse(a)free.fr> > >> > Hello. >> > >> > I found this: >> > >> > shortcut := $a ctrl. >> > self assert: shortcut == shortcut shift >> > >> > Why modifiers change receiver state instead of create new instance? >> >> I can understand since they modify the shortcut. >> >> > To me it is very bad unexpected behaviour. >> >> Why? >> >> > Because > > shortcut1 := $a ctrl. > shortcut2 := $a ctrl shift > > created different shortcuts. > > And it is fully unexpected that I can not refactor it to: > > shotcut2 := shortcut1 shift > > Because after that my shortcut1 become broken. > > It was happen in TxTextMorph where selection and movement shortcuts > created at same time > > TxTextMorph>>moveEditorOn: aShortcut by: aSelector > > self on: aShortcut do: [ > self moveEditorBy: aSelector withSelection: false ]. > self on: selectionModeModifier + aShortcut do: [ > self moveEditorBy: aSelector withSelection: true]. > Wow, that's beatiful piece of code! This is how it should look like: clear and understandable from a first sight. So, we should fix the shortcuts api to let this beauty live :) > > To fix it I add deep copy of given shortcut before modifier operation. > > > >> > There is another example: >> > >> > shortcut := $a ctrl. >> > self assert: shortcut == (KMModifier shift + shortcut) >> > >> > Yes. Such operation modified argument of message #+. What the crapp! >> Why it not returns new instance? >> > >> > I hope you agree to change this behaviour >> > >> > >> >> >> > -- Best regards, Igor Stasenko.

April 29, 2013