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

[pharo-project/pharo-core]

by GitHub

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

Feb. 28, 2017

[pharo-project/pharo-core] cf01ef: 60415

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: cf01ef14fd52d7b674eba24651c1e62ab1f388a3 https://github.com/pharo-project/pharo-core/commit/cf01ef14fd52d7b674eba246… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-28 (Tue, 28 Feb 2017) Changed paths: A Collections-Abstract.package/Collection.class/class/instance creation/empty.st M Collections-Abstract.package/Collection.class/class/instance creation/with_.st A Collections-Abstract.package/HashedCollection.class/class/instance creation/empty.st M Collections-Abstract.package/HashedCollection.class/class/instance creation/new.st A Collections-Tests.package/HashTableSizesTest.class/README.md A Collections-Tests.package/HashTableSizesTest.class/definition.st A Collections-Tests.package/HashTableSizesTest.class/instance/tests/testAtLeast.st M Collections-Unordered.package/HashTableSizes.class/README.md A Collections-Unordered.package/HashTableSizes.class/class/class initialization/initialize.st R Collections-Unordered.package/HashTableSizes.class/class/initialize-release/initialize.st A Collections-Unordered.package/HashTableSizes.class/class/private/basicAtLeast_.st A Collections-Unordered.package/HashTableSizes.class/class/private/maxSmallSize.st M Collections-Unordered.package/HashTableSizes.class/class/private/sizes.st A Collections-Unordered.package/HashTableSizes.class/class/private/smallSizesLookupTable.st M Collections-Unordered.package/HashTableSizes.class/class/public/atLeast_.st R Collections-Unordered.package/Set.class/class/instance creation/new.st M Collections-Unordered.package/Set.class/class/instance creation/newFrom_.st M Debugger-Tests.package/DebuggerModelTest.class/instance/tests/testStepInto.st M Morphic-Widgets-Tabs.package/TabManagerMorph.class/instance/private-actions/tabRefreshed_.st M Morphic-Widgets-Tabs.package/TabManagerMorph.class/instance/private-contents/addLastTabContents_among_delta_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60414.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60415.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60414.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60415.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Identification.package/GlobalIdentifierPersistence.class/instance/configuration/defaultPreferences.st Log Message: ----------- 60415 19763 TabManagerMorph do not respect multipleContents mode when tabs are built in background https://pharo.fogbugz.com/f/cases/19763 19762 Optimize small Dictionary and Set creation https://pharo.fogbugz.com/f/cases/19762 19459 add #empty instance creation method https://pharo.fogbugz.com/f/cases/19459 19502 Starting Pharo creates a .ston file in appdata directory https://pharo.fogbugz.com/f/cases/19502 http://files.pharo.org/image/60/60415.zip

Feb. 28, 2017

Re: [Pharo-dev] How to listen for windows messages?

by Torsten Bergmann

Hi, I guess what you want to achieve will not be an easy task for you if you are new to programming. But it is always good to have a goal and if you have time to learn I'm pretty sure you will master it. Even when OS-Windows inspire you for automizing tasks in other Windows processes (like autoit) you should not start with my OS-Windows project directly as contributing to it requires knowledge on your side on Smalltalk as well as Win32 C programming. First start with learning Smalltalk and Pharo - http://files.pharo.org/books/ - http://pharo.pharocloud.com/pharobooks - http://stephane.ducasse.free.fr/FreeBooks.html After having an idea about Smalltalk and Pharo you should try to learn UFFI which is Pharos unified foreign function interface and ability to call C DLL's. https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… Sideways start learning about the Win32 API and C as this helps to better understand how things are done on the Windows side. There are many, many tutorials out there. Try to call or wrap some simple DLL functions on you own first. There is a nice and tiny C compiler if you want to try out some C samples http://www.pellesc.de/index.php?page=download&lang=en With this initial knowledge you can try to understand why and how OS-Windows was done. I wrote many tests - just add a breakpoint and run them to debug through the code to understand. Google for the API descriptions of the Win32 functions that are called to get an understanding how Pharo and C get connected. Also check how you work with callbacks in UFFI (as this would be required for a hook). If you are then still interested in interception windows messages you should start reading here https://msdn.microsoft.com/en-us/library/windows/desktop/ms632589(v=vs.85).… Primarily one has to wrap SetWindowsHookEx API function and friends and wrap a good API for them in Pharo. Hope that helps to get started. Regards Torsten > Gesendet: Dienstag, 28. Februar 2017 um 06:04 Uhr > Von: lw1990 <lukewallace1990(a)gmail.com> > An: pharo-dev(a)lists.pharo.org > Betreff: [Pharo-dev] How to listen for windows messages? > > In the OS-Windows package, there exists the ability to use the windows api in > Pharo. > This is very powerful, and I intend to add more of the windows api into it > (it's only partially implemented). > > This appears to all have been done with DllCalls (FFI calls) so far. > > A big part of interacting with windows is listening to/intercepting and > responding to windows messages. > For example, every time a user presses a key on the keyboard, a windows > message will happen in the background for that key. If Pharo was aware of > these messages, then Pharo could do things in response to hotkeys pressed on > Windows (outside of a pharo window). > > It would also make reacting to events potentially nicer. Like making a > windows-desktop-manager in Pharo that can tell when a new window is created > by windows (maybe they opened notepad). It would certainly be better than an > infinite loop or timer of 'get active window and compare to last active > window and see if it changed'. Instead it would be 'when receive the > WM_MESSAGE for new window created, notify Pharo so it can react'. > > How can I set up a windows message hook in Pharo? > Please keep in mind I'm very new to programming, but I work from home and > have lots of time to learn :-) > > > > -- > View this message in context: http://forum.world.st/How-to-listen-for-windows-messages-tp4936285.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Feb. 28, 2017

