- Pharo-users - lists.pharo.org

Is anyone interested in developing a package for Google's Data API?

by Andy Burnett

I use Google's spreadsheet and word processor a lot. I would love to be able to access the data through Pharo. I can envisage all sorts of use-cases such as manipulating data collected through the spreadsheet forms, through to generating slide shows by writing to their presentation app. The thing that has held me back is the lack of a package which presents e.g. Spreadsheet as an object with a collection of methods. There are libraries for Java/Python/etc., but nothing - that I am aware of - for Pharo. Would anyone be interested in developing one? I could certainly contribute some funds towards the effort, and others may be able to do likewise. Cheers Andy á§

Sept. 11, 2014

Re: [Pharo-users] The fourth R

by Trygve Reenskaug

Hi Phil, Have you tried BabyUML? A horrible hack and not yet portable to other Squeaks, but it is a start. http://fulloo.info/Downloads/BabyIDE.zip This is set up for Windows, but the .image and .changes files should work anywhere (assuming the Squeak VM hasn't been improved so that it has lost backward compatibility). --Trygve On 11.09.2014 18:10, phil(a)highoctane.be wrote: > "Smalltalk is not a language, it is an object computer" > > Wow, that nails it quite nicely. > > And it feels a lot like that, especially with tools like GT-Playground. > > Now, the most complicated bit is for me to get the user to discuss > with the object computer through the UI in a satisfying way. Getting > the right UI for delivering the value is taking a very long time. > > Phil

Sept. 11, 2014

Re: [Pharo-users] The fourth R

by Trygve Reenskaug

On 07.09.2014 12:29, kilon alios wrote: > > ... > Referring to the rest of your post I dont agree that we need to separate Data from Code, I don't know of anybody who wants to separate data and code. May be you are thinking about DCI without having grokked it. Smalltalk sees an object as an entity that has a unique and immutable identity and that encapsulates state and behavior. DCI builds on this definition and has a powerful separation of concerns: 1. An object seen in isolation is specified by a class. This is observing the object from within its encapsulation boundary. A class says everything about how an object is constructed and nothing about how it collaborates with others. A DCI Data object is an object that does not collaborate with objects in its environment. 2. An ensemble of objects that collaborate to achieve a certain goal is specified by a DCI Context. The observation point is in the space between the objects. The objects are observed from outside their encapsulation boundaries, The message flow is visible and can be reasoned about. A DCI Context says everything about how objects collaborate to achieve a common goal and nothing about how they are constructed. The Class and the Context are orthogonal concepts and form the basis of my mental model of an object computer.

Sept. 11, 2014

Re: [Pharo-users] The fourth R

by phil＠highoctane.be

