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

Re: [Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient

by Frank Shearar

On 26 February 2013 20:48, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2013/2/26 Frank Shearar <frank.shearar(a)gmail.com>: >> On 26 February 2013 20:07, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>> There is no magic if as a programmer we do not define the dependencies we cannot do anything. ;) >>> so we should define configurationOf and we will take real advantages of them. > >> Nowadays with CI and all sorts of stuff we're (Pharo _and_ Squeak, I >> mean) in a much better place. There's still the modularity aspect to >> worry about in the general case, but CI can still help out a bit >> there, flushing out incompatible monkey patches. > > But the thing still is how to manage the dependencies without screwing > the whole image. > And so far, as Stephane said, the ConfigurationOf* is the only "safe" > (and viable?) way to do it. > > Dependency management is not a simple problem, but succeeding at it > would be a key differentiator. I know. You're right. I'm not saying anything different. Well, except for the differentiator part. The problem's pretty much solved in quite a few other languages. (Clojars can do this: https://clojars.org/cloverage. Rubygems doesn't, but it could, thanks to bundler.) SqueakMap's sole purpose is this: how do you FIND the ConfigurationOf? How do you know who to contact? What's the thing for, in the first place? And I'd argue that ss3 is not that catalog. (And that's before we talk about availability of services.) frank

Feb. 26, 2013

Re: [Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient

by Frank Shearar

On 26 February 2013 20:55, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> >> Oh, did you mean to type "you had no idea IF the package would load"? > > and work. > >> OK, sure, but that's not really SM's fault, that's just the way things >> were. >> >> Nowadays with CI and all sorts of stuff we're (Pharo _and_ Squeak, I >> mean) in a much better place. There's still the modularity aspect to >> worry about in the general case, but CI can still help out a bit >> there, flushing out incompatible monkey patches. > > If you want to use SqueakMap go ahead. I have been there and now I know > what I want for Pharo. I never know what you mean when you say things like this. What is it that you want for Pharo? > Stef > >

Feb. 26, 2013

Re: [Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient

by stephane ducasse

> > Oh, did you mean to type "you had no idea IF the package would load"? and work. > OK, sure, but that's not really SM's fault, that's just the way things > were. > > Nowadays with CI and all sorts of stuff we're (Pharo _and_ Squeak, I > mean) in a much better place. There's still the modularity aspect to > worry about in the general case, but CI can still help out a bit > there, flushing out incompatible monkey patches. If you want to use SqueakMap go ahead. I have been there and now I know what I want for Pharo. Stef

Feb. 26, 2013

Re: [Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient

by Esteban A. Maringolo

2013/2/26 Frank Shearar <frank.shearar(a)gmail.com>: > On 26 February 2013 20:07, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> There is no magic if as a programmer we do not define the dependencies we cannot do anything. ;) >> so we should define configurationOf and we will take real advantages of them. > Nowadays with CI and all sorts of stuff we're (Pharo _and_ Squeak, I > mean) in a much better place. There's still the modularity aspect to > worry about in the general case, but CI can still help out a bit > there, flushing out incompatible monkey patches. But the thing still is how to manage the dependencies without screwing the whole image. And so far, as Stephane said, the ConfigurationOf* is the only "safe" (and viable?) way to do it. Dependency management is not a simple problem, but succeeding at it would be a key differentiator. Regards,

Feb. 26, 2013

Re: [Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient

by Frank Shearar

On 26 February 2013 20:07, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > There is no magic if as a programmer we do not define the dependencies we cannot do anything. ;) > so we should define configurationOf and we will take real advantages of them. > > Now if you read the vision document you will see what we want: > > we want a distribution that will be filled up automatically by executing configurations that are published > in an inbox and validated (tests run, SmallLint rules run). > > Then we will be able to have a one click install of projects that are certified to load in a given image. > > Stef > PS: SqueakMap failed because you had no idea is the package would load in your image. > Believe me I know why I want the distribution infrastructure. Oh, did you mean to type "you had no idea IF the package would load"? OK, sure, but that's not really SM's fault, that's just the way things were. Nowadays with CI and all sorts of stuff we're (Pharo _and_ Squeak, I mean) in a much better place. There's still the modularity aspect to worry about in the general case, but CI can still help out a bit there, flushing out incompatible monkey patches. frank > On Feb 26, 2013, at 7:33 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> 2013/2/26 Marcus Denker <marcus.denker(a)inria.fr>: >>> On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: >> >>>> If you count the number of packages in SmalltalkHub and compare them >>>> to the ones in Npmjs.org, it is impressive how much we have. >>> But isn't "package" more like "repository" on smalltalkhub? >> >> It is a Project, but on the explore screen it says Packages, so... who knows? :) >> >> But it is true that GitHub is to SmalltakHub what npm/gem is to...? >> >>>> Of course NPM's user base is two orders of magnitude greater, but we >>>> need to start having more killer app "modules", and some sort of >>>> guideline for those starting with Pharo and/or Smalltalk. >>> And we need a system in the first place like thatâ¦ smalltalkhub is more for code >>> repositories, not in itself a repository of installable entities. >> >> Yes, having packages as "artifacts" is more straightforward than the >> configurations and all that jazz. >> >> The MetaRepo is going in that direction, but I still think that >> evaluating the install statements with Gofer or anything similar in a >> Workspace is somehow alien for a non smalltalker. >> >> There should be something that wraps Gofer and works like the apt, npm >> or gem commands. >> >>> So there is a lot of work aheadâ¦ but we will get there. >> >> No doubts of that. >> >> >> Regards! >> > >

Feb. 26, 2013

Re: [Pharo-project] BalloonCanvas>>drawPolygon

by Hilaire Fernandes

Le 26/02/2013 21:03, stephane ducasse a Ã©crit : > good idea! You may also want something like forum.pharo.org or lists.pharo.org, so users can easily get to where they want. For Dr. Geo I have many like bug.drgeo.eu, bugs.drgeo.eu, forum.drgeo.eu, translate.drgeo.eu,... > create a bug entry so that we do not forget Already done :)

