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

Re: [Pharo-users] Intro to git-only Pharo

by Stephane Ducasse

Hi joachim There is a distinction between managing projects and pharo. Pharo 60 is managed with Monticello. Pharo 70 will not. - git only - no monticello meta info any more - possible? Yes people use that everyday. But Pharo is not manage like that (even if we follow since years a git flow). In Pharo 70 Pharo itself will be manage with iceberg with git as a back end (notice the difference) - tools like merge/diff, committing from within the image You have all the diff merge tools within pharo - dependencies within my own project as well as dependencies on external code in - possibly multiple - external repositories Metacello handles this since year. There is a chapter on deep into pharo since ages - what is the current "most official" source repository for open source code? SmalltalkHub and SS3, - best practices for managing complex projects and keeping old versions reproducible at any time Use Metacello and use versions or symbolic versions to your own projects if you want to minimize changes. - tutorial for git newbies in a Pharo context? (Like, how do I start with a new packege - create folder first and do git init, or start in the image and push into repo later? as I said: beginners' stuff) There is one on the the github of iceberg. Stef On Wed, May 10, 2017 at 7:56 AM, Joachim Tuchel <jtuchel(a)objektfabrik.de> wrote: > Hi guys, > > please forgive me if this mail is a sign of ignorance. I am not a regular > Pharo user and one of the reasons for this is that I didn't like most of > the source management tools around Monticello. Coming from an envy > background, it feels like not being ready for prime time. Of course you > guys have been proving you can work with these tools quite well, but still > I'd be interested in using Pharo in a pure git-based environment, as it > most closely resembles some of the most-beloved features of envy. > > Over the years there was a lot of work and discussion on filetree, > gitfiletree, iceberg, cypress and maybe quite a few other projects that > sounded promising and interesting. But I must admit I lost track of what > was really done and how far things went in the last years. > > So are there any pointers to info material that I could look at to see > what the current status of source control in Pharo 5 and Pharo 6 is and/or > will be soon? > > I am mostly interested in these topics: > > - git only - no monticello meta info any more - possible? > - tools like merge/diff, committing from within the image > - dependencies within my own project as well as dependencies on > external code in - possibly multiple - external repositories > - what is the current "most official" source repository for open > source code? > - best practices for managing complex projects and keeping old > versions reproducible at any time > - tutorial for git newbies in a Pharo context? (Like, how do I start > with a new packege - create folder first and do git init, or start in the > image and push into repo later? as I said: beginners' stuff) > > Thanks for pointers and help > > > Joachim > > >

May 10, 2017

Intro to git-only Pharo

by Joachim Tuchel

