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

Re: [Pharo-dev] ||

by Thierry Goubier

2015-02-07 18:48 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Hernan, > > On Sat, Feb 7, 2015 at 7:41 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> >> 2015-02-07 5:59 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: >> >>> Personally I don't like Pragmas, they have not convinced me so far that >>> they fit the style of Smalltalk syntax. I have to confess though I never >>> liked descriptive elements and languages . >>> >>> >> Me neither. Actually the pragma idea is not wrong per se, it is the tag >> syntax to write them which bothers me. Because the world can be described >> with tags if you start that path. >> > > How exactly is the syntax wrong? > The <literalMessagePattern> syntax predates pragmas. It was used first > for numeric primitives in Smalltalk-76 or Smalltalk-80. Squeak extended it > with primitive:module:. I and others extended it to include arbitrary > literal message patterns. The syntax of a literal message pattern is the > syntax of a send with no receiver and only literal arguments. The use of > this syntax means > a) no new syntax > b) each pragma is potentially executable > c) methods using specific pragmas can be found using "find senders" > d) the execution side of a pragma can be found using "find implementors" > > So what's wrong with that? How is it wrong to use a common Smalltalk > object, a Message, that is well-supported in the system, for method > metadata? > The point was: descriptive and the world could be described by tags :) Message syntax for pragmas is just a consequence of the original primitive syntax, nothing else (I.e. natural syntax extension). Given how it is used and that the "potentially executable" is just that, potential, array literals would work just as well (and I'm nearly sure that a todays design for pragmas would give us something like STON content :)) > > > >> There are other ways to add metadata to methods. Without tagging. >> > > Haven't we discussed that? Putting metadata off to the side introduces a > bookkeeping problem. It is a bad idea. > And pragmas only partially address that. Imagine that Sista works, that it has dozens of tuning points for a method (int, no recurse, vect, is a reduce, openCL, thread-safe, hot point, this loop should be enrolled) do you imagine writing all that into the method to guide Sista with pragmas? You'll end up in exactly the same situation as OpenMP 4, where it is possible to write programs with more #pragma lines than C/C++ code. (And C #pragmas are clearly more powerfull than Smalltalk's, since they are not required to be at the start of the function only) > > >> And they don't need to be in the method pane itself. >> > > For some kinds of metadata, for metadata with semantics, not just a > documentary function, it is important for the metadata to be obvious. No > one has argued for hiding the primitive specification off-to-the-side. > "Need" is a poor criticism here because using turing equivalence lots of > things don't "need" to be the way they are. Instead why not ask what are > the pros and cons? > > > >> It is like having to specify protocol because there is no list pane to >> create them. >> > > I disagree. When the pragma is specifying type information, specifying > that the method is an action on a specific menu, is a pane in an inspector, > and many other uses, it is essential that that information be represented, > and putting it in a one-off bookkeeping system is a bad idea. We're not > talking about simple documentary metadata like author, category etc. We're > using pragmas for semantics, semantics of the method that are outside of > its execution semantics, semantics about how the method fits in the broader > system. And putting that in non-obvious places is a bad idea. > Good, you're giving my favorite examples for what pragmas are redundant :) The method with the menu pragma is named "worldMenuCommand" ... The method with the gtInspector pragma is named "gtInspectorPresentation..." Additionally, as I told you before: the pragma semantic isn't in the method... It's somewhere else in the system and senders of that pragma doesn't get it. Just have a look at OmniBrowser and tell me that you don't understand where the menu commands are :) Thierry

Feb. 7, 2015

Re: [Pharo-dev] ||

by kilon alios

"Kilon, pragmas are not limited to being descriptive." Ok , I went back and carefully read your posts. I did not noticed that pragmas are executable too, I stand corrected. It appears I underestimated Pragmas, after reading your posts I see where you going with this. Especially the part of adding methods to objects like menu entries definitely makes some sense. The more I think how I would do this, the more I start to appreciate pragmas. For example I would attach some variables to Object class to create a dictionary that will manage meta data for each method. That would move the definition of the method meta data outside the method definition itself but I am not sure if that is such a good thing afterall. I think I will let myself get a few years more experience in Pharo to make up my mind and fully appreciate pragmas.