"Smalltalk is not a language, it is an object computer" Wow, that nails it quite nicely. And it feels a lot like that, especially with tools like GT-Playground. Now, the most complicated bit is for me to get the user to discuss with the object computer through the UI in a satisfying way. Getting the right UI for delivering the value is taking a very long time. Phil On Thu, Sep 11, 2014 at 5:42 PM, Trygve Reenskaug <trygver(a)ifi.uio.no> wrote: > Hi kilon alios, > I want to go deeper than any programming language. "What is a computer?" > Almost all programming languages build on the von Neumann architecture > with data processing as " The execution of a systematic sequence of > operations > performed upon data." I believe this is unnecessarily low-level and > complex for general use. Much closer to the human mind is to build on an > object computer where the unit of storage is the object rather than the > bit or byte. Data processing becomes "the systematic exchange of messages > between objects." Lots of stuff that's of no interest to the general user > is then hidden under the hood. > > The users of immediate importance may be power users. Computational > chemists are my favorite examples. What shall be their mental model, what > do we teach them and how do we form our programs such that they can > understand and modify what goes on on the computer? > > I foresee that (virtual) object computers will supersede our current > computers for general programming. They will be supported by experts doing > systems programming on various levels from virtual machines down to > microcode and hardware. When this is achieved; Java, Ruby, C++, C, Haxe, > etc. will no longer be used for general application programming. (Smalltalk > is, of course, not a language but an object computer.) > > The "pythonic" culture should permeate more than Phyton, it should be > behind all we do. Thanks for sharing it. > C. A. R. Hoare says it succintly: > " There are two ways of constructing a software design: > - One way is to make it so simple that there are obviously no > deficiencies > - The other way is to make it so complicated that there are no > obvious deficiencies." > and > "The first method is far more difficultâ¦." > also: > "The price of reliability is the pursuit of the utmost simplicity" > > I think we are in agreement about the need for readable code. But I > disagree when you say "We need very complex solutions to very complex > problems". I believe we can attain simple solutions to very complex > problems. If the complexity is in the user's mental model then a direct > mapping of this model into code will be simple as seen from the user's > point of view. If the program is more complex than the user's mental model, > the program should be simplified. > > It would be helpful if you would suggest an example where Phyton leads to > more readable code than say Pharo. > > > On 07.09.2014 12:29, kilon alios wrote: > > Python has no competition. Sure there are languages that are more popular > than Python for their own reasons. There have been simpler languages before > python, there have been more popular languages, more cross platform > languages etc etc but Python fills a gap that no language was able to fill > before it , easy to use very powerful well documented libraries. Python is > a language that you can teach to a kid now and make a living later on using > until his or her old age. Its not because the language is simple , its > simple enough but not the simplest. Its because the culture surrounding the > creation of libraries . That culture has a name its called "pythonic" > > Beautiful is better than ugly. > Explicit is better than implicit. > Simple is better than complex. > Complex is better than complicated. > Flat is better than nested. > Sparse is better than dense. > Readability counts. > Special cases aren't special enough to break the rules. > Although practicality beats purity. > Errors should never pass silently. > Unless explicitly silenced. > In the face of ambiguity, refuse the temptation to guess. > There should be one-- and preferably only one --obvious way to do it. > Although that way may not be obvious at first unless you're Dutch. > Now is better than never. > Although never is often better than *right* now. > If the implementation is hard to explain, it's a bad idea. > If the implementation is easy to explain, it may be a good idea. > Namespaces are one honking great idea -- let's do more of those! > > this kind of ideology is why Python has been so successful. It has also inspired jokes like this > > http://xkcd.com/353/ > > it may look funny and it says thinks about overestimating the simplicity of those libraries but python does feel at times as simple as this, as simple as importing antigravity. > > So if a kid comes to me and ask me "what language should I learn" , I will recommend a language that is fairly easy to learn , has powerful library , easy to use libraries , well documented and its a language that will able to keep using even if his or her needs change, forever. For that only Python is the language that has been able to succeed and I think its adoption will continue to progress in educational institutions pretty much everywhere on the planet. > > Referring to the rest of your post I dont agree that we need to separate Data from Code, I think quite opossite that a kid needs to be taught why Code and Data are one and what that means in practice. I also don't agree that OO or functional programming or any other programming paradigm I am aware of are the future. They are simple solutions for simpler times. The coding community at large the way I see it is in denial hoping to apply simple recipes to solve complex problems. We need very complex solutions to very complex problems , we need tools that can interact with the user in many diffirent ways. > > Pharo is definitely showing the future, the close integration of IDE , language and environment. But thats is just the start, the next step is powerful tools that can deeply interact with code and solve automagically logical coding problems. Obviously all that has to be wrapped to an easy enough interface for the user even if the solutions is very complex. > > Fortunately this where the rest of the coding world is heading. For example iPython is one of the most popular python projects right and it offers a highly interactive environment for python coders that shares a lot of similarities with Pharo though the implementation is very different. > > So the future is no longer languages , is no longer IDEs , its not even environments but tools that are produced in these environments that can vastly automate coding and hide the increasing complexity of coding solutions. Maybe one day a child will be able to describe to a computer what kind of software he or she needs and the computer automatically generate the code for it. That day is not close enough but is where we are heading. > > > > On Sun, Sep 7, 2014 at 12:34 PM, Trygve Reenskaug <trygver(a)ifi.uio.no> > wrote: > >> I have for some time been pondering two problems. One is to identify >> the fourth R in *R*eading, w*R*iting, a*R*ithmetic, and p*R*ogramming. >> There are many contenders for the kids' first step. I believe the English >> government has chosen Phyton as a first language. Scratch has a certain >> popularity, there are many others. My concern is "what comes next"? I want >> the kid to gradually build a mental model of what computing is all about. >> Learn a little, do a little, lean more, do more, etc. up do old age. This >> goes much deeper than any programming language. It's a bit as learning to >> read. Personally, I "broke the reading code"at an early age. Since then, I >> have been learning more and more. What I read today would have been >> incomprehensible to me 75 years ago. But my basic mental model of what >> reading is all about has remained unchanged. I have never had to unlearn >> anything. >> >> I suggest that true object orientation (not class orientation) can form >> the foundation for the human mental model of computing. Internalize it and >> live with it forever. >> ------------------------------------- >> The other problem is to find a better example for DCI presentations. It >> should >> >> 1. Be executable and have a cool demo effect. >> 2. Its domain model should be obvious from the demo. >> 3. It should have very few and very simple Data classes. >> 4. It should have a Context that is clearly and obviously >> separate from the Data. >> 5. It should scale to any number of Contexts (use cases) without >> changing the Data classes. >> >> ----------------------------------------- >> *Last night I got an idea for an example: A waltzing couple. (See the >> attached for a picture and Wikipedia for a movie of the use case).* >> >> The program needs one simple class for a moveable shape and a DCI Context >> for each dance (waltz, foxtrot, tango, ... for two role, polonaise for >> more.) The example will clearly demonstrate the wisdom in separating what >> the system IS from what the system DOES since the simple Shape class would >> be overloaded with instance methods for all dances. >> >> What do you think? >> >> --Trygve >> > >

