github et al (was [squeak-dev] The Trunk: Monticello-cmm.575.mcz)

There is a simpler way, using Git as it is meant to be used. Take a look at https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/3deff0d7b9707258766d6f003b783077664a4023#diff-5fe4c9854ae64b52029283e0648affd4 . We've been using this for a couple of years, and it works nicely.

Quoting Frank Shearar <[hidden email]>:

On 20 November 2013 16:56, Chris Muller <[hidden email]> wrote:

No it doesn't.  And the fact that all the ones you mention do isn't a
strength.  All IDEs I know of surrender the *storage* of the repository to
something else, a file system, a database, a remote directory.  But lots of
Smalltalk environments keep firm control of their own source code control,
Store in VisualWorks, Orwell and later Team/V in Digitalk, Monticello in
Squeal/Pharo.  Just the addition of the simple version scheme in Squeak
changes & sources files puts it head and shoulders ahead of VisualWorks in
the ease of investigating history, undoing changes, etc.  This is vital to
the ease of programming, its flow, etc.  Squeak doers a great ob.  We
surrender that to something else at our peril.

Mild talking past each other here. IntelliJ uses your favourite
version control system under the hood to store your code: it supplies
menus for driving, for instance, git to commit code and whatnot. It
does, in addition, store versions for every time you hit enter (or
after a period of time). These are distinct features. I'm not
proposing losing the versions button or using git to store the data
behind the versions button.

I'm proposing that we keep the Monticello front end, add a few new
buttons, and rip out the storage of source on disk, replacing it with
git. I have yet to find a decent mapping of Smalltalk code to files,
but I'd put up with a crap one if it meant one less thing that we
didn't need to do.

The "storage" you refer to is already encapsulated by MCRepository.  I
would welcome a new MCGitRepository subclass if it were able to meet
the minimum API requirements of MCRepository.  But I see no need to
"rip out" any of the existing repository-types..

Smalltalk was 30 years ahead of its time in 1980. It's now a decade
behind other languages. That is a tragedy that, in my opinion at
least, largely comes from the Smalltalk community's extreme
insularity/NIH.

Again, I don't think this group will be moved by this line of
reasoning, even with such dramatic language ("tragedy?" c'mon).

I would use stronger language. I think our current state of affairs is
a _disaster_.

Something that would be much more convincing, to me at least, would be
learning what having a MCGitRepository would do for MY goals and also
the community at large.  For example, I'm intrigued by Git's forking
capability.  How could that capability integrate into our ecosystem in
a useful way to bring more development power to the community?

I'm actually tired of the whole argument. So, in lieu of further talk,
I'm just going to carry on squirreling away on my stuff, chipping away
at the dependency nightmare we have (and if you think that's
hyperbole, you really ought to haul out graphviz and take a long, hard
look at the dependency graph. Go make yourself some coffee while dot
munges the file (which you can generate off
https://gist.github.com/frankshearar/5781906)).

Eventually we'll get to a place where I can not shiver in horror, and
then I can think again about the git problem. Even better, maybe
Camillo Bruni, Dale Henrichs and friends will have done the hard work
for me.

frank

Cheers,
Juan Vuletich

Hi, Eliot

you have good point. One of the strengths of having SCM under our control
is that we can easily extend it for advanced uses (like history analysis you mentioned,

and proper metadata handling, loading/initialization order etc etc)

but there was a good reason for 'surrendering' VMMaker to git.

Because having parts of VM sources stored in MC package , while other parts  ALREADY in

external repository is even worse, which was always causing problems of desync

and messy and complicated update process.

Now it is in one repository, which means single git shapshot == full sources for given version of VM which simplifies process A LOT.. this simply overweights all the drawbacks of surrendering to git IMO.

And regarding name too long issue, i think it easy to solve: just get rid of that infamous Genie plugin, which nobody using anyways, or at least it needs serious refactoring,

because you really need to be genius to know how to properly use primitive which takes 15+ arguments. Its just insane :)

On 20 November 2013 18:46, Eliot Miranda <[hidden email]> wrote:

Hi Frank,

On Wed, Nov 20, 2013 at 2:10 AM, Frank Shearar <[hidden email]> wrote:

On 19 November 2013 22:00, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Tue, Nov 19, 2013 at 1:39 PM, Frank Shearar <[hidden email]>
> wrote:
>>
>> On 19 November 2013 21:24, Eliot Miranda <[hidden email]> wrote:
>> > Hi Frank,
>> >
>> > On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <[hidden email]>
>> > wrote:
>> >>
>> >> On 8 November 2013 22:30, Chris Muller <[hidden email]> wrote:
>> >> > The trunk is a huge part of the Squeak development process and
>> >> > ecosystem that deserves and needs representation somewhere in the
>> >> > system.  Access to it is reasonably needed by ReleaseBuilder,
>> >> > Installer, source.squeak.org's SqueakSource and
>> >> > MonticelloConfigurations.
>> >>
>> >> Does noone else in the Squeak community use MCMs? I don't, but my
>> >> libraries are all very, very small.
>> >>
>> >> > Squeak has been using its own flavor of Monticello for several years
>> >> > now, as does Pharo and GemStone.  So, to me, it feels fine to make it
>> >> > Monticello-For-Squeak, meaning to relax restrictions imposed by
>> >> > multiplatform so it can go as far as we want toward supporting the
>> >> > Squeak process.
>> >>
>> >> It's not really germane to this discussion, but if I could flick a
>> >> switch and have us updating from github, I would do so without
>> >> hesitation. Monticello predates git by about 3 years, so we were right
>> >> on the bleeding edge there for a while, but git is now very, very far
>> >> ahead. It just makes so much sense to me to just use a world class
>> >> tool that _we don't have to maintain_. (*)
>> >
>> >
>> > Here's an example of why surrendering one's source code control to
>> > something
>> > else is a really bad idea for an IDE:
>>
>> An IDE _always_ (*) surrenders source code control to something else!
>> And it works just fine for emacs, Eclipse, Netbeans, Visual Studio,
>> IntelliJ, ...
>
>
> No it doesn't.  And the fact that all the ones you mention do isn't a
> strength.  All IDEs I know of surrender the *storage* of the repository to
> something else, a file system, a database, a remote directory.  But lots of
> Smalltalk environments keep firm control of their own source code control,
> Store in VisualWorks, Orwell and later Team/V in Digitalk, Monticello in
> Squeal/Pharo.  Just the addition of the simple version scheme in Squeak
> changes & sources files puts it head and shoulders ahead of VisualWorks in
> the ease of investigating history, undoing changes, etc.  This is vital to
> the ease of programming, its flow, etc.  Squeak doers a great ob.  We
> surrender that to something else at our peril.

Mild talking past each other here. IntelliJ uses your favourite
version control system under the hood to store your code: it supplies
menus for driving, for instance, git to commit code and whatnot. It
does, in addition, store versions for every time you hit enter (or
after a period of time). These are distinct features. I'm not
proposing losing the versions button or using git to store the data
behind the versions button.

I'm proposing that we keep the Monticello front end, add a few new
buttons, and rip out the storage of source on disk, replacing it with
git. I have yet to find a decent mapping of Smalltalk code to files,
but I'd put up with a crap one if it meant one less thing that we
didn't need to do.

Replacing the simplest part of Monticello (storing files on disc) with something much more complex (n interface with git) does not make any sense to me.  The system already has an interface to files, already has an interface to a webdav repository, etc.  These already work really well.  Does it really need an interface with something that has complex state, can get mucked up, is open to meddling through the file-system, can get out of sync, etc, etc.  All of these pathologies have happened with MemoryHole's use of mercurial.  They can and will happen with git.  Monticello is bedrock.  KISS.

Smalltalk was 30 years ahead of its time in 1980. It's now a decade
behind other languages. That is a tragedy that, in my opinion at
least, largely comes from the Smalltalk community's extreme
insularity/NIH.

I agree and don't like the NIH syndrome.  Smalltalk should play well with others.  That Squeak doesn't excel here is one reason for it's lack of popularity.  To improve it ability to play well with others is one of the design goals behind Spur.  But playing well with others, for me, does not imply weakening strong parts of the system.  Make the FFI better, don't make Monticello worse.  Make the VM loadable as a dll.  Don't replace the programming environment with Eclipse.

> One of the things we're not doing is trying to solve looking at long-term
> history (ie. some kind of server that serves the long-term history of
> packages).
>
> Something I'm really excited to see the Pharo folks looking at is richer
> change analysis than just method history, i.e. being able to spot method
> refactorings, class renames and class hierarchy refactorings.

>> (*) Squeak being the exception
>
>
> Smalltalk being the exception actually.  Smalltalk has proved powerful
> enough for it to provide its own source code control, and that's been a
> great strength.

I claim synecdoche :)

>  AT work I have to use a thin skin above Mercurial that is
> the solution for Newspeak and I despise it.  Compared to Monticello, it's
> junk.

I've not used MemoryHole, so I have no idea how much of "it's junk"
comes from mercurial and how much from MemoryHole.

Most of it comes from Mercurial.  MemoryHole is broken w.r.t. merging, and that's its problem.  But much of the interface between it and mercurial is confused and buggy, and that's the problem of trying to keep two complex beasts in sync.

 

I do know that the
biggest reason I've not written any Newspeak (and I'm fully aware that
I have failed in communicating this to Gilad) is that I don't want to
touch the UI with a barge pole. I made a tiny start at writing a
newspeak-mode for Emacs, and that's as far as I got.

But the UI (Hopscotch and Brazil) is great.  Vassili's engineered something really powerful and elegant there.  It's not complete; only one person's worked on it.  But it's innovative and provides radically better tools.  For example, the ability to see as many open methods as one wants on the stack in the debugger.