Feb. 7, 2015

Re: [Pharo-dev] Pharo 4 & NeoCSV

by Sven Van Caekenberghe

> On 07 Feb 2015, at 17:21, stepharo <stepharo(a)free.fr> wrote: > > sven I'm adding a menu to the configuration browser to define the corresponding repo in MC because I'm tired to add repo manually. OK. I always just load a random small thing to get the repo defined ;-) > Stef > > Le 7/2/15 14:19, Sven Van Caekenberghe a Ã©crit : >> Hi Andreas, >> >> I added it. >> >> Sven >> >>> On 07 Feb 2015, at 13:59, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: >>> >>> I miss the configuration of NeoCSV in the configuration browser of Pharo 4. Is there any reason for the lack of it? >>> NeoJSON is available, thoughâ¦ >>> >>> Regards >>> Andreas >> >> > >

Feb. 7, 2015

Re: [Pharo-dev] ||

by Eliot Miranda

Hi Hernan, On Sat, Feb 7, 2015 at 7:41 AM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > > 2015-02-07 5:59 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > >> Personally I don't like Pragmas, they have not convinced me so far that >> they fit the style of Smalltalk syntax. I have to confess though I never >> liked descriptive elements and languages . >> >> > Me neither. Actually the pragma idea is not wrong per se, it is the tag > syntax to write them which bothers me. Because the world can be described > with tags if you start that path. > How exactly is the syntax wrong? The <literalMessagePattern> syntax predates pragmas. It was used first for numeric primitives in Smalltalk-76 or Smalltalk-80. Squeak extended it with primitive:module:. I and others extended it to include arbitrary literal message patterns. The syntax of a literal message pattern is the syntax of a send with no receiver and only literal arguments. The use of this syntax means a) no new syntax b) each pragma is potentially executable c) methods using specific pragmas can be found using "find senders" d) the execution side of a pragma can be found using "find implementors" So what's wrong with that? How is it wrong to use a common Smalltalk object, a Message, that is well-supported in the system, for method metadata? > There are other ways to add metadata to methods. Without tagging. > Haven't we discussed that? Putting metadata off to the side introduces a bookkeeping problem. It is a bad idea. > And they don't need to be in the method pane itself. > For some kinds of metadata, for metadata with semantics, not just a documentary function, it is important for the metadata to be obvious. No one has argued for hiding the primitive specification off-to-the-side. "Need" is a poor criticism here because using turing equivalence lots of things don't "need" to be the way they are. Instead why not ask what are the pros and cons? > It is like having to specify protocol because there is no list pane to > create them. > I disagree. When the pragma is specifying type information, specifying that the method is an action on a specific menu, is a pane in an inspector, and many other uses, it is essential that that information be represented, and putting it in a one-off bookkeeping system is a bad idea. We're not talking about simple documentary metadata like author, category etc. We're using pragmas for semantics, semantics of the method that are outside of its execution semantics, semantics about how the method fits in the broader system. And putting that in non-obvious places is a bad idea. > > HernÃ¡n > >> >> About python decorators I disagree that are similar to pragmas. Pragmas >> are focused on being descriptive , python decorators are descriptive as by >> product. The main focus of python decorators is to shorten code by >> introducing syntactic sugar. >> > Kilon, pragmas are not limited to being descriptive. > >> I agree though this is a very interesting discussion and I dont >> understand most of the things stated here so I leave an open door and mind >> for pragmas. Maybe one day I will "get it". >> > That would be nice :) > > > > > >> >> On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> >>> >>> 2015-02-06 22:00 GMT+01:00 stepharo <stepharo(a)free.fr>: >>> >>>> Really interesting discussion. I like pragmas but this is interesting >>>> to see them challenged. >>>> >>> >>> Thanks. It's a pleasure to discuss that way :) >>> >>> >>>> Yes, but there end up being lots of naming conventions and they are >>>>> non-obvious. Whereas pragmas, because they are in-your-face in the methods >>>>> in question, don't need conventions. They just need documenting ;-). >>>>> >>>> Thierry I'm skeptical that multiple protocol will save the problem >>>> because you will rely on coding conventions. >>>> >>> >>> Pragma as well: just explain the conventions behind the gtInspector >>> pragmas, for example. >>> >>> But give me multiple protocols and I'll show you the same conventions >>> rewritten in less lines (and a slightly more efficient code). >>> >>> >>>> And pragma is a clever tagging. >>>> >>> >>> Then maybe we should remove protocols and replace them with pragmas :) >>> >>> Thierry >>> >>> >>>> >>>> Stef >>>> >>>> >>>> >>> >> > -- best, Eliot

