- Pharo-users - lists.pharo.org

Re: [Pharo-users] Google visibility?

by Hilaire

I like interacting with the news group too, including with this mailing list. I found it very efficient. Hilaire Le 15/01/2017 Ã 09:46, jtuchel(a)objektfabrik.de a Ã©crit : > And that's exactly why I still like the usenet: I can read/answer > whenever I want, using my mail client (opera, thunderbird) and all is > archived and can be searched from within the mail client or by a search > engine, Usenet is a central place, accessible to anybody, anytime, and > you don't have to search for mailing lists and go through strange > opt-in/out mail exchanges, > > What was actually wrong with comp.lang.smalltalk and subforums that > could only be fixed by opening new sites and mailing lists and whatnot > that more or less all look abandoned these days? -- Dr. Geo http://drgeo.eu

Jan. 15, 2017

Re: [Pharo-users] About Git

by Peter Uhnak

I find these endless git vs monticello discussions confusing and pointless. Maybe we can hang Q&A list somewhere on pharo website to point to? Because git is getting increased traction in Pharo, so the same questions and endless discussions will popup over and over again. 1. Some people here are acting like STHub and Monticello is going away tomorrow. I don't see how that can happen unless Pharo decides to fundamentally redo its object model. (STHub may die to free some resources, but I don't think that's a foreseeable future plan.) 2. Git is not "new", or "cool", or "bandwagon" technology; it has been here for a decade and more than proven that its value (in fact git is older than Pharo ;)). 3. If you consider the nomenclature confusing because you don't understand or use some concepts, that's fine. That's what tools are for (e.g. I don't use `git add` with Pharo, because I can pick what changes I want with Komitter ( https://www.peteruhnak.com/blog/2016/08/12/fine-grained-committing-and-exte… ) similarly Iceberg should be capable of this too (I am on Pharo 5 so iirc)). 4. Some comparisons between online git managers (github/bitbucket/...) and sthub just show that people don't understand e.g. "i download a program, add something, upload my addition. lets take an upload step, _one_ simple step with monticello "i upload something once (git add), i upload it a second time (git commit), i upload it a third time (git push), i try to upload it a fourth time (pull request)" The correct version for monticello is (from what I've experienced): I download a program, add something locally, send mail to maintainer, wait, get permission. Now I have complete control over someone else's repository. I release a new version but make a mistake in configuration; now every downstream project is broken and CI informs me only afterwards). If said person doesn't want to give me full access, I have to fileout my changes (or copy paste them), send them by email, wait more. I don't find that a good workflow. If you are working on your own project and want to ignore many things git has to offer (which I do regularly for many projects where it makes sense), then you can have literally the same "one click" with very little work (that can be part of Iceberg/GitFileTree for anyone else to use). You click commit in pharo; now it's on github (or wherever). My views are certainly biased as I've been using git for long time before I came to Monticello, which I still find very limiting. If I am needlessly unfair towards monticello then please correct me --- which is also part of my point; this knowledge shouldn't be hidden in mailing lists (as they are usually disorganized by nature), but in some easily discoverable and structured form (which I guess also loops this discussion back into the original Google visibility topic ;)). Peter On Sun, Jan 15, 2017 at 01:12:37PM +0100, Norbert Hartl wrote: > > > > Am 15.01.2017 um 10:29 schrieb "itlists(a)schrievkrom.de" <itlists(a)schrievkrom.de>: > > > > I would give you many more "+" - if you wish - for your opinion: > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > Another point I would like to mention: keep the source code locally or > > at least have an easy option to hold all source code locally. > > > > I've seen so many times, that git or one of the other git repositories > > are down - that's a very critical point. > > > But....that's always the case with git. You have always all the code plus history locally. Plus you can commit while being offline. Which is exactly one point where git excels. Even envy cannot do that if I understood it correctly. > > > > I would like to have a local repository, where I can import external > > packages and I work locally only. > > > You can do that with metacello. > > > I also have thought several times that it would be nice to have a SQLite > > database holding all sources/packages. How much easier life would be > > with that. > > > I cannot see how using an in-memory sql database can make your life easier. To do what? > > Norbert > > Other than that: I prefer my simple server directory holding monticello > > packages - in the Gemstone/S area. > > > > But I have to admit, that all the source code management stuff I've seen > > since ENVY in the Smalltalk community are pretty poor stuff - and even > > considering integrating git is not a step forward in terms of technical > > improvements, but only in terms of marketing and mainstream technology. > > > > > > Marten > > > > > > > >> Am 14.01.2017 um 18:44 schrieb werner kassens: > >> Hi Dimitris, > >> i as a simple user tend to think about these things in simple terms: i > >> download a program, add something, upload my addition. lets take an > >> upload step, _one_ simple step with monticello: i upload something once > >> (git add), i upload it a second time (git commit), i upload it a third > >> time (git push), i try to upload it a fourth time (pull request), only > >> then i'm done (yes, there are possible shortcuts but so what). i'm sure > >> all this makes sense for the seasoned coder, but i certainly won't learn > >> that. <friendly grin> just as a small example how a user like me thinks > >> about this. > >> werner > >> > > > > > > > > -- > > Marten Feldtmann > > > >

Jan. 15, 2017

Re: [Pharo-users] Google visibility?

by phil＠highoctane.be

On Sun, Jan 15, 2017 at 6:22 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sven Van Caekenberghe-2 wrote > > so it is not a good idea for an open source project, as I feared. > > +1. I was concerned from the beginning that our conversations would get > more > fragmented. I rarely have time to check slack and the mailing list recently > seems to be missing quite a bit of deliberation that's happening elsewhere. > Amost all of the chatter happens on Slack. That's a fact. Less friction, more immediate feedback, ability to copy/paste snippets and pictures. Now, letting all of this in a forgetful back hole is a shame. Phil > > My 2c > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Google- > visibility-tp4929414p4929660.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

Jan. 15, 2017

Re: [Pharo-users] About Git

by Offray Vladimir Luna CÃ¡rdenas

On 15/01/17 04:29, itlists(a)schrievkrom.de wrote: > > I also have thought several times that it would be nice to have a SQLite > database holding all sources/packages. How much easier life would be > with that. > That's the core idea of fossil. "GitHub alike in a box" DVCS with tickets, wiki, web server/GUI in 2 MB. Cheers, Offray

Jan. 15, 2017

Re: [Pharo-users] Google visibility?

by phil＠highoctane.be

My point exactly. Currently working with a team of testers, they are very happy with mcz indeed. And have no clue of git. Phil On Sat, Jan 14, 2017 at 3:57 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. 15, 2017

Re: [Pharo-users] About Git

by phil＠highoctane.be

I am also amazed at the number of people not using basic git UI tools, like "git gui" and "gitk" + mergetool/difftool settings in the git config (kdiff3, meld, WinMerge, difuse) which make the work of merging so much easier (e.g. "git difftool" or "git mergetool" on the CLI when one encounters issues during a merge or rebase). "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." Err, as a "modern development team member", because as a lone coder trying to do all of this will just spend more time in messing with tooling than by creating the solution. I see that in a lof of shops where docker-compose or git flow is discussed much more than the business logic :-( Phil On Sat, Jan 14, 2017 at 3:14 PM, 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/ > 5c03481aeda7804317e6d9efbb761399fe0e7b67 > > 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. 15, 2017

Re: [Pharo-users] About Git

by phil＠highoctane.be

My reasons to like the legacy/mcz style [D]VCS in Pharo: 1) No fuss in saving things when I am starting something 2) Easy to explain to someone new to Pharo 3) Can use any FTP server as a repo (Useful when in a walled garden) 4) Compatible with the package cache, so I can collect mcz's from various projects and put them together and retrieve bits and pieces 5) Some compatibility with Squeak and other Smalltalk, which doesn't hurt 6) Merge tool kind of works 7) Easy to understand format for an mcz, so just get the .st source in it, and do some find/replace to align class names etc when in need 8) If one wants to actually understand the thing, it is all in source code format (educative) Git is better for a number of cases, yes, but why should we only have one thing? Fossil is also great and I'd say taking less of a ton of files as git does (synching my image and the myriad of files in .git/ is really shitty when working in a Dropbox folder, not so with mcz). Git needs regular maintenance, like compaction etc. Sometimes, git breaks. Good luck to recover from that. DVCS ~= backup. Long story short, Git requires more maintenance and freaks out some people. A note for working on Windows, a lot of VM crashes are due to Pharo not finding out the git.exe thing on the path. Check the settings for making this right. Out of the box, it is not. Maybe we should make that clear in a Playground or Help topic so that people do not face this when committing code they worked hard to produce. Phil On Sat, Jan 14, 2017 at 3:14 PM, 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/ > 5c03481aeda7804317e6d9efbb761399fe0e7b67 > > 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. 15, 2017

