January 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Older Pharo on MacOS Sierra

by Esteban Lorenzano

Hi, Pharo 4.0 (and related VMs) can be downloaded from here: http://files.pharo.org/get-files/40/ <http://files.pharo.org/get-files/40/> Esteban > On 14 Jan 2017, at 12:19, Hilaire <hilaire(a)drgeo.eu> wrote: > > I don't know yet Jeff. I don't have either a macos sierra at hand. Once > a Mac OS Sierra user reported me the problem your are mentioning[1], but > I did not get very far investigating the problem. > > For me it is not clear at all from[2] if there is any Mac VM 4.0. May be > Esteban can enlighten us. > > [1] http://forum.drgeo.eu/DrGeo-pb-mac-os-Sierra-td4024957.html > [2] http://pharo.org/download > Le 14/01/2017 Ã 11:35, J.F. Rick a Ã©crit : >> So, what's the proper procedure? I just moved my Pharo4 to the >> Application directory and it didn't work? Launched but the window is >> black. Is there a new Pharo4 VM for MacOS? If so, where is it? >> >> Thanks, >> >> Jeff > > -- > Dr. Geo > http://drgeo.eu > >

Jan. 14, 2017

Re: [Pharo-users] About Git

by Offray Vladimir Luna CÃ¡rdenas