Sept. 11, 2014

Re: [Pharo-users] The fourth R

by Trygve Reenskaug

Hi kilon alios, I want to go deeper than any programming language. "What is a computer?" Almost all programming languages build on the von Neumann architecture with data processing as " The execution of a systematic sequence of operations performed upon data." I believe this is unnecessarily low-level and complex for general use. Much closer to the human mind is to build on an object computer where the unit of storage is the object rather than the bit or byte. Data processing becomes "the systematic exchange of messages between objects." Lots of stuff that's of no interest to the general user is then hidden under the hood. The users of immediate importance may be power users. Computational chemists are my favorite examples. What shall be their mental model, what do we teach them and how do we form our programs such that they can understand and modify what goes on on the computer? I foresee that (virtual) object computers will supersede our current computers for general programming. They will be supported by experts doing systems programming on various levels from virtual machines down to microcode and hardware. When this is achieved; Java, Ruby, C++, C, Haxe, etc. will no longer be used for general application programming. (Smalltalk is, of course, not a language but an object computer.) The "pythonic" culture should permeate more than Phyton, it should be behind all we do. Thanks for sharing it. C. A. R. Hoare says it succintly: " There are two ways of constructing a software design: - One way is to make it so simple that there are obviously no deficiencies - The other way is to make it so complicated that there are no obvious deficiencies." and "The first method is far more difficultâ¦." also: "The price of reliability is the pursuit of the utmost simplicity" I think we are in agreement about the need for readable code. But I disagree when you say "We need very complex solutions to very complex problems". I believe we can attain simple solutions to very complex problems. If the complexity is in the user's mental model then a direct mapping of this model into code will be simple as seen from the user's point of view. If the program is more complex than the user's mental model, the program should be simplified. It would be helpful if you would suggest an example where Phyton leads to more readable code than say Pharo. On 07.09.2014 12:29, kilon alios wrote: > Python has no competition. Sure there are languages that are more > popular than Python for their own reasons. There have been simpler > languages before python, there have been more popular languages, more > cross platform languages etc etc but Python fills a gap that no > language was able to fill before it , easy to use very powerful well > documented libraries. Python is a language that you can teach to a kid > now and make a living later on using until his or her old age. Its not > because the language is simple , its simple enough but not the > simplest. Its because the culture surrounding the creation of > libraries . That culture has a name its called "pythonic" > > Beautiful is better than ugly. > Explicit is better than implicit. > Simple is better than complex. > Complex is better than complicated. > Flat is better than nested. > Sparse is better than dense. > Readability counts. > Special cases aren't special enough to break the rules. > Although practicality beats purity. > Errors should never pass silently. > Unless explicitly silenced. > In the face of ambiguity, refuse the temptation to guess. > There should be one-- and preferably only one --obvious way to do it. > Although that way may not be obvious at first unless you're Dutch. > Now is better than never. > Although never is often better than *right* now. > If the implementation is hard to explain, it's a bad idea. > If the implementation is easy to explain, it may be a good idea. > Namespaces are one honking great idea -- let's do more of those! > this kind of ideology is why Python has been so successful. It has also inspired jokes like this > http://xkcd.com/353/ > it may look funny and it says thinks about overestimating the simplicity of those libraries but python does feel at times as simple as this, as simple as importing antigravity. > So if a kid comes to me and ask me "what language should I learn" , I will recommend a language that is fairly easy to learn , has powerful library , easy to use libraries , well documented and its a language that will able to keep using even if his or her needs change, forever. For that only Python is the language that has been able to succeed and I think its adoption will continue to progress in educational institutions pretty much everywhere on the planet. > Referring to the rest of your post I dont agree that we need to separate Data from Code, I think quite opossite that a kid needs to be taught why Code and Data are one and what that means in practice. I also don't agree that OO or functional programming or any other programming paradigm I am aware of are the future. They are simple solutions for simpler times. The coding community at large the way I see it is in denial hoping to apply simple recipes to solve complex problems. We need very complex solutions to very complex problems , we need tools that can interact with the user in many diffirent ways. > Pharo is definitely showing the future, the close integration of IDE , language and environment. But thats is just the start, the next step is powerful tools that can deeply interact with code and solve automagically logical coding problems. Obviously all that has to be wrapped to an easy enough interface for the user even if the solutions is very complex. > Fortunately this where the rest of the coding world is heading. For example iPython is one of the most popular python projects right and it offers a highly interactive environment for python coders that shares a lot of similarities with Pharo though the implementation is very different. > So the future is no longer languages , is no longer IDEs , its not even environments but tools that are produced in these environments that can vastly automate coding and hide the increasing complexity of coding solutions. Maybe one day a child will be able to describe to a computer what kind of software he or she needs and the computer automatically generate the code for it. That day is not close enough but is where we are heading. > > > On Sun, Sep 7, 2014 at 12:34 PM, Trygve Reenskaug <trygver(a)ifi.uio.no > <mailto:trygver@ifi.uio.no>> wrote: > > I have for some time been pondering two problems. One is to > identify the fourth R in *R*eading, w*R*iting, a*R*ithmetic, and > p*R*ogramming. There are many contenders for the kids' first > step. I believe the English government has chosen Phyton as a > first language. Scratch has a certain popularity, there are many > others. My concern is "what comes next"? I want the kid to > gradually build a mental model of what computing is all about. > Learn a little, do a little, lean more, do more, etc. up do old > age. This goes much deeper than any programming language. It's a > bit as learning to read. Personally, I "broke the reading code"at > an early age. Since then, I have been learning more and more. What > I read today would have been incomprehensible to me 75 years > ago. But my basic mental model of what reading is all about has > remained unchanged. I have never had to unlearn anything. > > I suggest that true object orientation (not class orientation) can > form the foundation for the human mental model of computing. > Internalize it and live with it forever. > ------------------------------------- > The other problem is to find a better example for DCI > presentations. It should > > 1. Be executable and have a cool demo effect. > 2. Its domain model should be obvious from the demo. > 3. It should have very few and very simple Data classes. > 4. It should have a Context that is clearly and obviously > separate from the Data. > 5. It should scale to any number of Contexts (use cases) > without changing the Data classes. > > ----------------------------------------- > /Last night I got an idea for an example: A waltzing couple. (See > the attached for a picture and Wikipedia for a movie of the use > case)./ > > The program needs one simple class for a moveable shape and a DCI > Context for each dance (waltz, foxtrot, tango, ... for two role, > polonaise for more.) The example will clearly demonstrate the > wisdom in separating what the system IS from what the system DOES > since the simple Shape class would be overloaded with instance > methods for all dances. > > What do you think? > > --Trygve >