Feb. 7, 2015

Re: [Pharo-dev] [Slots] Invisible Slots

by Marcus Denker

> On 07 Feb 2015, at 18:29, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > On Fri, Feb 6, 2015 at 10:13 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > I want relationships for certain modeling purposes > What I like is that we should arrive to get a collection of useful slots with optimal implementation instead all of us reinventing the wheel. > > I have started to collect the examples in Slots-Examples (in #481). > At the start these are artificial (just testing/showing something), but slowly we will add useful ones, too. > > I started to implement PropertySlot, this uses hidden slots, initialisation (to set the empty dictionary of the base slot), virtual slots > (the proper slots), reflectively changing the class both when adding and removing (to add the base slot and remove it as needed). > and custom byte code generation to read and write with just #at: and #at:put on the base slotâ¦ Marcus

Feb. 7, 2015

Re: [Pharo-dev] [Slots] Invisible Slots

by Marcus Denker

On Fri, Feb 6, 2015 at 10:13 PM, stepharo <stepharo(a)free.fr> wrote: > I want relationships for certain modeling purposes > What I like is that we should arrive to get a collection of useful slots > with optimal implementation instead all of us reinventing the wheel. > > I have started to collect the examples in Slots-Examples (in #481). At the start these are artificial (just testing/showing something), but slowly we will add useful ones, too. I started to implement PropertySlot, this uses hidden slots, initialisation (to set the empty dictionary of the base slot), virtual slots (the proper slots), reflectively changing the class both when adding and removing (to add the base slot and remove it as needed). Marcus

Feb. 7, 2015

[ANN] Pharo Consortium New Academic Partner: REVEAL University of Lugano

by Marcus Denker

The Pharo Consortium is very happy to announce that the REVEAL research group of the University of Lugano has joined the Consortium as an Academic Partner. The REVEAL (Reverse Engineering, Visualization, Evolution Analysis Lab) group carries out research in diverse aspects of how to ease the comprehension and evolution of large and complex software systems. Current research is focused on software visualization, mining software repositories, collaborative development, and novel integrated development environments. About - REVEAL: http://www.inf.usi.ch/faculty/lanza/reveal.html - University of Lugano: http://www.usi.ch/en/index.htm - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

Feb. 7, 2015

Slides PharoDays...

by Marcus Denker

Hi, Slides are online: http://www.slideshare.net/pharoproject/presentations <http://www.slideshare.net/pharoproject/presentations> (thanks to Santiago for collecting and uploading!) Videos soonâ¦ need to put titles and cross links to slides. Marcus

Feb. 7, 2015

Re: [Pharo-dev] [squeak-dev] Re: ||

by kilon alios

And none of the XML and web technologies sell as much as Angry Birds and Candy Crash Saga :D I think you underestimate people. True Web is very popular, but lets not forget all the promises a decade ago that we will completely move to the cloud in a few years and we are still desktop all the way. Only desktop has moved to mobile devices which none could predict it at the time. On the other hand Smalltalk was not rejected because it was beautiful , it was rejected because it failed to adjust to current demands. It remained a good proof of concept and not much more than that. It opened the door , but never truly entered the room. On Sat, Feb 7, 2015 at 6:01 PM, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > > > Am 07.02.2015 um 16:18 schrieb David T. Lewis <lewis(a)mail.msen.com>: > > > > On Thu, Feb 05, 2015 at 01:54:51PM +0100, Marcus Denker wrote: > >> > >>> On 05 Feb 2015, at 10:12, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >>>> > >>>> On 05 Feb 2015, at 10:04, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >>> > >>> Another way to see it: How would the original Smalltalk be designed if > they would have had 4GB RAM in 1978? > >>> > >>> What fascinates me still is that Smalltalk used the existing resources > (even building their own machines) to an > >>> extreme, while today we are obsessed to find reasons why we can not do > anything that makes the system > >>> slower or use more memory than yesterday. And that even with resources > growing every year??? > >>> > >>> This is why we e.g. now have a meta object describing every instance > variable in Pharo. I am sure there are people > >>> who will see these ~7000 objects as pure waste??? while I would say > that we have already *now* the resources to be > >>> even more radical. > >>> > >> > >> Seemingly I still can not explain what I mean in away that people get > it, so please just ignore this mail. > >> > >> Marcus > >> > > > > Your point makes good sense to me. In 1978, a system in which a low-level > > integer was represented as an object with behavior would have been > perceived > > as a rediculously wasteful idea. And can you imagine someone seriously > > suggesting something so wasteful as automatic memory management? > > > > So if the "same" system was being designed today, it might very well > include > > new concepts that today are perceived as wasteful. Some of those concepts > > might turn out to be very good thing once we get used to them. > The times have changed. Today waste seems to be a requirement. > Whatever application you have - reimplement it using âweb technologiesâ. > Whatever data you have - store it in âthe cloudâ and tunnel its > transportation over port 80, > gain extra points for using XML here. > > Today, beautiful small things like Smalltalk are ignored by the masses and > being laughed at. > > Andreas >

Feb. 7, 2015

Re: [Pharo-dev] ||

by kilon alios

I agree, my objection too is how it looks syntax wise. As I said I don't understand pragmas deeply enough to make a decision if I want them removed or not. Tag wise, well I think a tag should be an IDE and not a language feature. But thats my personal preference. Protocols for me at least is another way to tag things. As I said in the past I would prefer a more elaborate system of tagging for methods and classes similar how Stackoverflow questions work of default and custom tags. On the other hand, people like different things so I never made a big deal out of it. So for now I just tolerate pragmas and they do tolerate me :D On Sat, Feb 7, 2015 at 5:41 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > > 2015-02-07 5:59 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > >> Personally I don't like Pragmas, they have not convinced me so far that >> they fit the style of Smalltalk syntax. I have to confess though I never >> liked descriptive elements and languages . >> >> > Me neither. Actually the pragma idea is not wrong per se, it is the tag > syntax to write them which bothers me. Because the world can be described > with tags if you start that path. > There are other ways to add metadata to methods. Without tagging. > And they don't need to be in the method pane itself. > It is like having to specify protocol because there is no list pane to > create them. > > HernÃ¡n > >> >> About python decorators I disagree that are similar to pragmas. Pragmas >> are focused on being descriptive , python decorators are descriptive as by >> product. The main focus of python decorators is to shorten code by >> introducing syntactic sugar. >> >> I agree though this is a very interesting discussion and I dont >> understand most of the things stated here so I leave an open door and mind >> for pragmas. Maybe one day I will "get it". >> > > > > > >> >> On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> >>> >>> 2015-02-06 22:00 GMT+01:00 stepharo <stepharo(a)free.fr>: >>> >>>> Really interesting discussion. I like pragmas but this is interesting >>>> to see them challenged. >>>> >>> >>> Thanks. It's a pleasure to discuss that way :) >>> >>> >>>> Yes, but there end up being lots of naming conventions and they are >>>>> non-obvious. Whereas pragmas, because they are in-your-face in the methods >>>>> in question, don't need conventions. They just need documenting ;-). >>>>> >>>> Thierry I'm skeptical that multiple protocol will save the problem >>>> because you will rely on coding conventions. >>>> >>> >>> Pragma as well: just explain the conventions behind the gtInspector >>> pragmas, for example. >>> >>> But give me multiple protocols and I'll show you the same conventions >>> rewritten in less lines (and a slightly more efficient code). >>> >>> >>>> And pragma is a clever tagging. >>>> >>> >>> Then maybe we should remove protocols and replace them with pragmas :) >>> >>> Thierry >>> >>> >>>> >>>> Stef >>>> >>>> >>>> >>> >> >

Feb. 7, 2015