Feb. 26, 2013

Re: [Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient

by stephane ducasse

There is no magic if as a programmer we do not define the dependencies we cannot do anything. ;) so we should define configurationOf and we will take real advantages of them. Now if you read the vision document you will see what we want: we want a distribution that will be filled up automatically by executing configurations that are published in an inbox and validated (tests run, SmallLint rules run). Then we will be able to have a one click install of projects that are certified to load in a given image. Stef PS: SqueakMap failed because you had no idea is the package would load in your image. Believe me I know why I want the distribution infrastructure. On Feb 26, 2013, at 7:33 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2013/2/26 Marcus Denker <marcus.denker(a)inria.fr>: >> On Feb 26, 2013, at 5:33 PM, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > >>> If you count the number of packages in SmalltalkHub and compare them >>> to the ones in Npmjs.org, it is impressive how much we have. >> But isn't "package" more like "repository" on smalltalkhub? > > It is a Project, but on the explore screen it says Packages, so... who knows? :) > > But it is true that GitHub is to SmalltakHub what npm/gem is to...? > >>> Of course NPM's user base is two orders of magnitude greater, but we >>> need to start having more killer app "modules", and some sort of >>> guideline for those starting with Pharo and/or Smalltalk. >> And we need a system in the first place like thatâ¦ smalltalkhub is more for code >> repositories, not in itself a repository of installable entities. > > Yes, having packages as "artifacts" is more straightforward than the > configurations and all that jazz. > > The MetaRepo is going in that direction, but I still think that > evaluating the install statements with Gofer or anything similar in a > Workspace is somehow alien for a non smalltalker. > > There should be something that wraps Gofer and works like the apt, npm > or gem commands. > >> So there is a lot of work aheadâ¦ but we will get there. > > No doubts of that. > > > Regards! >

Feb. 26, 2013

Re: [Pharo-project] BalloonCanvas>>drawPolygon

by stephane ducasse

good idea! create a bug entry so that we do not forget On Feb 26, 2013, at 8:59 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Le 26/02/2013 16:43, stephane ducasse a Ã©crit : >> can you open a bug entry on the pharo bug tracker? so that we can have a look. > > Done. > > Btw, a redirection http://bug[s].pharo.org will be very handy. > > Hilaire > >

Feb. 26, 2013

Re: [Pharo-project] BalloonCanvas>>drawPolygon

by Hilaire Fernandes

Le 26/02/2013 16:43, stephane ducasse a Ã©crit : > can you open a bug entry on the pharo bug tracker? so that we can have a look. Done. Btw, a redirection http://bug[s].pharo.org will be very handy. Hilaire

Feb. 26, 2013

[Pharo-project] Call for papers for Dyla'13: 7th Workshop on Dynamic Languages and Applications @ ECOOP

by Alexandre Bergel