>> The given error is unfortunate, but that's not even git's fault -
>> "Filename too long" says it all. That super long filename comes from
>> filetree, so the error's existent is a confluence of a particular
>> source->file mapping together with a file system limitation.
>
>
> But the net effect is the same.  By relying on something external the system
> broke.  And it's not easy for the Pharo community to get it fixed.  They'll
> have to wrk-around the problem, and compromise something they want in their
> name mangling.  I live with crap like this all the time in building the VM
> (mingw and cygwin are awful things to depend on).  At least in the VM
> building context (and Newspeak) it is only a few souls who have to suffer.
> I hope we don't inflict this kind of thing on the general Squeak community.

Sure. Bugs are bugs. Let's not forget the recent Monticello fail
regarding UTF-8. We'll also _always_ depend on something. But that
doesn't mean that we should take responsibility for the entire world,
because we don't have the manpower. Even if we did, it's not even a
good idea.

Agreed.  But having excellent control of Smalltalk programs is a must have and relying on an external source code control system that is designed for files won't accomplish that.

frank

>> > "When doing a git clone, I do get the following:
>> >
>> >
>> > Philippe@gravitation7 ~
>> > $ git clone --depth=1 https://github.com/pharo-project/pharo-vm.git
>> > Cloning into 'pharo-vm'...
>> > remote: Counting objects: 17493, done.
>> > remote: Compressing objects: 100% (12363/12363), done.
>> > remote: Total 17493 (delta 4271), reused 17137 (delta 4143)
>> > Receiving objects: 100% (17493/17493), 19.28 MiB | 1.88 MiB/s, done.
>> > Resolving deltas: 100% (4271/4271), done.
>> > Checking connectivity... done
>> > error: unable to create file
>> > mc/VMMaker-oscog.package/GeniePlugin.class/instance
>> >
>> > /primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors.
>> >
>> > mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla
>> > g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too long)
>> > Checking out files: 100% (17525/17525), done.
>> > fatal: unable to checkout working tree
>> > warning: Clone succeeded, but checkout failed.
>> > You can inspect what was checked out with 'git status'
>> > and retry the checkout with 'git checkout -f HEAD'
>> >
>> > Pretty weird error I'd say.
>> >
>> > Anyone knowing what this is related to?"
>> >
>> > IMO having Monticello under our own control is a key strength.  yes,
>> > it's
>> > effortful to maintain but I don't see why we can't summon that effort.
>> > I do
>> > fear that if we don't we just become like everything else and soon
>> > enough
>> > we're just another scripting language.  The Smalltalk team had a name
>> > for
>> > this, something like "error 22", meaning depending on the success of
>> > other
>> > projects or infrastructure.  It's a bad idea, unless its bedrock.
>>
>> Monticello was great, back in the day. But why do we _have_ to saddle
>> ourselves with the effort of maintaining it ourselves? What else might
>> we _better_ do if we didn't spend all our time NIHing everything?
>>
>> And now, 7 years of git later, I'd consider git to be bedrock. Git
>> _has succeeded_. It and mercurial have gutted the competition: darcs,
>> monotone, bazaar, ...
>>
>> frank
>>
>> >> > Having said that, I must admit this really does make it
>> >> > Squeak-specific, no longer generic.  So, maybe an alternative should
>> >> > be to model our development process elements in a new package,
>> >> > SqueakDevelopmentProcess (?), which would depend on our Squeak's
>> >> > generic Monticello to represent the elements of our development
>> >> > process.
>> >>
>> >> I'm not terribly concerned with Squeak-specific or otherwise. It's
>> >> just that it's _trunk_ specific. I'd rather see a
>> >> SqueakDevelopmentProcess package than see it in the Monticello
>> >> package.
>> >>
>> >> frank
>> >>
>> >> (*) Finding that switch to flick is pretty hard though, which is why I
>> >> don't rant and rave about this all the time. Filetree's OK, but
>> >> destroys the ability of browsing source on the git repository (but
>> >> gives you the proper fine-grained version control you'd want).
>> >> gitfiletree supplies a Pharo UI to filetree, and it would be
>> >> worthwhile to port that UI to Squeak, through ToolBuilderification.
>> >> Continuing this discussion would necessitate a subject thread change!
>> >>
>> >> > On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier
>> >> > <[hidden email]> wrote:
>> >> >> I have same feeling as Frank,
>> >> >> a specific address of a specific repository for a specific usage has
>> >> >> not
>> >> >> much thing to do in MC.
>> >> >> MC package should not integrate each and every possible usage of MC.
>> >> >> If this does not belong to ReleaseBuilder, then we can make it a
>> >> >> System
>> >> >> thing...
>> >> >> If it's only for MCM, didn't we get a MCMcmUpdater defaultUpdateURL?
>> >> >>
>> >> >>
>> >> >> 2013/11/8 Chris Muller <[hidden email]>
>> >> >>>
>> >> >>> MonticelloConfigurations has no dependency on ReleaseBuilder and I
>> >> >>> don't think we should introduce one.
>> >> >>>
>> >> >>> If you at least acknowledge "trunk" is a real-thing in the real
>> >> >>> world,
>> >> >>> then note existence of MCRepository>>#trunk.  Sure, we could make a
>> >> >>> class-var or something if that helps you feel better, but my
>> >> >>> opinion
>> >> >>> right now is that is not necessary because code can change if/when
>> >> >>> it
>> >> >>> needs to.  Let's not let maybe-future-pie-in-the-sky-perfect be the
>> >> >>> enemy of pragmatic progress in the present.
>> >> >>>
>> >> >>> On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar
>> >> >>> <[hidden email]>
>> >> >>> wrote:
>> >> >>> > On 8 November 2013 15:25,  <[hidden email]> wrote:
>> >> >>> >> Chris Muller uploaded a new version of Monticello to project The
>> >> >>> >> Trunk:
>> >> >>> >> http://source.squeak.org/trunk/Monticello-cmm.575.mcz
>> >> >>> >>
>> >> >>> >> ==================== Summary ====================
>> >> >>> >>
>> >> >>> >> Name: Monticello-cmm.575
>> >> >>> >> Author: cmm
>> >> >>> >> Time: 3 October 2013, 9:42:40.555 pm
>> >> >>> >> UUID: daeb51c6-0b6f-41db-883d-e9764e61d8c5
>> >> >>> >> Ancestors: Monticello-cmm.573
>> >> >>> >>
>> >> >>> >> - Integrate Berts suggestions.  Refactored and renamed the API
>> >> >>> >> for
>> >> >>> >> the
>> >> >>> >> new history and origin browsing functions to avoid ambiguity
>> >> >>> >> with
>> >> >>> >> other MC
>> >> >>> >> domain elements.  Went from "version" nomenclature to "history".
>> >> >>> >> - Related to those functions, browsing a list of patch
>> >> >>> >> operations
>> >> >>> >> is
>> >> >>> >> now abstracted from browsing a Patch.  MCPatch is now a
>> >> >>> >> MCOperationsList
>> >> >>> >> and, likewise, a MCPatchBrowser inherits from a
>> >> >>> >> MCOperationsBrowser.
>> >> >>> >> - Added well-known repository accessors for #trunk and
>> >> >>> >> #packageCache,
>> >> >>> >> and #trunkUrlString avoids scattering the hard-coded url string
>> >> >>> >> literal in
>> >> >>> >> so many places.
>> >> >>> >
>> >> >>> > I don't like this last item. MCHttpRepository has no business
>> >> >>> > knowing
>> >> >>> > about any particular location, nor should we commit ourselves to
>> >> >>> > any
>> >> >>> > particular repository implementation. For instance, it might make
>> >> >>> > a
>> >> >>> > whole lot of sense to build a repository backed by Cassandra.
>> >> >>> >
>> >> >>> > I'm not convinced that ReleaseBuilder isn't the right place for
>> >> >>> > this
>> >> >>> > info. Or, to avoid the double negative, I think ReleaseBuilder is
>> >> >>> > the
>> >> >>> > place that should know about the trunk URL, because
>> >> >>> > ReleaseBuilder's
>> >> >>> > the class responsible for this kind of thing. One kind of release
>> >> >>> > we
>> >> >>> > build is a release candidate, for instance.
>> >> >>> >
>> >> >>> > frank
>> >> >>> >
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > best,
>> > Eliot
>> >
>> >
>> >
>>
>
>
>
> --
> best,
> Eliot

--
best,

Eliot

--
Best regards,
Igor Stasenko.

On 21 November 2013 02:14, J. Vuletich (mail lists) <[hidden email]> wrote:

There is a simpler way, using Git as it is meant to be used. Take a look at https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/3deff0d7b9707258766d6f003b783077664a4023#diff-5fe4c9854ae64b52029283e0648affd4 . We've been using this for a couple of years, and it works nicely.

This is simpler, yes, but much less integrated than filetree.

Because having separate file per method, means git can produce proper diff on a per-method basis, while if you just store fileouts, git can often give you false diffs

(try changing order of methods fileout which will turn whole diff to be red/green,

while there could be no changes at all).

 

 

Quoting Frank Shearar <[hidden email]>:

On 20 November 2013 16:56, Chris Muller <[hidden email]> wrote:

No it doesn't.  And the fact that all the ones you mention do isn't a
strength.  All IDEs I know of surrender the *storage* of the repository to
something else, a file system, a database, a remote directory.  But lots of
Smalltalk environments keep firm control of their own source code control,
Store in VisualWorks, Orwell and later Team/V in Digitalk, Monticello in
Squeal/Pharo.  Just the addition of the simple version scheme in Squeak
changes & sources files puts it head and shoulders ahead of VisualWorks in
the ease of investigating history, undoing changes, etc.  This is vital to
the ease of programming, its flow, etc.  Squeak doers a great ob.  We
surrender that to something else at our peril.

Mild talking past each other here. IntelliJ uses your favourite
version control system under the hood to store your code: it supplies
menus for driving, for instance, git to commit code and whatnot. It
does, in addition, store versions for every time you hit enter (or
after a period of time). These are distinct features. I'm not
proposing losing the versions button or using git to store the data
behind the versions button.

I'm proposing that we keep the Monticello front end, add a few new
buttons, and rip out the storage of source on disk, replacing it with
git. I have yet to find a decent mapping of Smalltalk code to files,
but I'd put up with a crap one if it meant one less thing that we
didn't need to do.

The "storage" you refer to is already encapsulated by MCRepository.  I
would welcome a new MCGitRepository subclass if it were able to meet
the minimum API requirements of MCRepository.  But I see no need to
"rip out" any of the existing repository-types..

Smalltalk was 30 years ahead of its time in 1980. It's now a decade
behind other languages. That is a tragedy that, in my opinion at
least, largely comes from the Smalltalk community's extreme
insularity/NIH.

Again, I don't think this group will be moved by this line of
reasoning, even with such dramatic language ("tragedy?" c'mon).

I would use stronger language. I think our current state of affairs is
a _disaster_.

Something that would be much more convincing, to me at least, would be
learning what having a MCGitRepository would do for MY goals and also
the community at large.  For example, I'm intrigued by Git's forking
capability.  How could that capability integrate into our ecosystem in
a useful way to bring more development power to the community?

I'm actually tired of the whole argument. So, in lieu of further talk,
I'm just going to carry on squirreling away on my stuff, chipping away
at the dependency nightmare we have (and if you think that's
hyperbole, you really ought to haul out graphviz and take a long, hard
look at the dependency graph. Go make yourself some coffee while dot
munges the file (which you can generate off
https://gist.github.com/frankshearar/5781906)).

Eventually we'll get to a place where I can not shiver in horror, and
then I can think again about the git problem. Even better, maybe
Camillo Bruni, Dale Henrichs and friends will have done the hard work
for me.

frank

Cheers,
Juan Vuletich

--
Best regards,
Igor Stasenko.

On Thu, Nov 21, 2013 at 4:40 PM, Igor Stasenko <[hidden email]> wrote:

Hi, Eliot

you have good point. One of the strengths of having SCM under our control
is that we can easily extend it for advanced uses (like history analysis you mentioned,

and proper metadata handling, loading/initialization order etc etc)

but there was a good reason for 'surrendering' VMMaker to git.

But I didn't.  VMMaker is still under Monticello.  What I did was store generated sources in svn *alongside* the existing platform sources.  IIRC, Ian Piumarta had already done this with the unix builds.

Because having parts of VM sources stored in MC package , while other parts  ALREADY in

external repository is even worse, which was always causing problems of desync

and messy and complicated update process.

Agreed.

 

Now it is in one repository, which means single git shapshot == full sources for given version of VM which simplifies process A LOT.. this simply overweights all the drawbacks of surrendering to git IMO.

But I haven't surrendered VMMaker to git.

 

And regarding name too long issue, i think it easy to solve: just get rid of that infamous Genie plugin, which nobody using anyways, or at least it needs serious refactoring,

because you really need to be genius to know how to properly use primitive which takes 15+ arguments. Its just insane :)

That's not a solution.  That's avoidance ;-).

 

On 20 November 2013 18:46, Eliot Miranda <[hidden email]> wrote:

Hi Frank,

On Wed, Nov 20, 2013 at 2:10 AM, Frank Shearar <[hidden email]> wrote:

On 19 November 2013 22:00, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Tue, Nov 19, 2013 at 1:39 PM, Frank Shearar <[hidden email]>
> wrote:
>>
>> On 19 November 2013 21:24, Eliot Miranda <[hidden email]> wrote:
>> > Hi Frank,
>> >
>> > On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <[hidden email]>
>> > wrote:
>> >>
>> >> On 8 November 2013 22:30, Chris Muller <[hidden email]> wrote:
>> >> > The trunk is a huge part of the Squeak development process and
>> >> > ecosystem that deserves and needs representation somewhere in the
>> >> > system.  Access to it is reasonably needed by ReleaseBuilder,
>> >> > Installer, source.squeak.org's SqueakSource and
>> >> > MonticelloConfigurations.
>> >>
>> >> Does noone else in the Squeak community use MCMs? I don't, but my
>> >> libraries are all very, very small.
>> >>
>> >> > Squeak has been using its own flavor of Monticello for several years
>> >> > now, as does Pharo and GemStone.  So, to me, it feels fine to make it
>> >> > Monticello-For-Squeak, meaning to relax restrictions imposed by
>> >> > multiplatform so it can go as far as we want toward supporting the
>> >> > Squeak process.
>> >>
>> >> It's not really germane to this discussion, but if I could flick a
>> >> switch and have us updating from github, I would do so without
>> >> hesitation. Monticello predates git by about 3 years, so we were right
>> >> on the bleeding edge there for a while, but git is now very, very far
>> >> ahead. It just makes so much sense to me to just use a world class
>> >> tool that _we don't have to maintain_. (*)
>> >
>> >
>> > Here's an example of why surrendering one's source code control to
>> > something
>> > else is a really bad idea for an IDE:
>>
>> An IDE _always_ (*) surrenders source code control to something else!
>> And it works just fine for emacs, Eclipse, Netbeans, Visual Studio,
>> IntelliJ, ...
>
>
> No it doesn't.  And the fact that all the ones you mention do isn't a
> strength.  All IDEs I know of surrender the *storage* of the repository to
> something else, a file system, a database, a remote directory.  But lots of
> Smalltalk environments keep firm control of their own source code control,
> Store in VisualWorks, Orwell and later Team/V in Digitalk, Monticello in
> Squeal/Pharo.  Just the addition of the simple version scheme in Squeak
> changes & sources files puts it head and shoulders ahead of VisualWorks in
> the ease of investigating history, undoing changes, etc.  This is vital to
> the ease of programming, its flow, etc.  Squeak doers a great ob.  We
> surrender that to something else at our peril.

Mild talking past each other here. IntelliJ uses your favourite
version control system under the hood to store your code: it supplies
menus for driving, for instance, git to commit code and whatnot. It
does, in addition, store versions for every time you hit enter (or
after a period of time). These are distinct features. I'm not
proposing losing the versions button or using git to store the data
behind the versions button.

I'm proposing that we keep the Monticello front end, add a few new
buttons, and rip out the storage of source on disk, replacing it with
git. I have yet to find a decent mapping of Smalltalk code to files,
but I'd put up with a crap one if it meant one less thing that we
didn't need to do.

Replacing the simplest part of Monticello (storing files on disc) with something much more complex (n interface with git) does not make any sense to me.  The system already has an interface to files, already has an interface to a webdav repository, etc.  These already work really well.  Does it really need an interface with something that has complex state, can get mucked up, is open to meddling through the file-system, can get out of sync, etc, etc.  All of these pathologies have happened with MemoryHole's use of mercurial.  They can and will happen with git.  Monticello is bedrock.  KISS.

Smalltalk was 30 years ahead of its time in 1980. It's now a decade
behind other languages. That is a tragedy that, in my opinion at
least, largely comes from the Smalltalk community's extreme
insularity/NIH.

I agree and don't like the NIH syndrome.  Smalltalk should play well with others.  That Squeak doesn't excel here is one reason for it's lack of popularity.  To improve it ability to play well with others is one of the design goals behind Spur.  But playing well with others, for me, does not imply weakening strong parts of the system.  Make the FFI better, don't make Monticello worse.  Make the VM loadable as a dll.  Don't replace the programming environment with Eclipse.

> One of the things we're not doing is trying to solve looking at long-term
> history (ie. some kind of server that serves the long-term history of
> packages).
>
> Something I'm really excited to see the Pharo folks looking at is richer
> change analysis than just method history, i.e. being able to spot method
> refactorings, class renames and class hierarchy refactorings.

>> (*) Squeak being the exception
>
>
> Smalltalk being the exception actually.  Smalltalk has proved powerful
> enough for it to provide its own source code control, and that's been a
> great strength.

I claim synecdoche :)

>  AT work I have to use a thin skin above Mercurial that is
> the solution for Newspeak and I despise it.  Compared to Monticello, it's
> junk.

I've not used MemoryHole, so I have no idea how much of "it's junk"
comes from mercurial and how much from MemoryHole.

Most of it comes from Mercurial.  MemoryHole is broken w.r.t. merging, and that's its problem.  But much of the interface between it and mercurial is confused and buggy, and that's the problem of trying to keep two complex beasts in sync.

 

I do know that the
biggest reason I've not written any Newspeak (and I'm fully aware that
I have failed in communicating this to Gilad) is that I don't want to
touch the UI with a barge pole. I made a tiny start at writing a
newspeak-mode for Emacs, and that's as far as I got.