Sept. 11, 2014

Re: [Pharo-users] Strange colour reversal on the Spec site

by Damien Pollet

Issue reported https://github.com/spec-framework/spec-framework.github.io/issues/2 On 11 September 2014 06:07, Alain Busser <alain.busser(a)gmail.com> wrote: > Hi, > > I can confirm that this page looks really strange: > http://spec.st/docs/own-model/ > > At the end, only the word "bindings" appears, the rest is security ink... > Also, all the lines are separated by a darker shade of gray and the script, > if it was visible, would appear as a collection of lines rather than a > single text. > > Alain > > On Thu, Sep 11, 2014 at 6:18 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >> >> >> We are passionate people with strong opinions. We have to be, otherwise we >> would not be spending our time on this language which is not ânormalâ. >> Sometimes this causes disagreements. Sometimes these disagreements cannot be >> resolved. When the latter happens, this is a sad thing. >> >> I am not interested in judging, determining who was ârightâ and who was >> âwrongâ. From his/her point of view everybody is ârightâ (at least to a high >> degree). I just want to do what, for me, is the best for the overall >> project. I may be âwrongâ, but I do not know any better. Iâm just another >> guy, you know? >> >> All of the above being said, for me, the best action is to give my little >> bit of support to the version of Spec that is in the Pharo distribution >> because I think that this is the best for the project. I would like to keep >> working on the documentation and improving it. Specifically I mean the >> version that Stef linked to below as it corresponds to whatâs in Pharo. I >> have had some ideas about missing content as well. So when stuff calms down, >> letâs sync and work on further improving the documentation. >> >> On Sep 10, 2014, at 3:45 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Hello andy >> >> I'm sorry about this story. The pharo board (Tudor Girba, Sven van >> Cackenberghe, Esteban Lorenzano, Marcus Denker and me) >> will react officially this is problem. I'm in the board but I do not >> want that people think that I'm trying any action that would >> be about personal nature, especially since I personally supported a >> lot Benjamin during all these years - and I do not understand >> his sudden action. Now since this is out of my reach, I prefer to >> focus on making Pharo better and I'm working on that actively :) >> >> I decided as one of Pharo founder to follow the board and let them >> handle this situation. I decided that I will not influence nor act >> because I prefer to be in positive mindset and push Pharo further. >> The board told me that they will clarify the situation, especially >> since there are actions that were not correct. >> I'm waiting as you for an official statement from the board, and I >> know that it will come and be really clear. >> As you can imagine the board wants to do it right and settle it as an >> example for any future frameworks or part (Zinc, Glamour, Athens, TxText, >> ...) >> that (will) compose Pharo. >> We are setting an industrial consortium to push Pharo for real (As you >> can see in the reporthttp://consortium.pharo.org/web?_s=DiSVVVKk3sFm2ouZ >> Inria put 300 K euros not counting the salary of the permanent members >> of our team) and rules should be clear and followed. >> >> Now the GPL license does not apply to the version of Spec that is >> available in the Pharo distribution since it is MIT from the beginning >> and it will stay forever as it. We did not fork it. We are actively >> improving Spec. Some clean ups got already integrated and others are >> pending. >> We will maintain and improve the Spec documentation too. For example >> we will probably add the part >> written by Stefan Eggermont that was submitted but never integrated. >> I'm waiting just to avoid adding to the confusion. >> >> You can find a version of the Spec documentation as part of the next >> book: >> >> https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… >> It may be not fully in par with the github repo but we will sync with >> Johan Fabry too in the future. >> >> >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD lab - Computer Science Department (DCC) - University of Chile >> >