How to listen for windows messages?

by lw1990

In the OS-Windows package, there exists the ability to use the windows api in Pharo. This is very powerful, and I intend to add more of the windows api into it (it's only partially implemented). This appears to all have been done with DllCalls (FFI calls) so far. A big part of interacting with windows is listening to/intercepting and responding to windows messages. For example, every time a user presses a key on the keyboard, a windows message will happen in the background for that key. If Pharo was aware of these messages, then Pharo could do things in response to hotkeys pressed on Windows (outside of a pharo window). It would also make reacting to events potentially nicer. Like making a windows-desktop-manager in Pharo that can tell when a new window is created by windows (maybe they opened notepad). It would certainly be better than an infinite loop or timer of 'get active window and compare to last active window and see if it changed'. Instead it would be 'when receive the WM_MESSAGE for new window created, notify Pharo so it can react'. How can I set up a windows message hook in Pharo? Please keep in mind I'm very new to programming, but I work from home and have lots of time to learn :-) -- View this message in context: http://forum.world.st/How-to-listen-for-windows-messages-tp4936285.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 28, 2017

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

by Ben Coman

The over-arching goal is to udnerstand and maybe fix this timeout issue. I first jumped straight to reviewing sqUnixSocket.c but at 2250 lines it wasn't clear where to start. Then I noticed the following primitives were not called from the Image... primGetAddressInfoFamily primGetAddressInfoNext primGetNameInfoServiceSize primGetAddressInfoSize primGetAddressInfoHost:service:flags:family:type:protocol: primGetNameInfoHostResult: primGetNameInfoServiceResult: primGetAddressInfoResult: primGetAddressInfoType primGetNameInfoHostSize primGetAddressInfoProtocol and just wanted to get a better feel for how things fit together. For example... primNameResolverError is called by resolverError but this has no senders in the Image. Now btw, was it Linux images that were locking up? And/or other platforms? cheers -ben On Tue, Feb 28, 2017 at 3:18 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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. 28, 2017

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

by Martin Dias

Uko: OK, added it as: https://pharo.fogbugz.com/f/cases/19768/Epicea-Lost- Changes-Detector-Add-Apply-all-button-on-top-of-the-list-of-change Stef: I see... each line should have a checkbox. I remember to see in Spec's FastTableModel a method to enable that... I will try. Ben: I think that's not necessary because the EpLostChangesDetector already opens a browser where only the "lost changes" are visible. Where "lost changes" means everything logged by Epicea after last Image Save. About selection, I like it but in the past I had problems to programatically select items in Spec wodget (a TreeModel) so don't have too much expectatives for now... Maybe as checkboxes as Stef said. MartÃn On Mon, Feb 27, 2017 at 2:42 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > 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> > 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> 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> >> wrote: >> >> Hi. Does this report match your idea? >> https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters >> >> Martin >> >> On Thu, Feb 23, 2017 at 3:35 PM, stepharong <stepharong(a)free.fr> wrote: >> >>> I agree :) >>> >>> On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman <btc(a)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/ >>> >> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> >> >> > >

Feb. 27, 2017

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

by Eliot Miranda

Hi Hannes, On Mon, Feb 27, 2017 at 10:58 AM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > 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? > I did a quick hack in Squeak but didn't have time to finish is. I wrote some tests. Complex cases worked, small tricky cases broke the scanner. MCHttpRepository location: 'http://source.squeak.org/inbox' user: '' password: '' Compiler.quasiliteral-eem.280 [Derived from Compiler-nice.279, and renamed from the bogusly named Compiler.quasiquote-eem.248] Add a quasi-literal form for "string interpolation", that allows convenient embedding of expressions within a format string, and provides a convenient way of embedding literal strings within an alternative literal string syntax whose string delimiter is different. e.g. `hello [#cruel] world!` evaluates to 'hello cruel world'. `S1[B1]...SN[BN]SN+1` is equivalent to { 'S1'. [B1] value. ... 'SN'. [BN] value. 'SN+1' } concatenateQuasiLiteral where concatenateQuasiLiteral sends asString to each element and answers the concatenation of those elements. however, single-statement blocks are inlined, so e.g. the above `hello [#cruel] world!` is compiled as { 'hello '. #cruel. ' world!' } concatenateQuasiLiteral See e.g. Tests.quasiliteral-eem.296 for tests and examples. Tests.quasiliteral-eem.296 Renamed from the bogus quasiquote to quasiliteral. Added Balazs' errors as failing tests. > --Hannes > > > https://developer.mozilla.org/en/docs/Web/JavaScript/ > Reference/Template_literals > > 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. > > -- _,,,^..^,,,_ best, Eliot

Feb. 27, 2017

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

by Stephane Ducasse

Thanks Ben. I would love that we can address this timeout. It is ruining first contact with Pharo. And this year the university set up here was even worse. Stef. On Mon, Feb 27, 2017 at 8:18 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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] [Pharo-users] Fwd: GSoC 2017: Pharo Consortium has been accepted as a mentor organization!

by Serge Stinckwich

On Mon, Feb 27, 2017 at 8:19 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Congratulations! > > p.s. I think my name was there from last year (I didn't have time for this this year), so if you encounter it anywhere, feel free to remove it. BTW, I add you name, because you help a lot last year :-) -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Feb. 27, 2017

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

by Peter Uhnak

Congratulations! p.s. I think my name was there from last year (I didn't have time for this this year), so if you encounter it anywhere, feel free to remove it. Peter On Mon, Feb 27, 2017 at 06:07:18PM +0100, Serge Stinckwich wrote: > 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