But the UI (Hopscotch and Brazil) is great.  Vassili's engineered something really powerful and elegant there.  It's not complete; only one person's worked on it.  But it's innovative and provides radically better tools.  For example, the ability to see as many open methods as one wants on the stack in the debugger.

>> The given error is unfortunate, but that's not even git's fault -
>> "Filename too long" says it all. That super long filename comes from
>> filetree, so the error's existent is a confluence of a particular
>> source->file mapping together with a file system limitation.
>
>
> But the net effect is the same.  By relying on something external the system
> broke.  And it's not easy for the Pharo community to get it fixed.  They'll
> have to wrk-around the problem, and compromise something they want in their
> name mangling.  I live with crap like this all the time in building the VM
> (mingw and cygwin are awful things to depend on).  At least in the VM
> building context (and Newspeak) it is only a few souls who have to suffer.
> I hope we don't inflict this kind of thing on the general Squeak community.

Sure. Bugs are bugs. Let's not forget the recent Monticello fail
regarding UTF-8. We'll also _always_ depend on something. But that
doesn't mean that we should take responsibility for the entire world,
because we don't have the manpower. Even if we did, it's not even a
good idea.

Agreed.  But having excellent control of Smalltalk programs is a must have and relying on an external source code control system that is designed for files won't accomplish that.

frank

