Discussion:
github et al (was [squeak-dev] The Trunk: Monticello-cmm.575.mcz)
(too old to reply)
Eliot Miranda
2013-11-20 03:24:59 UTC
Permalink
Hi Frank,
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:

"When doing a git clone, I do get the following:


***@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.
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
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?
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 <
Chris Muller uploaded a new version of Monticello to project The
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131119/62d8d7c2/attachment-0001.htm
Frank Shearar
2013-11-20 03:39:23 UTC
Permalink
Post by Eliot Miranda
Hi Frank,
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
An IDE _always_ (*) surrenders source code control to something else!
And it works just fine for emacs, Eclipse, Netbeans, Visual Studio,
IntelliJ, ...

(*) Squeak being the exception

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.
Post by Eliot Miranda
$ 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
Post by Eliot Miranda
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
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?
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
Chris Muller uploaded a new version of Monticello to project The
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
Eliot Miranda
2013-11-20 04:00:59 UTC
Permalink
Post by Eliot Miranda
Post by Eliot Miranda
Hi Frank,
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
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.

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. 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.
Post by Eliot Miranda
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.
Post by Eliot Miranda
Post by Eliot Miranda
$ 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
Post by Eliot Miranda
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
Post by Eliot Miranda
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
Post by Eliot Miranda
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
Post by Eliot Miranda
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
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
Post by Eliot Miranda
thing...
If it's only for MCM, didn't we get a MCMcmUpdater defaultUpdateURL?
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,
Post by Eliot Miranda
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
Post by Eliot Miranda
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
Chris Muller uploaded a new version of Monticello to project The
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
Post by Eliot Miranda
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
Post by Eliot Miranda
particular repository implementation. For instance, it might make
a
Post by Eliot Miranda
whole lot of sense to build a repository backed by Cassandra.
I'm not convinced that ReleaseBuilder isn't the right place for
this
Post by Eliot Miranda
info. Or, to avoid the double negative, I think ReleaseBuilder is the
place that should know about the trunk URL, because
ReleaseBuilder's
Post by Eliot Miranda
the class responsible for this kind of thing. One kind of release
we
Post by Eliot Miranda
build is a release candidate, for instance.
frank
--
best,
Eliot
--
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131119/83cea432/attachment.htm
Chris Muller
2013-11-20 05:47:22 UTC
Permalink
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
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.
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).
Yes we are! The history-providing prototype has been running on box4
for > 2 months now. Did you not see the announcement?

http://forum.world.st/ANN-New-source-squeak-org-prototype-td4707006.html

In fact, Eliot, YOU were one of the persons I did this for because you
(and Tim) had expressed interest in it before. It's in trunk now, why
don't you give it a try?

1) Add this repository to Monticello:

MCHttpRepository
location: 'http://box4.squeak.org:8888/trunk'
user: 'id'
password: 'pw'

2) Add the above repository to a package you wish to enable history for.
3) In a browser's class or methods pane, select 'browse mc history' or
'browse mc origin'.

Your timing is impeccable because, as of this very moment, I'm
preparing a new version of this prototype which provides this for not
just Trunk but all projects including VMMaker, Etoys, Inbox, etc.
Post by Eliot Miranda
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.
Post by Frank Shearar
(*) 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. 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.
Post by Frank Shearar
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.
Post by Frank Shearar
Post by Eliot Miranda
$ 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
Post by Eliot Miranda
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
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?
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
Chris Muller uploaded a new version of Monticello to project The
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
Frank Shearar
2013-11-20 16:10:40 UTC
Permalink
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
Hi Frank,
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
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.

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.
Post by Eliot Miranda
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.
Post by Frank Shearar
(*) 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 :)
Post by Eliot Miranda
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. 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.
Post by Eliot Miranda
Post by Frank Shearar
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.

frank
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
$ 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
Post by Eliot Miranda
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
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?
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
Chris Muller uploaded a new version of Monticello to project The
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
Chris Muller
2013-11-20 22:56:35 UTC
Permalink
Post by Frank Shearar
Post by Eliot Miranda
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..
Post by Frank Shearar
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).

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?
Frank Shearar
2013-11-21 02:42:02 UTC
Permalink
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
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..
Post by Frank Shearar
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_.
Post by Chris Muller
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
Eliot Miranda
2013-11-21 04:27:47 UTC
Permalink
Post by Eliot Miranda
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
something else, a file system, a database, a remote directory. But
lots of
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
Smalltalk environments keep firm control of their own source code
control,
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
Store in VisualWorks, Orwell and later Team/V in Digitalk, Monticello
in
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
Squeal/Pharo. Just the addition of the simple version scheme in Squeak
changes & sources files puts it head and shoulders ahead of
VisualWorks in
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
the ease of investigating history, undoing changes, etc. This is
vital to
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
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..
Post by Frank Shearar
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_.
What specifically is broken? Can you concentrate on process rather than
component?
Post by Eliot Miranda
Post by Chris Muller
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)).
I don't want to keep on at you but I would suggest that the dependency
nightmare is orthogonal to source code control. It is about modularity,
not versioning. Do you agree?
Post by Eliot Miranda
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
--
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131120/d35624d9/attachment.htm
Chris Muller
2013-11-21 04:44:28 UTC
Permalink
Post by Frank Shearar
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.
Dale presented a prototype for this 18 months ago at Smalltalk
Solutions 2012, so the work may very well be done by now.
Frank Shearar
2013-11-21 19:40:00 UTC
Permalink
Post by Chris Muller
Post by Frank Shearar
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.
Dale presented a prototype for this 18 months ago at Smalltalk
Solutions 2012, so the work may very well be done by now.
Yes: https://github.com/dalehenrich/Filetree There's also Tim
Felgentreff's Gitocello, which uses chunk format:
github.com/timfel/Gitocello

Thierry Goubier also wrote a UI for Pharo:
https://github.com/ThierryGoubier/AltBrowser
Frank Shearar
2013-11-21 19:34:25 UTC
Permalink
Post by Eliot Miranda
Post by Frank Shearar
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
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..
Post by Frank Shearar
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_.
What specifically is broken? Can you concentrate on process rather than
component?
Post by Frank Shearar
Post by Chris Muller
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)).
I don't want to keep on at you but I would suggest that the dependency
nightmare is orthogonal to source code control. It is about modularity, not
versioning. Do you agree?
I meant "I'm bowing out of the conversation and this is what I'm going
to do instead". Yes, they're orthogonal.