On 14/01/17 09:14, Dimitris Chloupis wrote: [...] > > > Remember we have to compete with languages like Ruby and Python . [...] And in the live coding and moldability camp the competition goes pretty well (Ruby has Sonic Pi, Python has Jupyter, for other audience, but none of those are as moldable as Pharo or bring so much liveness to coding, and not all competition is for the soul and heart of developers, there is a wider world were we can offer a pretty interesting value proposal > So basically the mentality here is "give me Iceberg so I do not have > to learn Git or work like Git" , yeah good luck with that one. > > I am not against Iceberg but I am sure it will be used as an excuse , > like with many other things to bash Git and other non-Smalltalk > technologies, each time it fails. I agree with not having git in front. So yes, I will wait for Iceberg and will use StHub as much as I can. I share that Smalltalk and Pharo need to be less insular, by supporting external technologies and formats (git, markdown, etc), but the experience should be as smooth as possible and we need ways to map the live coding experience to that external world. > > > I am trying to avoid having this kind of discussions but on the other > hand I do not think all this denial is a good thing for Pharo. > > Another thing I like to stress here, is that your goal to create a > self contained enviroment fully implemented in Smalltalk sorry I meant > Pharo, will not happens. > > Gone are the times of 70, 80s and even 90s that a simple GUI could cut > it. Nowdays a modern coder uses a vast array of tools at his arsenal > because coding has become very complex to accomodate the high > expectations of modern users. We do not have the time, the money or > the community to build a tool that can compete on equal terms with the > ocean of tools that exist out there. > I don't know if denial is the proper world. I have said before I do not want become part of a holy war anytime someone mentions a DVCS that is not git or markup that is no pillar and so on, but I think that we, as a community are getting better at increasing diversity, despite of our own passion for some technologies. I don't think that the proper way is fully implementing all in Smalltalk, but "internalizing" the environment in the language as much as we can (in a similar way to Racket people). FileSystem or ZipArchive are a good examples of how to talk with the environment while being inside Pharo making the OS invisible for the user and with a smoother experience. "Internalizing" the environment in the language is the key to keep community and technologies diverse, while keeping the fluid experience of live coding in Pharo. Cheers, Offray > People do not use Git because they cannot use far simpler VCS , of > course not. They use because they know that projects grow and demands > changes and the time comes that they wish they have picked Git in the > first place because the more the project grows the more difficult it > becomes to switch VCS.

Jan. 14, 2017

Re: [Pharo-users] About Git

by Dimitris Chloupis

We agree that we disagree, that's ok , we all have our own ways we like to work. On Sat, 14 Jan 2017 at 17:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > We disagree, I should not have responded. > > > > Eclipse, IntelliJ, Emacs and so many other IDEs with massive user bases > all try to make things nice and easy to use inside their own IDE, to give > developers a cool, intelligent, language aware workflow. Of course Pharo > wants to do the same without being an island. > > > > Pharo/Smalltalk will never become a flat file based language. > > > > And yes, the pull request example was too big, but if it is only two minor > changes, any tool will do, if it is complex, all tools suffer, that is my > opinion. > > > > About your list of points: > > > > > My reason for not liking Monticello > > > a) GUI looks ugly > > > > Is an opinion > > > > > b) GUI opens needless windows (a generic Pharo problem) > > > > Is an opinion > > > > > c) No syntax highlighting in case of Browsing online code (diffs, > changes etc) > > > > An annoyance, not impossible to fix > > > > > d) No visualization of the commit history. > > > > Ok > > > > > e) the usual problems with documentation > > > > Not directly relevant here > > > > > f) No easy undo functionality > > > > Ok > > > > > g) Need to press a refresh button for monticello to be kept up to date > > > > An implementation detail > > > > > h) Monticello contacts irrelevant online repos even for local commits, > as a result a slow connection can freeze the image (WTF) > > > > It can be turned off, but yes it is annoying, although the reason for this > behaviour can be explained I also don't like this. > > > > > i) No clear indication of where the history branches and where it merges > > > > Same as d) > > > > This biggest issue is that it is not easy to get standard resources inside > MC. > > > > > > > On 14 Jan 2017, at 15:14, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > > > > > > > > > On Sat, Jan 14, 2017 at 3:21 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > > > On 14 Jan 2017, at 12:58, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > > > > > I fail to see what is user friendly about Monticello , I find its GUI > and the total workflow really bad, certainly the worst VCS GUI I have ever > used. But I will admit this is my personal taste and my opinion that can be > safely ignore. > > > > > > That is your opinion and you are entitled to it, but I am pretty sure > you don't speak for the majority of Smalltalk users in general. > > > > > > > > > The only way to know for sure is to do some form of survey, but as I > said its my opinion. Even if others agree with me, we still may have > different opinions. > > > > > > I don't understand what is bad about MC in the IDE: your code is easily > put in packages, you look at changes at the method and class definition > level, you compare and commit, look at incoming changes and that's it. > Merging is just as easy or difficult as anywhere else. > > > > > > > > > My reason for not liking Monticello > > > a) GUI looks ugly > > > b) GUI opens needless windows (a generic Pharo problem) > > > c) No syntax highlighting in case of Browsing online code (diffs, > changes etc) > > > d) No visualization of the commit history. > > > e) the usual problems with documentation > > > f) No easy undo functionality > > > g) Need to press a refresh button for monticello to be kept up to date > > > h) Monticello contacts irrelevant online repos even for local commits, > as a result a slow connection can freeze the image (WTF) > > > i) No clear indication of where the history branches and where it merges > > > > > > and the list goes on , but those are the main > > > > > > I wonder even if Monticello improved at all since Pharo forked from > Squeak. > > > > > > It is true that StHub is not actively maintained, but that does not > change the fact that it just works. Indeed certain features were/are > missing, nothing is perfect. Given the load is has to endure it is pretty > stable (remember that SqueakSource collapsed under the Pharo load) even if > it needs an occasional reset. > > > > > > "nothing is perfect" is a lousy excuse and a cliche. Yes it works but > this is not the image I think that will inspire newcomers to use Pharo. > > > > > > Remember we have to compete with languages like Ruby and Python . > > > > > > Here is an example. I have this pull request open > > > > > > https://github.com/svenvc/ston/pull/17/files > > > > > > it is so big, changes so much that I cannot even begin figuring out what > happened. I want my in-IDE tools that understand Smalltalk. > > > > > > > > > One sec... one sec > > > are you trying to tell me that this a good commit ? > > > > https://github.com/svenvc/ston/pull/17/commits/5c03481aeda7804317e6d9efbb76… > > > > > > seriously ? > > > > > > 84 files changed in ONE commit ? > > > > > > seriously ? > > > > > > please do not blame Git if you guys have terrible workflows. This would > be even bigger mess with the Pharo VCS . > > > > > > But this definitely not a good way to use Git or any VCS. > > > > > > Let be serious here, I know you guys love Smalltalk > > > But common > > > A bit of common sense would not hurt. > > > If someone have sent me such a pull request I would have rejected it in > an instant without even looking at the code. > > > > > > But if you guys like to deal with this kind of mess inside the Pharo > image, be my guest. I prefer the Git way of using Git and not the > "whatever" way and avoid the mess as much as possible. > > > > > > One day (soon) the new tools (Iceberg ?) will allow me to do that, allow > me to see git as just an opaque back end, allow me to remain inside the > Pharo IDE (again, not that I can not or do not work in a terminal, far from > it, I just don't want to for my Pharo workflow) > > > > > > So basically the mentality here is "give me Iceberg so I do not have to > learn Git or work like Git" , yeah good luck with that one. > > > > > > I am not against Iceberg but I am sure it will be used as an excuse , > like with many other things to bash Git and other non-Smalltalk > technologies, each time it fails. > > > > > > You already compare Iceberg with using Git from the terminal. Of course > you will not mention SourceTree , GitUP, SmartGit , GitKraken and a ton of > other brilliant Git GUIs . Hell even Github offers its own Git GUI client > that makes using Git a breeze. > > > > > > I think you greatly overestimate the opinion that people have about > Smalltalk, I can assure you its both positive and negative and VCS falls > under the negative category. I would like to see a community that treats > Smalltalk not as the holy grail. > > > > > > The pull request example you used against Pharo and Git shows exactly > this kind of attitude , taking extremely bad situations that can be easily > be avoided as an excuse to present Smalltalk as "the superior tool". > > > > > > And when people do not bite the bait, you blame Smalltalk and emphasize > that Pharo is not really Smalltalk but Smalltalk inspired. > > > > > > I have never been part of this ideology and will never going to be. > > > > > > You guys are amazing and building a great tools, but in so many cases > you just lose touch with reality. > > > > > > You ask me how many Smalltalkers agree with me, let me ask you how many > coders in general you think would agree with you ? > > > > > > I am trying to avoid having this kind of discussions but on the other > hand I do not think all this denial is a good thing for Pharo. > > > > > > Another thing I like to stress here, is that your goal to create a self > contained enviroment fully implemented in Smalltalk sorry I meant Pharo, > will not happens. > > > > > > > > > Gone are the times of 70, 80s and even 90s that a simple GUI could cut > it. Nowdays a modern coder uses a vast array of tools at his arsenal > because coding has become very complex to accomodate the high expectations > of modern users. We do not have the time, the money or the community to > build a tool that can compete on equal terms with the ocean of tools that > exist out there. > > > > > > People do not use Git because they cannot use far simpler VCS , of > course not. They use because they know that projects grow and demands > changes and the time comes that they wish they have picked Git in the first > place because the more the project grows the more difficult it becomes to > switch VCS. > > > > > >