>> > "When doing a git clone, I do get the following:
>> >
>> >
>> > Philippe@gravitation7 ~
>> > $ git clone --depth=1 https://github.com/pharo-project/pharo-vm.git
>> > Cloning into 'pharo-vm'...
>> > remote: Counting objects: 17493, done.
>> > remote: Compressing objects: 100% (12363/12363), done.
>> > remote: Total 17493 (delta 4271), reused 17137 (delta 4143)
>> > Receiving objects: 100% (17493/17493), 19.28 MiB | 1.88 MiB/s, done.
>> > Resolving deltas: 100% (4271/4271), done.
>> > Checking connectivity... done
>> > error: unable to create file
>> > mc/VMMaker-oscog.package/GeniePlugin.class/instance
>> >
>> > /primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors.
>> >
>> > mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla
>> > g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too long)
>> > Checking out files: 100% (17525/17525), done.
>> > fatal: unable to checkout working tree
>> > warning: Clone succeeded, but checkout failed.
>> > You can inspect what was checked out with 'git status'
>> > and retry the checkout with 'git checkout -f HEAD'
>> >
>> > Pretty weird error I'd say.
>> >
>> > Anyone knowing what this is related to?"
>> >
>> > IMO having Monticello under our own control is a key strength.  yes,
>> > it's
>> > effortful to maintain but I don't see why we can't summon that effort.
>> > I do
>> > fear that if we don't we just become like everything else and soon
>> > enough
>> > we're just another scripting language.  The Smalltalk team had a name
>> > for
>> > this, something like "error 22", meaning depending on the success of
>> > other
>> > projects or infrastructure.  It's a bad idea, unless its bedrock.
>>
>> Monticello was great, back in the day. But why do we _have_ to saddle
>> ourselves with the effort of maintaining it ourselves? What else might
>> we _better_ do if we didn't spend all our time NIHing everything?
>>
>> And now, 7 years of git later, I'd consider git to be bedrock. Git
>> _has succeeded_. It and mercurial have gutted the competition: darcs,
>> monotone, bazaar, ...
>>
>> frank
>>
>> >> > Having said that, I must admit this really does make it
>> >> > Squeak-specific, no longer generic.  So, maybe an alternative should
>> >> > be to model our development process elements in a new package,
>> >> > SqueakDevelopmentProcess (?), which would depend on our Squeak's
>> >> > generic Monticello to represent the elements of our development
>> >> > process.
>> >>
>> >> I'm not terribly concerned with Squeak-specific or otherwise. It's
>> >> just that it's _trunk_ specific. I'd rather see a
>> >> SqueakDevelopmentProcess package than see it in the Monticello
>> >> package.
>> >>
>> >> frank
>> >>
>> >> (*) Finding that switch to flick is pretty hard though, which is why I
>> >> don't rant and rave about this all the time. Filetree's OK, but
>> >> destroys the ability of browsing source on the git repository (but
>> >> gives you the proper fine-grained version control you'd want).
>> >> gitfiletree supplies a Pharo UI to filetree, and it would be
>> >> worthwhile to port that UI to Squeak, through ToolBuilderification.
>> >> Continuing this discussion would necessitate a subject thread change!
>> >>
>> >> > On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier
>> >> > <[hidden email]> wrote:
>> >> >> I have same feeling as Frank,
>> >> >> a specific address of a specific repository for a specific usage has
>> >> >> not
>> >> >> much thing to do in MC.
>> >> >> MC package should not integrate each and every possible usage of MC.
>> >> >> If this does not belong to ReleaseBuilder, then we can make it a
>> >> >> System
>> >> >> thing...
>> >> >> If it's only for MCM, didn't we get a MCMcmUpdater defaultUpdateURL?
>> >> >>
>> >> >>
>> >> >> 2013/11/8 Chris Muller <[hidden email]>
>> >> >>>
>> >> >>> MonticelloConfigurations has no dependency on ReleaseBuilder and I
>> >> >>> don't think we should introduce one.
>> >> >>>
>> >> >>> If you at least acknowledge "trunk" is a real-thing in the real
>> >> >>> world,
>> >> >>> then note existence of MCRepository>>#trunk.  Sure, we could make a
>> >> >>> class-var or something if that helps you feel better, but my
>> >> >>> opinion
>> >> >>> right now is that is not necessary because code can change if/when
>> >> >>> it
>> >> >>> needs to.  Let's not let maybe-future-pie-in-the-sky-perfect be the
>> >> >>> enemy of pragmatic progress in the present.
>> >> >>>
>> >> >>> On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar
>> >> >>> <[hidden email]>
>> >> >>> wrote:
>> >> >>> > On 8 November 2013 15:25,  <[hidden email]> wrote:
>> >> >>> >> Chris Muller uploaded a new version of Monticello to project The
>> >> >>> >> Trunk:
>> >> >>> >> http://source.squeak.org/trunk/Monticello-cmm.575.mcz
>> >> >>> >>
>> >> >>> >> ==================== Summary ====================
>> >> >>> >>
>> >> >>> >> Name: Monticello-cmm.575
>> >> >>> >> Author: cmm
>> >> >>> >> Time: 3 October 2013, 9:42:40.555 pm
>> >> >>> >> UUID: daeb51c6-0b6f-41db-883d-e9764e61d8c5
>> >> >>> >> Ancestors: Monticello-cmm.573
>> >> >>> >>
>> >> >>> >> - Integrate Berts suggestions.  Refactored and renamed the API
>> >> >>> >> for
>> >> >>> >> the
>> >> >>> >> new history and origin browsing functions to avoid ambiguity
>> >> >>> >> with
>> >> >>> >> other MC
>> >> >>> >> domain elements.  Went from "version" nomenclature to "history".
>> >> >>> >> - Related to those functions, browsing a list of patch
>> >> >>> >> operations
>> >> >>> >> is
>> >> >>> >> now abstracted from browsing a Patch.  MCPatch is now a
>> >> >>> >> MCOperationsList
>> >> >>> >> and, likewise, a MCPatchBrowser inherits from a
>> >> >>> >> MCOperationsBrowser.
>> >> >>> >> - Added well-known repository accessors for #trunk and
>> >> >>> >> #packageCache,
>> >> >>> >> and #trunkUrlString avoids scattering the hard-coded url string
>> >> >>> >> literal in
>> >> >>> >> so many places.
>> >> >>> >
>> >> >>> > I don't like this last item. MCHttpRepository has no business
>> >> >>> > knowing
>> >> >>> > about any particular location, nor should we commit ourselves to
>> >> >>> > any
>> >> >>> > particular repository implementation. For instance, it might make
>> >> >>> > a
>> >> >>> > whole lot of sense to build a repository backed by Cassandra.
>> >> >>> >
>> >> >>> > I'm not convinced that ReleaseBuilder isn't the right place for
>> >> >>> > this
>> >> >>> > info. Or, to avoid the double negative, I think ReleaseBuilder is
>> >> >>> > the
>> >> >>> > place that should know about the trunk URL, because
>> >> >>> > ReleaseBuilder's
>> >> >>> > the class responsible for this kind of thing. One kind of release
>> >> >>> > we
>> >> >>> > build is a release candidate, for instance.
>> >> >>> >
>> >> >>> > frank
>> >> >>> >
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > best,
>> > Eliot
>> >
>> >
>> >
>>
>
>
>
> --
> best,
> Eliot

--
best,

Eliot

--
Best regards,
Igor Stasenko.

--
best,

Eliot

On Thu, Nov 21, 2013 at 4:52 PM, Igor Stasenko <[hidden email]> wrote:

On 21 November 2013 02:14, J. Vuletich (mail lists) <[hidden email]> wrote:

There is a simpler way, using Git as it is meant to be used. Take a look at https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/3deff0d7b9707258766d6f003b783077664a4023#diff-5fe4c9854ae64b52029283e0648affd4 . We've been using this for a couple of years, and it works nicely.

This is simpler, yes, but much less integrated than filetree.

Because having separate file per method, means git can produce proper diff on a per-method basis, while if you just store fileouts, git can often give you false diffs

(try changing order of methods fileout which will turn whole diff to be red/green,

while there could be no changes at all).

And the fact that git requires one file per method to generate proper diffs is my #1 reason for wanting /not/ to use a file-oriented SCM for Smalltalk.  I can only conclude that put up with the line-oriented diffs that git/subversion/mercurial/sccs/rcs/cvs produce is that the macro preprocessor in C and C++ makes it impossible in general to derive the structure of C and C++ programs form their source.  You yourself, Igor (and I agree with you except that a macro system is very useful) were complaining about how awful the C.C++ macro system is (and it is).  hat a mad world we live in :-).

 

 

Quoting Frank Shearar <[hidden email]>:

On 20 November 2013 16:56, Chris Muller <[hidden email]> wrote:

No it doesn't.  And the fact that all the ones you mention do isn't a
strength.  All IDEs I know of surrender the *storage* of the repository to
something else, a file system, a database, a remote directory.  But lots of
Smalltalk environments keep firm control of their own source code control,
Store in VisualWorks, Orwell and later Team/V in Digitalk, Monticello in
Squeal/Pharo.  Just the addition of the simple version scheme in Squeak
changes & sources files puts it head and shoulders ahead of VisualWorks in
the ease of investigating history, undoing changes, etc.  This is vital to
the ease of programming, its flow, etc.  Squeak doers a great ob.  We
surrender that to something else at our peril.

Mild talking past each other here. IntelliJ uses your favourite
version control system under the hood to store your code: it supplies
menus for driving, for instance, git to commit code and whatnot. It
does, in addition, store versions for every time you hit enter (or
after a period of time). These are distinct features. I'm not
proposing losing the versions button or using git to store the data
behind the versions button.

I'm proposing that we keep the Monticello front end, add a few new
buttons, and rip out the storage of source on disk, replacing it with
git. I have yet to find a decent mapping of Smalltalk code to files,
but I'd put up with a crap one if it meant one less thing that we
didn't need to do.

The "storage" you refer to is already encapsulated by MCRepository.  I
would welcome a new MCGitRepository subclass if it were able to meet
the minimum API requirements of MCRepository.  But I see no need to
"rip out" any of the existing repository-types..

Smalltalk was 30 years ahead of its time in 1980. It's now a decade
behind other languages. That is a tragedy that, in my opinion at
least, largely comes from the Smalltalk community's extreme
insularity/NIH.

Again, I don't think this group will be moved by this line of
reasoning, even with such dramatic language ("tragedy?" c'mon).

I would use stronger language. I think our current state of affairs is
a _disaster_.

Something that would be much more convincing, to me at least, would be
learning what having a MCGitRepository would do for MY goals and also
the community at large.  For example, I'm intrigued by Git's forking
capability.  How could that capability integrate into our ecosystem in
a useful way to bring more development power to the community?

I'm actually tired of the whole argument. So, in lieu of further talk,
I'm just going to carry on squirreling away on my stuff, chipping away
at the dependency nightmare we have (and if you think that's
hyperbole, you really ought to haul out graphviz and take a long, hard
look at the dependency graph. Go make yourself some coffee while dot
munges the file (which you can generate off
https://gist.github.com/frankshearar/5781906)).

Eventually we'll get to a place where I can not shiver in horror, and
then I can think again about the git problem. Even better, maybe
Camillo Bruni, Dale Henrichs and friends will have done the hard work
for me.

frank

Cheers,
Juan Vuletich

--
Best regards,
Igor Stasenko.

--
best,

Eliot

On 22 November 2013 01:59, Eliot Miranda <[hidden email]> wrote:

On Thu, Nov 21, 2013 at 4:40 PM, Igor Stasenko <[hidden email]> wrote:

Hi, Eliot

you have good point. One of the strengths of having SCM under our control
is that we can easily extend it for advanced uses (like history analysis you mentioned,

and proper metadata handling, loading/initialization order etc etc)

but there was a good reason for 'surrendering' VMMaker to git.

But I didn't.  VMMaker is still under Monticello.  What I did was store generated sources in svn *alongside* the existing platform sources.  IIRC, Ian Piumarta had already done this with the unix builds.

You know my opinion in that regard: generated code is already a build process artifact,
in this regard, storing it under SCM, is nothing better as if you would just store compiled VM binary too. And besides, where is guarantees that you can recreate them from first principles?

I know, you also storing .image and .changes files, which even worse.. causing

a huge bloat in repository, but works as a poor-man's solution to desync problem :)

Because having parts of VM sources stored in MC package , while other parts  ALREADY in

external repository is even worse, which was always causing problems of desync

and messy and complicated update process.

Agreed.

 

Now it is in one repository, which means single git shapshot == full sources for given version of VM which simplifies process A LOT.. this simply overweights all the drawbacks of surrendering to git IMO.

But I haven't surrendered VMMaker to git.

I know, but we (in Pharo) did.
 

 

And regarding name too long issue, i think it easy to solve: just get rid of that infamous Genie plugin, which nobody using anyways, or at least it needs serious refactoring,

because you really need to be genius to know how to properly use primitive which takes 15+ arguments. Its just insane :)

That's not a solution.  That's avoidance ;-).

 

sure. but in this particular case, i think more fitting term would be "legacy code cleanup" :)

 

On 20 November 2013 18:46, Eliot Miranda <[hidden email]> wrote:

Hi Frank,

On Wed, Nov 20, 2013 at 2:10 AM, Frank Shearar <[hidden email]> wrote:

On 19 November 2013 22:00, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Tue, Nov 19, 2013 at 1:39 PM, Frank Shearar <[hidden email]>
> wrote:
>>
>> On 19 November 2013 21:24, Eliot Miranda <[hidden email]> wrote:
>> > Hi Frank,
>> >
>> > On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <[hidden email]>
>> > wrote:
>> >>
>> >> On 8 November 2013 22:30, Chris Muller <[hidden email]> wrote:
>> >> > The trunk is a huge part of the Squeak development process and
>> >> > ecosystem that deserves and needs representation somewhere in the
>> >> > system.  Access to it is reasonably needed by ReleaseBuilder,
>> >> > Installer, source.squeak.org's SqueakSource and
>> >> > MonticelloConfigurations.
>> >>
>> >> Does noone else in the Squeak community use MCMs? I don't, but my
>> >> libraries are all very, very small.
>> >>
>> >> > Squeak has been using its own flavor of Monticello for several years
>> >> > now, as does Pharo and GemStone.  So, to me, it feels fine to make it
>> >> > Monticello-For-Squeak, meaning to relax restrictions imposed by
>> >> > multiplatform so it can go as far as we want toward supporting the
>> >> > Squeak process.
>> >>
>> >> It's not really germane to this discussion, but if I could flick a
>> >> switch and have us updating from github, I would do so without
>> >> hesitation. Monticello predates git by about 3 years, so we were right
>> >> on the bleeding edge there for a while, but git is now very, very far
>> >> ahead. It just makes so much sense to me to just use a world class
>> >> tool that _we don't have to maintain_. (*)
>> >
>> >
>> > Here's an example of why surrendering one's source code control to
>> > something
>> > else is a really bad idea for an IDE:
>>
>> An IDE _always_ (*) surrenders source code control to something else!
>> And it works just fine for emacs, Eclipse, Netbeans, Visual Studio,
>> IntelliJ, ...
>
>
> No it doesn't.  And the fact that all the ones you mention do isn't a
> strength.  All IDEs I know of surrender the *storage* of the repository to
> something else, a file system, a database, a remote directory.  But lots of
> Smalltalk environments keep firm control of their own source code control,
> Store in VisualWorks, Orwell and later Team/V in Digitalk, Monticello in
> Squeal/Pharo.  Just the addition of the simple version scheme in Squeak
> changes & sources files puts it head and shoulders ahead of VisualWorks in
> the ease of investigating history, undoing changes, etc.  This is vital to
> the ease of programming, its flow, etc.  Squeak doers a great ob.  We
> surrender that to something else at our peril.

Mild talking past each other here. IntelliJ uses your favourite
version control system under the hood to store your code: it supplies
menus for driving, for instance, git to commit code and whatnot. It
does, in addition, store versions for every time you hit enter (or
after a period of time). These are distinct features. I'm not
proposing losing the versions button or using git to store the data
behind the versions button.

I'm proposing that we keep the Monticello front end, add a few new
buttons, and rip out the storage of source on disk, replacing it with
git. I have yet to find a decent mapping of Smalltalk code to files,
but I'd put up with a crap one if it meant one less thing that we
didn't need to do.

Replacing the simplest part of Monticello (storing files on disc) with something much more complex (n interface with git) does not make any sense to me.  The system already has an interface to files, already has an interface to a webdav repository, etc.  These already work really well.  Does it really need an interface with something that has complex state, can get mucked up, is open to meddling through the file-system, can get out of sync, etc, etc.  All of these pathologies have happened with MemoryHole's use of mercurial.  They can and will happen with git.  Monticello is bedrock.  KISS.

Smalltalk was 30 years ahead of its time in 1980. It's now a decade
behind other languages. That is a tragedy that, in my opinion at
least, largely comes from the Smalltalk community's extreme
insularity/NIH.

I agree and don't like the NIH syndrome.  Smalltalk should play well with others.  That Squeak doesn't excel here is one reason for it's lack of popularity.  To improve it ability to play well with others is one of the design goals behind Spur.  But playing well with others, for me, does not imply weakening strong parts of the system.  Make the FFI better, don't make Monticello worse.  Make the VM loadable as a dll.  Don't replace the programming environment with Eclipse.

> One of the things we're not doing is trying to solve looking at long-term
> history (ie. some kind of server that serves the long-term history of
> packages).
>
> Something I'm really excited to see the Pharo folks looking at is richer
> change analysis than just method history, i.e. being able to spot method
> refactorings, class renames and class hierarchy refactorings.

>> (*) Squeak being the exception
>
>
> Smalltalk being the exception actually.  Smalltalk has proved powerful
> enough for it to provide its own source code control, and that's been a
> great strength.

I claim synecdoche :)

