Hi, I have found useful those roadmaps: https://github.com/pharo-project/pharo-workingRoadmaps Could it be possible to make one for the Pharo tools (e.g. Nautilus)? I think there are people who have better idea what to make first and what later. I would like to contribute on it and roadmap could help me. Thanks, Juraj
I see GTInspector as a big splash. I guess that if there would be a Tool Roadmap, it would be focused on GTInspector. Alexandre On Aug 23, 2014, at 5:34 PM, Juraj Kubelka <juraj.kubelka@gmail.com> wrote:
Hi,
I have found useful those roadmaps: https://github.com/pharo-project/pharo-workingRoadmaps Could it be possible to make one for the Pharo tools (e.g. Nautilus)? I think there are people who have better idea what to make first and what later. I would like to contribute on it and roadmap could help me.
Thanks, Juraj
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 24/8/14 05:39, Alexandre Bergel wrote:
I see GTInspector as a big splash. I guess that if there would be a Tool Roadmap, it would be focused on GTInspector.
Not necessarily. No time to explain sorry but else I would not improve morphic because bloc is coming and parallel actions are important. Stef
Alexandre
On Aug 23, 2014, at 5:34 PM, Juraj Kubelka <juraj.kubelka@gmail.com> wrote:
Hi,
I have found useful those roadmaps: https://github.com/pharo-project/pharo-workingRoadmaps Could it be possible to make one for the Pharo tools (e.g. Nautilus)? I think there are people who have better idea what to make first and what later. I would like to contribute on it and roadmap could help me.
Thanks, Juraj
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion) Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ? I understand that you are very busy, so no problem if there is no link on existing material, I should survive, just wait a little :) TIA Regards Alain Le 24/08/2014 08:03, stepharo a écrit :
On 24/8/14 05:39, Alexandre Bergel wrote:
I see GTInspector as a big splash. I guess that if there would be a Tool Roadmap, it would be focused on GTInspector.
Not necessarily. No time to explain sorry but else I would not improve morphic because bloc is coming and parallel actions are important.
Stef
thats a normal reaction, the vast majority of people don't care about progress they care about money. They care about using products with large market share. This is why Apple releases information about its commercial success each semester. Progress is all about getting outside your comfort zone and doing the hard work sometimes driving yourself bankrupt (see Tesla) . So Pharo or Squeak in the end is for that minority of people who look for something really different and unique. If all you look is an language that is a variant of C or an IDE that is a variant of Visual Studion then neither Squeak or Pharo is for you and the fact you dislike the interface is just an excuse. I strongly disagree on Morphic, personally I love using it. It can be cleaner but still beats any other GUI I have used in terms of ease of use without sacrificing power. Spec on the other hand looks ugly to me , weird and very difficult to understand. But maybe its just my opinion and how my brain is wired. Afterall Spec has been very popular with Pharo devs so definitely is something I keep a close eye on . I really hope Morphic does not get removed, at least continue to be distributed as third party library.Though thats is unlikely with all the hard work of cleaning it up. Definetly there is room for a lot of libraries and alternatives, after all each person has different needs, preferences and goals. Personally I like seeing all this variation even if that means I wont be using most of it and there will be only of handful of tools I will be using. I love seeing people thinking outside the box and going for unexplored territory and I think Pharo as a platform is ideal for that. A roadmap is a very useful to have it helps the community get in sync and eliminates duplicate efforts. I am very interested into the Morphic cleanup and I may join the efforts too. On Tue, Aug 26, 2014 at 12:17 AM, Alain Rastoul <alr.dev@free.fr> wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
I understand that you are very busy, so no problem if there is no link on existing material, I should survive, just wait a little :)
TIA
Regards
Alain
Le 24/08/2014 08:03, stepharo a écrit :
On 24/8/14 05:39, Alexandre Bergel wrote:
I see GTInspector as a big splash. I guess that if there would be a Tool Roadmap, it would be focused on GTInspector.
Not necessarily. No time to explain sorry but else I would not improve morphic because bloc is coming and parallel actions are important.
Stef
I strongly disagree on Morphic, personally I love using it. It can be cleaner but still beats any other GUI I have used in terms of ease of use without sacrificing power. Spec on the other hand looks ugly to me , weird and very difficult to understand. But maybe its just my opinion and how my brain is wired. Afterall Spec has been very popular with Pharo devs so definitely is something I keep a close eye on . I really hope Morphic does not get removed, at least continue to be distributed as third party library.Though thats is unlikely with all the hard work of cleaning it up.
Morphic and Spec address different concerns. Building a UI with Morphic alone is what one would use to do something very custom (like a game for example). Now, creating a larger UI that way is definitely going to be super pain in the assets. That's where Spec does fit. Of course at this point in time, the underlying Morphic widgets are quite complicated and sometimes behave in strange ways (try right clicks on the dev tools in unexpected areas...). It takes a while to get used to but it works well. http://spec.st/docs/home/ I also wouldn't want Morphic to be removed, but definitely would like to see it cleaned up in some areas. What I am not sure about is how much of an external library we will depend on. One key thing in Morphic is that one can learn a lot by looking inside (and solve problems), something which will maybe not be there with a new version. Phil
On Tue, Aug 26, 2014 at 12:17 AM, Alain Rastoul <alr.dev@free.fr> wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
I understand that you are very busy, so no problem if there is no link on existing material, I should survive, just wait a little :)
TIA
Regards
Alain
Le 24/08/2014 08:03, stepharo a écrit :
On 24/8/14 05:39, Alexandre Bergel wrote:
I see GTInspector as a big splash. I guess that if there would be a Tool Roadmap, it would be focused on GTInspector.
Not necessarily. No time to explain sorry but else I would not improve morphic because bloc is coming and parallel actions are important.
Stef
yes and I do keep a close eye on Spec, I will keep trying to experiment with it and see if it fits the way I like to work. For now I dont see how Morphic is a pain in the ass for large UIs but I will have to try building a large UI first. It looks like that I will be building one very soon and being custom is a very important requirement to me. I do understand what you say though, On Tue, Aug 26, 2014 at 10:26 AM, phil@highoctane.be <phil@highoctane.be> wrote:
I strongly disagree on Morphic, personally I love using it. It can be
cleaner but still beats any other GUI I have used in terms of ease of use without sacrificing power. Spec on the other hand looks ugly to me , weird and very difficult to understand. But maybe its just my opinion and how my brain is wired. Afterall Spec has been very popular with Pharo devs so definitely is something I keep a close eye on . I really hope Morphic does not get removed, at least continue to be distributed as third party library.Though thats is unlikely with all the hard work of cleaning it up.
Morphic and Spec address different concerns.
Building a UI with Morphic alone is what one would use to do something very custom (like a game for example).
Now, creating a larger UI that way is definitely going to be super pain in the assets.
That's where Spec does fit. Of course at this point in time, the underlying Morphic widgets are quite complicated and sometimes behave in strange ways (try right clicks on the dev tools in unexpected areas...).
It takes a while to get used to but it works well. http://spec.st/docs/home/
I also wouldn't want Morphic to be removed, but definitely would like to see it cleaned up in some areas. What I am not sure about is how much of an external library we will depend on. One key thing in Morphic is that one can learn a lot by looking inside (and solve problems), something which will maybe not be there with a new version.
Phil
On Tue, Aug 26, 2014 at 12:17 AM, Alain Rastoul <alr.dev@free.fr> wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
I understand that you are very busy, so no problem if there is no link on existing material, I should survive, just wait a little :)
TIA
Regards
Alain
Le 24/08/2014 08:03, stepharo a écrit :
On 24/8/14 05:39, Alexandre Bergel wrote:
I see GTInspector as a big splash. I guess that if there would be a Tool Roadmap, it would be focused on GTInspector.
Not necessarily. No time to explain sorry but else I would not improve morphic because bloc is coming and parallel actions are important.
Stef
philippeback wrote
Building a UI with Morphic alone is what one would use to do something very custom (like a game for example).
Now, creating a larger UI that way is definitely going to be super pain in the assets.
That's where Spec does fit.
Is there any evidence of this? As far as I know no one has built anything more complex than a class browser. I would say Spec was incapable of building a complex interface of any kind. It's clumsy, developer-hostile, and counter-intuitive. The whole Spec process of writing code in three different places is the very definition of a /super pain in the asset/s. it is far less intuitive to my mind than creating composite morphs. Progress on Spec is glacially slow - but that's not the problem. Spec is profoundly misconceived and fundamentally flawed and offers nothing over raw Morphic. The Spec model is simply not how anyone would want to build an interface in 2014. I certainly would never use it. -- View this message in context: http://forum.world.st/Roadmap-on-tools-tp4774285p4775282.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Le 28 août 2014 20:16, "kmo" <voxkmp@gmail.com> a écrit :
philippeback wrote
Building a UI with Morphic alone is what one would use to do something very custom (like a game for example).
Now, creating a larger UI that way is definitely going to be super pain
in
the assets.
That's where Spec does fit.
Is there any evidence of this? As far as I know no one has built anything more complex than a class browser. I would say Spec was incapable of building a complex interface of any kind. It's clumsy, developer-hostile, and counter-intuitive.
The whole Spec process of writing code in three different places is the very definition of a /super pain in the asset/s. it is far less intuitive to my mind than creating composite morphs.
Progress on Spec is glacially slow - but that's not the problem. Spec is profoundly misconceived and fundamentally flawed and offers nothing over raw Morphic. The Spec model is simply not how anyone would want to build an interface in 2014. I certainly would never use it.
What it offers is some regularity over the API Frankly, do you find that the Morphic widgets APIs are ok? On Java I used Swing a lot. But that was no walk in the park either. Even with tools like Matisse. In Tcl/Tk things were good but all by hand. And the widgets were aged despite some efforts. UI work is hard to do well with scarce resources. At the end of the day, my UIs are done in HTML5, JQuery and CSS + SVG. And clients are fine with that. Maybe with SDL and Woden will we get something new. Phil
-- View this message in context:
http://forum.world.st/Roadmap-on-tools-tp4774285p4775282.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2014-08-28 16:32 GMT-03:00 phil@highoctane.be <phil@highoctane.be>:
Le 28 août 2014 20:16, "kmo" <voxkmp@gmail.com> a écrit :
philippeback wrote
UI work is hard to do well with scarce resources.
At the end of the day, my UIs are done in HTML5, JQuery and CSS + SVG.
As the UIs of most of the solutions out there. Sneaking into smartphones, kiosks, cars... and other IDEs as well. :) Esteban A. Maringolo
As far as I know no one has built anything more complex than a class browser. I would say Spec was incapable of building a complex interface of any kind. It's clumsy, developer-hostile, and counter- intuitive.
The whole Spec process of writing code in three different places is the very definition of a /super pain in the asset/s. it is far less intuitive to my mind than creating composite morphs.
Progress on Spec is glacially slow - but that's not the problem. Spec is profoundly misconceived and fundamentally flawed and offers nothing over raw Morphic. The Spec model is simply not how anyone would want to build an interface in 2014. I certainly would never use it.
Okay, but how do you really feel? :) I'm intrigued by the 2014 comment, though (which of course will look hilarious in 2015). How do people want to build interfaces in 2014? -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
Guys - this reply has interesting content with potentially useful insight, but I really encourage everyone to think about how to best frame these kinds of comments without âsappingâ the energy out of those writing frameworks like Spec. We all need to make sure that we can have healthy debate and iterate on new ideas but without causing others to feel despondent. We need to energise everyone in our conversations! This was a strong message from ESUG this year (and we didnât always get it right, but we tried to help each other do this). If there are better ideas out there - you really want someone already working on something (which they may have spent lots of energy on already), to not give up in despair, but to seize the opportunity of new insight and apply their knowledge and creative to get a better outcome OR to iterate on their current solution and apply observations from others to create something better. At ESUG, this was a topic of conversation for one of the âShow us your projectsâ slots (disclaimer - I presented that topic on the Zapp framework because I found a few of us in the pub going down a more negative path than we had intended). I presented Zapp - http://www.amazon.co.uk/Zapp-Lightning-Empowerment-William-Byham/dp/07126803... and urged everyone to consider how we can ALL help each send sparks of excitement (aka Zapp) to encourage better things. This seemed to strike a chord in the audience. I wanted to share this - because I certainly appreciate peoples thoughts on all of these topics, but I really donât want to see us have more casualties in our amazing community. So please - try and think âZappâ not âSappâ - and try and use your experience/advice/observations as a way to empower others to make useful change - or consider the direction they may be taking such that they want to do more. Tim p.s. This is easy to say/write - and quite hard to do well. I know we will all make mistakes doing this well - but practicing it is important, and having words like âZappâ and a way to tell each other this is just as important as the code we write. On 28 Aug 2014, at 19:15, kmo <voxkmp@gmail.com> wrote:
philippeback wrote
Building a UI with Morphic alone is what one would use to do something very custom (like a game for example).
Now, creating a larger UI that way is definitely going to be super pain in the assets.
That's where Spec does fit.
Is there any evidence of this? As far as I know no one has built anything more complex than a class browser. I would say Spec was incapable of building a complex interface of any kind. It's clumsy, developer-hostile, and counter-intuitive.
The whole Spec process of writing code in three different places is the very definition of a /super pain in the asset/s. it is far less intuitive to my mind than creating composite morphs.
Progress on Spec is glacially slow - but that's not the problem. Spec is profoundly misconceived and fundamentally flawed and offers nothing over raw Morphic. The Spec model is simply not how anyone would want to build an interface in 2014. I certainly would never use it.
-- View this message in context: http://forum.world.st/Roadmap-on-tools-tp4774285p4775282.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
This reminds me though a bit of Truman Show. Everyone was happy and so was Truman, but Truman was living a lie and in the end he preferred living in the real world than be trapped inside his happy bubble. I think this movie teaches very well the importance of honesty. Also if you really intend to create tools that are according to people needs and wants, its way more important to find what people don't like than people like. Because people mostly and I include myself have no idea what they like apart from a few things here and there but have a very good idea what they don't like. But yes criticism does not mean you have to be rude about it. Just because someone designed something you don't like that does not make him a moron or an idiot or.......... afterall none is the center of the world and none can represent the bulk of users out there, each one of us wants something diffirent. Also most people are easily offended by the truth, I had such an incident during the weekend when I said " Greek computing is still in the stone age" someone near asked me if I am professional coder , he was and obviously offended by my remark but as a lawyer myself heavily dependent on software I explained him in detail what I meant . He assumed that I was implying that we dont have Greeks that excel at coding , software development etc which of course is not the case since I was referring to big Greek software companies and the whole computing policy of my country. We ended up agreeing in many things. So the reality is that truth is a very complex subject and the best way to approach is head on, leaving hurt egos and excessive emotions out of the door and trying to be specific about it . Or else you will end up with a "frozen smile" community that wont be very productive. On Mon, Sep 1, 2014 at 1:21 PM, Tim Mackinnon <tim@testit.works> wrote:
Guys - this reply has interesting content with potentially useful insight, but I really encourage everyone to think about how to best frame these kinds of comments without âsappingâ the energy out of those writing frameworks like Spec. We all need to make sure that we can have healthy debate and iterate on new ideas but without causing others to feel despondent.
We need to energise everyone in our conversations! This was a strong message from ESUG this year (and we didnât always get it right, but we tried to help each other do this).
If there are better ideas out there - you really want someone already working on something (which they may have spent lots of energy on already), to not give up in despair, but to seize the opportunity of new insight and apply their knowledge and creative to get a better outcome OR to iterate on their current solution and apply observations from others to create something better.
At ESUG, this was a topic of conversation for one of the âShow us your projectsâ slots (disclaimer - I presented that topic on the Zapp framework because I found a few of us in the pub going down a more negative path than we had intended). I presented Zapp - http://www.amazon.co.uk/Zapp-Lightning-Empowerment-William-Byham/dp/07126803... and urged everyone to consider how we can ALL help each send sparks of excitement (aka Zapp) to encourage better things. This seemed to strike a chord in the audience.
I wanted to share this - because I certainly appreciate peoples thoughts on all of these topics, but I really donât want to see us have more casualties in our amazing community.
So please - try and think âZappâ not âSappâ - and try and use your experience/advice/observations as a way to empower others to make useful change - or consider the direction they may be taking such that they want to do more.
Tim
p.s. This is easy to say/write - and quite hard to do well. I know we will all make mistakes doing this well - but practicing it is important, and having words like âZappâ and a way to tell each other this is just as important as the code we write.
On 28 Aug 2014, at 19:15, kmo <voxkmp@gmail.com> wrote:
philippeback wrote
Building a UI with Morphic alone is what one would use to do something very custom (like a game for example).
Now, creating a larger UI that way is definitely going to be super pain in the assets.
That's where Spec does fit.
Is there any evidence of this? As far as I know no one has built anything more complex than a class browser. I would say Spec was incapable of building a complex interface of any kind. It's clumsy, developer-hostile, and counter-intuitive.
The whole Spec process of writing code in three different places is the very definition of a /super pain in the asset/s. it is far less intuitive to my mind than creating composite morphs.
Progress on Spec is glacially slow - but that's not the problem. Spec is profoundly misconceived and fundamentally flawed and offers nothing over raw Morphic. The Spec model is simply not how anyone would want to build an interface in 2014. I certainly would never use it.
-- View this message in context: http://forum.world.st/Roadmap-on-tools-tp4774285p4775282.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
A friend of mine ("Makis") is a greek and utterly skilled at programming. Phil On Mon, Sep 1, 2014 at 2:10 PM, kilon alios <kilon.alios@gmail.com> wrote:
This reminds me though a bit of Truman Show. Everyone was happy and so was Truman, but Truman was living a lie and in the end he preferred living in the real world than be trapped inside his happy bubble. I think this movie teaches very well the importance of honesty. Also if you really intend to create tools that are according to people needs and wants, its way more important to find what people don't like than people like. Because people mostly and I include myself have no idea what they like apart from a few things here and there but have a very good idea what they don't like.
But yes criticism does not mean you have to be rude about it. Just because someone designed something you don't like that does not make him a moron or an idiot or.......... afterall none is the center of the world and none can represent the bulk of users out there, each one of us wants something diffirent.
Also most people are easily offended by the truth, I had such an incident during the weekend when I said " Greek computing is still in the stone age" someone near asked me if I am professional coder , he was and obviously offended by my remark but as a lawyer myself heavily dependent on software I explained him in detail what I meant . He assumed that I was implying that we dont have Greeks that excel at coding , software development etc which of course is not the case since I was referring to big Greek software companies and the whole computing policy of my country. We ended up agreeing in many things.
So the reality is that truth is a very complex subject and the best way to approach is head on, leaving hurt egos and excessive emotions out of the door and trying to be specific about it .
Or else you will end up with a "frozen smile" community that wont be very productive.
On Mon, Sep 1, 2014 at 1:21 PM, Tim Mackinnon <tim@testit.works> wrote:
Guys - this reply has interesting content with potentially useful insight, but I really encourage everyone to think about how to best frame these kinds of comments without âsappingâ the energy out of those writing frameworks like Spec. We all need to make sure that we can have healthy debate and iterate on new ideas but without causing others to feel despondent.
We need to energise everyone in our conversations! This was a strong message from ESUG this year (and we didnât always get it right, but we tried to help each other do this).
If there are better ideas out there - you really want someone already working on something (which they may have spent lots of energy on already), to not give up in despair, but to seize the opportunity of new insight and apply their knowledge and creative to get a better outcome OR to iterate on their current solution and apply observations from others to create something better.
At ESUG, this was a topic of conversation for one of the âShow us your projectsâ slots (disclaimer - I presented that topic on the Zapp framework because I found a few of us in the pub going down a more negative path than we had intended). I presented Zapp - http://www.amazon.co.uk/Zapp-Lightning-Empowerment-William-Byham/dp/07126803... and urged everyone to consider how we can ALL help each send sparks of excitement (aka Zapp) to encourage better things. This seemed to strike a chord in the audience.
I wanted to share this - because I certainly appreciate peoples thoughts on all of these topics, but I really donât want to see us have more casualties in our amazing community.
So please - try and think âZappâ not âSappâ - and try and use your experience/advice/observations as a way to empower others to make useful change - or consider the direction they may be taking such that they want to do more.
Tim
p.s. This is easy to say/write - and quite hard to do well. I know we will all make mistakes doing this well - but practicing it is important, and having words like âZappâ and a way to tell each other this is just as important as the code we write.
On 28 Aug 2014, at 19:15, kmo <voxkmp@gmail.com> wrote:
philippeback wrote
Building a UI with Morphic alone is what one would use to do something very custom (like a game for example).
Now, creating a larger UI that way is definitely going to be super pain in the assets.
That's where Spec does fit.
Is there any evidence of this? As far as I know no one has built anything more complex than a class browser. I would say Spec was incapable of building a complex interface of any kind. It's clumsy, developer-hostile, and counter-intuitive.
The whole Spec process of writing code in three different places is the very definition of a /super pain in the asset/s. it is far less intuitive to my mind than creating composite morphs.
Progress on Spec is glacially slow - but that's not the problem. Spec is profoundly misconceived and fundamentally flawed and offers nothing over raw Morphic. The Spec model is simply not how anyone would want to build an interface in 2014. I certainly would never use it.
-- View this message in context: http://forum.world.st/Roadmap-on-tools-tp4774285p4775282.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Mon, Aug 25, 2014 at 11:17 PM, Alain Rastoul <alr.dev@free.fr> wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
Yes, apparently spec is distributed now under a dual licence : MIT when used as an external library (not sure what it means when you use Smalltalk) and GPL when integrated in an IDE ... I think that this is a potential problem for Pharo. https://github.com/spec-framework/spec#license -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On 26 Aug 2014, at 10:03, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Aug 25, 2014 at 11:17 PM, Alain Rastoul <alr.dev@free.fr> wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
Yes, apparently spec is distributed now under a dual licence : MIT when used as an external library (not sure what it means when you use Smalltalk) and GPL when integrated in an IDE ... I think that this is a potential problem for Pharo.
GPL is not compatible with Pharo. All code that is part of the Pharo main distribution is either historical (Apple Licence) or MIT. We even let people sign a document that makes this clear. New code has to be MIT, we do not accept any other license (as part of the main distribution). e.g. Zinc was done because the HTTP server we were using was made GPL (it did not have a licence when we started to use it). Marcus
On Tue, Aug 26, 2014 at 10:10 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Aug 2014, at 10:03, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Aug 25, 2014 at 11:17 PM, Alain Rastoul <alr.dev@free.fr> wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
Yes, apparently spec is distributed now under a dual licence : MIT when used as an external library (not sure what it means when you use Smalltalk) and GPL when integrated in an IDE ... I think that this is a potential problem for Pharo.
GPL is not compatible with Pharo. All code that is part of the Pharo main distribution is either historical (Apple Licence) or MIT.
We even let people sign a document that makes this clear.
New code has to be MIT, we do not accept any other license (as part of the main distribution).
e.g. Zinc was done because the HTTP server we were using was made GPL (it did not have a licence when we started to use it).
I completely agree with you. This why I was worried with this double licencing of spec. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Hi all, Since the code of Spec has been integrated in Pharo when it was MIT, I think that this is not a problem. To me, the new licence only apply to the new code in the repository of Spec since the licence changed. So now, no spec code should be loaded in the Pharo base image. Cheers, Luc 2014-08-26 10:18 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com>:
On Tue, Aug 26, 2014 at 10:10 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Aug 2014, at 10:03, Serge Stinckwich <serge.stinckwich@gmail.com>
wrote:
On Mon, Aug 25, 2014 at 11:17 PM, Alain Rastoul <alr.dev@free.fr>
wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
Yes, apparently spec is distributed now under a dual licence : MIT when used as an external library (not sure what it means when you use Smalltalk) and GPL when integrated in an IDE ... I think that this is a potential problem for Pharo.
GPL is not compatible with Pharo. All code that is part of the Pharo main distribution is either historical (Apple Licence) or MIT.
We even let people sign a document that makes this clear.
New code has to be MIT, we do not accept any other license (as part of the main distribution).
e.g. Zinc was done because the HTTP server we were using was made GPL (it did not have a licence when we started to use it).
I completely agree with you. This why I was worried with this double licencing of spec.
Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Due to Ben leaving, we have one MIT version and his version. Now, we will have the Pharo fork and his version. Maybe is it time to fork the repo and get our own under the Pharo project. Phil On Tue, Aug 26, 2014 at 10:22 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi all,
Since the code of Spec has been integrated in Pharo when it was MIT, I think that this is not a problem. To me, the new licence only apply to the new code in the repository of Spec since the licence changed. So now, no spec code should be loaded in the Pharo base image.
Cheers,
Luc
2014-08-26 10:18 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com>:
On Tue, Aug 26, 2014 at 10:10 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Aug 2014, at 10:03, Serge Stinckwich <serge.stinckwich@gmail.com>
wrote:
On Mon, Aug 25, 2014 at 11:17 PM, Alain Rastoul <alr.dev@free.fr>
wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
Yes, apparently spec is distributed now under a dual licence : MIT when used as an external library (not sure what it means when you use Smalltalk) and GPL when integrated in an IDE ... I think that this is a potential problem for Pharo.
GPL is not compatible with Pharo. All code that is part of the Pharo main distribution is either historical (Apple Licence) or MIT.
We even let people sign a document that makes this clear.
New code has to be MIT, we do not accept any other license (as part of the main distribution).
e.g. Zinc was done because the HTTP server we were using was made GPL (it did not have a licence when we started to use it).
I completely agree with you. This why I was worried with this double licencing of spec.
Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
There is another option: work together again. On 26 Aug 2014, at 10:56, phil@highoctane.be wrote:
Due to Ben leaving, we have one MIT version and his version. Now, we will have the Pharo fork and his version.
Maybe is it time to fork the repo and get our own under the Pharo project.
Phil
On Tue, Aug 26, 2014 at 10:22 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote: Hi all,
Since the code of Spec has been integrated in Pharo when it was MIT, I think that this is not a problem. To me, the new licence only apply to the new code in the repository of Spec since the licence changed. So now, no spec code should be loaded in the Pharo base image.
Cheers,
Luc
2014-08-26 10:18 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com>: On Tue, Aug 26, 2014 at 10:10 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Aug 2014, at 10:03, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Aug 25, 2014 at 11:17 PM, Alain Rastoul <alr.dev@free.fr> wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
Yes, apparently spec is distributed now under a dual licence : MIT when used as an external library (not sure what it means when you use Smalltalk) and GPL when integrated in an IDE ... I think that this is a potential problem for Pharo.
GPL is not compatible with Pharo. All code that is part of the Pharo main distribution is either historical (Apple Licence) or MIT.
We even let people sign a document that makes this clear.
New code has to be MIT, we do not accept any other license (as part of the main distribution).
e.g. Zinc was done because the HTTP server we were using was made GPL (it did not have a licence when we started to use it).
I completely agree with you. This why I was worried with this double licencing of spec.
Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On 26 Aug 2014, at 10:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
There is another option: work together again.
Is an option, in theory. But doesnât looks like happening any time soon, sadly :( Esteban
On 26 Aug 2014, at 10:56, phil@highoctane.be wrote:
Due to Ben leaving, we have one MIT version and his version. Now, we will have the Pharo fork and his version.
Maybe is it time to fork the repo and get our own under the Pharo project.
Phil
On Tue, Aug 26, 2014 at 10:22 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote: Hi all,
Since the code of Spec has been integrated in Pharo when it was MIT, I think that this is not a problem. To me, the new licence only apply to the new code in the repository of Spec since the licence changed. So now, no spec code should be loaded in the Pharo base image.
Cheers,
Luc
2014-08-26 10:18 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com>: On Tue, Aug 26, 2014 at 10:10 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Aug 2014, at 10:03, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Aug 25, 2014 at 11:17 PM, Alain Rastoul <alr.dev@free.fr> wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
Yes, apparently spec is distributed now under a dual licence : MIT when used as an external library (not sure what it means when you use Smalltalk) and GPL when integrated in an IDE ... I think that this is a potential problem for Pharo.
GPL is not compatible with Pharo. All code that is part of the Pharo main distribution is either historical (Apple Licence) or MIT.
We even let people sign a document that makes this clear.
New code has to be MIT, we do not accept any other license (as part of the main distribution).
e.g. Zinc was done because the HTTP server we were using was made GPL (it did not have a licence when we started to use it).
I completely agree with you. This why I was worried with this double licencing of spec.
Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On 26 Aug 2014, at 11:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 26 Aug 2014, at 10:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
There is another option: work together again.
Is an option, in theory. But doesnât looks like happening any time soon, sadly :(
Well, everybody loses by forking.
Esteban
On 26 Aug 2014, at 10:56, phil@highoctane.be wrote:
Due to Ben leaving, we have one MIT version and his version. Now, we will have the Pharo fork and his version.
Maybe is it time to fork the repo and get our own under the Pharo project.
Phil
On Tue, Aug 26, 2014 at 10:22 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote: Hi all,
Since the code of Spec has been integrated in Pharo when it was MIT, I think that this is not a problem. To me, the new licence only apply to the new code in the repository of Spec since the licence changed. So now, no spec code should be loaded in the Pharo base image.
Cheers,
Luc
2014-08-26 10:18 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com>: On Tue, Aug 26, 2014 at 10:10 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Aug 2014, at 10:03, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Aug 25, 2014 at 11:17 PM, Alain Rastoul <alr.dev@free.fr> wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
Yes, apparently spec is distributed now under a dual licence : MIT when used as an external library (not sure what it means when you use Smalltalk) and GPL when integrated in an IDE ... I think that this is a potential problem for Pharo.
GPL is not compatible with Pharo. All code that is part of the Pharo main distribution is either historical (Apple Licence) or MIT.
We even let people sign a document that makes this clear.
New code has to be MIT, we do not accept any other license (as part of the main distribution).
e.g. Zinc was done because the HTTP server we were using was made GPL (it did not have a licence when we started to use it).
I completely agree with you. This why I was worried with this double licencing of spec.
Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On 26 Aug 2014, at 11:42, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Aug 2014, at 11:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 26 Aug 2014, at 10:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
There is another option: work together again.
Is an option, in theory. But doesnât looks like happening any time soon, sadly :(
Well, everybody loses by forking.
yes, but it was not our decision. Is just the only thing we can do now (well, we could also remove spec from Pharo, thatâs also possible in theory) Esteban
Esteban
On 26 Aug 2014, at 10:56, phil@highoctane.be wrote:
Due to Ben leaving, we have one MIT version and his version. Now, we will have the Pharo fork and his version.
Maybe is it time to fork the repo and get our own under the Pharo project.
Phil
On Tue, Aug 26, 2014 at 10:22 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote: Hi all,
Since the code of Spec has been integrated in Pharo when it was MIT, I think that this is not a problem. To me, the new licence only apply to the new code in the repository of Spec since the licence changed. So now, no spec code should be loaded in the Pharo base image.
Cheers,
Luc
2014-08-26 10:18 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com>: On Tue, Aug 26, 2014 at 10:10 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Aug 2014, at 10:03, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Aug 25, 2014 at 11:17 PM, Alain Rastoul <alr.dev@free.fr> wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
Yes, apparently spec is distributed now under a dual licence : MIT when used as an external library (not sure what it means when you use Smalltalk) and GPL when integrated in an IDE ... I think that this is a potential problem for Pharo.
GPL is not compatible with Pharo. All code that is part of the Pharo main distribution is either historical (Apple Licence) or MIT.
We even let people sign a document that makes this clear.
New code has to be MIT, we do not accept any other license (as part of the main distribution).
e.g. Zinc was done because the HTTP server we were using was made GPL (it did not have a licence when we started to use it).
I completely agree with you. This why I was worried with this double licencing of spec.
Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On Tue, Aug 26, 2014 at 11:42 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Aug 2014, at 11:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 26 Aug 2014, at 10:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
There is another option: work together again.
Is an option, in theory. But doesnât looks like happening any time soon,
sadly :(
Well, everybody loses by forking.
Sure but for Ben new commits will be GPL. Pull requests included. Basically, we are fucked on that line I'd say. Pharo is a fork and not too bad at that. Sometimes, one needs to throw the baggage out of the train. Right away through the window when the train is going. The less we muddle with this, the more we can refocus again. The key point is to get a new maintainer who is as good as Ben. I mourn the loss and would love to see him back (along with a couple of other people, like Lukas, Adrian, Cami, etc). As a community maybe we can become better at damage control. These were high caliber individuals and contributors. Phil
Esteban
On 26 Aug 2014, at 10:56, phil@highoctane.be wrote:
Due to Ben leaving, we have one MIT version and his version. Now, we will have the Pharo fork and his version.
Maybe is it time to fork the repo and get our own under the Pharo
project.
Phil
On Tue, Aug 26, 2014 at 10:22 AM, Luc Fabresse <luc.fabresse@gmail.com>
wrote:
Hi all,
Since the code of Spec has been integrated in Pharo when it was MIT, I think that this is not a problem. To me, the new licence only apply to the new code in the repository of Spec since the licence changed. So now, no spec code should be loaded in the Pharo base image.
Cheers,
Luc
2014-08-26 10:18 GMT+02:00 Serge Stinckwich < serge.stinckwich@gmail.com>: On Tue, Aug 26, 2014 at 10:10 AM, Marcus Denker < marcus.denker@inria.fr> wrote:
On 26 Aug 2014, at 10:03, Serge Stinckwich <
serge.stinckwich@gmail.com> wrote:
On Mon, Aug 25, 2014 at 11:17 PM, Alain Rastoul <alr.dev@free.fr>
wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
Yes, apparently spec is distributed now under a dual licence : MIT when used as an external library (not sure what it means when you use Smalltalk) and GPL when integrated in an IDE ... I think that this is a potential problem for Pharo.
GPL is not compatible with Pharo. All code that is part of the Pharo main distribution is either historical (Apple Licence) or MIT.
We even let people sign a document that makes this clear.
New code has to be MIT, we do not accept any other license (as part of the main distribution).
e.g. Zinc was done because the HTTP server we were using was made GPL (it did not have a licence when we started to use it).
I completely agree with you. This why I was worried with this double licencing of spec.
Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On 26 Aug 2014, at 11:50, phil@highoctane.be wrote:
On Tue, Aug 26, 2014 at 11:42 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Aug 2014, at 11:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 26 Aug 2014, at 10:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
There is another option: work together again.
Is an option, in theory. But doesnât looks like happening any time soon, sadly :(
Well, everybody loses by forking.
Sure but for Ben new commits will be GPL. Pull requests included. Basically, we are fucked on that line I'd say.
@Phil Look, I don't want to defend or attack either party and the recent license change is a bit dubious, like Marcus said. But for the sake of argument, I think your conclusion is wrong: he says/wants Spec to be managed as an external library that gets integrated back to Pharo from time to time. When doing so, everything remains MIT licensed. Else he wants it to be GPL-ed so that it cannot be integrated in Pharo. @Esteban But again: if there is a conflict there are always two solutions, solve it or part ways. Saying the other party made me do it is the same as saying I am right and he is wrong (and this goes for both sides ;-) Maybe we should start another thread about this. Because the basic question is not about a license or a name change but about how to work together and about control, specifically for parts and/or developers that are external. I know that this is a complex discussion, but if we in general have problems of working modular than we are in trouble, no ? Sven
If Benjamin does not intend to continue developing in Pharo , that means he will not continue developing Spec. So in any case you need to talk to him and see exactly what his intentions are. But if he does not want to let us use it as integrated library for Pharo then I don't think you guys have much of a choice. One thing to remember here is that licenses extend to modification and extensions, that means that anyone who makes an extension to Spec or a Spec based app cannot integrate it to Pharo so already Pharo tools using Spec are against the dual license. Personally I would not use such library for my projects because I do care integrating some of my code back to Pharo to contribute to the progress of Pharo. On Tue, Aug 26, 2014 at 1:22 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Aug 2014, at 11:50, phil@highoctane.be wrote:
On Tue, Aug 26, 2014 at 11:42 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Aug 2014, at 11:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 26 Aug 2014, at 10:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
There is another option: work together again.
Is an option, in theory. But doesnât looks like happening any time
soon, sadly :(
Well, everybody loses by forking.
Sure but for Ben new commits will be GPL. Pull requests included. Basically, we are fucked on that line I'd say.
@Phil
Look, I don't want to defend or attack either party and the recent license change is a bit dubious, like Marcus said. But for the sake of argument, I think your conclusion is wrong: he says/wants Spec to be managed as an external library that gets integrated back to Pharo from time to time. When doing so, everything remains MIT licensed. Else he wants it to be GPL-ed so that it cannot be integrated in Pharo.
@Esteban
But again: if there is a conflict there are always two solutions, solve it or part ways. Saying the other party made me do it is the same as saying I am right and he is wrong (and this goes for both sides ;-)
Maybe we should start another thread about this. Because the basic question is not about a license or a name change but about how to work together and about control, specifically for parts and/or developers that are external. I know that this is a complex discussion, but if we in general have problems of working modular than we are in trouble, no ?
Sven
On Tue, Aug 26, 2014 at 12:53 PM, kilon alios <kilon.alios@gmail.com> wrote:
If Benjamin does not intend to continue developing in Pharo , that means he will not continue developing Spec. So in any case you need to talk to him and see exactly what his intentions are.
But if he does not want to let us use it as integrated library for Pharo then I don't think you guys have much of a choice. One thing to remember here is that licenses extend to modification and extensions, that means that anyone who makes an extension to Spec or a Spec based app cannot integrate it to Pharo so already Pharo tools using Spec are against the dual license. Personally I would not use such library for my projects because I do care integrating some of my code back to Pharo to contribute to the progress of Pharo.
Spec has been developed under MIT. From there, before the license change, we can fork and do whatever we want. Furthermore, contributors have signed a paper. And Ben has been publishing papers etc, under a budget. So, we can fork and change what we need to. What we cannot do is take the new stuff Ben would do. But as you say, this looks like a dead end anyway. What the heck, we can take Spec from where it is now, this is a core Pharo asset, and make it work and grow, it is not like this tool is done by the way, far from it. And Spec is not Morphic only, it is for all kinds of rendering backends (Seaside, Morphic, Bloc maybe). Phil
On Tue, Aug 26, 2014 at 1:22 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Aug 2014, at 11:50, phil@highoctane.be wrote:
On Tue, Aug 26, 2014 at 11:42 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Aug 2014, at 11:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 26 Aug 2014, at 10:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
There is another option: work together again.
Is an option, in theory. But doesnât looks like happening any time
soon, sadly :(
Well, everybody loses by forking.
Sure but for Ben new commits will be GPL. Pull requests included. Basically, we are fucked on that line I'd say.
@Phil
Look, I don't want to defend or attack either party and the recent license change is a bit dubious, like Marcus said. But for the sake of argument, I think your conclusion is wrong: he says/wants Spec to be managed as an external library that gets integrated back to Pharo from time to time. When doing so, everything remains MIT licensed. Else he wants it to be GPL-ed so that it cannot be integrated in Pharo.
@Esteban
But again: if there is a conflict there are always two solutions, solve it or part ways. Saying the other party made me do it is the same as saying I am right and he is wrong (and this goes for both sides ;-)
Maybe we should start another thread about this. Because the basic question is not about a license or a name change but about how to work together and about control, specifically for parts and/or developers that are external. I know that this is a complex discussion, but if we in general have problems of working modular than we are in trouble, no ?
Sven
ours is already part of the pharo core. we should save the corresponding packages in Pharo/Spec project. Esteban On 26 Aug 2014, at 10:56, phil@highoctane.be wrote:
Due to Ben leaving, we have one MIT version and his version. Now, we will have the Pharo fork and his version.
Maybe is it time to fork the repo and get our own under the Pharo project.
Phil
On Tue, Aug 26, 2014 at 10:22 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote: Hi all,
Since the code of Spec has been integrated in Pharo when it was MIT, I think that this is not a problem. To me, the new licence only apply to the new code in the repository of Spec since the licence changed. So now, no spec code should be loaded in the Pharo base image.
Cheers,
Luc
2014-08-26 10:18 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com>: On Tue, Aug 26, 2014 at 10:10 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Aug 2014, at 10:03, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Aug 25, 2014 at 11:17 PM, Alain Rastoul <alr.dev@free.fr> wrote:
+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion)
Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ?
Yes, apparently spec is distributed now under a dual licence : MIT when used as an external library (not sure what it means when you use Smalltalk) and GPL when integrated in an IDE ... I think that this is a potential problem for Pharo.
GPL is not compatible with Pharo. All code that is part of the Pharo main distribution is either historical (Apple Licence) or MIT.
We even let people sign a document that makes this clear.
New code has to be MIT, we do not accept any other license (as part of the main distribution).
e.g. Zinc was done because the HTTP server we were using was made GPL (it did not have a licence when we started to use it).
I completely agree with you. This why I was worried with this double licencing of spec.
Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On 26 Aug 2014, at 10:18, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
GPL is not compatible with Pharo. All code that is part of the Pharo main distribution is either historical (Apple Licence) or MIT.
We even let people sign a document that makes this clear.
New code has to be MIT, we do not accept any other license (as part of the main distribution).
e.g. Zinc was done because the HTTP server we were using was made GPL (it did not have a licence when we started to use it).
I completely agree with you. This why I was worried with this double licencing of spec.
I do not think that you can change a license without getting the OK of all authors, I guess it is a mistake in the config of the project. Marcus
On Tue, Aug 26, 2014 at 10:23 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Aug 2014, at 10:18, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
GPL is not compatible with Pharo. All code that is part of the Pharo main distribution is either historical (Apple Licence) or MIT.
We even let people sign a document that makes this clear.
New code has to be MIT, we do not accept any other license (as part of the main distribution).
e.g. Zinc was done because the HTTP server we were using was made GPL (it did not have a licence when we started to use it).
I completely agree with you. This why I was worried with this double licencing of spec.
I do not think that you can change a license without getting the OK of all authors, I guess it is a mistake in the config of the project.
This is not a mistake, look here: https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f397... -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
I found Ben's dual licensing not clear at all (and explanations and comments even less). â¢GPL v3 license when shipped as part of a programming language, its core libraries and frameworks, or its Integrated Development Environment. â¢MIT license for other cases. As I finally understand it, Pharo would be GPL v3 in all cases. A killer change But as stated in the license agreement (the one found on the old pharo site): "... Supplier hereby grants Distributor a perpetual, irrevocable, non-exclusive, royalty-free, worldwide license to distribute the Software, and specifically the Supplierâs Code therein, to end users, subject to the license agreement commonly known as the âMIT Licenseâ " Ben can change the license of the code he writes to GPL and stop this agreement at that point, but the change in the license is not retroactive, the Pharo version will have to start before revision xxx where it changed and go on it's way. Still there will be a problem in the repository(ies).
On 23/8/14 23:34, Juraj Kubelka wrote:
Hi,
I have found useful those roadmaps: https://github.com/pharo-project/pharo-workingRoadmaps Could it be possible to make one for the Pharo tools (e.g. Nautilus)? I think there are people who have better idea what to make first and what later. I would like to contribute on it and roadmap could help me.
Sure! The point of the roadmap is really listing the feasible steps to improve the system in a regular manner. Create one for Nautilus. - I would remove the bytecode and text icons (which are not consistent with the instance access BTW) - I would remove the history navigation for example Now we will certainly add (but in a modular way) the GT-Inspector. But it does not mean that we should not continue to improve the traditional tools. Stef
Thanks, Juraj
Hi! I have created the Nautilus roadmap (in the pull request). I have taken as a base the recent email of Nicolai Hess. If anyone wants to stress something important or give a link to a bug we should consider, I appreciate it. You can write it here in the mainline list or by changing the roadmap. Thanks, Juraj On Aug 24, 2014, at 2:01 AM, stepharo <stepharo@free.fr> wrote:
On 23/8/14 23:34, Juraj Kubelka wrote:
Hi,
I have found useful those roadmaps: https://github.com/pharo-project/pharo-workingRoadmaps Could it be possible to make one for the Pharo tools (e.g. Nautilus)? I think there are people who have better idea what to make first and what later. I would like to contribute on it and roadmap could help me.
Sure! The point of the roadmap is really listing the feasible steps to improve the system in a regular manner. Create one for Nautilus. - I would remove the bytecode and text icons (which are not consistent with the instance access BTW) - I would remove the history navigation for example
Now we will certainly add (but in a modular way) the GT-Inspector. But it does not mean that we should not continue to improve the traditional tools.
Stef
Thanks, Juraj
This is supercool :) People are taking the "pharo is yours" slogan into the next level. Continue like that, guys! Esteban
On 25 Aug 2014, at 18:40, Juraj Kubelka <juraj.kubelka@gmail.com> wrote:
Hi!
I have created the Nautilus roadmap (in the pull request). I have taken as a base the recent email of Nicolai Hess.
If anyone wants to stress something important or give a link to a bug we should consider, I appreciate it. You can write it here in the mainline list or by changing the roadmap.
Thanks, Juraj
On Aug 24, 2014, at 2:01 AM, stepharo <stepharo@free.fr> wrote:
On 23/8/14 23:34, Juraj Kubelka wrote: Hi,
I have found useful those roadmaps: https://github.com/pharo-project/pharo-workingRoadmaps Could it be possible to make one for the Pharo tools (e.g. Nautilus)? I think there are people who have better idea what to make first and what later. I would like to contribute on it and roadmap could help me.
Sure! The point of the roadmap is really listing the feasible steps to improve the system in a regular manner. Create one for Nautilus. - I would remove the bytecode and text icons (which are not consistent with the instance access BTW) - I would remove the history navigation for example
Now we will certainly add (but in a modular way) the GT-Inspector. But it does not mean that we should not continue to improve the traditional tools.
Stef
Thanks, Juraj
2014-08-25 18:40 GMT+02:00 Juraj Kubelka <juraj.kubelka@gmail.com>:
Hi!
I have created the Nautilus roadmap <https://github.com/pharo-project/pharo-workingRoadmaps> (in the pull request <https://github.com/pharo-project/pharo-workingRoadmaps/pull/3>). I have taken as a base the recent email of Nicolai Hess.
If anyone wants to stress something important or give a link to a bug we should consider, I appreciate it. You can write it here in the mainline list or by changing the roadmap.
Thanks, Juraj
Great! Thank you.
On Aug 24, 2014, at 2:01 AM, stepharo <stepharo@free.fr> wrote:
On 23/8/14 23:34, Juraj Kubelka wrote:
Hi,
I have found useful those roadmaps: https://github.com/pharo-project/pharo-workingRoadmaps Could it be possible to make one for the Pharo tools (e.g. Nautilus)? I think there are people who have better idea what to make first and what later. I would like to contribute on it and roadmap could help me.
Sure! The point of the roadmap is really listing the feasible steps to improve the system in a regular manner. Create one for Nautilus. - I would remove the bytecode and text icons (which are not consistent with the instance access BTW) - I would remove the history navigation for example
Now we will certainly add (but in a modular way) the GT-Inspector. But it does not mean that we should not continue to improve the traditional tools.
Stef
Thanks, Juraj
participants (18)
-
Alain Rastoul -
Alexandre Bergel -
Ben Coman -
Craig Latta -
Esteban A. Maringolo -
Esteban Lorenzano -
Juraj Kubelka -
kilon alios -
kmo -
Luc Fabresse -
Marcus Denker -
Nicolai Hess -
phil＠highoctane.be -
Serge Stinckwich -
stepharo -
Sven Van Caekenberghe -
Tim Mackinnon -
Torsten Bergmann