frank
Post by Eliot Miranda
Post by Frank Shearar
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
--
best,
Eliot
J. Vuletich (mail lists)
2013-11-21 07:14:34 UTC
Permalink
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.
Post by Frank Shearar
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
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..
Post by Frank Shearar
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_.
Post by Chris Muller
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
Igor Stasenko
2013-11-22 06:52:03 UTC
Permalink
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).
Post by Frank Shearar
Post by Eliot Miranda
No it doesn't. And the fact that all the ones you mention do isn't a
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
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
Post by Eliot Miranda
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131122/3571b1e4/attachment.htm
Eliot Miranda
2013-11-22 07:04:47 UTC
Permalink
On 21 November 2013 02:14, J. Vuletich (mail lists) <
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 :-).
Post by Frank Shearar
Post by Eliot Miranda
No it doesn't. And the fact that all the ones you mention do isn't a
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
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
Post by Eliot Miranda
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131121/1c029d8f/attachment.htm
Igor Stasenko
2013-11-22 07:22:34 UTC
Permalink
Post by Eliot Miranda
On 21 November 2013 02:14, J. Vuletich (mail lists) <
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 :-).
In fact, git under the hood operates with things which completely
orthogonal to files,
the entities it uses is just a tree of binary blobs (objects), and there's
even API for operating with them, but need additional work.
It is completely unnecessary to map methods to files and then inventing the
way how to deal with metadata (FileTree uses JSON for that), Camillo can
give more details
on that, because he was working on more advanced git integration,
which directly operates with repository bypassing need of using files
or need to go to command line and manually do git commit etc.
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
No it doesn't. And the fact that all the ones you mention do isn't a
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
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
Post by Eliot Miranda
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
--
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131122/f7bcfcfa/attachment-0001.htm
J. Vuletich (mail lists)
2013-11-22 07:26:13 UTC
Permalink
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.
But that's not true, as I just answered Igor. All that is needed is to save stuff in package files in a well defined order, as Cuis does.
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 :-).
--
best,
Eliot
Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131121/fa625933/attachment.htm
Frank Shearar
2013-11-22 16:03:06 UTC
Permalink
Post by Eliot Miranda
On 21 November 2013 02:14, J. Vuletich (mail lists)
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
Post by Eliot Miranda
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 :-).
Post by Frank Shearar
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
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..
Post by Frank Shearar
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_.
Post by Chris Muller
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
Igor Stasenko
2013-11-22 21:01:26 UTC
Permalink
Post by J. Vuletich (mail lists)
Post by Eliot Miranda
On 21 November 2013 02:14, J. Vuletich (mail lists)
Post by J. Vuletich (mail lists)
There is a simpler way, using Git as it is meant to be used. Take a
look
Post by Eliot Miranda
Post by J. Vuletich (mail lists)
at
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/3deff0d7b9707258766d6f003b783077664a4023#diff-5fe4c9854ae64b52029283e0648affd4
Post by Eliot Miranda
Post by J. Vuletich (mail lists)
. 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
Post by Eliot Miranda
on a per-method basis, while if you just store fileouts, git can often
give
Post by Eliot Miranda
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
Post by Eliot Miranda
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.
Absolutely..
For curious, you can download an image here:
https://ci.inria.fr/pharo-contribution/job/FileSystem-Git/PHARO=30,VERSION=development,VM=vm/lastSuccessfulBuild/artifact/FileSystem-Git.zip

And here is piece of code (from test suite) which demonstrates, that you
don't have to work with files to work with git :)
(it actually uses #fileNamed: (imo should be #named: instead), because if
you look how it is handled internally in GitTreeEntry, it has no any
special handling and can be arbitrary string):

setUp
| commit1 commit2 blob1 blob2 tree1 tree2 stamp |
super setUp.
stamp := GitStamp new
name: 'Homer Simpson';
email: '***@nuke.com';
yourself.
reference := (FileSystem memory / 'test.git').
basicRepository := GitRepository on: reference.

blob1 := (GitBlob bytes: 'testBlob' in: basicRepository) store;
yourself.
blob2 := (GitBlob bytes: 'second test Blob' in: basicRepository) store;
yourself.
tree1 := GitTree
entries: {
GitTreeEntry
fileNamed: 'blob1'
hash: blob1 hash
in: basicRepository}
in: basicRepository.
tree1 store.

tree2 := GitTree
entries: {
GitTreeEntry
fileNamed: 'blob2'
hash: blob2 hash
in: basicRepository}
in: basicRepository.
tree2 store.

commit1 := (GitCommit in: basicRepository)
tree: tree1;
message: 'message1';
author: stamp;
committer: stamp;
store;
yourself.

commit2 := (GitCommit in: basicRepository)
tree: tree2;
message: 'message2';
author: stamp;
committer: stamp;
parents: { commit1 hexHash };
store;
yourself.

basicRepository
updateRef: basicRepository headsDir / 'branch1' to: commit1 hexHash;
updateRef: basicRepository headsDir / 'master' to: commit2
hexHash.
GitFSCK validate: basicRepository.

repository := FileSystemGitRepository on: reference.
Post by J. Vuletich (mail lists)
frank
Post by Eliot Miranda
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
Post by Eliot Miranda
in C and C++ makes it impossible in general to derive the structure of C
and
Post by Eliot Miranda
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
Post by Eliot Miranda
the C.C++ macro system is (and it is). hat a mad world we live in :-).
Post by J. Vuletich (mail lists)
Post by Frank Shearar
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
No it doesn't. And the fact that all the ones you mention do
isn't a
Post by Eliot Miranda
Post by J. Vuletich (mail lists)
Post by Frank Shearar
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by J. Vuletich (mail lists)
Post by Frank Shearar
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by J. Vuletich (mail lists)
Post by Frank Shearar
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by J. Vuletich (mail lists)
Post by Frank Shearar
Post by Chris Muller
Post by Frank Shearar
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
Post by Eliot Miranda
Post by J. Vuletich (mail lists)
Post by Frank Shearar
Post by Chris Muller
Post by Frank Shearar
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
Post by Eliot Miranda
Post by J. Vuletich (mail lists)
Post by Frank Shearar
Post by Chris Muller
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..
Post by Frank Shearar
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_.
Post by Chris Muller
Something that would be much more convincing, to me at least, would
be
Post by Eliot Miranda
Post by J. Vuletich (mail lists)
Post by Frank Shearar
Post by Chris Muller
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
Post by Eliot Miranda
Post by J. Vuletich (mail lists)
Post by Frank Shearar
Post by Chris Muller
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
--
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131122/91d38478/attachment.htm
J. Vuletich (mail lists)
2013-11-22 07:22:28 UTC
Permalink
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.
Yes. That's what I mean by using Git as it is meant to be used. Git versions the file system. It is meant to be transparent to dev tools, that are completely unaware of it. True, another way to say this is "less integrated".
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).
I consider the link I sent as a "proper diff". I really can't see how it is not obvious that the proper way to version packages is simply using a file per package!