Jan. 14, 2017

Re: [Pharo-users] About Git

by Sven Van Caekenberghe

We disagree, I should not have responded. Eclipse, IntelliJ, Emacs and so many other IDEs with massive user bases all try to make things nice and easy to use inside their own IDE, to give developers a cool, intelligent, language aware workflow. Of course Pharo wants to do the same without being an island. Pharo/Smalltalk will never become a flat file based language. And yes, the pull request example was too big, but if it is only two minor changes, any tool will do, if it is complex, all tools suffer, that is my opinion. About your list of points: > My reason for not liking Monticello > a) GUI looks ugly Is an opinion > b) GUI opens needless windows (a generic Pharo problem) Is an opinion > c) No syntax highlighting in case of Browsing online code (diffs, changes etc) An annoyance, not impossible to fix > d) No visualization of the commit history. Ok > e) the usual problems with documentation Not directly relevant here > f) No easy undo functionality Ok > g) Need to press a refresh button for monticello to be kept up to date An implementation detail > h) Monticello contacts irrelevant online repos even for local commits, as a result a slow connection can freeze the image (WTF) It can be turned off, but yes it is annoying, although the reason for this behaviour can be explained I also don't like this. > i) No clear indication of where the history branches and where it merges Same as d) This biggest issue is that it is not easy to get standard resources inside MC. > On 14 Jan 2017, at 15:14, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > > On Sat, Jan 14, 2017 at 3:21 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 14 Jan 2017, at 12:58, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > > I fail to see what is user friendly about Monticello , I find its GUI and the total workflow really bad, certainly the worst VCS GUI I have ever used. But I will admit this is my personal taste and my opinion that can be safely ignore. > > That is your opinion and you are entitled to it, but I am pretty sure you don't speak for the majority of Smalltalk users in general. > > > The only way to know for sure is to do some form of survey, but as I said its my opinion. Even if others agree with me, we still may have different opinions. > > I don't understand what is bad about MC in the IDE: your code is easily put in packages, you look at changes at the method and class definition level, you compare and commit, look at incoming changes and that's it. Merging is just as easy or difficult as anywhere else. > > > My reason for not liking Monticello > a) GUI looks ugly > b) GUI opens needless windows (a generic Pharo problem) > c) No syntax highlighting in case of Browsing online code (diffs, changes etc) > d) No visualization of the commit history. > e) the usual problems with documentation > f) No easy undo functionality > g) Need to press a refresh button for monticello to be kept up to date > h) Monticello contacts irrelevant online repos even for local commits, as a result a slow connection can freeze the image (WTF) > i) No clear indication of where the history branches and where it merges > > and the list goes on , but those are the main > > I wonder even if Monticello improved at all since Pharo forked from Squeak. > > It is true that StHub is not actively maintained, but that does not change the fact that it just works. Indeed certain features were/are missing, nothing is perfect. Given the load is has to endure it is pretty stable (remember that SqueakSource collapsed under the Pharo load) even if it needs an occasional reset. > > "nothing is perfect" is a lousy excuse and a cliche. Yes it works but this is not the image I think that will inspire newcomers to use Pharo. > > Remember we have to compete with languages like Ruby and Python . > > Here is an example. I have this pull request open > > https://github.com/svenvc/ston/pull/17/files > > it is so big, changes so much that I cannot even begin figuring out what happened. I want my in-IDE tools that understand Smalltalk. > > > One sec... one sec > are you trying to tell me that this a good commit ? > https://github.com/svenvc/ston/pull/17/commits/5c03481aeda7804317e6d9efbb76… > > seriously ? > > 84 files changed in ONE commit ? > > seriously ? > > please do not blame Git if you guys have terrible workflows. This would be even bigger mess with the Pharo VCS . > > But this definitely not a good way to use Git or any VCS. > > Let be serious here, I know you guys love Smalltalk > But common > A bit of common sense would not hurt. > If someone have sent me such a pull request I would have rejected it in an instant without even looking at the code. > > But if you guys like to deal with this kind of mess inside the Pharo image, be my guest. I prefer the Git way of using Git and not the "whatever" way and avoid the mess as much as possible. > > One day (soon) the new tools (Iceberg ?) will allow me to do that, allow me to see git as just an opaque back end, allow me to remain inside the Pharo IDE (again, not that I can not or do not work in a terminal, far from it, I just don't want to for my Pharo workflow) > > So basically the mentality here is "give me Iceberg so I do not have to learn Git or work like Git" , yeah good luck with that one. > > I am not against Iceberg but I am sure it will be used as an excuse , like with many other things to bash Git and other non-Smalltalk technologies, each time it fails. > > You already compare Iceberg with using Git from the terminal. Of course you will not mention SourceTree , GitUP, SmartGit , GitKraken and a ton of other brilliant Git GUIs . Hell even Github offers its own Git GUI client that makes using Git a breeze. > > I think you greatly overestimate the opinion that people have about Smalltalk, I can assure you its both positive and negative and VCS falls under the negative category. I would like to see a community that treats Smalltalk not as the holy grail. > > The pull request example you used against Pharo and Git shows exactly this kind of attitude , taking extremely bad situations that can be easily be avoided as an excuse to present Smalltalk as "the superior tool". > > And when people do not bite the bait, you blame Smalltalk and emphasize that Pharo is not really Smalltalk but Smalltalk inspired. > > I have never been part of this ideology and will never going to be. > > You guys are amazing and building a great tools, but in so many cases you just lose touch with reality. > > You ask me how many Smalltalkers agree with me, let me ask you how many coders in general you think would agree with you ? > > I am trying to avoid having this kind of discussions but on the other hand I do not think all this denial is a good thing for Pharo. > > Another thing I like to stress here, is that your goal to create a self contained enviroment fully implemented in Smalltalk sorry I meant Pharo, will not happens. > Gone are the times of 70, 80s and even 90s that a simple GUI could cut it. Nowdays a modern coder uses a vast array of tools at his arsenal because coding has become very complex to accomodate the high expectations of modern users. We do not have the time, the money or the community to build a tool that can compete on equal terms with the ocean of tools that exist out there. > > People do not use Git because they cannot use far simpler VCS , of course not. They use because they know that projects grow and demands changes and the time comes that they wish they have picked Git in the first place because the more the project grows the more difficult it becomes to switch VCS.