Re: [Pharo-users] About Git

by Norbert Hartl

> Am 15.01.2017 um 10:29 schrieb "itlists(a)schrievkrom.de" <itlists(a)schrievkrom.de>: > > I would give you many more "+" - if you wish - for your opinion: > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > Another point I would like to mention: keep the source code locally or > at least have an easy option to hold all source code locally. > > I've seen so many times, that git or one of the other git repositories > are down - that's a very critical point. > But....that's always the case with git. You have always all the code plus history locally. Plus you can commit while being offline. Which is exactly one point where git excels. Even envy cannot do that if I understood it correctly. > I would like to have a local repository, where I can import external > packages and I work locally only. > You can do that with metacello. > I also have thought several times that it would be nice to have a SQLite > database holding all sources/packages. How much easier life would be > with that. > I cannot see how using an in-memory sql database can make your life easier. To do what? Norbert > Other than that: I prefer my simple server directory holding monticello > packages - in the Gemstone/S area. > > But I have to admit, that all the source code management stuff I've seen > since ENVY in the Smalltalk community are pretty poor stuff - and even > considering integrating git is not a step forward in terms of technical > improvements, but only in terms of marketing and mainstream technology. > > > Marten > > > >> Am 14.01.2017 um 18:44 schrieb werner kassens: >> Hi Dimitris, >> i as a simple user tend to think about these things in simple terms: i >> download a program, add something, upload my addition. lets take an >> upload step, _one_ simple step with monticello: i upload something once >> (git add), i upload it a second time (git commit), i upload it a third >> time (git push), i try to upload it a fourth time (pull request), only >> then i'm done (yes, there are possible shortcuts but so what). i'm sure >> all this makes sense for the seasoned coder, but i certainly won't learn >> that. <friendly grin> just as a small example how a user like me thinks >> about this. >> werner >> > > > > -- > Marten Feldtmann >

