February 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] NetNameResolver graph of primitive senders

by Sven Van Caekenberghe

Ben, Nice work ! So the conclusion is that only #addressForName:[timeout:] is used a lot and its counterpart #nameForAddress:[timeout:] just a little bit. Right ? What was your goal in doing this analysis ? Sven > On 27 Feb 2017, at 15:40, Ben Coman <btc(a)openinworld.com> wrote: > > Following up discussion on the Catalog sometimes delaying Spotter in locations with poor network > http://forum.world.st/Catalog-loading-in-Spotter-td4934969.html#a4935842 > > Just sharing a poke I had at understanding the name resolution call chain down to the primitives. > Attached is a Roassal/Artefact generated PDF based on "methods" and "links" from this... > > methods := NetNameResolver class methods select: [:m | m selector beginsWith: 'prim']. "start with primitives" > methods := methods asSet. > prevMethods := #() asSet. > links := Set new. > 3 timesRepeat: [ > |newMethods todo| > newMethods := methods difference: prevMethods. > prevMethods := methods copy. > todo := newMethods collect: [:m| > |senders| > ((((m methodClass inheritsFrom: TestAsserter) > or: [m selector = #new]) > or: [m methodClass printString beginsWith: 'SmaCC']) > or: [m selector printString beginsWith: '#init']) > ifTrue: [m -> #()] > ifFalse: [m -> (m senders collect: [:rgmd| rgmd compiledMethod])]. > ]. > todo := todo select: [:sendersOf| sendersOf value size > 0]. "remove fluff" > todo := todo sorted: [:sendersOf1 :sendersOf2| sendersOf1 value size > sendersOf2 value size]. "helps debugging" > todo do: [:sendersOf| > sendersOf value do: [:sender| > methods add: sender. > links add: (sender->sendersOf key). > ] > ]. > ]. > methods copy do: [:m| links detect: [:l| (m = l key) or: [ m = l value] ] ifNone: [ methods remove: m]]. "remove fluff" > > > > After loading Roassal from the Catalog into 60411 > I started with Mondrian to graph like this... > > b := RTMondrian new. > b shape box. > b nodes: methods forEach: [:each| > b shape > withText: [:m| m methodClass printString, String cr, m selector printString]; > withTextColor: Color black. > b nodes: { each }. > b layout > ]. > b shape arrowedLine withShorterDistanceAttachPoint. > links do: [:l| b edges connectFrom: l value to: l key]. > b layout horizontalDominanceTree horizontalGap: 100. > b build. > b view inspect > > But I wanted to fine tune the layout by moving around a few subtrees > and couldn't work out how to add RTDraggableChildren to the Mondrian edges. > > So I tried Roassal direct like this... > v := RTView new. > v @ RTDraggableView. > labelTemplate := (RTLabel new text: [:m | m methodClass printString, String cr, m selector printString]). > > els := labelTemplate elementsOn: methods. "also see alternative below" > v addAll: els. > eb := RTEdgeBuilder new > view: v; > elements: els. > > links do: [:l| eb connectFrom: l value to: l key]. > RTHorizontalDominanceTreeLayout on: els. > els @ RTDraggableChildren. > v inspect. > > But couldn't work out how to put a border around the RTLabel, nor change its background colour. > I saw RTShape>>#fillColor: and #fillColorElement: but couldn't determine how to make use of them. > > The best I could come up with is the following alternative that replaces > the code in the middle that assigns "els" and "eb" with... > els := RTBox elementsOn: methods. > v addAll: els. > RTNest new > for: els > add: [ :group :method | > group > addAll: (labelTemplate elementsOn: {method})]. > eb := RTEdgeBuilder new > view: v; > elements: els. > > cheers -ben > <NetNameResolver-3level-primitive-senders.pdf>

Feb. 27, 2017

Re: [Pharo-dev] [squeak-dev] Re: [vwnc] Does anyone have a "new" string literal?

by H. Hirzel