BTW, in Cuis, the sorting order of the stuff in .pck.st files is well defined, so the problem you say can not happen.

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131121/82ab85e7/attachment.htm
Tobias Pape
2013-11-21 19:15:31 UTC
Permalink
Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1665 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131121/4a25e9fc/signature.pgp
H. Hirzel
2013-11-22 02:21:36 UTC
Permalink
Very informative, Tobias. Thank you!

Would it be possible to have versions without 'Test' packages to more
clearly see where the remaining problems are?

--Hannes

P.S. I wonder why 'Network' depends on 'Morphic' and why 'Compression'
depends on 'Multilingual'....
Hi,
Post by Frank Shearar
(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)).
While we are at it, I just updated my irregular Squeak-Trunk-Dependency
graph
(see at https://github.com/krono/Squeak-Trunk-Deps)
And lo and behold, we are improving. See the attached PDFs for an
impression.
Still, one of the major problems is the circular dependencies, but
we already talked about that :)
Best
-Tobias
PS: attached the 2 pdfs generated with the script you find on the github
page
with the trunk image from this morning (12983)
Frank Shearar
2013-11-22 03:13:30 UTC
Permalink
Post by H. Hirzel
Very informative, Tobias. Thank you!
Would it be possible to have versions without 'Test' packages to more
clearly see where the remaining problems are?
I've adjusted my dotfile maker to grey out the Test packages and
dependencies on these packages. Here's what it looks like:
Loading Image... (size
6.4MB)

I've noticed that the cycles tend to get pulled into the middle of the nest.
Post by H. Hirzel
--Hannes
P.S. I wonder why 'Network' depends on 'Morphic'
SuperSwikiServer, PRServerDirectory and ServerDirectory use
AlignmentMorph, FileDirectoryWrapper, ProjectViewMorph, and so on.
Post by H. Hirzel
and why 'Compression'
depends on 'Multilingual'....
GZipReadStream, ReadWriteStream, ZipArchiveMember use
MultiByteBinaryOrTextStream and TextConverter.

(I get these from Dependency Browser, off the Apps menu. It's a
marvellous tool!)