Jan. 14, 2017

Re: [Pharo-users] Google visibility?

by Dimitris Chloupis

fair enough, its a free world :) On Sat, Jan 14, 2017 at 4:58 PM Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > Hi, > > > On 14/01/17 06:58, Dimitris Chloupis wrote: > > [...] > > > > I also never said "Do not use Pharo VCS" , if that is what rocks your > > boat, but to actual claim that Pharo VCS is more reliable, easier to > > use and more powerful would require a huge leap of faith because from > > the very first experience it pretty crystal clear that is not. > > > > And there is not just Git, there are plenty of other VCS out there > > that are just light years ahead, some probably better than Git. > > > > [...] > > In our case, with field work with not programmers and newbies, I can > tell there is no leap of faith at all. We have been using external DVCs > and internal ones. The workflow with the later is simpler, they don't > see anything about reliability or difficult. Just update and commit > (fossil is similar in someway). Maybe is the small scale of the project > or the local community, but in this context, git has been really > obtrusive, while StHub for code and fossil for files are not. > > Cheers, > > Offray > >

Jan. 14, 2017

Re: [Pharo-users] Google visibility?

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 14/01/17 06:58, Dimitris Chloupis wrote: [...] > > I also never said "Do not use Pharo VCS" , if that is what rocks your > boat, but to actual claim that Pharo VCS is more reliable, easier to > use and more powerful would require a huge leap of faith because from > the very first experience it pretty crystal clear that is not. > > And there is not just Git, there are plenty of other VCS out there > that are just light years ahead, some probably better than Git. > [...] In our case, with field work with not programmers and newbies, I can tell there is no leap of faith at all. We have been using external DVCs and internal ones. The workflow with the later is simpler, they don't see anything about reliability or difficult. Just update and commit (fossil is similar in someway). Maybe is the small scale of the project or the local community, but in this context, git has been really obtrusive, while StHub for code and fossil for files are not. Cheers, Offray