Sept. 11, 2014

Re: [Pharo-users] Strange colour reversal on the Spec site

by Alain Busser

Hi, I can confirm that this page looks really strange: http://spec.st/docs/own-model/ At the end, only the word "bindings" appears, the rest is security ink... Also, all the lines are separated by a darker shade of gray and the script, if it was visible, would appear as a collection of lines rather than a single text. Alain On Thu, Sep 11, 2014 at 6:18 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > We are passionate people with strong opinions. We have to be, otherwise we > would not be spending our time on this language which is not ânormalâ. > Sometimes this causes disagreements. Sometimes these disagreements cannot > be resolved. When the latter happens, this is a sad thing. > > I am not interested in judging, determining who was ârightâ and who was > âwrongâ. From his/her point of view everybody is ârightâ (at least to a > high degree). I just want to do what, for me, is the best for the overall > project. I may be âwrongâ, but I do not know any better. Iâm just another > guy, you know? > > All of the above being said, for me, the best action is to give my little > bit of support to the version of Spec that is in the Pharo distribution > because I think that this is the best for the project. I would like to keep > working on the documentation and improving it. Specifically I mean the > version that Stef linked to below as it corresponds to whatâs in Pharo. I > have had some ideas about missing content as well. So when stuff calms > down, letâs sync and work on further improving the documentation. > > On Sep 10, 2014, at 3:45 PM, stepharo <stepharo(a)free.fr> wrote: > > Hello andy > > I'm sorry about this story. The pharo board (Tudor Girba, Sven van > Cackenberghe, Esteban Lorenzano, Marcus Denker and me) > will react officially this is problem. I'm in the board but I do not > want that people think that I'm trying any action that would > be about personal nature, especially since I personally supported a > lot Benjamin during all these years - and I do not understand > his sudden action. Now since this is out of my reach, I prefer to > focus on making Pharo better and I'm working on that actively :) > > I decided as one of Pharo founder to follow the board and let them > handle this situation. I decided that I will not influence nor act > because I prefer to be in positive mindset and push Pharo further. > The board told me that they will clarify the situation, especially > since there are actions that were not correct. > I'm waiting as you for an official statement from the board, and I > know that it will come and be really clear. > As you can imagine the board wants to do it right and settle it as an > example for any future frameworks or part (Zinc, Glamour, Athens, TxText, > ...) > that (will) compose Pharo. > We are setting an industrial consortium to push Pharo for real (As you > can see in the reporthttp://consortium.pharo.org/web?_s=DiSVVVKk3sFm2ouZ > Inria put 300 K euros not counting the salary of the permanent members > of our team) and rules should be clear and followed. > > Now the GPL license does not apply to the version of Spec that is > available in the Pharo distribution since it is MIT from the beginning > and it will stay forever as it. We did not fork it. We are actively > improving Spec. Some clean ups got already integrated and others are > pending. > We will maintain and improve the Spec documentation too. For example > we will probably add the part > written by Stefan Eggermont that was submitted but never integrated. > I'm waiting just to avoid adding to the confusion. > > You can find a version of the Spec documentation as part of the next > book: > > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… > It may be not fully in par with the github repo but we will sync with > Johan Fabry too in the future. > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