On 2/27/17, DavidLeibs <david.leibs(a)gmail.com> wrote: > I realize this is a few years old but I wanted to give an update on my > quest > for quasi-literals. I did a complete quasi-literal framework for Java when > I moved over to Oracle Labs. It used the annotation compiler + a few > tweeks > to the scanner and parser. You could extend the name space of the > quasi-literal and have inline SQL or APL. All the parsing, validation, and > code rewriting happened at compile time. We proposed it to the Java Product > guys and got ignored to death. > > As to the characters I did backquote for simple quasi-literal Strings and > used Oxford Brackets for the quasi-literals with a language namespace. <| > ...|>. Back quote can be hard to see but is nice for String substitute. > > At this point in time the language that does it most right is JavaScript. > Thanks Mark Miller for all the hard work over the years! Thanks David for following up this discussion. I wonder if just going for JavaScript ES6 solution (back-ticks) would be the most straightforward thing to do? --Hannes https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Template_lit… Syntax ---------- `string text` `string text line 1 string text line 2` `string text ${expression} string text` tag `string text ${expression} string text` Description ---------------- Template literals are enclosed by the back-tick (` `) (grave accent) character instead of double or single quotes. Template literals can contain place holders. These are indicated by the Dollar sign and curly braces (${expression}). The expressions in the place holders and the text between them get passed to a function. The default function just concatenates the parts into a single string. If there is an expression preceding the template literal (tag here), the template string is called "tagged template literal". In that case, the tag expression (usually a function) gets called with the processed template literal, which you can then manipulate before outputting. To escape a back-tick in a template literal, put a backslash \ before the back-tick.

Feb. 27, 2017

Re: [Pharo-dev] [Pharo-users] Fwd: GSoC 2017: Pharo Consortium has been accepted as a mentor organization!

by Guillermo Polito

Thanks :) On Mon, Feb 27, 2017 at 7:22 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Well done! > > Le 27/02/2017 Ã 18:07, Serge Stinckwich a Ã©crit : > > Great news ! > > > > Thank you Jigyasa, Uko, Peter and Alex for your great work this year ! > > > > -- > Dr. Geo > http://drgeo.eu > > >

Feb. 27, 2017

Re: [Pharo-dev] [squeak-dev] Re: [vwnc] Does anyone have a "new" string literal?

by DavidLeibs

I realize this is a few years old but I wanted to give an update on my quest for quasi-literals. I did a complete quasi-literal framework for Java when I moved over to Oracle Labs. It used the annotation compiler + a few tweeks to the scanner and parser. You could extend the name space of the quasi-literal and have inline SQL or APL. All the parsing, validation, and code rewriting happened at compile time. We proposed it to the Java Product guys and got ignored to death. As to the characters I did backquote for simple quasi-literal Strings and used Oxford Brackets for the quasi-literals with a language namespace. <| ...|>. Back quote can be hard to see but is nice for String substitute. At this point in time the language that does it most right is JavaScript. Thanks Mark Miller for all the hard work over the years! -- View this message in context: http://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp46670… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 27, 2017

Re: [Pharo-dev] Epicea - showing latest lost changes

by Yuriy Tymchuk

Of course. For me itâs about 2 things: 1) I usually need to restore 100% of the changes, so having such button is convenient. 2) I think that newcomers will be confused if they just se a list without any hints what to do with it. Uko > On 27 Feb 2017, at 05:41, Martin Dias <tinchodias(a)gmail.com> wrote: > > > > On Fri, Feb 24, 2017 at 12:04 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > I have one more suggestion for Epicea. When the window pops up Iâd like to have a big âRESTOREâ button to reapply all the changes. I think it will be also more user friendly, as how should an newcomer know that he has to select all the items in the list and use the context menu. > > Uko, maybe it could be an "Apply all" button on top of the list of changes? > > > > Cheers. > Uko > > >> On 24 Feb 2017, at 08:33, stepharong <stepharong(a)free.fr <mailto:stepharong@free.fr>> wrote: >> >> Hi martin >> >> Thanks for our constant improvement of epicea. >> In VW they have a nice way to filter >> >> you can filter the entitiies >> doit or not >> method or not >> packages or not >> and you can deselect a selected item. >> >> this way you can say I do not want any doit except this one. >> >> >> >> On Fri, 24 Feb 2017 06:29:36 +0100, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >> >> Hi. Does this report match your idea? >> https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters <https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters> >> >> Martin >> >> On Thu, Feb 23, 2017 at 3:35 PM, stepharong <stepharong(a)free.fr <mailto:stepharong@free.fr>> wrote: >> I agree :) >> >> On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> >> One thing I am missing from Epicea that I used to be able to do >> is being able to filter out old changes. If I've been thrashing >> some method back and forth between a few implementations, >> often I don't want to see *all* the old changes,only the latest ones. >> >> An option to restore old versions would also be nice, but I don't think that feature existed previously. >> >> cheers -ben >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ <http://www.opera.com/mail/> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ <http://www.opera.com/mail/> >