Jan. 14, 2017

About Git

by Dimitris Chloupis

On Sat, Jan 14, 2017 at 3:21 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 14 Jan 2017, at 12:58, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > I fail to see what is user friendly about Monticello , I find its GUI > and the total workflow really bad, certainly the worst VCS GUI I have ever > used. But I will admit this is my personal taste and my opinion that can be > safely ignore. > > That is your opinion and you are entitled to it, but I am pretty sure you > don't speak for the majority of Smalltalk users in general. > > The only way to know for sure is to do some form of survey, but as I said its my opinion. Even if others agree with me, we still may have different opinions. > I don't understand what is bad about MC in the IDE: your code is easily > put in packages, you look at changes at the method and class definition > level, you compare and commit, look at incoming changes and that's it. > Merging is just as easy or difficult as anywhere else. > > My reason for not liking Monticello a) GUI looks ugly b) GUI opens needless windows (a generic Pharo problem) c) No syntax highlighting in case of Browsing online code (diffs, changes etc) d) No visualization of the commit history. e) the usual problems with documentation f) No easy undo functionality g) Need to press a refresh button for monticello to be kept up to date h) Monticello contacts irrelevant online repos even for local commits, as a result a slow connection can freeze the image (WTF) i) No clear indication of where the history branches and where it merges and the list goes on , but those are the main I wonder even if Monticello improved at all since Pharo forked from Squeak. > It is true that StHub is not actively maintained, but that does not change > the fact that it just works. Indeed certain features were/are missing, > nothing is perfect. Given the load is has to endure it is pretty stable > (remember that SqueakSource collapsed under the Pharo load) even if it > needs an occasional reset. > > "nothing is perfect" is a lousy excuse and a cliche. Yes it works but this is not the image I think that will inspire newcomers to use Pharo. Remember we have to compete with languages like Ruby and Python . > Here is an example. I have this pull request open > > https://github.com/svenvc/ston/pull/17/files > > it is so big, changes so much that I cannot even begin figuring out what > happened. I want my in-IDE tools that understand Smalltalk. > > One sec... one sec are you trying to tell me that this a good commit ? https://github.com/svenvc/ston/pull/17/commits/5c03481aeda7804317e6d9efbb76… seriously ? 84 files changed in ONE commit ? seriously ? please do not blame Git if you guys have terrible workflows. This would be even bigger mess with the Pharo VCS . But this definitely not a good way to use Git or any VCS. Let be serious here, I know you guys love Smalltalk But common A bit of common sense would not hurt. If someone have sent me such a pull request I would have rejected it in an instant without even looking at the code. But if you guys like to deal with this kind of mess inside the Pharo image, be my guest. I prefer the Git way of using Git and not the "whatever" way and avoid the mess as much as possible. > One day (soon) the new tools (Iceberg ?) will allow me to do that, allow > me to see git as just an opaque back end, allow me to remain inside the > Pharo IDE (again, not that I can not or do not work in a terminal, far from > it, I just don't want to for my Pharo workflow) > So basically the mentality here is "give me Iceberg so I do not have to learn Git or work like Git" , yeah good luck with that one. I am not against Iceberg but I am sure it will be used as an excuse , like with many other things to bash Git and other non-Smalltalk technologies, each time it fails. You already compare Iceberg with using Git from the terminal. Of course you will not mention SourceTree , GitUP, SmartGit , GitKraken and a ton of other brilliant Git GUIs . Hell even Github offers its own Git GUI client that makes using Git a breeze. I think you greatly overestimate the opinion that people have about Smalltalk, I can assure you its both positive and negative and VCS falls under the negative category. I would like to see a community that treats Smalltalk not as the holy grail. The pull request example you used against Pharo and Git shows exactly this kind of attitude , taking extremely bad situations that can be easily be avoided as an excuse to present Smalltalk as "the superior tool". And when people do not bite the bait, you blame Smalltalk and emphasize that Pharo is not really Smalltalk but Smalltalk inspired. I have never been part of this ideology and will never going to be. You guys are amazing and building a great tools, but in so many cases you just lose touch with reality. You ask me how many Smalltalkers agree with me, let me ask you how many coders in general you think would agree with you ? I am trying to avoid having this kind of discussions but on the other hand I do not think all this denial is a good thing for Pharo. Another thing I like to stress here, is that your goal to create a self contained enviroment fully implemented in Smalltalk sorry I meant Pharo, will not happens. Gone are the times of 70, 80s and even 90s that a simple GUI could cut it. Nowdays a modern coder uses a vast array of tools at his arsenal because coding has become very complex to accomodate the high expectations of modern users. We do not have the time, the money or the community to build a tool that can compete on equal terms with the ocean of tools that exist out there. People do not use Git because they cannot use far simpler VCS , of course not. They use because they know that projects grow and demands changes and the time comes that they wish they have picked Git in the first place because the more the project grows the more difficult it becomes to switch VCS.

