On 29 January 2012 18:48, Philippe Marschall wrote:
> On 29.01.2012 17:02, Sven Van Caekenberghe wrote:
>>
>>
>> On 29 Jan 2012, at 15:30, Philippe Marschall wrote:
>>
As for scale.. monticello scales well.
>>>
>>>
>>> No, it does not.
>>
>>
>> Please elaborate: I really can't see the differe
Wow guys, it is nice for me to see that this thread raised some fruits
already and it seems it will even more in the future :)
Best regards
Janko
S, Dale Henrichs piše:
> Otto,
>
> This looks very interesting! Since you are still using Monticello, I think it
> should be very straightforward to
On 01/29/2012 07:02 PM, Frank Shearar wrote:
- GSOC 2010 had a proposal
l(http://gsoc2010.esug.org/projects/git-mercurial) - Goran, did this
get off the ground?
AFAIK, not really.
regards, Göran
On 01/29/2012 05:02 PM, Sven Van Caekenberghe wrote:
PS: one of the things that we should take from git, as many others have said on
this list, is selective commits.
If I ever get around to picking up Deltas again it would make a really
good tool to enable this on top of current MC (or any ot
On 29.01.2012 21:12, Guido Stepken wrote:
I often discuss with Frank Lesser about Smalltalk compiler internals. He
has written a Smalltalk VM (GVM), that is written in Assembler and jits
Smalltalk directly dynamically into Intel machine code, that is *faster*
than C in normal cases, expecially wh
On 29.01.2012 22:31, Chris Muller wrote:
But the goal of making the image smaller is congruent with the goal of
making Morphic smaller, which would be congruent with the desire for
Monticello to be "scalable".
What are you talking about? I chose Morphic because it was the first
package I found
But the goal of making the image smaller is congruent with the goal of
making Morphic smaller, which would be congruent with the desire for
Monticello to be "scalable". So the solution should be smaller
packages, not more and bigger tools.
Besides, the measure of scale you've chosen is an build /
I often discuss with Frank Lesser about Smalltalk compiler internals. He
has written a Smalltalk VM (GVM), that is written in Assembler and jits
Smalltalk directly dynamically into Intel machine code, that is *faster*
than C in normal cases, expecially when fine tuned, able to run VS, VA,
Squeak, D
On 29.01.2012 19:39, Stéphane Ducasse wrote:
No, it does not.
Please elaborate: I really can't see the difference between doing a merge
(either an easy one or a more diffucult one over multiple files, spread over a
couple of days, with intervening changes by others) using either Monticello
On Sun, Jan 29, 2012 at 11:39 AM, Philippe Marschall wrote:
> On 29.01.2012 17:29, Steve Wart wrote:
>
>> Big legacy projects are still using Envy for VisualWorks less for the
>> reasons listed below, but mostly because it's extremely difficult to
>> migrate to Store without doing a "big bang" an
On 29.01.2012 19:39, Stéphane Ducasse wrote:
No, it does not.
Please elaborate: I really can't see the difference between doing a merge
(either an easy one or a more diffucult one over multiple files, spread over a
couple of days, with intervening changes by others) using either Monticello
-is-java-10x-more-verbose-than-python-loc-a-modest-empiric-approach/
>
> From: dimitris chloupis
> To: "Pharo-project@lists.gforge.inria.fr"
>
> Sent: Sunday, 29 January 2012, 18:58
> Subject: Re: [Pharo-project] Smalltalk for small projects only?
>
> sorry cou
On 29.01.2012 17:29, Steve Wart wrote:
Big legacy projects are still using Envy for VisualWorks less for the
reasons listed below, but mostly because it's extremely difficult to
migrate to Store without doing a "big bang" and most of these projects
don't have 200+ developers anymore anyhow (discl
Yes took me 10 hours to install GTK and it crashed on me…
So … I do not see this discussion going anywhere.
On Jan 29, 2012, at 7:16 PM, Sven Van Caekenberghe wrote:
>
> On 29 Jan 2012, at 18:48, Philippe Marschall wrote:
>
>> The scalability limits of Monticello are well understood. PackageIn
>>> No, it does not.
>>
>> Please elaborate: I really can't see the difference between doing a merge
>> (either an easy one or a more diffucult one over multiple files, spread over
>> a couple of days, with intervening changes by others) using either
>> Monticello or Git.
>
> The scalability
quite a momentum with
> huge projects and it is afterall a smalltalk child. Why not smalltalk ?
>
> --
> *From:* Janko Mivšek
> *To:* Pharo-project@lists.gforge.inria.fr; dimitris chloupis <
> theki...@yahoo.co.uk>
> *Sent:* Saturday, 28 January 2012, 22:08
> *Subject:* Re:
-project@lists.gforge.inria.fr
| Sent: Sunday, January 29, 2012 8:02:51 AM
| Subject: Re: [Pharo-project] Smalltalk for small projects only?
|
|
| On 29 Jan 2012, at 15:30, Philippe Marschall wrote:
|
| >> As for scale.. monticello scales well.
| >
| > No, it does not.
|
| Please el
On 29 Jan 2012, at 18:48, Philippe Marschall wrote:
> The scalability limits of Monticello are well understood. PackageInfo doesn't
> scale, at all. You put too many classes in a package, and snapshotting gets
> really slow. Don't believe me? Make a change in Morphic which has only 200
> class
On 29 January 2012 16:29, Steve Wart wrote:
> Big legacy projects are still using Envy for VisualWorks less for the
> reasons listed below, but mostly because it's extremely difficult to migrate
> to Store without doing a "big bang" and most of these projects don't have
> 200+ developers anymore a
On 29.01.2012 17:02, Sven Van Caekenberghe wrote:
On 29 Jan 2012, at 15:30, Philippe Marschall wrote:
As for scale.. monticello scales well.
No, it does not.
Please elaborate: I really can't see the difference between doing a merge
(either an easy one or a more diffucult one over multiple
Sunday, 29 January 2012, 18:58
Subject: Re: [Pharo-project] Smalltalk for small projects only?
sorry could not find it , nor I remember the name, I have seen one or two . But
in any case I think the comparison is obvious. If you visit the language game ,
the code required by python is usually 2x 3x
t@lists.gforge.inria.fr"
Sent: Sunday, 29 January 2012, 16:12
Subject: Re: [Pharo-project] Smalltalk for small projects only?
Reference, please :) I fully believe it.
Bill
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...
Big legacy projects are still using Envy for VisualWorks less for the
reasons listed below, but mostly because it's extremely difficult to
migrate to Store without doing a "big bang" and most of these projects
don't have 200+ developers anymore anyhow (disclaimer: I'm only familiar
with 2 or 3 of t
On 29 Jan 2012, at 15:30, Philippe Marschall wrote:
>> As for scale.. monticello scales well.
>
> No, it does not.
Please elaborate: I really can't see the difference between doing a merge
(either an easy one or a more diffucult one over multiple files, spread over a
couple of days, with inte
On 28.01.2012 21:16, Janko Mivšek wrote:
Dale,
I agree with you that source code management is where we are weak. A
process therefore, as James already said.
In SCM VisualWorks is ahead in my opinion, even that Store is also not
perfect yet. But it would be useful to reuse some of ideas in Mon
On 28.01.2012 22:27, Igor Stasenko wrote:
On 28 January 2012 22:06, Hilaire Fernandes wrote:
May be it is time to forget about the image, I mean the name of the
image and change for something else, more in the proximal learning zone
of programmer. It is not an image we have, it is a data base o
@lists.gforge.inria.fr; dimitris chloupis
Subject: Re: [Pharo-project] Smalltalk for small projects only?
Dimitris,
this is very interesting; I've always wanted to read that kind of study. Do you
have a pointer?
Thanks,
Michael
Am 29.01.2012 um 08:51 schrieb dimitris chloupis
mailto:theki...@yahoo.
Michael Haupt
> To: "Pharo-project@lists.gforge.inria.fr"
>
> Sent: Saturday, 28 January 2012, 23:29
> Subject: Re: [Pharo-project] Smalltalk for small projects only?
>
> Janko,
>
> Am 28.01.2012 um 21:08 schrieb Janko Mivšek :
> >> I think this is a post that clearly
200 developers on a project ? Scaring . They should use another
technology than Java to go under 50 developers. They will save a lot of
money :)
Laurent
2012/1/28 Janko Mivšek
> Hi guys,
>
> Ralph Johnson in his InfoQ interview made an interesting observation:
>
> 2:55 minute: "Smalltalk ma
think the numbers wont be
very dissimilar for smalltalk
From: Michael Haupt
To: "Pharo-project@lists.gforge.inria.fr"
Sent: Saturday, 28 January 2012, 23:29
Subject: Re: [Pharo-project] Smalltalk for small projects only?
Janko,
Am 28.01.2012 um
exactly what I meant, glad you see it that way too.
From: Hilaire Fernandes
To: pharo-project@lists.gforge.inria.fr
Sent: Saturday, 28 January 2012, 23:06
Subject: Re: [Pharo-project] Smalltalk for small projects only?
May be it is time to forget about the
:08
Subject: Re: [Pharo-project] Smalltalk for small projects only?
S, dimitris chloupis piše:
> I think this is a post that clearly illustrates the big problem with
> smalltalk. The very fact that is compared with Java and Java survives.
Yes, that 4-5 peole can do what 50 Java people are
Janko,
Am 28.01.2012 um 23:37 schrieb Janko Mivšek :
>> I'm not so sure the people at those Smalltalk firms building software for
>> banks et al. have no project management. Boasting? ;-)
>
> As I said in first post, there are few exceptions. But they all have
> their dev. process developed inte
ey can make real progress.
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] on behalf of Lawson English
[lengli...@cox.net]
Sent: Saturday, January 28, 2012 2:16 PM
To: pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-pro
Hi Michael,
S, Michael Haupt piše:
>>> I think this is a post that clearly illustrates the big problem with
>>> smalltalk. The very fact that is compared with Java and Java survives.
>> Yes, that 4-5 people can do what 50 Java people are needed is both a
>> blessing and a curse :)
>
> I wanted
Janko,
Metacello itself needs work to make it usable by groups of developers ... the
lack of merge capability is a real hindrance to being able to have multiple
folks work on the same project and use Metacello ...
I imagine that a Metacello configuration is the moral equivalent of a git
reposi
Janko,
Am 28.01.2012 um 21:08 schrieb Janko Mivšek :
>> I think this is a post that clearly illustrates the big problem with
>> smalltalk. The very fact that is compared with Java and Java survives.
>
> Yes, that 4-5 peole can do what 50 Java people are needed is both a
> blessing and a curse :)
On 28 January 2012 22:06, Hilaire Fernandes wrote:
> May be it is time to forget about the image, I mean the name of the
> image and change for something else, more in the proximal learning zone
> of programmer. It is not an image we have, it is a data base of object,
> and we are programming on t
May be it is time to forget about the image, I mean the name of the
image and change for something else, more in the proximal learning zone
of programmer. It is not an image we have, it is a data base of object,
and we are programming on this object data base.
Hilaire
Le 28/01/2012 17:50, dimitr
Dale,
I agree with you that source code management is where we are weak. A
process therefore, as James already said.
In SCM VisualWorks is ahead in my opinion, even that Store is also not
perfect yet. But it would be useful to reuse some of ideas in Monticello
based SCM tools too. With Metacello
an
> image that can brake any barrier, even do direct streaming from disk
> when the memory is not enough or when we dont want to occupy its entirety ?
>
> *From:* Janko Mivšek
> *To:* "Pharo-project@lists
On 1/28/12 10:12 AM, Schwab,Wilhelm K wrote:
You say "underhyped" as though this is bad - *hype* is BADD. Junk
needs hype to survive.
It took me a while to learn that "creating an application" in ST is
"hard" - it's because it's not well supported because the initiated
don't waste their
ry 28, 2012 11:50 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Smalltalk for small projects only?
I think this is a post that clearly illustrates the big problem with smalltalk.
The very fact that is compared with Java and Java survives.
You know I dont find it mysterious
January 2012, 17:46
Subject: [Pharo-project] Smalltalk for small projects only?
Hi guys,
Ralph Johnson in his InfoQ interview made an interesting observation:
2:55 minute: "Smalltalk made an fundamental error ... image ... you can
build something with 4-5 people what 50 people can build
Hi guys,
Ralph Johnson in his InfoQ interview made an interesting observation:
2:55 minute: "Smalltalk made an fundamental error ... image ... you can
build something with 4-5 people what 50 people can build in Java, but if
you take 200 people in Java ... it is really designed for small systems
.
45 matches
Mail list logo