Sept. 11, 2014

Re: [Pharo-users] Strange colour reversal on the Spec site

by Johan Fabry

We are passionate people with strong opinions. We have to be, otherwise we would not be spending our time on this language which is not ânormalâ. Sometimes this causes disagreements. Sometimes these disagreements cannot be resolved. When the latter happens, this is a sad thing. I am not interested in judging, determining who was ârightâ and who was âwrongâ. From his/her point of view everybody is ârightâ (at least to a high degree). I just want to do what, for me, is the best for the overall project. I may be âwrongâ, but I do not know any better. Iâm just another guy, you know? All of the above being said, for me, the best action is to give my little bit of support to the version of Spec that is in the Pharo distribution because I think that this is the best for the project. I would like to keep working on the documentation and improving it. Specifically I mean the version that Stef linked to below as it corresponds to whatâs in Pharo. I have had some ideas about missing content as well. So when stuff calms down, letâs sync and work on further improving the documentation. On Sep 10, 2014, at 3:45 PM, stepharo <stepharo(a)free.fr> wrote: > Hello andy > > I'm sorry about this story. The pharo board (Tudor Girba, Sven van Cackenberghe, Esteban Lorenzano, Marcus Denker and me) > will react officially this is problem. I'm in the board but I do not want that people think that I'm trying any action that would > be about personal nature, especially since I personally supported a lot Benjamin during all these years - and I do not understand > his sudden action. Now since this is out of my reach, I prefer to focus on making Pharo better and I'm working on that actively :) > > I decided as one of Pharo founder to follow the board and let them handle this situation. I decided that I will not influence nor act > because I prefer to be in positive mindset and push Pharo further. > The board told me that they will clarify the situation, especially since there are actions that were not correct. > I'm waiting as you for an official statement from the board, and I know that it will come and be really clear. > As you can imagine the board wants to do it right and settle it as an example for any future frameworks or part (Zinc, Glamour, Athens, TxText, ...) > that (will) compose Pharo. > We are setting an industrial consortium to push Pharo for real (As you can see in the reporthttp://consortium.pharo.org/web?_s=DiSVVVKk3sFm2ouZ > Inria put 300 K euros not counting the salary of the permanent members of our team) and rules should be clear and followed. > > Now the GPL license does not apply to the version of Spec that is available in the Pharo distribution since it is MIT from the beginning > and it will stay forever as it. We did not fork it. We are actively improving Spec. Some clean ups got already integrated and others are pending. > We will maintain and improve the Spec documentation too. For example we will probably add the part > written by Stefan Eggermont that was submitted but never integrated. I'm waiting just to avoid adding to the confusion. > > You can find a version of the Spec documentation as part of the next book: > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… > It may be not fully in par with the github repo but we will sync with Johan Fabry too in the future. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Sept. 11, 2014