Jan. 14, 2017

Re: [Pharo-users] Google visibility?

by Sven Van Caekenberghe

> On 14 Jan 2017, at 12:58, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > I fail to see what is user friendly about Monticello , I find its GUI and the total workflow really bad, certainly the worst VCS GUI I have ever used. But I will admit this is my personal taste and my opinion that can be safely ignore. That is your opinion and you are entitled to it, but I am pretty sure you don't speak for the majority of Smalltalk users in general. I don't understand what is bad about MC in the IDE: your code is easily put in packages, you look at changes at the method and class definition level, you compare and commit, look at incoming changes and that's it. Merging is just as easy or difficult as anywhere else. Is it perfect ? Does it have all features ? No, of course not. Remember that we have total control over its model and implementation in code. > StHub on the other hand is whole different situation. > > My criticism about StHub unlike Monticello are not opinion based, they are fact based, StHub is unmaintaned , with the usual failures prompting Esteban to reset the whole thing and lacking the most fundamental features like a sophisticated search facility and any form of browsing. I could go on, but I think the shortcomings are obvious. That's no bashing, its a statement of facts. It is true that StHub is not actively maintained, but that does not change the fact that it just works. Indeed certain features were/are missing, nothing is perfect. Given the load is has to endure it is pretty stable (remember that SqueakSource collapsed under the Pharo load) even if it needs an occasional reset. Do I want something better ? Sure, people are working on that. > On the subject of file based code, I wonder what you use for Pharo VCS because the default Pharo VCS is basically zip (mcz extension) files containing source code files , the usual text files with the "st" extension. If you mean the fact of actually worrying about the files themselves, the only worrying you do with Git is for the gitignore file (if you actually use one) that basically there can be listed what files or directories should be ignored by Git. The rest are done automagically by Filetree, GitFileTree or in my case my Git GUI client. No normal user looks or needs to look inside .mcz files. That is the whole point, it is based on a model/abstraction visible/manipulated in the IDE only. Again, I know git, I use git, even for Pharo. But the current approach is not good enough and it is far from stable or user friendly enough for prime time (I don't mean that git, GitHub or any other git tool is not good, I am talking about the interface with the Pharo IDE and workflow). Here is an example. I have this pull request open https://github.com/svenvc/ston/pull/17/files it is so big, changes so much that I cannot even begin figuring out what happened. I want my in-IDE tools that understand Smalltalk. One day (soon) the new tools (Iceberg ?) will allow me to do that, allow me to see git as just an opaque back end, allow me to remain inside the Pharo IDE (again, not that I can not or do not work in a terminal, far from it, I just don't want to for my Pharo workflow). Still, MC and its classic repositories will remain with us for a long time. > I also never said "Do not use Pharo VCS" , if that is what rocks your boat, but to actual claim that Pharo VCS is more reliable, easier to use and more powerful would require a huge leap of faith because from the very first experience it pretty crystal clear that is not. > > And there is not just Git, there are plenty of other VCS out there that are just light years ahead, some probably better than Git. I disagree. > But I have no problem if some people prefer to use the old VCS instead of Git. I am not here to impose my workflow and I never stated that we should. > > As a matter of fact I do not mind any choice the community makes as long as I have freedom to choose my own tools and my own workflow. I am pretty sure all options will remain open. > On Sat, Jan 14, 2017 at 11:10 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 14 Jan 2017, at 00:48, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > > > On STHub, fortunately is live enough to let some of us being productive without the noise of git in front. > > So true. > > Let's stop bashing StHub: it works fine for 1000s of projects. I know we are building something new and I am all for it, but as long as it is not as user friendly as Monticello (all operations clean and simple in Pharo, reliably) we are not there yet. > > The point is: we all know how to use git, but most Pharo developers don't want to deal with file based Pharo code, at all, ever. > > Sven