Jan. 15, 2017

Re: [Pharo-users] About Git

by itlists＠schrievkrom.de

I would give you many more "+" - if you wish - for your opinion: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Another point I would like to mention: keep the source code locally or at least have an easy option to hold all source code locally. I've seen so many times, that git or one of the other git repositories are down - that's a very critical point. I would like to have a local repository, where I can import external packages and I work locally only. I also have thought several times that it would be nice to have a SQLite database holding all sources/packages. How much easier life would be with that. Other than that: I prefer my simple server directory holding monticello packages - in the Gemstone/S area. But I have to admit, that all the source code management stuff I've seen since ENVY in the Smalltalk community are pretty poor stuff - and even considering integrating git is not a step forward in terms of technical improvements, but only in terms of marketing and mainstream technology. Marten Am 14.01.2017 um 18:44 schrieb werner kassens: > Hi Dimitris, > i as a simple user tend to think about these things in simple terms: i > download a program, add something, upload my addition. lets take an > upload step, _one_ simple step with monticello: i upload something once > (git add), i upload it a second time (git commit), i upload it a third > time (git push), i try to upload it a fourth time (pull request), only > then i'm done (yes, there are possible shortcuts but so what). i'm sure > all this makes sense for the seasoned coder, but i certainly won't learn > that. <friendly grin> just as a small example how a user like me thinks > about this. > werner > -- Marten Feldtmann

Jan. 15, 2017

Re: [Pharo-users] Google visibility?

by stepharong

On Sat, 14 Jan 2017 10:09:02 +0100, 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. + 10000 And so far we deliver and I would add that I appreciate particularly when I see code commits for improvements instead of just rants. > > Sven -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 15, 2017