Hi guys, please forgive me if this mail is a sign of ignorance. I am not a regular Pharo user and one of the reasons for this is that I didn't like most of the source management tools around Monticello. Coming from an envy background, it feels like not being ready for prime time. Of course you guys have been proving you can work with these tools quite well, but still I'd be interested in using Pharo in a pure git-based environment, as it most closely resembles some of the most-beloved features of envy. Over the years there was a lot of work and discussion on filetree, gitfiletree, iceberg, cypress and maybe quite a few other projects that sounded promising and interesting. But I must admit I lost track of what was really done and how far things went in the last years. So are there any pointers to info material that I could look at to see what the current status of source control in Pharo 5 and Pharo 6 is and/or will be soon? I am mostly interested in these topics: * git only - no monticello meta info any more - possible? * tools like merge/diff, committing from within the image * dependencies within my own project as well as dependencies on external code in - possibly multiple - external repositories * what is the current "most official" source repository for open source code? * best practices for managing complex projects and keeping old versions reproducible at any time * tutorial for git newbies in a Pharo context? (Like, how do I start with a new packege - create folder first and do git init, or start in the image and push into repo later? as I said: beginners' stuff) Thanks for pointers and help Joachim

May 10, 2017

Re: [Pharo-users] Epicea vs RB refactorings

by Martin Dias

On Wed, May 3, 2017 at 5:22 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-04-26 11:19 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > >> Hi, >> >> I'm under the impression that Epicea is supposed to replace RB >> refactorings at some point. >> > > I think it was never the goal and not supposed to happen. Epicea is only > changes logger. Maybe Martin will correct me. > Yes, Epicea uses RB refactorings and doesn't pretend replacing it. > > >> >> If that is true, is it currently possible to build refactorings by hand? >> >> For example in RB I often do: >> >> ``` >> model := RBNamespace new. >> >> model defineClass: ('<1s> subclass: #<2s><n><t>instanceVariableNames: >> <3p><n><t>classVariableNames: ''''<n><t>poolDictionaries: >> ''''<n><t>category: <4p>' expandMacrosWith: 'Object' with: 'MySomething' >> with: 'var1 var2' with: 'MyPackage'). >> cls := model classNamed: #MySomething. >> cls compile: 'var1 >> ^ var1' classified: 'accessing'. >> >> (ChangesBrowser changes: model changes changes) open >> ``` >> >> or >> >> (removing a method from a class) >> ``` >> model := RBNamespace new. >> model removeMethod: #testTrimRight from: StringTest. >> (ChangesBrowser changes: model changes changes) open >> > > I use directly RBRefactoring subclasses: > > ref := RBRemoveMethodRefactoring removeMethods: #(testTrimRight) from: > StringTest. > ref execute."perform complete changes without preview" > ref primitiveExecute. "for preview" > (ChangesBrowser changes: {ref}) open. > > > > >

May 10, 2017

Wandering Through Dependency Hell

by Evan Donahue

Hello, I was wondering if there was a resource somewhere that laid out a best practice for how to manage version control in Pharo. I know *how* to use Monticello and Versionner, but something about the way I use them inevitably dooms my efforts to the darkest circles of dependency hell, where strange and gruesome partial versions of old and abandoned branches come back to haunt me like some kind of object oriented night of the living dead. In particular, I usually commit daily to a local repository on my disk, and only occasionally to a remote repository like smalltalkhub. It has come to my attention that this only commits recent changes, with the result that no single repository actually has the current working code that I see in my image. I am in that situation now, where loading the latest version revives some distant and broken code where good, currently working code should be. If anyone knows how to figure out how to force all the current good code in my image into one massive commit, so that other people can check out the current, working version, please do not hesitate to let me know. Thanks, Evan

May 10, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by Pierce Ng

On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote: > I don't know. I do know that I can't use something with the > ridiculous compile times of Haskell or Swift. That just kills flow > and productivity. You could hop onto an office chair and engage your colleague in sword fighting. That's a plus! :-) Pierce

May 10, 2017

Re: [Pharo-users] smalltalkhub.com down?

by Andrei Chis

Also pharo.org looks down. http://downforeveryoneorjustme.com/pharo.org On Tue, May 9, 2017 at 11:09 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > http://downforeveryoneorjustme.com/http://smalltalkhub.com/ > mc/dkh/metacello/main/?C=M;O=D > > >

May 9, 2017

smalltalkhub.com down?

by Dale Henrichs

http://downforeveryoneorjustme.com/http://smalltalkhub.com/mc/dkh/metacello…

May 9, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by phil＠highoctane.be

Let me add that I am perfectly happy with the system given the type and size of applications I do write and maintain. And having flow is #1 criteria for enjoying my work. Phil On Tue, May 9, 2017 at 6:59 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 09/05/17 16:17, Eric Velten de Melo wrote: > >> I think he forgets to mention Haskell, which is probably the reason >> behind the shift of Swift towards optional values (Option type in Scala, >> Maybe type in Haskell). You can't talk about modern type system without >> talking about Haskell, Monads and Algebraic Data Types (Maybe is a monad). >> > > I don't know. I do know that I can't use something with the ridiculous > compile times of Haskell or Swift. That just kills flow and productivity. > > Stephan > > > > >

May 9, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by GÃ¶ran Krampe

On 09/05/17 21:22, Steven R. Baker wrote: > I'd like to have that confirmed; it would challenge "conventional > wisdom" on static typing. I don't recall details but I have read that no static type information was actually used for "speeding up", it was all PICs etc. So yes, an interesting fact. However - I don't think you can "prove" anything in this area. The fastest dynamic lang implementations like LuaJIT, V8 etc are still a fair factor away from the performance of C, C++, Nim, Rust (and similar statically typed langs and their compilers). In other words, the things you can optimize dynamically in an advanced runtime (say a tracing JIT like LuaJIT) haven't *yet* proven to overtake the raw advantage of all possible compile time optimizations. In theory a warmed up sufficiently advanced VM should beat statically compiled code - simply by the fact it has more information at hand. But... it hasn't been observed yet AFAIK. And even if it happens - in many areas where you need raw power you also have: - Memory requirements - Consistency in speed ...and a VM like say the JVM tend to fail hard on both accounts even if it can approach C++ speeds when sufficiently warmed up. regards, GÃ¶ran

May 9, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by Steven R. Baker

> I think he forgets to mention Haskell, which is probably the reason > behind the shift of Swift towards optional values (Option type in > Scala, Maybe type in Haskell). You can't talk about modern type system > without talking about Haskell, Monads and Algebraic Data Types (Maybe > is a monad). > > I don't believe the future is dynamic typing, I believe it is type > inference and optional typing. There is no need to be radical about > it. One great sadly forgotten example of this is Strongtalk, which was > rumored to be the fastest implementation of Smalltalk ever made (I > don't know how it compares to the latest Pharo VM, though) and > included an optional strong type system I talked to some folks about Strongtalk at StS a few years back, and they told me that in order to achieve the speed improvements, they had to throw away type information. Basically, they tried to prove that static typing was faster, and proved the opposite. I'd like to have that confirmed; it would challenge "conventional wisdom" on static typing. -Steven > (http://www.strongtalk.org/) Strongtalk team was bought by Sun before > they could release the language and their advancements in virtual > machine development were taken by the Java Virtual Machine. It is one > of my dreams to see Strongtalk back into action or maybe a version of > Self with optional typing, but I unfortunately lack the required > skills and time to do so. > > 2017-05-09 10:26 GMT-03:00 Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>>: > > Fantastic article. Very well rounded. I particularly liked > "Meanwhile the Smalltalk programmers were scratching their heads > wondering what the big deal was. You see, their language was also > strongly typed; but their types were undeclared. In Smalltalk > types were enforced at runtime." > > and..."You see, the Smalltalk programmers had solved the missile > problem in their own unique way. They invented a discipline. Today > we call that discipline: Test Driven Development. ... You see, > when a Java programmer gets used to TDD, they start asking > themselves a very important question: âWhy am I wasting time > satisfying the type constraints of Java when my unit tests are > already checking everything?â > > cheers -ben > > On Tue, May 9, 2017 at 2:49 PM, askoh <askoh(a)askoh.com > <mailto:askoh@askoh.com>> wrote: > > This is a quote from Bob Martin of "Clean Code" fame. Enjoy, > Aik-Siong Koh > > http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html > <http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html> > > > > -- > View this message in context: > http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-p… > <http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-p…> > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > > >

May 9, 2017