Jan. 14, 2017

Re: [Pharo-users] Google visibility?

by Dimitris Chloupis

I fail to see what is user friendly about Monticello , I find its GUI and the total workflow really bad, certainly the worst VCS GUI I have ever used. But I will admit this is my personal taste and my opinion that can be safely ignore. StHub on the other hand is whole different situation. My criticism about StHub unlike Monticello are not opinion based, they are fact based, StHub is unmaintaned , with the usual failures prompting Esteban to reset the whole thing and lacking the most fundamental features like a sophisticated search facility and any form of browsing. I could go on, but I think the shortcomings are obvious. That's no bashing, its a statement of facts. On the subject of file based code, I wonder what you use for Pharo VCS because the default Pharo VCS is basically zip (mcz extension) files containing source code files , the usual text files with the "st" extension. If you mean the fact of actually worrying about the files themselves, the only worrying you do with Git is for the gitignore file (if you actually use one) that basically there can be listed what files or directories should be ignored by Git. The rest are done automagically by Filetree, GitFileTree or in my case my Git GUI client. I also never said "Do not use Pharo VCS" , if that is what rocks your boat, but to actual claim that Pharo VCS is more reliable, easier to use and more powerful would require a huge leap of faith because from the very first experience it pretty crystal clear that is not. And there is not just Git, there are plenty of other VCS out there that are just light years ahead, some probably better than Git. But I have no problem if some people prefer to use the old VCS instead of Git. I am not here to impose my workflow and I never stated that we should. As a matter of fact I do not mind any choice the community makes as long as I have freedom to choose my own tools and my own workflow. On Sat, Jan 14, 2017 at 11:10 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 14 Jan 2017, at 00:48, Offray Vladimir Luna CÃ¡rdenas < > offray.luna(a)mutabit.com> wrote: > > > > On STHub, fortunately is live enough to let some of us being productive > without the noise of git in front. > > So true. > > Let's stop bashing StHub: it works fine for 1000s of projects. I know we > are building something new and I am all for it, but as long as it is not as > user friendly as Monticello (all operations clean and simple in Pharo, > reliably) we are not there yet. > > The point is: we all know how to use git, but most Pharo developers don't > want to deal with file based Pharo code, at all, ever. > > Sven >