frank
Post by H. Hirzel
Hi,
Post by Frank Shearar
(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)).
While we are at it, I just updated my irregular Squeak-Trunk-Dependency
graph
(see at https://github.com/krono/Squeak-Trunk-Deps)
And lo and behold, we are improving. See the attached PDFs for an
impression.
Still, one of the major problems is the circular dependencies, but
we already talked about that :)
Best
-Tobias
PS: attached the 2 pdfs generated with the script you find on the github
page
with the trunk image from this morning (12983)
Casey Ransberger
2013-11-22 08:30:48 UTC
Permalink
Gotta say I love the geographic metaphor! Wow! That's planet Squeak right there.
Hi,
Post by Frank Shearar
(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)).
While we are at it, I just updated my irregular Squeak-Trunk-Dependency graph
(see at https://github.com/krono/Squeak-Trunk-Deps)
And lo and behold, we are improving. See the attached PDFs for an impression.
Still, one of the major problems is the circular dependencies, but
we already talked about that :)
Best
-Tobias
PS: attached the 2 pdfs generated with the script you find on the github page
with the trunk image from this morning (12983)
<trunkimage-deps-map.pdf>
<trunkimage-deps.pdf>
Eliot Miranda
2013-11-20 23:46:59 UTC
Permalink
Hi Frank,
Post by Eliot Miranda
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
Hi Frank,
On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
now, as does Pharo and GemStone. So, to me, it feels fine to make
it
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
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
Post by Eliot Miranda
something else, a file system, a database, a remote directory. But lots
of
Post by Eliot Miranda
Smalltalk environments keep firm control of their own source code
control,
Post by Eliot Miranda
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
Post by Eliot Miranda
the ease of investigating history, undoing changes, etc. This is vital
to
Post by Eliot Miranda
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
Post by Eliot Miranda
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.
Post by Eliot Miranda
One of the things we're not doing is trying to solve looking at long-term
Post by Eliot Miranda
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.
Post by Frank Shearar
(*) 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 :)
Post by Eliot Miranda
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.
Post by Eliot Miranda
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.
Post by Eliot Miranda
Post by Eliot Miranda
Post by Frank Shearar
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
Post by Eliot Miranda
broke. And it's not easy for the Pharo community to get it fixed.
They'll
Post by Eliot Miranda
have to wrk-around the problem, and compromise something they want in
their
Post by Eliot Miranda
name mangling. I live with crap like this all the time in building the
VM
Post by Eliot Miranda
(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.
Post by Eliot Miranda
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.
Post by Eliot Miranda
frank
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
$ 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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Having said that, I must admit this really does make it
Squeak-specific, no longer generic. So, maybe an alternative
should
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
I have same feeling as Frank,
a specific address of a specific repository for a specific usage
has
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
not
much thing to do in MC.
MC package should not integrate each and every possible usage of
MC.
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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?
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
MonticelloConfigurations has no dependency on ReleaseBuilder and
I
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
it
needs to. Let's not let maybe-future-pie-in-the-sky-perfect be
the
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
enemy of pragmatic progress in the present.
On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar
Chris Muller uploaded a new version of Monticello to project
The
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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".
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
- 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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
any
particular repository implementation. For instance, it might
make
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
the
place that should know about the trunk URL, because
ReleaseBuilder's
the class responsible for this kind of thing. One kind of
release
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
we
build is a release candidate, for instance.
frank
--
best,
Eliot
--
best,
Eliot
--
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131120/d0ef39bb/attachment-0001.htm
Igor Stasenko
2013-11-22 06:40:48 UTC
Permalink
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 :)
Post by Eliot Miranda
Hi Frank,
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
Hi Frank,
On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
now, as does Pharo and GemStone. So, to me, it feels fine to
make it
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
on the bleeding edge there for a while, but git is now very, very
far
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
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
Post by Eliot Miranda
something else, a file system, a database, a remote directory. But
lots of
Post by Eliot Miranda
Smalltalk environments keep firm control of their own source code
control,
Post by Eliot Miranda
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
Post by Eliot Miranda
the ease of investigating history, undoing changes, etc. This is vital
to
Post by Eliot Miranda
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
Post by Eliot Miranda
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.
Post by Frank Shearar
(*) 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 :)
Post by Eliot Miranda
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
Post by Eliot Miranda
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.
Post by Eliot Miranda
Post by Frank Shearar
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
Post by Eliot Miranda
broke. And it's not easy for the Pharo community to get it fixed.
They'll
Post by Eliot Miranda
have to wrk-around the problem, and compromise something they want in
their
Post by Eliot Miranda
name mangling. I live with crap like this all the time in building the
VM
Post by Eliot Miranda
(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.
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
$ 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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too
long)
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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.
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Having said that, I must admit this really does make it
Squeak-specific, no longer generic. So, maybe an alternative
should
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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!
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier
I have same feeling as Frank,
a specific address of a specific repository for a specific usage
has
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
not
much thing to do in MC.
MC package should not integrate each and every possible usage of
MC.
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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?
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
MonticelloConfigurations has no dependency on ReleaseBuilder
and I
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
it
needs to. Let's not let maybe-future-pie-in-the-sky-perfect be
the
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
enemy of pragmatic progress in the present.
On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar
Chris Muller uploaded a new version of Monticello to project
The
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
for
the
new history and origin browsing functions to avoid ambiguity
with
other MC
domain elements. Went from "version" nomenclature to
"history".
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
- 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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
any
particular repository implementation. For instance, it might
make
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
a
whole lot of sense to build a repository backed by Cassandra.
I'm not convinced that ReleaseBuilder isn't the right place
for
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
this
info. Or, to avoid the double negative, I think
ReleaseBuilder is
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
the
place that should know about the trunk URL, because
ReleaseBuilder's
the class responsible for this kind of thing. One kind of
release
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
we
build is a release candidate, for instance.
frank
--
best,
Eliot
--
best,
Eliot
--
best,
Eliot
--
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131122/715b4fc8/attachment.htm
Eliot Miranda
2013-11-22 06:59:16 UTC
Permalink
Post by Igor Stasenko
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
Post by Igor Stasenko
parts ALREADY in
external repository is even worse, which was always causing problems of
desync
and messy and complicated update process.
Agreed.
Post by Igor Stasenko
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.
Post by Igor Stasenko
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 ;-).
Post by Igor Stasenko
Post by Eliot Miranda
Hi Frank,
On Tue, Nov 19, 2013 at 1:39 PM, Frank Shearar <
Post by Frank Shearar
Post by Eliot Miranda
Hi Frank,
On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <
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
Post by Frank Shearar
Post by Eliot Miranda
now, as does Pharo and GemStone. So, to me, it feels fine to
make it
Post by Frank Shearar
Post by Eliot Miranda
Monticello-For-Squeak, meaning to relax restrictions imposed by
multiplatform so it can go as far as we want toward supporting
the
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
on the bleeding edge there for a while, but git is now very, very
far
Post by Frank Shearar
Post by Eliot Miranda
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
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.
Post by Frank Shearar
(*) 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.
Post by Frank Shearar
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
Post by Frank Shearar
Post by Eliot Miranda
$ 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
Post by Frank Shearar
Post by Eliot Miranda
g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too
long)
Post by Frank Shearar
Post by Eliot Miranda
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.
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
Having said that, I must admit this really does make it
Squeak-specific, no longer generic. So, maybe an alternative
should
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
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!
Post by Frank Shearar
Post by Eliot Miranda
On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier
I have same feeling as Frank,
a specific address of a specific repository for a specific
usage has
Post by Frank Shearar
Post by Eliot Miranda
not
much thing to do in MC.
MC package should not integrate each and every possible usage
of MC.
Post by Frank Shearar
Post by Eliot Miranda
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?
Post by Frank Shearar
Post by Eliot Miranda
MonticelloConfigurations has no dependency on ReleaseBuilder
and I
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
it
needs to. Let's not let maybe-future-pie-in-the-sky-perfect
be the
Post by Frank Shearar
Post by Eliot Miranda
enemy of pragmatic progress in the present.
On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar
Chris Muller uploaded a new version of Monticello to
project The
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
for
the
new history and origin browsing functions to avoid ambiguity
with
other MC
domain elements. Went from "version" nomenclature to
"history".
Post by Frank Shearar
Post by Eliot Miranda
- 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
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
any
particular repository implementation. For instance, it might
make
Post by Frank Shearar
Post by Eliot Miranda
a
whole lot of sense to build a repository backed by Cassandra.
I'm not convinced that ReleaseBuilder isn't the right place
for
Post by Frank Shearar
Post by Eliot Miranda
this
info. Or, to avoid the double negative, I think
ReleaseBuilder is
Post by Frank Shearar
Post by Eliot Miranda
the
place that should know about the trunk URL, because
ReleaseBuilder's
the class responsible for this kind of thing. One kind of
release
Post by Frank Shearar
Post by Eliot Miranda
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
Igor Stasenko
2013-11-22 07:12:33 UTC
Permalink
Post by Eliot Miranda
Post by Igor Stasenko
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 :)
Post by Eliot Miranda
Because having parts of VM sources stored in MC package , while other
Post by Igor Stasenko
parts ALREADY in
external repository is even worse, which was always causing problems of
desync
and messy and complicated update process.
Agreed.
Post by Igor Stasenko
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.
Post by Eliot Miranda
Post by Igor Stasenko
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" :)
Post by Eliot Miranda
Post by Igor Stasenko
Post by Eliot Miranda
Hi Frank,
On Tue, Nov 19, 2013 at 1:39 PM, Frank Shearar <
Post by Frank Shearar
Post by Eliot Miranda
Hi Frank,
On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <
The trunk is a huge part of the Squeak development process and
ecosystem that deserves and needs representation somewhere in
the
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
now, as does Pharo and GemStone. So, to me, it feels fine to
make it
Post by Frank Shearar
Post by Eliot Miranda
Monticello-For-Squeak, meaning to relax restrictions imposed by
multiplatform so it can go as far as we want toward supporting
the
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
on the bleeding edge there for a while, but git is now very, very
far
Post by Frank Shearar
Post by Eliot Miranda
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
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.
Post by Frank Shearar
(*) 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.
Post by Frank Shearar
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
Post by Frank Shearar
Post by Eliot Miranda
$ git clone --depth=1
https://github.com/pharo-project/pharo-vm.git
Post by Frank Shearar
Post by Eliot Miranda
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.
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too
long)
Post by Frank Shearar
Post by Eliot Miranda
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,
Post by Frank Shearar
Post by Eliot Miranda
it's
effortful to maintain but I don't see why we can't summon that
effort.
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
for
this, something like "error 22", meaning depending on the success
of
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
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
Post by Eliot Miranda
Having said that, I must admit this really does make it
Squeak-specific, no longer generic. So, maybe an alternative
should
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
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.
Post by Frank Shearar
Post by Eliot Miranda
Continuing this discussion would necessitate a subject thread
change!
Post by Frank Shearar
Post by Eliot Miranda
On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier
I have same feeling as Frank,
a specific address of a specific repository for a specific
usage has
Post by Frank Shearar
Post by Eliot Miranda
not
much thing to do in MC.
MC package should not integrate each and every possible usage
of MC.
Post by Frank Shearar
Post by Eliot Miranda
If this does not belong to ReleaseBuilder, then we can make it
a
Post by Frank Shearar
Post by Eliot Miranda
System
thing...
If it's only for MCM, didn't we get a MCMcmUpdater
defaultUpdateURL?
Post by Frank Shearar
Post by Eliot Miranda
MonticelloConfigurations has no dependency on ReleaseBuilder
and I
Post by Frank Shearar
Post by Eliot Miranda
don't think we should introduce one.
If you at least acknowledge "trunk" is a real-thing in the
real
Post by Frank Shearar
Post by Eliot Miranda
world,
then note existence of MCRepository>>#trunk. Sure, we could
make a
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
it
needs to. Let's not let maybe-future-pie-in-the-sky-perfect
be the
Post by Frank Shearar
Post by Eliot Miranda
enemy of pragmatic progress in the present.
On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar
Chris Muller uploaded a new version of Monticello to
project The
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
for
the
new history and origin browsing functions to avoid
ambiguity
Post by Frank Shearar
Post by Eliot Miranda
with
other MC
domain elements. Went from "version" nomenclature to
"history".
Post by Frank Shearar
Post by Eliot Miranda
- 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
Post by Frank Shearar
Post by Eliot Miranda
literal in
so many places.
I don't like this last item. MCHttpRepository has no
business
Post by Frank Shearar
Post by Eliot Miranda
knowing
about any particular location, nor should we commit
ourselves to
Post by Frank Shearar
Post by Eliot Miranda
any
particular repository implementation. For instance, it
might make
Post by Frank Shearar
Post by Eliot Miranda
a
whole lot of sense to build a repository backed by
Cassandra.
Post by Frank Shearar
Post by Eliot Miranda
I'm not convinced that ReleaseBuilder isn't the right place
for
Post by Frank Shearar
Post by Eliot Miranda
this
info. Or, to avoid the double negative, I think
ReleaseBuilder is
Post by Frank Shearar
Post by Eliot Miranda
the
place that should know about the trunk URL, because
ReleaseBuilder's
the class responsible for this kind of thing. One kind of
release
Post by Frank Shearar
Post by Eliot Miranda
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131122/561db51e/attachment.htm
Eliot Miranda
2013-11-22 07:30:31 UTC
Permalink
Post by Igor Stasenko
Post by Eliot Miranda
Post by Igor Stasenko
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
Post by Igor Stasenko
Post by Eliot Miranda
Post by Igor Stasenko
parts ALREADY in
external repository is even worse, which was always causing problems of
desync
and messy and complicated update process.
Agreed.
Post by Igor Stasenko
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.
Post by Eliot Miranda
Post by Igor Stasenko
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" :)
Post by Eliot Miranda
Post by Igor Stasenko
Post by Eliot Miranda
Hi Frank,
On Tue, Nov 19, 2013 at 1:39 PM, Frank Shearar <
Post by Frank Shearar
Post by Eliot Miranda
Hi Frank,
On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <
The trunk is a huge part of the Squeak development process and
ecosystem that deserves and needs representation somewhere in
the
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
now, as does Pharo and GemStone. So, to me, it feels fine to
make it
Post by Frank Shearar
Post by Eliot Miranda
Monticello-For-Squeak, meaning to relax restrictions imposed by
multiplatform so it can go as far as we want toward supporting
the
Post by Frank Shearar
Post by Eliot Miranda
Squeak process.
It's not really germane to this discussion, but if I could flick
a
Post by Frank Shearar
Post by Eliot Miranda
switch and have us updating from github, I would do so without
hesitation. Monticello predates git by about 3 years, so we were
right
Post by Frank Shearar
Post by Eliot Miranda
on the bleeding edge there for a while, but git is now very,
very far
Post by Frank Shearar
Post by Eliot Miranda
ahead. It just makes so much sense to me to just use a world
class
Post by Frank Shearar
Post by Eliot Miranda
tool that _we don't have to maintain_. (*)
Here's an example of why surrendering one's source code control to
something
An IDE _always_ (*) surrenders source code control to something
else!
Post by Frank Shearar
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.
Post by Frank Shearar
(*) 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.
Post by Frank Shearar
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
Post by Frank Shearar
Post by Eliot Miranda
$ git clone --depth=1
https://github.com/pharo-project/pharo-vm.git
Post by Frank Shearar
Post by Eliot Miranda
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.
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too
long)
Post by Frank Shearar
Post by Eliot Miranda
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,
Post by Frank Shearar
Post by Eliot Miranda
it's
effortful to maintain but I don't see why we can't summon that
effort.
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
for
this, something like "error 22", meaning depending on the success
of
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
ourselves with the effort of maintaining it ourselves? What else
might
Post by Frank Shearar
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
darcs,
Post by Frank Shearar
monotone, bazaar, ...
frank
Post by Eliot Miranda
Having said that, I must admit this really does make it
Squeak-specific, no longer generic. So, maybe an alternative
should
Post by Frank Shearar
Post by Eliot Miranda
be to model our development process elements in a new package,
SqueakDevelopmentProcess (?), which would depend on our
Squeak's
Post by Frank Shearar
Post by Eliot Miranda
generic Monticello to represent the elements of our development
process.
I'm not terribly concerned with Squeak-specific or otherwise.
It's
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
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.
Post by Frank Shearar
Post by Eliot Miranda
Continuing this discussion would necessitate a subject thread
change!
Post by Frank Shearar
Post by Eliot Miranda
On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier
I have same feeling as Frank,
a specific address of a specific repository for a specific
usage has
Post by Frank Shearar
Post by Eliot Miranda
not
much thing to do in MC.
MC package should not integrate each and every possible usage
of MC.
Post by Frank Shearar
Post by Eliot Miranda
If this does not belong to ReleaseBuilder, then we can make
it a
Post by Frank Shearar
Post by Eliot Miranda
System
thing...
If it's only for MCM, didn't we get a MCMcmUpdater
defaultUpdateURL?
Post by Frank Shearar
Post by Eliot Miranda
MonticelloConfigurations has no dependency on ReleaseBuilder
and I
Post by Frank Shearar
Post by Eliot Miranda
don't think we should introduce one.
If you at least acknowledge "trunk" is a real-thing in the
real
Post by Frank Shearar
Post by Eliot Miranda
world,
then note existence of MCRepository>>#trunk. Sure, we could
make a
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
it
needs to. Let's not let maybe-future-pie-in-the-sky-perfect
be the
Post by Frank Shearar
Post by Eliot Miranda
enemy of pragmatic progress in the present.
On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar
Chris Muller uploaded a new version of Monticello to
project The
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
for
the
new history and origin browsing functions to avoid
ambiguity
Post by Frank Shearar
Post by Eliot Miranda
with
other MC
domain elements. Went from "version" nomenclature to
"history".
Post by Frank Shearar
Post by Eliot Miranda
- 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
Post by Frank Shearar
Post by Eliot Miranda
literal in
so many places.
I don't like this last item. MCHttpRepository has no
business
Post by Frank Shearar
Post by Eliot Miranda
knowing
about any particular location, nor should we commit
ourselves to
Post by Frank Shearar
Post by Eliot Miranda
any
particular repository implementation. For instance, it
might make
Post by Frank Shearar
Post by Eliot Miranda
a
whole lot of sense to build a repository backed by
Cassandra.
Post by Frank Shearar
Post by Eliot Miranda
I'm not convinced that ReleaseBuilder isn't the right
place for
Post by Frank Shearar
Post by Eliot Miranda
this
info. Or, to avoid the double negative, I think
ReleaseBuilder is
Post by Frank Shearar
Post by Eliot Miranda
the
place that should know about the trunk URL, because
ReleaseBuilder's
the class responsible for this kind of thing. One kind of
release
Post by Frank Shearar
Post by Eliot Miranda
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131121/69f6b533/attachment.htm
Igor Stasenko
2013-11-22 07:43:37 UTC
Permalink
Post by Eliot Miranda
Post by Igor Stasenko
Post by Eliot Miranda
Post by Igor Stasenko
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.
.. and not to mention , that depending on build target we may want to
generate different sources (instead of putting numerous ifdefs here and
there), which then will make storing generated sources under SCM completely
meaningless.
Post by Eliot Miranda
Because having parts of VM sources stored in MC package , while other
Post by Igor Stasenko
Post by Eliot Miranda
Post by Igor Stasenko
parts ALREADY in
external repository is even worse, which was always causing problems of
desync
and messy and complicated update process.
Agreed.
Post by Igor Stasenko
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.
Post by Eliot Miranda
Post by Igor Stasenko
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" :)
Post by Eliot Miranda
Post by Igor Stasenko
Post by Eliot Miranda
Hi Frank,
On Wed, Nov 20, 2013 at 2:10 AM, Frank Shearar <
On Tue, Nov 19, 2013 at 1:39 PM, Frank Shearar <
Post by Frank Shearar
Post by Eliot Miranda
Hi Frank,
On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <
The trunk is a huge part of the Squeak development process and
ecosystem that deserves and needs representation somewhere in
the
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
libraries are all very, very small.
Squeak has been using its own flavor of Monticello for
several years
Post by Frank Shearar
Post by Eliot Miranda
now, as does Pharo and GemStone. So, to me, it feels fine to
make it
Post by Frank Shearar
Post by Eliot Miranda
Monticello-For-Squeak, meaning to relax restrictions imposed
by
Post by Frank Shearar
Post by Eliot Miranda
multiplatform so it can go as far as we want toward
supporting the
Post by Frank Shearar
Post by Eliot Miranda
Squeak process.
It's not really germane to this discussion, but if I could
flick a
Post by Frank Shearar
Post by Eliot Miranda
switch and have us updating from github, I would do so without
hesitation. Monticello predates git by about 3 years, so we
were right
Post by Frank Shearar
Post by Eliot Miranda
on the bleeding edge there for a while, but git is now very,
very far
Post by Frank Shearar
Post by Eliot Miranda
ahead. It just makes so much sense to me to just use a world
class
Post by Frank Shearar
Post by Eliot Miranda
tool that _we don't have to maintain_. (*)
Here's an example of why surrendering one's source code control
to
Post by Frank Shearar
Post by Eliot Miranda
something
An IDE _always_ (*) surrenders source code control to something
else!
Post by Frank Shearar
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.
Post by Frank Shearar
(*) 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.
Post by Frank Shearar
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
Post by Frank Shearar
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
Post by Frank Shearar
Post by Eliot Miranda
$ git clone --depth=1
https://github.com/pharo-project/pharo-vm.git
Post by Frank Shearar
Post by Eliot Miranda
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.
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too
long)
Post by Frank Shearar
Post by Eliot Miranda
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,
Post by Frank Shearar
Post by Eliot Miranda
it's
effortful to maintain but I don't see why we can't summon that
effort.
Post by Frank Shearar
Post by Eliot Miranda
I do
fear that if we don't we just become like everything else and
soon
Post by Frank Shearar
Post by Eliot Miranda
enough
we're just another scripting language. The Smalltalk team had a
name
Post by Frank Shearar
Post by Eliot Miranda
for
this, something like "error 22", meaning depending on the
success of
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
ourselves with the effort of maintaining it ourselves? What else
might
Post by Frank Shearar
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
darcs,
Post by Frank Shearar
monotone, bazaar, ...
frank
Post by Eliot Miranda
Having said that, I must admit this really does make it
Squeak-specific, no longer generic. So, maybe an alternative
should
Post by Frank Shearar
Post by Eliot Miranda
be to model our development process elements in a new package,
SqueakDevelopmentProcess (?), which would depend on our
Squeak's
Post by Frank Shearar
Post by Eliot Miranda
generic Monticello to represent the elements of our
development
Post by Frank Shearar
Post by Eliot Miranda
process.
I'm not terribly concerned with Squeak-specific or otherwise.
It's
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
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.
Post by Frank Shearar
Post by Eliot Miranda
Continuing this discussion would necessitate a subject thread
change!
Post by Frank Shearar
Post by Eliot Miranda
On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier
I have same feeling as Frank,
a specific address of a specific repository for a specific
usage has
Post by Frank Shearar
Post by Eliot Miranda
not
much thing to do in MC.
MC package should not integrate each and every possible
usage of MC.
Post by Frank Shearar
Post by Eliot Miranda
If this does not belong to ReleaseBuilder, then we can make
it a
Post by Frank Shearar
Post by Eliot Miranda
System
thing...
If it's only for MCM, didn't we get a MCMcmUpdater
defaultUpdateURL?
Post by Frank Shearar
Post by Eliot Miranda
MonticelloConfigurations has no dependency on
ReleaseBuilder and I
Post by Frank Shearar
Post by Eliot Miranda
don't think we should introduce one.
If you at least acknowledge "trunk" is a real-thing in the
real
Post by Frank Shearar
Post by Eliot Miranda
world,
then note existence of MCRepository>>#trunk. Sure, we
could make a
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
it
needs to. Let's not let
maybe-future-pie-in-the-sky-perfect be the
Post by Frank Shearar
Post by Eliot Miranda
enemy of pragmatic progress in the present.
On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar
Chris Muller uploaded a new version of Monticello to
project The
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
for
the
new history and origin browsing functions to avoid
ambiguity
Post by Frank Shearar
Post by Eliot Miranda
with
other MC
domain elements. Went from "version" nomenclature to
"history".
Post by Frank Shearar
Post by Eliot Miranda
- 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
Post by Frank Shearar
Post by Eliot Miranda
literal in
so many places.
I don't like this last item. MCHttpRepository has no
business
Post by Frank Shearar
Post by Eliot Miranda
knowing
about any particular location, nor should we commit
ourselves to
Post by Frank Shearar
Post by Eliot Miranda
any
particular repository implementation. For instance, it
might make
Post by Frank Shearar
Post by Eliot Miranda
a
whole lot of sense to build a repository backed by
Cassandra.
Post by Frank Shearar
Post by Eliot Miranda
I'm not convinced that ReleaseBuilder isn't the right
place for
Post by Frank Shearar
Post by Eliot Miranda
this
info. Or, to avoid the double negative, I think
ReleaseBuilder is
Post by Frank Shearar
Post by Eliot Miranda
the
place that should know about the trunk URL, because
ReleaseBuilder's
the class responsible for this kind of thing. One kind of
release
Post by Frank Shearar
Post by Eliot Miranda
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
--
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131122/9168efe6/attachment-0001.htm
tim Rowledge
2013-11-22 07:52:06 UTC
Permalink
Post by Igor Stasenko
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.
.. and not to mention , that depending on build target we may want to generate different sources (instead of putting numerous ifdefs here and there), which then will make storing generated sources under SCM completely meaningless.
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" :)
Hi Frank,
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
Hi Frank,
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
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.
Post by Eliot Miranda
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.
Post by Frank Shearar
(*) 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 :)
Post by Eliot Miranda
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.
Post by Eliot Miranda
Post by Frank Shearar
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
Post by Eliot Miranda
Post by Frank Shearar
Post by Eliot Miranda
$ 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
Post by Eliot Miranda
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
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?
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
Chris Muller uploaded a new version of Monticello to project The
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
--
Best regards,
Igor Stasenko.
Hey guys, how about trimming your posts, eh?