Re: [Pharo-users] Strange colour reversal on the Spec site

by Andy Burnett

Steph, Thanks very much for such a comprehensive answer. I shall look forward to hearing from the board. Cheers Andy

Sept. 10, 2014

Re: [Pharo-users] Strange colour reversal on the Spec site

by kilon alios

yes he is correct I see it too her using Google Chrome. Same problem as Andy describes it http://spec.st/docs/quickstart/ On Wed, Sep 10, 2014 at 9:41 PM, Ben Coman <btc(a)openinworld.com> wrote: > Andy Burnett wrote: > > Hello, > > I am posting here, because I couldn't find a Spec specific list. > Two things: > > 1. The colour scheme for all the code examples on the site seems to > have gone very odd. The text is now a light blue/green on a white > background. Almost completely illegible. Has someone changed a css file? > > > Do have have a specific url? > http://spec.st looks fine to me. > > > 1. I noticed in the news section that the license has changed to GPL, > because of a disagreement with the direction of Pharo. Could someone > explain what the disagreement was, and whether this is something we should > be concerned about? > > Cheers > Andy > á§ > > > It has not been explained beyond it being mostly a personality clash. > There was some final technical issue that went against some existing > Smalltalk conventions, but there was not much discussion brought to the > community on that conflict. Note the Spec code already in Pharo is MIT > licensed, so there is no concern about that. I guess in a way it shows how > the MIT is more-free than the GPL, that such can occur. Of course, the > reverse cannot. > > I would be concerned about loading external-Spec into a Pharo based > project. Although the new dual license seems written to allow parties other > than Pharo to use external-Spec in a non-GPL project, the implications of > how that might contaminate a Pharo based project is not clear. Also I > guess discussion of external-Spec probably won't proceed on this list, so > until I see news of a separate Spec mailing list to collaborate with users > and other developers, it would seem that developer has struck out on his > own. Pharo-internal-Spec will continue development here under the MIT > license. > > cheers -ben >

Sept. 10, 2014