>  AT work I have to use a thin skin above Mercurial that is
> the solution for Newspeak and I despise it.  Compared to Monticello, it's
> junk.

I've not used MemoryHole, so I have no idea how much of "it's junk"
comes from mercurial and how much from MemoryHole.

Most of it comes from Mercurial.  MemoryHole is broken w.r.t. merging, and that's its problem.  But much of the interface between it and mercurial is confused and buggy, and that's the problem of trying to keep two complex beasts in sync.

 

I do know that the
biggest reason I've not written any Newspeak (and I'm fully aware that
I have failed in communicating this to Gilad) is that I don't want to
touch the UI with a barge pole. I made a tiny start at writing a
newspeak-mode for Emacs, and that's as far as I got.

But the UI (Hopscotch and Brazil) is great.  Vassili's engineered something really powerful and elegant there.  It's not complete; only one person's worked on it.  But it's innovative and provides radically better tools.  For example, the ability to see as many open methods as one wants on the stack in the debugger.

>> The given error is unfortunate, but that's not even git's fault -
>> "Filename too long" says it all. That super long filename comes from
>> filetree, so the error's existent is a confluence of a particular
>> source->file mapping together with a file system limitation.
>
>
> But the net effect is the same.  By relying on something external the system
> broke.  And it's not easy for the Pharo community to get it fixed.  They'll
> have to wrk-around the problem, and compromise something they want in their
> name mangling.  I live with crap like this all the time in building the VM
> (mingw and cygwin are awful things to depend on).  At least in the VM
> building context (and Newspeak) it is only a few souls who have to suffer.
> I hope we don't inflict this kind of thing on the general Squeak community.

Sure. Bugs are bugs. Let's not forget the recent Monticello fail
regarding UTF-8. We'll also _always_ depend on something. But that
doesn't mean that we should take responsibility for the entire world,
because we don't have the manpower. Even if we did, it's not even a
good idea.

