On Thu, Nov 21, 2013 at 4:40 PM, Igor Stasenko <siguctua at gmail.com> 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 <eliot.miranda at gmail.com> wrote:
>
>> Hi Frank,
>>
>> On Wed, Nov 20, 2013 at 2:10 AM, Frank Shearar <frank.shearar at gmail.com>wrote:
>>
>>> On 19 November 2013 22:00, Eliot Miranda <eliot.miranda at gmail.com>
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Tue, Nov 19, 2013 at 1:39 PM, Frank Shearar <
>>> frank.shearar at gmail.com>
>>> > wrote:
>>> >>
>>> >> On 19 November 2013 21:24, Eliot Miranda <eliot.miranda at gmail.com>
>>> wrote:
>>> >> > Hi Frank,
>>> >> >
>>> >> > On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <
>>> frank.shearar at gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> On 8 November 2013 22:30, Chris Muller <asqueaker at gmail.com>
>>> 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 at 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
>>> >> >> > <nicolas.cellier.aka.nice at gmail.com> 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 <asqueaker at gmail.com>
>>> >> >> >>>
>>> >> >> >>> 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
>>> >> >> >>> <frank.shearar at gmail.com>
>>> >> >> >>> wrote:
>>> >> >> >>> > On 8 November 2013 15:25,  <commits at source.squeak.org>
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131121/797c10df/attachment-0001.htm