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

Committed to wrong repo in sthub , any way to delete my commit ?

by kilon alios

Hi , I was working on my project Hyperion and I made a mistake. I committed my latest commit to PharoLauncher repo instead of my Hyperion repo in smalltalkhub. Is there a way to delete the commit so that my Hyperion package does not appear inside the PharoLauncher repo ? Sorry for the mistake :(

Nov. 17, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30579 Home: https://github.com/pharo-project/pharo-core

Nov. 17, 2013

[pharo-project/pharo-core] d6c0b5: 30579

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: d6c0b575a99debda79114a992d2a5fe13ed44eea https://github.com/pharo-project/pharo-core/commit/d6c0b575a99debda79114a99… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-17 (Sun, 17 Nov 2013) Changed paths: R Collections-Strings.package/ByteString.class/instance/comparing/findSubstringViaPrimitive_in_startingAt_matchTable_.st M Collections-Strings.package/ByteString.class/instance/comparing/findSubstring_in_startingAt_matchTable_.st A Collections-Strings.package/String.class/instance/comparing/findIn_startingAt_matchTable_.st A Collections-Strings.package/String.class/instance/comparing/findSubstringViaPrimitive_in_startingAt_matchTable_.st M Collections-Strings.package/String.class/instance/converting/asWideString.st A Collections-Strings.package/WideString.class/instance/comparing/findIn_startingAt_matchTable_.st A Collections-Strings.package/WideString.class/instance/converting/asWideString.st A Collections-Strings.package/WideSymbol.class/instance/comparing/findIn_startingAt_matchTable_.st A Collections-Strings.package/WideSymbol.class/instance/converting/asWideString.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script234.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30579.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30579 3634 Clean up handling of WideStrings https://pharo.fogbugz.com/f/cases/3634 http://files.pharo.org/image/30/30579.zip

Nov. 17, 2013

Re: [Pharo-dev] Efficient string concatenation - proposed new

by Sven Van Caekenberghe

On 17 Nov 2013, at 12:49, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > Well, maybe, although it's interesting to consider how many strings streams need to beat string concatenation. Moreover, streams aren't hyper efficient eitherâ¦ Yes, indeed. It also depends on what is being concatenated (constants vs objects). Quick and dirty (totally unscientific): [ 'foo', 'bar' ] bench. '4,650,000 per second.' [ '' join: #( 'foo' 'bar' ) ] bench. '814,000 per second.' [ String streamContents: [ :out | out nextPutAll: 'foo'; nextPutAll: 'bar' ] ] bench. '1,900,000 per second.' [ 'foo', 'bar', 'baz' ] bench. '2,470,000 per second.' [ '' join: #( 'foo' 'bar' 'baz' ) ] bench. '719,000 per second.' [ String streamContents: [ :out | out nextPutAll: 'foo'; nextPutAll: 'bar'; nextPutAll: 'baz' ] ] bench. '1,710,000 per second.' [ 'foo', 'bar', 'baz', 'foobar' ] bench. '2,030,000 per second.' [ '' join: #( 'foo' 'bar' 'baz' 'foobar' ) ] bench. '665,000 per second.' [ String streamContents: [ :out | out nextPutAll: 'foo'; nextPutAll: 'bar'; nextPutAll: 'baz'; nextPutAll: 'foobar' ] ] bench. '1,580,000 per second.' [ Date today asString, $- asString, Time now asString ] bench. '61,800 per second.' [ String streamContents: [ :out | out print: Date today; nextPut: $-; print: Time now ] ] bench. '71,700 per second.' Weâre only measuring execution speed, not memory allocation, which is important too. The length of the strings is a variable as well, of course. Furthermore, many #printOn: implementations are not very efficient while they should be. Conclusion, letâs be careful with a too simple advice. Sven > On 11/16/13 10:09 , btc(a)openinworld.com wrote: >> >> Code Critic rule Optimization > String concatenation instead of streams >> says: >> >> "Check for string concatenation inside some iteration message. Since >> string concatenation is O(n^2), it is better to use streaming since it >> is O(n) - assuming that n is large enough. As a general principal avoid >> , since the receiver is copied. Therefore chaining , messages will lead >> to multiple useless copies of the receiver." >> >> That is, >> String streamContents: [:s | >> #('abc' 'def' 'ghi') do: [:each | s nextPutAll: each asString]] >> >> should be used instead of... >> 'abc' , 'def' , 'ghi'. >> >> However the first clutters the code. What about something like... >> { 'abc' . 'def' . 'ghi' } asStreamString >> where >> Collection>>asStreamString >> ^ String streamContents: [:s | self do: [:each | s nextPutAll: >> each asString]] >> >> cheers -ben >> >

Nov. 17, 2013

How to draw an ellipse with Athens?

by Alexandre Bergel

Hi! In Roassal, I have the following to draw an ellipse: -=-=-=-=-=-=-=-=-=-= fillOval: aRectangle color: aColor borderWidth: aBorderWidth borderColor: aBorderColor |p rect stroke | rect := self virtualToRealRectangle: aRectangle. nativeCanvas pathTransform restoreAfter: [ p:= nativeCanvas createPath: [:path | |halfPi | halfPi := Float pi /2. path absolute; moveTo: rect topCenter; cwArcTo: rect rightCenter angle: halfPi; cwArcTo: rect bottomCenter angle: halfPi; cwArcTo: rect leftCenter angle: halfPi; cwArcTo: rect topCenter angle: halfPi]. nativeCanvas setShape: p. nativeCanvas setPaint: aColor. nativeCanvas draw. stroke := nativeCanvas setStrokePaint: aBorderColor. stroke width: aBorderWidth. nativeCanvas draw ] -=-=-=-=-=-=-=-=-=-= I feel this is not quite right. It produces something like: With the following Roassal script: -=-=-=-=-=-=-=-=-=-= | view el | view := ROView new. el := ROElement on: 'hello world'. el + ROLabel + ROEllipse. el @ RODraggable. view add: el. view open -=-=-=-=-=-=-=-=-=-= It is has if the halfPi variable does not have the right value. I have found example on the web (e.g., https://developer.gnome.org/gtkmm-tutorial/3.2/sec-cairo-drawing-arcs.html.…) However I was not able to map them in Athens. Help appreciated. This is a bug in Roassal that has been there for too long :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 17, 2013

Re: [Pharo-dev] SVG described countries in Roassal

by Alexandre Bergel

Within Roassal I need to have a svg shape that knows about a path. Currently I do not make use of Athens to draw the SVG, I simply use Athens to draw lines. Within Roassal I can define any SVG path as a shape. For example: view add: (ROSVGPath path: 'M10,10 L30,30') element Why this should not be at the level of Roassal? If I want to define a box, I would simply do view add: (ROBox new extent: 30 @ 20) element It follows the same pattern no? Alexandre On Nov 17, 2013, at 8:45 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I see that you have a loooot of fun. > Now I have the impression that in the future version you should not expose ROSVGPath and others > because there are at the importer level not Roassal. So why do you need to wrap them. > If there is something missing in SVGPath what is it? > > Stef > >> Hi! >> >> I had fun understanding how countries may be described using SVG. >> Here is a first shoot: >> >> <Screen Shot 2013-11-16 at 5.36.21 PM.png> >> >> Moving the mouse above a country name highlight the country. You can now rehearse your geography. >> >> The complete source code of this example is: >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> | view element nameComponent label | >> view := ROView new. >> >> ROSVGPath countries do: [ :k | >> element := (ROSVGPath path: (ROSVGPath perform: k)) elementOn: k. >> view add: element. >> ]. >> >> nameComponent := ROElement new. >> ROSVGPath countries do: [ :k | >> label := ROLabel elementOn: k asString. >> label @ ROLightlyHighlightable. >> label on: ROMouseEnter do: [ :event | ROBlink highlight: (view elementFromModel: event model asSymbol) ]. >> label on: ROMouseLeave do: [ :event | ROBlink unhighlight: (view elementFromModel: event model asSymbol) ]. >> nameComponent add: label. >> ]. >> ROGridLayout new >> gapSize: -3; >> lineItemsCount: 15; >> on: nameComponent elements. >> >> view add: nameComponent. >> nameComponent translateTo: 0 @ 400. >> >> view openInWindowSized: 1000 @ 700 >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 17, 2013

Re: [Pharo-dev] Spotlight discussion

by Camillo Bruni

On 2013-11-17, at 13:24, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > You need first this magic invocation > > GlobalMenuBar current > openInWorld; > beSticky. > > Then it will be in the top right corner. > Note: there is s far no hotkey to get the focus. > Note2: it is probably buggy since it has not been updated to the new Spec3 I can confirm the last part, though looks like the way to go!

Nov. 17, 2013

Re: [Pharo-dev] Spotlight discussion

by Benjamin

You need first this magic invocation GlobalMenuBar current openInWorld; beSticky. Then it will be in the top right corner. Note: there is s far no hotkey to get the focus. Note2: it is probably buggy since it has not been updated to the new Spec3 Ben On 17 Nov 2013, at 11:09, Camillo Bruni <camillobruni(a)gmail.com> wrote: > How do I activate it? I only got the old spotlight behavior :) > > On 2013-11-17, at 00:58, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> The new spotlight beta can be tested here: https://ci.inria.fr/pharo-contribution/job/New-Pharo-IDE/ >> >> It planned to answer before but I was in the plane :P >> >> Ben >> >> On 16 Nov 2013, at 18:37, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >> >>> >>> El 16-11-2013, a las 13:53, btc(a)openinworld.com escribiÃ³: >>> >>>> Juraj Kubelka wrote: >>>>> El 16-11-2013, a las 12:30, Alexandre Bergel <alexandre.bergel(a)me.com> >>>>> escribiÃ³: >>>>> >>>>> >>>>> >>>>>> I think it would be great to always have it apparent. >>>>>> >>>>>> >>>>> Could be. The advantage is developers know it is here. Disadvantage it occupy space which may most of the time is not used. >>>>> >>>>> Cheers, >>>>> Jura >>>>> >>>>> >>>> >>>> It wouldn't occupy space if it was part of the background, or always put itself to the back when finished. Other windows would just cover it. A tooltip on it could advise the shortcut for bringing it to the front. >>>> >>> >>> OK, good idea. So Shift+Enter will bring it to the front. Thanks. >>> >>> Cheers, >>> Jura >>> >>> >>>> cheers -ben >>>> >>>>> >>>>>> Using keys to select the item we want. Maybe right and left key to move implementors / senders. >>>>>> >>>>>> Alexandre >>>>>> >>>>>> >>>>>> On Nov 16, 2013, at 12:28 PM, Juraj Kubelka >>>>>> <juraj.kubelka(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi Esteban, >>>>>>> >>>>>>> StÃ©phane mentioned that you have some ideas how to improve Spotlight. I am interested to participate on it. Can we have a discussion about it? >>>>>>> >>>>>>> Thanks, >>>>>>> Jura >>>>>>> >>>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel >>>>>> http://www.bergel.eu >>>>>> >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> >

Nov. 17, 2013

Re: [Pharo-dev] [issue tracker] Please review "fix review needed" issues

by kilon alios

ok , will take a look at it and see how I may help. On Sat, Nov 16, 2013 at 8:35 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 16 Nov 2013, at 17:50, kilon alios <kilon.alios(a)gmail.com> wrote: > > A bit more details would help. For example I certainly dont mind testing > fixes and marking them as resolved. My problem is that I am not an > experienced smalltalker so I cant be sure what the expected behavior is. > > Is there a guideline, criteria , principles a fix should follow, or is it > just a matter "if it works, its ok" ? Also I was curious what happens to a > fix after its marked as resolved, how exactly the slice is integrated ? > > > That is the problemâ¦ itâs not an algorithmic decision. Itâs âDo you think > this is a good idea to do and is the implementation ok?â. > > Marcus > > > On Sat, Nov 16, 2013 at 6:32 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> So we now have an automatic system to check that a change does not break >> tests and even passes Code Critique. >> >> Nevertheless, this does *not* mean that any change that passes is good. >> (e.g. a change that just deletes all tests is fine for >> the monkey). >> >> So we *need* people to look at proposed changes! >> >> Right now I feel that I decide far too many things. It would be very nice >> to have the input of more people. >> >> Marcus >> > > >

Nov. 17, 2013

Re: [Pharo-dev] Efficient string concatenation - proposed new

by Andres Valloud

Well, maybe, although it's interesting to consider how many strings streams need to beat string concatenation. Moreover, streams aren't hyper efficient either... On 11/16/13 10:09 , btc(a)openinworld.com wrote: > > Code Critic rule Optimization > String concatenation instead of streams > says: > > "Check for string concatenation inside some iteration message. Since > string concatenation is O(n^2), it is better to use streaming since it > is O(n) - assuming that n is large enough. As a general principal avoid > , since the receiver is copied. Therefore chaining , messages will lead > to multiple useless copies of the receiver." > > That is, > String streamContents: [:s | > #('abc' 'def' 'ghi') do: [:each | s nextPutAll: each asString]] > > should be used instead of... > 'abc' , 'def' , 'ghi'. > > However the first clutters the code. What about something like... > { 'abc' . 'def' . 'ghi' } asStreamString > where > Collection>>asStreamString > ^ String streamContents: [:s | self do: [:each | s nextPutAll: > each asString]] > > cheers -ben > > >

Nov. 17, 2013