Jan. 14, 2017

Re: [Pharo-users] Older Pharo on MacOS Sierra

by Bruce O'Neel

Hi, Pharo 4 might be hard on MacOS Sierra. There was a late change to the VM, at least for Squeak, to stop the black screen on startup on Sierra.Â Â Â Pharo 4 was before that change, and, for that matter, before Sierra.Â Pharo 5 was after and clearly has that change. I'm pretty sure that the patches are one of these two: [https://github.com/OpenSmalltalk/opensmalltalk-vm/...](https://github.com/O… [https://github.com/OpenSmalltalk/opensmalltalk-vm/...](https://github.com/O… and I'm almost 100% sure that the second is the magic one. The simple solution would be to replace the VM in the Pharo 4 bundle with the VM in the Pharo 5 bundle, but, alas, the VM in the Pharo 5 bundle can't read the image from Pharo 4. So it would look as if one's choices are: * Build the version of the VM from the Pharo 4 bundle, but, apply one or both of the patches above. * Figure out why Pharo 4 is necessary and move to Pharo 5. * Run a squeak V3 VM and hack something together.Â This might not give the full Pharo experience. To run the squeak V3 do the following: Download and unzip the newest Squeak V3 VM. [https://bintray.com/opensmalltalk/vm/download_file...](https://bintray.com/… Alt click on the CocoaFast app and choose open. Quit. Download Pharo 4.Â Alt click on Pharo 4 and choose "Show Package Contents."Â Navigate to Contents -> Resources.Â Drag the "Pharo4.0.image" overtop the CocoaFast app and it launches.Â You do have startup errors, so, you now have some time to play around. I realize that neither look so easy, though the second one is probably the wisest just because the Pharo group moves quickly. cheers bruce I don't know yet Jeff. I don't have either a macos sierra at hand. Once a Mac OS Sierra user reported me the problem your are mentioning[1], but I did not get very far investigating the problem. For me it is not clear at all from[2] if there is any Mac VM 4.0. May be Esteban can enlighten us. [1] http://forum.drgeo.eu/DrGeo-pb-mac-os-Sierra-td402... [2] http://pharo.org/download Le 14/01/2017 Ã 11:35, J.F. Rick a Ã©crit : > So, what's the proper procedure? I just moved my Pharo4 to the > Application directory and it didn't work? Launched but the window is > black. Is there a new Pharo4 VM for MacOS? If so, where is it? > > Thanks, > > Jeff -- Dr. Geo http://drgeo.eu

Jan. 14, 2017