tim
--
tim Rowledge; ***@rowledge.org; http://www.rowledge.org/tim
Useful Latin Phrases:- Totum dependeat. = Let it all hang out.
Igor Stasenko
2013-11-22 08:18:51 UTC
Permalink
Post by tim Rowledge
Hey guys, how about trimming your posts, eh?
yep, sorry.
Loading Image...

:)
Post by tim Rowledge
tim
--
Useful Latin Phrases:- Totum dependeat. = Let it all hang out.
--
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131122/72d6c84c/attachment.htm
David T. Lewis
2013-11-22 07:19:29 UTC
Permalink
Post by Eliot Miranda
Post by Igor Stasenko
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.
Yes, that's right. And more recently, Ian has updated this so that generated
sources are in ./src next to ./platforms, exactly as you have done for Cog.

Dave
Chris Muller
2013-11-20 06:08:51 UTC
Permalink
Post by Frank Shearar
Post by Eliot Miranda
hesitation. Monticello predates git by about 3 years, so we were right...
Monticello was great, back in the day.
And now, 7 years of git later, I'd...
One thing that's usually not a big factor with a lot of Smalltalkers
-- the "age" of the software. In fact that seems a strange thing to
focus on given you're using a 30-year old language in the first
place..
Post by Frank Shearar
Post by Eliot Miranda
ahead. It just makes so much sense to me to just use a world class
tool that _we don't have to maintain_. (*)
It's fine to be impressed with "successful" (translation: used by lots
of developers) bedrock software but we should not trick ourselves into
thinking there's "nothing to do" to use it. The _interface_ to the
SCM...
Post by Frank Shearar
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.
... is not necessarily easier to "maintain" than SCM integrated
directly into the Smalltalk environment. In fact, the domain model is
probably the simplest part of Monticello.