Agreed.  But having excellent control of Smalltalk programs is a must have and relying on an external source code control system that is designed for files won't accomplish that.

frank

>> > "When doing a git clone, I do get the following:
>> >
>> >
>> > Philippe@gravitation7 ~
>> > $ git clone --depth=1 https://github.com/pharo-project/pharo-vm.git
>> > Cloning into 'pharo-vm'...
>> > remote: Counting objects: 17493, done.
>> > remote: Compressing objects: 100% (12363/12363), done.
>> > remote: Total 17493 (delta 4271), reused 17137 (delta 4143)
>> > Receiving objects: 100% (17493/17493), 19.28 MiB | 1.88 MiB/s, done.
>> > Resolving deltas: 100% (4271/4271), done.
>> > Checking connectivity... done
>> > error: unable to create file
>> > mc/VMMaker-oscog.package/GeniePlugin.class/instance
>> >
>> > /primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors.
>> >
>> > mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla
>> > g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too long)
>> > Checking out files: 100% (17525/17525), done.
>> > fatal: unable to checkout working tree
>> > warning: Clone succeeded, but checkout failed.
>> > You can inspect what was checked out with 'git status'
>> > and retry the checkout with 'git checkout -f HEAD'
>> >
>> > Pretty weird error I'd say.
>> >
>> > Anyone knowing what this is related to?"
>> >
>> > IMO having Monticello under our own control is a key strength.  yes,
>> > it's
>> > effortful to maintain but I don't see why we can't summon that effort.
>> > I do
>> > fear that if we don't we just become like everything else and soon
>> > enough
>> > we're just another scripting language.  The Smalltalk team had a name
>> > for
>> > this, something like "error 22", meaning depending on the success of
>> > other
>> > projects or infrastructure.  It's a bad idea, unless its bedrock.
>>
>> Monticello was great, back in the day. But why do we _have_ to saddle
>> ourselves with the effort of maintaining it ourselves? What else might
>> we _better_ do if we didn't spend all our time NIHing everything?
>>
>> And now, 7 years of git later, I'd consider git to be bedrock. Git
>> _has succeeded_. It and mercurial have gutted the competition: darcs,
>> monotone, bazaar, ...
>>
>> frank
>>
>> >> > Having said that, I must admit this really does make it
>> >> > Squeak-specific, no longer generic.  So, maybe an alternative should
>> >> > be to model our development process elements in a new package,
>> >> > SqueakDevelopmentProcess (?), which would depend on our Squeak's
>> >> > generic Monticello to represent the elements of our development
>> >> > process.
>> >>
>> >> I'm not terribly concerned with Squeak-specific or otherwise. It's
>> >> just that it's _trunk_ specific. I'd rather see a
>> >> SqueakDevelopmentProcess package than see it in the Monticello
>> >> package.
>> >>
>> >> frank
>> >>
>> >> (*) Finding that switch to flick is pretty hard though, which is why I
>> >> don't rant and rave about this all the time. Filetree's OK, but
>> >> destroys the ability of browsing source on the git repository (but
>> >> gives you the proper fine-grained version control you'd want).
>> >> gitfiletree supplies a Pharo UI to filetree, and it would be
>> >> worthwhile to port that UI to Squeak, through ToolBuilderification.
>> >> Continuing this discussion would necessitate a subject thread change!
>> >>
>> >> > On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier
>> >> > <[hidden email]> wrote:
>> >> >> I have same feeling as Frank,
>> >> >> a specific address of a specific repository for a specific usage has
>> >> >> not
>> >> >> much thing to do in MC.
>> >> >> MC package should not integrate each and every possible usage of MC.
>> >> >> If this does not belong to ReleaseBuilder, then we can make it a
>> >> >> System
>> >> >> thing...
>> >> >> If it's only for MCM, didn't we get a MCMcmUpdater defaultUpdateURL?
>> >> >>
>> >> >>
>> >> >> 2013/11/8 Chris Muller <[hidden email]>
>> >> >>>
>> >> >>> MonticelloConfigurations has no dependency on ReleaseBuilder and I
>> >> >>> don't think we should introduce one.
>> >> >>>
>> >> >>> If you at least acknowledge "trunk" is a real-thing in the real
>> >> >>> world,
>> >> >>> then note existence of MCRepository>>#trunk.  Sure, we could make a
>> >> >>> class-var or something if that helps you feel better, but my
>> >> >>> opinion
>> >> >>> right now is that is not necessary because code can change if/when
>> >> >>> it
>> >> >>> needs to.  Let's not let maybe-future-pie-in-the-sky-perfect be the
>> >> >>> enemy of pragmatic progress in the present.
>> >> >>>
>> >> >>> On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar
>> >> >>> <[hidden email]>
>> >> >>> wrote:
>> >> >>> > On 8 November 2013 15:25,  <[hidden email]> wrote:
>> >> >>> >> Chris Muller uploaded a new version of Monticello to project The
>> >> >>> >> Trunk:
>> >> >>> >> http://source.squeak.org/trunk/Monticello-cmm.575.mcz
>> >> >>> >>
>> >> >>> >> ==================== Summary ====================
>> >> >>> >>
>> >> >>> >> Name: Monticello-cmm.575
>> >> >>> >> Author: cmm
>> >> >>> >> Time: 3 October 2013, 9:42:40.555 pm
>> >> >>> >> UUID: daeb51c6-0b6f-41db-883d-e9764e61d8c5
>> >> >>> >> Ancestors: Monticello-cmm.573
>> >> >>> >>
>> >> >>> >> - Integrate Berts suggestions.  Refactored and renamed the API
>> >> >>> >> for
>> >> >>> >> the
>> >> >>> >> new history and origin browsing functions to avoid ambiguity
>> >> >>> >> with
>> >> >>> >> other MC
>> >> >>> >> domain elements.  Went from "version" nomenclature to "history".
>> >> >>> >> - Related to those functions, browsing a list of patch
>> >> >>> >> operations
>> >> >>> >> is
>> >> >>> >> now abstracted from browsing a Patch.  MCPatch is now a
>> >> >>> >> MCOperationsList
>> >> >>> >> and, likewise, a MCPatchBrowser inherits from a
>> >> >>> >> MCOperationsBrowser.
>> >> >>> >> - Added well-known repository accessors for #trunk and
>> >> >>> >> #packageCache,
>> >> >>> >> and #trunkUrlString avoids scattering the hard-coded url string
>> >> >>> >> literal in
>> >> >>> >> so many places.
>> >> >>> >
>> >> >>> > I don't like this last item. MCHttpRepository has no business
>> >> >>> > knowing
>> >> >>> > about any particular location, nor should we commit ourselves to
>> >> >>> > any
>> >> >>> > particular repository implementation. For instance, it might make
>> >> >>> > a
>> >> >>> > whole lot of sense to build a repository backed by Cassandra.
>> >> >>> >
>> >> >>> > I'm not convinced that ReleaseBuilder isn't the right place for
>> >> >>> > this
>> >> >>> > info. Or, to avoid the double negative, I think ReleaseBuilder is
>> >> >>> > the
>> >> >>> > place that should know about the trunk URL, because
>> >> >>> > ReleaseBuilder's
>> >> >>> > the class responsible for this kind of thing. One kind of release
>> >> >>> > we
>> >> >>> > build is a release candidate, for instance.
>> >> >>> >
>> >> >>> > frank
>> >> >>> >
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > best,
>> > Eliot
>> >
>> >
>> >
>>
>
>
>
> --
> best,
> Eliot

--
best,

Eliot

--
Best regards,
Igor Stasenko.

--
best,

Eliot

--
Best regards,
Igor Stasenko.

On Thu, Nov 21, 2013 at 5:12 PM, Igor Stasenko <[hidden email]> wrote:

On 22 November 2013 01:59, Eliot Miranda <[hidden email]> wrote:

On Thu, Nov 21, 2013 at 4:40 PM, Igor Stasenko <[hidden email]> wrote:

Hi, Eliot

you have good point. One of the strengths of having SCM under our control
is that we can easily extend it for advanced uses (like history analysis you mentioned,

and proper metadata handling, loading/initialization order etc etc)

but there was a good reason for 'surrendering' VMMaker to git.

But I didn't.  VMMaker is still under Monticello.  What I did was store generated sources in svn *alongside* the existing platform sources.  IIRC, Ian Piumarta had already done this with the unix builds.

You know my opinion in that regard: generated code is already a build process artifact,
in this regard, storing it under SCM, is nothing better as if you would just store compiled VM binary too. And besides, where is guarantees that you can recreate them from first principles?

I know, you also storing .image and .changes files, which even worse.. causing

a huge bloat in repository, but works as a poor-man's solution to desync problem :)

 

In fact it's a waste of space.  I never keep it up-to-date.  I should nuke it and rely on Metacello to recreate VMMaker images.

Because having parts of VM sources stored in MC package , while other parts  ALREADY in

external repository is even worse, which was always causing problems of desync

and messy and complicated update process.

Agreed.

 

Now it is in one repository, which means single git shapshot == full sources for given version of VM which simplifies process A LOT.. this simply overweights all the drawbacks of surrendering to git IMO.

But I haven't surrendered VMMaker to git.

I know, but we (in Pharo) did.
 

 

And regarding name too long issue, i think it easy to solve: just get rid of that infamous Genie plugin, which nobody using anyways, or at least it needs serious refactoring,

because you really need to be genius to know how to properly use primitive which takes 15+ arguments. Its just insane :)

That's not a solution.  That's avoidance ;-).

 

sure. but in this particular case, i think more fitting term would be "legacy code cleanup" :)

 

On 20 November 2013 18:46, Eliot Miranda <[hidden email]> wrote:

Hi Frank,

On Wed, Nov 20, 2013 at 2:10 AM, Frank Shearar <[hidden email]> wrote:

On 19 November 2013 22:00, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Tue, Nov 19, 2013 at 1:39 PM, Frank Shearar <[hidden email]>
> wrote:
>>
>> On 19 November 2013 21:24, Eliot Miranda <[hidden email]> wrote:
>> > Hi Frank,
>> >
>> > On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <[hidden email]>
>> > wrote:
>> >>
>> >> On 8 November 2013 22:30, Chris Muller <[hidden email]> wrote:
>> >> > The trunk is a huge part of the Squeak development process and
>> >> > ecosystem that deserves and needs representation somewhere in the
>> >> > system.  Access to it is reasonably needed by ReleaseBuilder,
>> >> > Installer, source.squeak.org's SqueakSource and
>> >> > MonticelloConfigurations.
>> >>
>> >> Does noone else in the Squeak community use MCMs? I don't, but my
>> >> libraries are all very, very small.
>> >>
>> >> > Squeak has been using its own flavor of Monticello for several years
>> >> > now, as does Pharo and GemStone.  So, to me, it feels fine to make it
>> >> > Monticello-For-Squeak, meaning to relax restrictions imposed by
>> >> > multiplatform so it can go as far as we want toward supporting the
>> >> > Squeak process.
>> >>
>> >> It's not really germane to this discussion, but if I could flick a
>> >> switch and have us updating from github, I would do so without
>> >> hesitation. Monticello predates git by about 3 years, so we were right
>> >> on the bleeding edge there for a while, but git is now very, very far
>> >> ahead. It just makes so much sense to me to just use a world class
>> >> tool that _we don't have to maintain_. (*)
>> >
>> >
>> > Here's an example of why surrendering one's source code control to
>> > something
>> > else is a really bad idea for an IDE:
>>
>> An IDE _always_ (*) surrenders source code control to something else!
>> And it works just fine for emacs, Eclipse, Netbeans, Visual Studio,
>> IntelliJ, ...
>
>
> No it doesn't.  And the fact that all the ones you mention do isn't a
> strength.  All IDEs I know of surrender the *storage* of the repository to
> something else, a file system, a database, a remote directory.  But lots of
> Smalltalk environments keep firm control of their own source code control,
> Store in VisualWorks, Orwell and later Team/V in Digitalk, Monticello in
> Squeal/Pharo.  Just the addition of the simple version scheme in Squeak
> changes & sources files puts it head and shoulders ahead of VisualWorks in
> the ease of investigating history, undoing changes, etc.  This is vital to
> the ease of programming, its flow, etc.  Squeak doers a great ob.  We
> surrender that to something else at our peril.

Mild talking past each other here. IntelliJ uses your favourite
version control system under the hood to store your code: it supplies
menus for driving, for instance, git to commit code and whatnot. It
does, in addition, store versions for every time you hit enter (or
after a period of time). These are distinct features. I'm not
proposing losing the versions button or using git to store the data
behind the versions button.

I'm proposing that we keep the Monticello front end, add a few new
buttons, and rip out the storage of source on disk, replacing it with
git. I have yet to find a decent mapping of Smalltalk code to files,
but I'd put up with a crap one if it meant one less thing that we
didn't need to do.

Replacing the simplest part of Monticello (storing files on disc) with something much more complex (n interface with git) does not make any sense to me.  The system already has an interface to files, already has an interface to a webdav repository, etc.  These already work really well.  Does it really need an interface with something that has complex state, can get mucked up, is open to meddling through the file-system, can get out of sync, etc, etc.  All of these pathologies have happened with MemoryHole's use of mercurial.  They can and will happen with git.  Monticello is bedrock.  KISS.

Smalltalk was 30 years ahead of its time in 1980. It's now a decade
behind other languages. That is a tragedy that, in my opinion at
least, largely comes from the Smalltalk community's extreme
insularity/NIH.

I agree and don't like the NIH syndrome.  Smalltalk should play well with others.  That Squeak doesn't excel here is one reason for it's lack of popularity.  To improve it ability to play well with others is one of the design goals behind Spur.  But playing well with others, for me, does not imply weakening strong parts of the system.  Make the FFI better, don't make Monticello worse.  Make the VM loadable as a dll.  Don't replace the programming environment with Eclipse.

> One of the things we're not doing is trying to solve looking at long-term
> history (ie. some kind of server that serves the long-term history of
> packages).
>
> Something I'm really excited to see the Pharo folks looking at is richer
> change analysis than just method history, i.e. being able to spot method
> refactorings, class renames and class hierarchy refactorings.

>> (*) Squeak being the exception
>
>
> Smalltalk being the exception actually.  Smalltalk has proved powerful
> enough for it to provide its own source code control, and that's been a
> great strength.

I claim synecdoche :)

>  AT work I have to use a thin skin above Mercurial that is
> the solution for Newspeak and I despise it.  Compared to Monticello, it's
> junk.

I've not used MemoryHole, so I have no idea how much of "it's junk"
comes from mercurial and how much from MemoryHole.

Most of it comes from Mercurial.  MemoryHole is broken w.r.t. merging, and that's its problem.  But much of the interface between it and mercurial is confused and buggy, and that's the problem of trying to keep two complex beasts in sync.

 

I do know that the
biggest reason I've not written any Newspeak (and I'm fully aware that
I have failed in communicating this to Gilad) is that I don't want to
touch the UI with a barge pole. I made a tiny start at writing a
newspeak-mode for Emacs, and that's as far as I got.

But the UI (Hopscotch and Brazil) is great.  Vassili's engineered something really powerful and elegant there.  It's not complete; only one person's worked on it.  But it's innovative and provides radically better tools.  For example, the ability to see as many open methods as one wants on the stack in the debugger.

>> The given error is unfortunate, but that's not even git's fault -
>> "Filename too long" says it all. That super long filename comes from
>> filetree, so the error's existent is a confluence of a particular
>> source->file mapping together with a file system limitation.
>
>
> But the net effect is the same.  By relying on something external the system
> broke.  And it's not easy for the Pharo community to get it fixed.  They'll
> have to wrk-around the problem, and compromise something they want in their
> name mangling.  I live with crap like this all the time in building the VM
> (mingw and cygwin are awful things to depend on).  At least in the VM
> building context (and Newspeak) it is only a few souls who have to suffer.
> I hope we don't inflict this kind of thing on the general Squeak community.

Sure. Bugs are bugs. Let's not forget the recent Monticello fail
regarding UTF-8. We'll also _always_ depend on something. But that
doesn't mean that we should take responsibility for the entire world,
because we don't have the manpower. Even if we did, it's not even a
good idea.

Agreed.  But having excellent control of Smalltalk programs is a must have and relying on an external source code control system that is designed for files won't accomplish that.

frank