Feb. 27, 2017

Re: [Pharo-dev] [Pharo-users] Fwd: GSoC 2017: Pharo Consortium has been accepted as a mentor organization!

by Tudor Girba

Congratulations. And thank you! Cheers, Doru > On Feb 27, 2017, at 6:21 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > This is great!! > We, the organizers, will discuss and make a public call. > > Alexandre > > Le 27 fÃ©vr. 2017 Ã 14:07, Serge Stinckwich <serge.stinckwich(a)gmail.com> a Ã©crit : > >> Great news ! >> >> Thank you Jigyasa, Uko, Peter and Alex for your great work this year ! >> >> >> ---------- Forwarded message ---------- >> From: Google Summer of Code <summerofcode-noreply(a)google.com> >> Date: Mon, Feb 27, 2017 at 6:00 PM >> Subject: GSoC 2017: Pharo Consortium has been accepted as a mentor organization! >> To: sergestinckwich(a)gmail.com >> >> >> >> Congratulations! Pharo Consortium has been selected as a Google Summer of Code 2017 mentor organization. >> >> You can now invite mentors and update your organization profile. >> >> Please click here to visit your dashboard: https://summerofcode.withgoogle.com/dashboard/ >> >> This email was sent to serge.stinckwich(a)gmail.com. >> >> You are receiving this email because of your participation in Google Summer of Code 2017. >> https://summerofcode.withgoogle.com >> >> To leave the program and stop receiving all emails, you can go to your profile and request deletion of your program profile. >> >> For any questions, please contact gsoc-support(a)google.com. Replies to this message go to an unmonitored mailbox. >> >> Â© 2017 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA >> >> >> >> >> -- >> Serge Stinckwich >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ -- www.tudorgirba.com www.feenk.com âThe smaller and more pervasive the hardware becomes, the more physical the software gets."

Feb. 27, 2017

Re: [Pharo-dev] [Pharo-users] Fwd: GSoC 2017: Pharo Consortium has been accepted as a mentor organization!

by Alexandre Bergel

This is great!! We, the organizers, will discuss and make a public call. Alexandre > Le 27 fÃ©vr. 2017 Ã 14:07, Serge Stinckwich <serge.stinckwich(a)gmail.com> a Ã©crit : > > Great news ! > > Thank you Jigyasa, Uko, Peter and Alex for your great work this year ! > > > ---------- Forwarded message ---------- > From: Google Summer of Code <summerofcode-noreply(a)google.com> > Date: Mon, Feb 27, 2017 at 6:00 PM > Subject: GSoC 2017: Pharo Consortium has been accepted as a mentor organization! > To: sergestinckwich(a)gmail.com > > > > Congratulations! Pharo Consortium has been selected as a Google Summer of Code 2017 mentor organization. > > You can now invite mentors and update your organization profile. > > Please click here to visit your dashboard: https://summerofcode.withgoogle.com/dashboard/ > > This email was sent to serge.stinckwich(a)gmail.com. > > You are receiving this email because of your participation in Google Summer of Code 2017. > https://summerofcode.withgoogle.com > > To leave the program and stop receiving all emails, you can go to your profile and request deletion of your program profile. > > For any questions, please contact gsoc-support(a)google.com. Replies to this message go to an unmonitored mailbox. > > Â© 2017 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA > > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/

Feb. 27, 2017

Fwd: GSoC 2017: Pharo Consortium has been accepted as a mentor organization!

by Serge Stinckwich