I think other IDE's use external SCM because they're not an integrated
development "environment" at all. They're a cluster of tools.
Smalltalk is a true integrated environment which I believe ironically
makes using integrated SCM not only possible but just as easy as
interfacing to external.

- Chris
Post by Frank Shearar
Post by Eliot Miranda
Hi Frank,
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
An IDE _always_ (*) surrenders source code control to something else!
And it works just fine for emacs, Eclipse, Netbeans, Visual Studio,
IntelliJ, ...
(*) Squeak being the exception
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.
Post by Eliot Miranda
$ 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
Post by Eliot Miranda
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
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?
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
Chris Muller uploaded a new version of Monticello to project The
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
Eliot Miranda
2013-11-20 06:13:48 UTC
Permalink
Post by Frank Shearar
Post by Eliot Miranda
hesitation. Monticello predates git by about 3 years, so we were
right...
Post by Frank Shearar
Monticello was great, back in the day.
And now, 7 years of git later, I'd...
One thing that's usually not a big factor with a lot of Smalltalkers
-- the "age" of the software. In fact that seems a strange thing to
focus on given you're using a 30-year old language in the first
place..
Post by Frank Shearar
Post by Eliot Miranda
ahead. It just makes so much sense to me to just use a world class
tool that _we don't have to maintain_. (*)
It's fine to be impressed with "successful" (translation: used by lots
of developers) bedrock software but we should not trick ourselves into
thinking there's "nothing to do" to use it. The _interface_ to the
SCM...
Post by Frank Shearar
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.
... is not necessarily easier to "maintain" than SCM integrated
directly into the Smalltalk environment. In fact, the domain model is
probably the simplest part of Monticello.
I think other IDE's use external SCM because they're not an integrated
development "environment" at all. They're a cluster of tools.
Smalltalk is a true integrated environment which I believe ironically
makes using integrated SCM not only possible but just as easy as
interfacing to external.
+1. well said.
- Chris
Post by Frank Shearar
Post by Eliot Miranda
Hi Frank,
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
Post by Frank Shearar
An IDE _always_ (*) surrenders source code control to something else!
And it works just fine for emacs, Eclipse, Netbeans, Visual Studio,
IntelliJ, ...
(*) Squeak being the exception
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.
Post by Eliot Miranda
$ 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
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
effortful to maintain but I don't see why we can't summon that effort.
I do
Post by Frank Shearar
Post by Eliot Miranda
fear that if we don't we just become like everything else and soon
enough
Post by Frank Shearar
Post by Eliot Miranda
we're just another scripting language. The Smalltalk team had a name
for
Post by Frank Shearar
Post by Eliot Miranda
this, something like "error 22", meaning depending on the success of
other
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Eliot Miranda
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
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
Post by Frank Shearar
Post by Eliot Miranda
thing...
If it's only for MCM, didn't we get a MCMcmUpdater defaultUpdateURL?
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,
Post by Frank Shearar
Post by Eliot Miranda
then note existence of MCRepository>>#trunk. Sure, we could make a
class-var or something if that helps you feel better, but my
opinion
Post by Frank Shearar
Post by Eliot Miranda
right now is that is not necessary because code can change if/when
it
Post by Frank Shearar
Post by Eliot Miranda
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
Chris Muller uploaded a new version of Monticello to project The
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
Post by Frank Shearar
Post by Eliot Miranda
the
new history and origin browsing functions to avoid ambiguity
with
Post by Frank Shearar
Post by Eliot Miranda
other MC
domain elements. Went from "version" nomenclature to "history".
- Related to those functions, browsing a list of patch
operations
Post by Frank Shearar
Post by Eliot Miranda
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
Post by Frank Shearar
Post by Eliot Miranda
particular repository implementation. For instance, it might
make a
Post by Frank Shearar
Post by Eliot Miranda
whole lot of sense to build a repository backed by Cassandra.
I'm not convinced that ReleaseBuilder isn't the right place for
this
Post by Frank Shearar
Post by Eliot Miranda
info. Or, to avoid the double negative, I think ReleaseBuilder is the
place that should know about the trunk URL, because
ReleaseBuilder's
Post by Frank Shearar
Post by Eliot Miranda
the class responsible for this kind of thing. One kind of
release we
Post by Frank Shearar
Post by Eliot Miranda
build is a release candidate, for instance.
frank
--
best,
Eliot
--
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131119/27a87bd0/attachment.htm
Frank Shearar
2013-11-20 16:21:29 UTC
Permalink
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
hesitation. Monticello predates git by about 3 years, so we were right...
Monticello was great, back in the day.
And now, 7 years of git later, I'd...
One thing that's usually not a big factor with a lot of Smalltalkers
-- the "age" of the software. In fact that seems a strange thing to
focus on given you're using a 30-year old language in the first
place..
It's obviously a much more complicated equation than just age. Had I
suggested using git in 2007 you'd have said "what is this unproven new
fangled nonsense?" My point is that in the distributed version control
world there are exactly two players, and not a lot to choose between
them: git and mercurial. Almost noone uses anything else. Why is that?
Post by Chris Muller
Post by Frank Shearar
Post by Eliot Miranda
ahead. It just makes so much sense to me to just use a world class
tool that _we don't have to maintain_. (*)
It's fine to be impressed with "successful" (translation: used by lots
of developers) bedrock software but we should not trick ourselves into
thinking there's "nothing to do" to use it. The _interface_ to the
SCM...
I don't believe I ever suggested that it would be a trivial change.
Post by Chris Muller
Post by Frank Shearar
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.
... is not necessarily easier to "maintain" than SCM integrated
directly into the Smalltalk environment. In fact, the domain model is
probably the simplest part of Monticello.
But your file system's not integrated directly into the Smalltalk environment.

Yes, the domain model in Monticello is very simple. The domain model
for git is, too. That's not an interesting part of the problem.
Consider: if you want any kind of tool to review changes, you have to
write it yourself. Because that really common task that everyone else
already has a tool for? You don't.
Post by Chris Muller
I think other IDE's use external SCM because they're not an integrated
development "environment" at all. They're a cluster of tools.
Smalltalk is a true integrated environment which I believe ironically
makes using integrated SCM not only possible but just as easy as
interfacing to external.
"There is only Smalltalk" is, in my opinion, the biggest reason why
we're now 10 years behind everyone else. Seriously.

frank
Post by Chris Muller
- Chris
Post by Frank Shearar
Post by Eliot Miranda
Hi Frank,
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
An IDE _always_ (*) surrenders source code control to something else!
And it works just fine for emacs, Eclipse, Netbeans, Visual Studio,
IntelliJ, ...
(*) Squeak being the exception
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.
Post by Eliot Miranda
$ 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
Post by Eliot Miranda
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
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?
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
Chris Muller uploaded a new version of Monticello to project The
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
Loading...