>> > "When doing a git clone, I do get the following:
>> >
>> >
>> > Philippe@gravitation7 ~
>> > $ git clone --depth=1 https://github.com/pharo-project/pharo-vm.git
>> > Cloning into 'pharo-vm'...
>> > remote: Counting objects: 17493, done.
>> > remote: Compressing objects: 100% (12363/12363), done.
>> > remote: Total 17493 (delta 4271), reused 17137 (delta 4143)
>> > Receiving objects: 100% (17493/17493), 19.28 MiB | 1.88 MiB/s, done.
>> > Resolving deltas: 100% (4271/4271), done.
>> > Checking connectivity... done
>> > error: unable to create file
>> > mc/VMMaker-oscog.package/GeniePlugin.class/instance
>> >
>> > /primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors.
>> >
>> > mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla
>> > g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too long)
>> > Checking out files: 100% (17525/17525), done.
>> > fatal: unable to checkout working tree
>> > warning: Clone succeeded, but checkout failed.
>> > You can inspect what was checked out with 'git status'
>> > and retry the checkout with 'git checkout -f HEAD'
>> >
>> > Pretty weird error I'd say.
>> >
>> > Anyone knowing what this is related to?"
>> >
>> > IMO having Monticello under our own control is a key strength.  yes,
>> > it's
>> > effortful to maintain but I don't see why we can't summon that effort.
>> > I do
>> > fear that if we don't we just become like everything else and soon
>> > enough
>> > we're just another scripting language.  The Smalltalk team had a name
>> > for
>> > this, something like "error 22", meaning depending on the success of
>> > other
>> > projects or infrastructure.  It's a bad idea, unless its bedrock.
>>
>> Monticello was great, back in the day. But why do we _have_ to saddle
>> ourselves with the effort of maintaining it ourselves? What else might
>> we _better_ do if we didn't spend all our time NIHing everything?
>>
>> And now, 7 years of git later, I'd consider git to be bedrock. Git
>> _has succeeded_. It and mercurial have gutted the competition: darcs,
>> monotone, bazaar, ...
>>
>> frank
>>
>> >> > Having said that, I must admit this really does make it
>> >> > Squeak-specific, no longer generic.  So, maybe an alternative should
>> >> > be to model our development process elements in a new package,
>> >> > SqueakDevelopmentProcess (?), which would depend on our Squeak's
>> >> > generic Monticello to represent the elements of our development
>> >> > process.
>> >>
>> >> I'm not terribly concerned with Squeak-specific or otherwise. It's
>> >> just that it's _trunk_ specific. I'd rather see a
>> >> SqueakDevelopmentProcess package than see it in the Monticello
>> >> package.
>> >>
>> >> frank
>> >>
>> >> (*) Finding that switch to flick is pretty hard though, which is why I
>> >> don't rant and rave about this all the time. Filetree's OK, but
>> >> destroys the ability of browsing source on the git repository (but
>> >> gives you the proper fine-grained version control you'd want).
>> >> gitfiletree supplies a Pharo UI to filetree, and it would be
>> >> worthwhile to port that UI to Squeak, through ToolBuilderification.
>> >> Continuing this discussion would necessitate a subject thread change!
>> >>
>> >> > On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier
>> >> > <[hidden email]> wrote:
>> >> >> I have same feeling as Frank,
>> >> >> a specific address of a specific repository for a specific usage has
>> >> >> not
>> >> >> much thing to do in MC.
>> >> >> MC package should not integrate each and every possible usage of MC.
>> >> >> If this does not belong to ReleaseBuilder, then we can make it a
>> >> >> System
>> >> >> thing...
>> >> >> If it's only for MCM, didn't we get a MCMcmUpdater defaultUpdateURL?
>> >> >>
>> >> >>
>> >> >> 2013/11/8 Chris Muller <[hidden email]>
>> >> >>>
>> >> >>> MonticelloConfigurations has no dependency on ReleaseBuilder and I
>> >> >>> don't think we should introduce one.
>> >> >>>
>> >> >>> If you at least acknowledge "trunk" is a real-thing in the real
>> >> >>> world,
>> >> >>> then note existence of MCRepository>>#trunk.  Sure, we could make a
>> >> >>> class-var or something if that helps you feel better, but my
>> >> >>> opinion
>> >> >>> right now is that is not necessary because code can change if/when
>> >> >>> it
>> >> >>> needs to.  Let's not let maybe-future-pie-in-the-sky-perfect be the
>> >> >>> enemy of pragmatic progress in the present.
>> >> >>>
>> >> >>> On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar
>> >> >>> <[hidden email]>
>> >> >>> wrote:
>> >> >>> > On 8 November 2013 15:25,  <[hidden email]> wrote:
>> >> >>> >> Chris Muller uploaded a new version of Monticello to project The
>> >> >>> >> Trunk:
>> >> >>> >> http://source.squeak.org/trunk/Monticello-cmm.575.mcz
>> >> >>> >>
>> >> >>> >> ==================== Summary ====================
>> >> >>> >>
>> >> >>> >> Name: Monticello-cmm.575
>> >> >>> >> Author: cmm
>> >> >>> >> Time: 3 October 2013, 9:42:40.555 pm
>> >> >>> >> UUID: daeb51c6-0b6f-41db-883d-e9764e61d8c5
>> >> >>> >> Ancestors: Monticello-cmm.573
>> >> >>> >>
>> >> >>> >> - Integrate Berts suggestions.  Refactored and renamed the API
>> >> >>> >> for
>> >> >>> >> the
>> >> >>> >> new history and origin browsing functions to avoid ambiguity
>> >> >>> >> with
>> >> >>> >> other MC
>> >> >>> >> domain elements.  Went from "version" nomenclature to "history".
>> >> >>> >> - Related to those functions, browsing a list of patch
>> >> >>> >> operations
>> >> >>> >> is
>> >> >>> >> now abstracted from browsing a Patch.  MCPatch is now a
>> >> >>> >> MCOperationsList
>> >> >>> >> and, likewise, a MCPatchBrowser inherits from a
>> >> >>> >> MCOperationsBrowser.
>> >> >>> >> - Added well-known repository accessors for #trunk and
>> >> >>> >> #packageCache,
>> >> >>> >> and #trunkUrlString avoids scattering the hard-coded url string
>> >> >>> >> literal in
>> >> >>> >> so many places.
>> >> >>> >
>> >> >>> > I don't like this last item. MCHttpRepository has no business
>> >> >>> > knowing
>> >> >>> > about any particular location, nor should we commit ourselves to
>> >> >>> > any
>> >> >>> > particular repository implementation. For instance, it might make
>> >> >>> > a
>> >> >>> > whole lot of sense to build a repository backed by Cassandra.
>> >> >>> >
>> >> >>> > I'm not convinced that ReleaseBuilder isn't the right place for
>> >> >>> > this
>> >> >>> > info. Or, to avoid the double negative, I think ReleaseBuilder is
>> >> >>> > the
>> >> >>> > place that should know about the trunk URL, because
>> >> >>> > ReleaseBuilder's
>> >> >>> > the class responsible for this kind of thing. One kind of release
>> >> >>> > we
>> >> >>> > build is a release candidate, for instance.
>> >> >>> >
>> >> >>> > frank
>> >> >>> >
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > best,
>> > Eliot
>> >
>> >
>> >
>>
>
>
>
> --
> best,
> Eliot

--
best,

Eliot

--
Best regards,
Igor Stasenko.

--
best,

Eliot

--
Best regards,
Igor Stasenko.

--
best,

Eliot

Hey guys, how about trimming your posts, eh?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Totum dependeat. = Let it all hang out.

On 22 November 2013 01:04, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Thu, Nov 21, 2013 at 4:52 PM, Igor Stasenko <[hidden email]> wrote:
>>
>>
>>
>>
>> On 21 November 2013 02:14, J. Vuletich (mail lists)
>> <[hidden email]> wrote:
>>>
>>> There is a simpler way, using Git as it is meant to be used. Take a look
>>> at
>>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/3deff0d7b9707258766d6f003b783077664a4023#diff-5fe4c9854ae64b52029283e0648affd4
>>> . We've been using this for a couple of years, and it works nicely.
>>>
>> This is simpler, yes, but much less integrated than filetree.
>> Because having separate file per method, means git can produce proper diff
>> on a per-method basis, while if you just store fileouts, git can often give
>> you false diffs
>> (try changing order of methods fileout which will turn whole diff to be
>> red/green,
>> while there could be no changes at all).
>
>
> And the fact that git requires one file per method to generate proper diffs
> is my #1 reason for wanting /not/ to use a file-oriented SCM for Smalltalk.

Git is not a file-oriented SCM. Igor's comment says that filetree is
doing exactly the right thing, as far as versioning things goes: a
single method is a single code datum so goes into a separate object.
Monticello happens to do exactly the same thing.

frank

> I can only conclude that put up with the line-oriented diffs that
> git/subversion/mercurial/sccs/rcs/cvs produce is that the macro preprocessor
> in C and C++ makes it impossible in general to derive the structure of C and
> C++ programs form their source.  You yourself, Igor (and I agree with you
> except that a macro system is very useful) were complaining about how awful
> the C.C++ macro system is (and it is).  hat a mad world we live in :-).
>
>>
>>
>>>
>>>
>>> Quoting Frank Shearar <[hidden email]>:
>>>
>>>> On 20 November 2013 16:56, Chris Muller <[hidden email]> wrote:
>>>>>>>
>>>>>>> No it doesn't.  And the fact that all the ones you mention do isn't a
>>>>>>> strength.  All IDEs I know of surrender the *storage* of the
>>>>>>> repository to
>>>>>>> something else, a file system, a database, a remote directory.  But
>>>>>>> lots of
>>>>>>> Smalltalk environments keep firm control of their own source code
>>>>>>> control,
>>>>>>> Store in VisualWorks, Orwell and later Team/V in Digitalk, Monticello
>>>>>>> in
>>>>>>> Squeal/Pharo.  Just the addition of the simple version scheme in
>>>>>>> Squeak
>>>>>>> changes & sources files puts it head and shoulders ahead of
>>>>>>> VisualWorks in
>>>>>>> the ease of investigating history, undoing changes, etc.  This is
>>>>>>> vital to
>>>>>>> the ease of programming, its flow, etc.  Squeak doers a great ob.  We
>>>>>>> surrender that to something else at our peril.
>>>>>>
>>>>>>
>>>>>> Mild talking past each other here. IntelliJ uses your favourite
>>>>>> version control system under the hood to store your code: it supplies
>>>>>> menus for driving, for instance, git to commit code and whatnot. It
>>>>>> does, in addition, store versions for every time you hit enter (or
>>>>>> after a period of time). These are distinct features. I'm not
>>>>>> proposing losing the versions button or using git to store the data
>>>>>> behind the versions button.
>>>>>>
>>>>>> I'm proposing that we keep the Monticello front end, add a few new
>>>>>> buttons, and rip out the storage of source on disk, replacing it with
>>>>>> git. I have yet to find a decent mapping of Smalltalk code to files,
>>>>>> but I'd put up with a crap one if it meant one less thing that we
>>>>>> didn't need to do.
>>>>>
>>>>>
>>>>> The "storage" you refer to is already encapsulated by MCRepository.  I
>>>>> would welcome a new MCGitRepository subclass if it were able to meet
>>>>> the minimum API requirements of MCRepository.  But I see no need to
>>>>> "rip out" any of the existing repository-types..
>>>>>
>>>>>> Smalltalk was 30 years ahead of its time in 1980. It's now a decade
>>>>>> behind other languages. That is a tragedy that, in my opinion at
>>>>>> least, largely comes from the Smalltalk community's extreme
>>>>>> insularity/NIH.
>>>>>
>>>>>
>>>>> Again, I don't think this group will be moved by this line of
>>>>> reasoning, even with such dramatic language ("tragedy?" c'mon).
>>>>
>>>>
>>>> I would use stronger language. I think our current state of affairs is
>>>> a _disaster_.
>>>>
>>>>> Something that would be much more convincing, to me at least, would be
>>>>> learning what having a MCGitRepository would do for MY goals and also
>>>>> the community at large.  For example, I'm intrigued by Git's forking
>>>>> capability.  How could that capability integrate into our ecosystem in
>>>>> a useful way to bring more development power to the community?
>>>>
>>>>
>>>> I'm actually tired of the whole argument. So, in lieu of further talk,
>>>> I'm just going to carry on squirreling away on my stuff, chipping away
>>>> at the dependency nightmare we have (and if you think that's
>>>> hyperbole, you really ought to haul out graphviz and take a long, hard
>>>> look at the dependency graph. Go make yourself some coffee while dot
>>>> munges the file (which you can generate off
>>>> https://gist.github.com/frankshearar/5781906)).
>>>>
>>>> Eventually we'll get to a place where I can not shiver in horror, and
>>>> then I can think again about the git problem. Even better, maybe
>>>> Camillo Bruni, Dale Henrichs and friends will have done the hard work
>>>> for me.
>>>>
>>>> frank
>>>>
>>>>
>>>
>>>
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>>
>>
>
>
>
> --
> best,
> Eliot
>
>
>