Dyla'13, 7th Workshop on Dynamic Languages and Applications Colocated with ECOOP, ECMFA and ECSA 1â5 July, Montpellier, France http://rmod.lille.inria.fr/web/pier/Events/Dyla13 !! Important dates - Submission deadline: April 19th - Notification: mid-May - Workshop: July 1st - Ecoop early registration: mid-May !! Abstract The advent of Java and C# has been a major breakthrough in the adoption of some important object-oriented language characteristics. This breakthrough turned academic features like interfaces, garbage collection, and meta-programming into technologies generally accepted by industry. Nevertheless, the massive adoption of these languages now also gives rise to a growing awareness of their limitations. A number of reactions from industry testify this: invokedynamic bytecode instruction has been included in latest Java virtual machine release; the dynamic language runtime (DLR) is gaining popularity; C# adopted dynamic as a valid static type. Gartner prognoses further growth (http://blogs.gartner.com/mark_driver/2008/12/10) of dynamic languages. Researchers and practitioners struggle with static type systems, overly complex abstract grammars, simplistic concurrency mechanisms, limited reflection capabilities, and the absence of higher-order language constructs such as delegation, closures and continuations. Dynamic languages such as Ruby, Python, JavaScript and Lua are a step forward in addressing these problems while getting more and more popular. Making these languages mainstream requires practitioners to look back and pick mechanisms up in existing dynamic languages such as Lisp, Scheme, Smalltalk and Self. Practitioners also need to further explore discover new dynamic approaches in the context of new challenging fields such as pervasive computing. The goal of this workshop is to act as a forum where practitioners can discuss new advances in the design, implementation and application of dynamically typed languages that, sometimes radically, diverge from the statically typed class-based mainstream. Another objective is to discuss new as well as older "forgotten" languages and features in this context. Topics of interest include, but are not limited to: - programming language extensions - programming environment extensions - executing environments - static and dynamic analyses - optional type-checking - meta-object protocols - reserve engineering - domain-specific languages/tooling - testing environments - live programming !! Targeted audience The expected audience of this workshop is practitioners and researchers sharing the same interest in dynamically typed languages. Lua, Python, Ruby, Scheme and Smalltalk are gaining a significant popularity both in industry and academia. Nevertheless, each community has the tendency to only look at what it produces. Broadening the scope of each community is the goal of the workshop. To achieve this goal we will form a PC with leading persons from all languages mentioned above, fostering participation from all targeted communities. !! Workshop Format and Submission Information The workshop will have a demo-oriented style. The idea is to allow participants to demonstrate new and interesting features and discuss what they feel is relevant for the dynamic-language community. To participate to the workshop, you can either - submit (before __April 19th 2013__) an article (ACM Tighter Alternate style http://www.acm.org/sigs/publications/proceedings-templates) describing your presentation and/or tool. Articles whose length ranges from 2 to 15 pages will be carefully reviewed by a program committee including but not limited to the organizers. Each accepted paper will be presented for 20 to 30 minutes and be published to the ACM Digital Library (at the option of each author) and the workshop's web site. The submission website is http://www.easychair.org/conferences/?conf=dyla2013. - or give a 10-minute lightning demo of your work. A dedicated session will be allocated for this, provided there is ample time available. A session on pair programming is also planned. People will then get a chance to share their technologies by interacting with other participants. !! Program committee - Carl Friedrich Bolz, Heinrich-Heine-UniversitÃ¤t DÃ¼sseldorf, Germany (http://cfbolz.de) - Camillo Bruni, Inria Lille-Nord Europe, France (http://rmod.lille.inria.fr/web/pier/team/bruni) - Adrian Kuhn, University of British Columbia, Canada (https://www.cs.ubc.ca/people/adrian-kuhn) - Lukas Renggli, Google, Switzerland (http://www.lukas-renggli.ch/) - Juan Pablo Sandoval Alcocer, University of Chile (http://users.dcc.uchile.cl/~jsandova/) - Bastian Steinert, Hasso-Plattner-Institute, Germany (http://www.bastiansteinert.org) - Veronica Uquillas Gomez, Vrije Universiteit Brussel, Belgium (http://soft.vub.ac.be/~vuquilla/) - Simon Urli, University of Nice-Sophia Antipolis, France (http://www.simonurli.fr/) - Didier Verna, EPITA Research and Development Laboratory, France (http://www.lrde.epita.fr/~didier) - the 4 workshop organizers !! Workshop Organizers - Alexandre Bergel (http://bergel.eu) - Damien Cassou (http://damiencassou.seasidehosting.st) - Jorge Ressia (http://www.jorgeressia.com) - Serge Stinckwich (http://www.doesnotunderstand.org) !! News feed Follow us on twitter: http://twitter.com/dyla2013 For further information: http://rmod.lille.inria.fr/web/pier/Events/Dyla13 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 26, 2013