Great news ! Thank you Jigyasa, Uko, Peter and Alex for your great work this year ! ---------- Forwarded message ---------- From: Google Summer of Code <summerofcode-noreply(a)google.com> Date: Mon, Feb 27, 2017 at 6:00 PM Subject: GSoC 2017: Pharo Consortium has been accepted as a mentor organization! To: sergestinckwich(a)gmail.com [image: Google Summer of Code] Congratulations! Pharo Consortium has been selected as a Google Summer of Code 2017 mentor organization. You can now invite mentors and update your organization profile. Please click here to visit your dashboard: https://summerofcode. withgoogle.com/dashboard/ This email was sent to serge.stinckwich(a)gmail.com. You are receiving this email because of your participation in Google Summer of Code 2017. https://summerofcode.withgoogle.com To leave the program and stop receiving all emails, you can go to your profile <https://summerofcode.withgoogle.com/dashboard/profile/> and request deletion of your program profile. For any questions, please contact gsoc-support(a)google.com. Replies to this message go to an unmonitored mailbox. Â© 2017 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Feb. 27, 2017

REMEMBER: Tomorrow 28/02 16h UTC TechTalk: Reflectivity

by Esteban Lorenzano

Hi, It will be handled by Marcus who will present current status of Reflectivity integration. Esteban

Feb. 27, 2017

NetNameResolver graph of primitive senders

by Ben Coman

Following up discussion on the Catalog sometimes delaying Spotter in locations with poor network http://forum.world.st/Catalog-loading-in-Spotter-td4934969.html#a4935842 Just sharing a poke I had at understanding the name resolution call chain down to the primitives. Attached is a Roassal/Artefact generated PDF based on "methods" and "links" from this... methods := NetNameResolver class methods select: [:m | m selector beginsWith: 'prim']. "start with primitives" methods := methods asSet. prevMethods := #() asSet. links := Set new. 3 timesRepeat: [ |newMethods todo| newMethods := methods difference: prevMethods. prevMethods := methods copy. todo := newMethods collect: [:m| |senders| ((((m methodClass inheritsFrom: TestAsserter) or: [m selector = #new]) or: [m methodClass printString beginsWith: 'SmaCC']) or: [m selector printString beginsWith: '#init']) ifTrue: [m -> #()] ifFalse: [m -> (m senders collect: [:rgmd| rgmd compiledMethod])]. ]. todo := todo select: [:sendersOf| sendersOf value size > 0]. "remove fluff" todo := todo sorted: [:sendersOf1 :sendersOf2| sendersOf1 value size > sendersOf2 value size]. "helps debugging" todo do: [:sendersOf| sendersOf value do: [:sender| methods add: sender. links add: (sender->sendersOf key). ] ]. ]. methods copy do: [:m| links detect: [:l| (m = l key) or: [ m = l value] ] ifNone: [ methods remove: m]]. "remove fluff" After loading Roassal from the Catalog into 60411 I started with Mondrian to graph like this... b := RTMondrian new. b shape box. b nodes: methods forEach: [:each| b shape withText: [:m| m methodClass printString, String cr, m selector printString]; withTextColor: Color black. b nodes: { each }. b layout ]. b shape arrowedLine withShorterDistanceAttachPoint. links do: [:l| b edges connectFrom: l value to: l key]. b layout horizontalDominanceTree horizontalGap: 100. b build. b view inspect But I wanted to fine tune the layout by moving around a few subtrees and couldn't work out how to add RTDraggableChildren to the Mondrian edges. So I tried Roassal direct like this... v := RTView new. v @ RTDraggableView. labelTemplate := (RTLabel new text: [:m | m methodClass printString, String cr, m selector printString]). els := labelTemplate elementsOn: methods. "also see alternative below" v addAll: els. eb := RTEdgeBuilder new view: v; elements: els. links do: [:l| eb connectFrom: l value to: l key]. RTHorizontalDominanceTreeLayout on: els. els @ RTDraggableChildren. v inspect. But couldn't work out how to put a border around the RTLabel, nor change its background colour. I saw RTShape>>#fillColor: and #fillColorElement: but couldn't determine how to make use of them. The best I could come up with is the following alternative that replaces the code in the middle that assigns "els" and "eb" with... els := RTBox elementsOn: methods. v addAll: els. RTNest new for: els add: [ :group :method | group addAll: (labelTemplate elementsOn: {method})]. eb := RTEdgeBuilder new view: v; elements: els. cheers -ben

Feb. 27, 2017