[Pharo-project] Why a package management system
So you are educating them.... Frankly I stopped trying long time ago.
No, I just tell them what I think is necessary to move forward. Other may be more educated here, it is just sharing MHO so others can to form an own opinion.
I think it would be much more ... "becoming" (and fruitful) if we all could stop "trash talking" each other - especially those of us who play a "larger role".
+1 Meanwhile the Pharo community has grown with new members and many people dont care about old discussions. Let's use our energy to move forward and (if possible) share as much knowledge and code as long as parts of our communities overlap. I therefore would really like to see a common exchange mechanism used on both sides. I'm sure I'm not able to convince one or the other to use package systems like Metacello but at least I hope to make them think about the need of a more modular system. Bye T. "I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel." -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser
2010/2/23 Torsten Bergmann <astares@gmx.de>
So you are educating them.... Frankly I stopped trying long time ago.
No, I just tell them what I think is necessary to move forward. Other may be more educated here, it is just sharing MHO so others can to form an own opinion.
Your mail is excellent and show very well the advantages of work with Metacello. When I read the first article about Metacello don't figured out is power until I invested some time to learn it and developed some "ConfigurationOf..." and currently I think is an invaluable tool that help to put Pharo/Squeak at the "next level" :)
Let's use our energy to move forward and (if possible) share as much knowledge and code as long as parts of our communities overlap.
I therefore would really like to see a common exchange mechanism used on both sides.
I'm sure I'm not able to convince one or the other to use package systems like Metacello but at least I hope to make them think about the need of a more modular system.
Package systems are needed to professional development and I think that Metacello is a very good tool. I'm happily using it. Germán.
When I read the first article about Metacello don't figured out is power until I invested some time to learn it and developed some "ConfigurationOf..." and currently I think is an invaluable tool that help to put Pharo/Squeak at the "next level" :)
Thanks. I'm really happy that dale started to push that (even if keith was doing the same with Sake) because since the first day we worked with MC and used MC to manage 3.9 we were aware that we need such mechanism. Expressing package dependency is key to system deployment scale.
Hi! Torsten Bergmann wrote:
So you are educating them.... Frankly I stopped trying long time ago.
No, I just tell them what I think is necessary to move forward. Other may be more educated here, it is just sharing MHO so others can to form an own opinion.
Right, discussion is good. And believe me - the squeak-dev community is NOT oblivious to the needs of a package system. I mean, come on, Monticello, SqueakMap, Universes etc etc - it all was around before Pharo was born. What I have seen so far in Metacello is indeed nothing new - the senarios and discussions about dependencies etc go loooong way back. BUT... that *doesn't* mean I am passing any judgment on Metacello - IMHO all efforts are good per definition! :) I haven't formed an opinion myself.
I think it would be much more ... "becoming" (and fruitful) if we all could stop "trash talking" each other - especially those of us who play a "larger role".
+1
Thank you.
Meanwhile the Pharo community has grown with new members and many people dont care about old discussions.
Let's use our energy to move forward and (if possible) share as much knowledge and code as long as parts of our communities overlap.
Yes, exactly.
I therefore would really like to see a common exchange mechanism used on both sides.
I'm sure I'm not able to convince one or the other to use package systems like Metacello but at least I hope to make them think about the need of a more modular system.
Ehm, "a more modular system" has been on the table since... hell, way back to Squeak 3.3! And yeah, even earlier of course - you can probably track it back to PARC if you try hard. :) :) Anyway, "common exchange mechanism" - I am working on Deltastreams which I even presented at Brest, though unfortunately colliding with the Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY this problem (fork interchange), and it was born in 2007: http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.ht... I and Igor are the ones working on it - and after Brest we have had very little time to move it forward. I still think it is a very important piece of the puzzle though. regards, Göran
Hi Göran: Sorry by my intromision here, but want to say somethings :) 2010/2/23 Göran Krampe <goran@krampe.se>
Hi!
Torsten Bergmann wrote:
So you are educating them.... Frankly I stopped trying long time ago.
No, I just tell them what I think is necessary to move forward. Other may be more educated here, it is just sharing MHO so others can to form an own opinion.
Right, discussion is good. And believe me - the squeak-dev community is NOT oblivious to the needs of a package system. I mean, come on, Monticello, SqueakMap, Universes etc etc - it all was around before Pharo was born.
What I have seen so far in Metacello is indeed nothing new - the senarios and discussions about dependencies etc go loooong way back.
I'm on Squeak from old 3.2 times. And yes, a lot of discussions about packages, etc, but only discussions on most of cases. I think Metacello solves the dependencies questions very well and the other tools not (with exception of Universes probably, but abandoned now). Also Metacello provides all the features explained on the excellent mail of Torsten, assuring that the configurations will work with the time not breaking stuffs. The solution of using Metacello+Monticello is, imho, very simple, easy and productive and is here, available to us. :)
I therefore would really like to see a common exchange mechanism used
on both sides.
I'm sure I'm not able to convince one or the other to use package systems like Metacello but at least I hope to make them think about the need of a more modular system.
Ehm, "a more modular system" has been on the table since... hell, way back to Squeak 3.3! And yeah, even earlier of course - you can probably track it back to PARC if you try hard. :) :)
hehe, I remember the 3.3 modules breaking almost all the things coming from 3.2.
Anyway, "common exchange mechanism" - I am working on Deltastreams which I even presented at Brest, though unfortunately colliding with the Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY this problem (fork interchange), and it was born in 2007:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.ht...
I and Igor are the ones working on it - and after Brest we have had very little time to move it forward. I still think it is a very important piece of the puzzle though.
But Deltastreams are ready to use on production systems? Cheers. Germán.
Hi! Germán Arduino wrote:
Hi Göran:
Sorry by my intromision here, but want to say somethings :)
2010/2/23 Göran Krampe <goran@krampe.se <mailto:goran@krampe.se>> [SNIP] What I have seen so far in Metacello is indeed nothing new - the senarios and discussions about dependencies etc go loooong way back.
I'm on Squeak from old 3.2 times. And yes, a lot of discussions about packages, etc, but only discussions on most of cases. I think Metacello solves the dependencies questions very well and the other tools not (with exception of Universes probably, but abandoned now). Also Metacello provides all the features explained on the excellent mail of Torsten, assuring that the configurations will work with the time not breaking stuffs.
The solution of using Metacello+Monticello is, imho, very simple, easy and productive and is here, available to us. :)
I never claimed otherwise! I am just saying that there is nothing new - and frankly, though I admit not having read carefully, I didn't find the example so... impressive. Perhaps I need to read it again. Again though - I am not saying anything negative about Metacello. [SNIP]
Anyway, "common exchange mechanism" - I am working on Deltastreams which I even presented at Brest, though unfortunately colliding with the Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY this problem (fork interchange), and it was born in 2007:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.ht...
I and Igor are the ones working on it - and after Brest we have had very little time to move it forward. I still think it is a very important piece of the puzzle though.
But Deltastreams are ready to use on production systems?
Nope, not yet, although very close. But since the topic came up I wanted to mention it. But AFAIK there is no other tool/project aimed at that use case. Again, I may be wrong :) regards, Göran
But Deltastreams are ready to use on production systems?
Nope, not yet, although very close. But since the topic came up I wanted to mention it. But AFAIK there is no other tool/project aimed at that use case. Again, I may be wrong :
BTW I like deltastream and your presentation at esug was convincing now this is important to try it for real before commiting. Stef
Den 23.02.2010 13:00, skrev Göran Krampe:
Hi!
Torsten Bergmann wrote:
So you are educating them.... Frankly I stopped trying long time ago.
No, I just tell them what I think is necessary to move forward. Other may be more educated here, it is just sharing MHO so others can to form an own opinion.
Right, discussion is good. And believe me - the squeak-dev community is NOT oblivious to the needs of a package system. I mean, come on, Monticello, SqueakMap, Universes etc etc - it all was around before Pharo was born.
What I have seen so far in Metacello is indeed nothing new - the senarios and discussions about dependencies etc go loooong way back.
BUT... that *doesn't* mean I am passing any judgment on Metacello - IMHO all efforts are good per definition! :) I haven't formed an opinion myself.
No system is going to perfectly fulfill everyones perception of what would be "The Best Way"(tm), but as long as the need for functionality provided by a system is real, actually deciding on one, IS important.
From what I've seen in archive discussion, that seems to have been the biggest showstopper for noticeable progress in the Squeak community. Paradoxically, existing systems which clearly contain lousy code, are left in (or replacements objected to) on the basis of backwards-compatability... IMHO, this is the biggest difference between Squeak and Pharo I've seen. Sure, you can now unload Etoys from Squeak, your image will still contain code like ImageSegment>>findRogueRootsAllMorphs: though. Sure, you can new add Preferences with pragmas now, you still have a class with a Dictionary accessed and stored into by the entire system, and 1223 accessors for things local to specific packages though.
Metacello is nothing new for sure, but contrary to other systems, it seems to have reached wide acceptance in Pharo. Understandably, many here feel it'd be nice if the "classic" Squeak-community decided to use it as well. Personally, I doubt it will happen (for any PMS really, as evidenced by Sake/Packages, as well as all the other previous attempts), yet I appreciate Torsten's and others effort to at least correct the plain-out misconceptions some people seem to have about deficiencies of Metacello. Pretty sure noone would argue Monticello is a perfect system either, achieving critical mass was though.
Meanwhile the Pharo community has grown with new members and many people dont care about old discussions.
Let's use our energy to move forward and (if possible) share as much knowledge and code as long as parts of our communities overlap.
Yes, exactly.
+1.
Anyway, "common exchange mechanism" - I am working on Deltastreams which I even presented at Brest, though unfortunately colliding with the Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY this problem (fork interchange), and it was born in 2007:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.ht...
I and Igor are the ones working on it - and after Brest we have had very little time to move it forward. I still think it is a very important piece of the puzzle though.
regards, Göran I've been meaning to make system-change notifications for Pharo so the recording-part could work there too, but I never seem to get around to it :( Part of the problem is of course my own personal "The Best Way"(tm), which f.ex. would include Announcements. Since I'd like the ability to have Weak subscriptions, I'd first have to deoptimize the Announcement-package Levente made a bit to make it "prettier", make it a strict superset of what if found in Core already, fix WeakRegistry so each resource registered for an object actually gets finalized, which again means... etc... Oh, and hope it'd end up good enough that it'd warrant inclusion:)
Cheers, Henry
Metacello is nothing new for sure, but contrary to other systems, it seems to have reached wide acceptance in Pharo.
IMHO that's a key point. We don't need to have the best package management system, we need to have only ONE. Major Linux distributions are great for that. Ruby too (though there has been a lot of problems when github came in, you had to choose which fork of the gem you wanted to use, everybody fork..... gemcutter has resolved this). When there will be needs to switch to another package management system, trash the old, only use the new one. So we can keep one way to load packages. Metacello is great :) Laurent Laffont.
+ 1 let us work on the infrastructure.
Metacello is nothing new for sure, but contrary to other systems, it seems to have reached wide acceptance in Pharo.
IMHO that's a key point. We don't need to have the best package management system, we need to have only ONE. Major Linux distributions are great for that. Ruby too (though there has been a lot of problems when github came in, you had to choose which fork of the gem you wanted to use, everybody fork..... gemcutter has resolved this).
When there will be needs to switch to another package management system, trash the old, only use the new one. So we can keep one way to load packages.
Metacello is great :)
Laurent Laffont. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I've been meaning to make system-change notifications for Pharo so the recording-part could work there too, but I never seem to get around to it :( Part of the problem is of course my own personal "The Best Way"(tm), which f.ex. would include Announcements. Since I'd like the ability to have Weak subscriptions, I'd first have to deoptimize the Announcement-package Levente made a bit to make it "prettier",
can you explain a bit more the technical aspect?
make it a strict superset of what if found in Core already, fix WeakRegistry so each resource registered for an object actually gets finalized, which again means... etc... Oh, and hope it'd end up good enough that it'd warrant inclusion:)
I would love to see a bit more enhancement on Announcement. Stef
On 23.02.2010 19:01, Stéphane Ducasse wrote:
I've been meaning to make system-change notifications for Pharo so the recording-part could work there too, but I never seem to get around to it :( Part of the problem is of course my own personal "The Best Way"(tm), which f.ex. would include Announcements. Since I'd like the ability to have Weak subscriptions, I'd first have to deoptimize the Announcement-package Levente made a bit to make it "prettier", can you explain a bit more the technical aspect? Well, Levente's implementation, each kind of arg has it's own Subscription class, for performance reasons. What I was hoping to do was consolidate these so there's only two classes, one for Strong, and one for weak subscriptions. Using cull: this is possible, with a small performance penalty at subscriber evaluation time (IIRC, 4 times less overhead compared to valueWithPossibleArgs:, but double the overhead of direct value: evaluation which you achieve with the one-class-per-arg-type approach ), but with faster subscription creation. Thus, you get a simpler implementation at the cost of some performance.
Lacking Weak subscriptions is, as Bill put it in an earlier mail: "a lot like the dependency days of MVC - remember #release? I'm trying to forget" - If you don't outlive your announcer, you have to unsubscribe manually to be GC'd.
make it a strict superset of what if found in Core already, fix WeakRegistry so each resource registered for an object actually gets finalized, which again means... etc... Oh, and hope it'd end up good enough that it'd warrant inclusion:) I would love to see a bit more enhancement on Announcement. I described the issue with WeakRegistry>>toFinalize:send:to:with: in a previous mail, it's only related in the term that Levente's implementation uses it. (I encountered it while writing some tests for weak subscriptions) Reading Squeak-Dev, it seems he's picked it up, and there's a version in the Inbox, I'll be reviewing that :D
As for the Announcement implementation, AXAnnouncements follow what was described in the post of Vassily more closely, which both make use of them more portable, as well as provide some other benefits, the ones which seems of most value to me is the simple implementation of weak subscriptions, plus support for registering actions taking more than the announcement itself as a parameter for handlers. http://n4.nabble.com/Notifications-of-windows-opening-closing-focus-td129655... (where the above quote is taken from) contains a relevant discussion as to why I find these features useful. Changing Lukas' implementation as provided in Core to do the same, (I think) you'd loose much of its simple elegance The one thing I'm ambivalent about regarding VW/AX implementation vs. Lukas', is whether when:do: should be setting the block as subscriber (VW) instead of the instance sending when:do: (Lukas). When using this method together with strong subscriptions in VW, I almost always ended up using when:do:for: so I could register the instance as subscriber instead. Cheers, Henry
----- "Torsten Bergmann" <astares@gmx.de> wrote: | I'm sure I'm not able to convince one or the other to use package | systems like Metacello but at least I hope to make them think about | the need of a more modular system. Torsten, Just for the record. I truly look forward to the day when a better package management system comes along. If Metacello spurs some folks with "obviously better ideas" to produce a Package Management system that we can all use, then it will have been worth the effort:) Until the better mousetrap appears, I will continue to slog along on Metacello. Dale
On 24. 02. 2010 02:55, Dale Henrichs wrote:
If Metacello spurs some folks with "obviously better ideas" to produce a Package Management system that we can all use, then it will have been worth the effort:) Until the better mousetrap appears, I will continue to slog along on Metacello.
That's a good plan, Dale. Metacello has a momentum right now and with continuing it has a chance to become a de-facto tool on top of Monticello for PMS. I just hope that the momentum will continue to some decent GUI tools as well :) Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
2010/2/24 Janko Mivšek <janko.mivsek@eranova.si>
On 24. 02. 2010 02:55, Dale Henrichs wrote:
If Metacello spurs some folks with "obviously better ideas" to produce a Package Management system that we can all use, then it will have been worth the effort:) Until the better mousetrap appears, I will continue to slog along on Metacello.
That's a good plan, Dale. Metacello has a momentum right now and with continuing it has a chance to become a de-facto tool on top of Monticello for PMS. I just hope that the momentum will continue to some decent GUI tools as well :)
Janko, I don't know what it "decent" for you, but did you try Metacello-OB and Metaceller ?
Best regards Janko
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Just for the record. I truly look forward to the day when a better package management system comes along.
If Metacello spurs some folks with "obviously better ideas" to produce a Package Management system that we can all use, then it will have been worth the effort:)
Until the better mousetrap appears, I will continue to slog along on Metacello.
this is the only strategy. build use learn build use learn build use learn build use learn build use learn build use learn build use learn build use learn build use learn build use learn build use learn build use learn build use learn and may be swicth build use learn build use learn build use learn build use learn Thanks for your steady building approach
2010/2/24 Germán Arduino <garduino@gmail.com>:
2010/2/24 Stéphane Ducasse <stephane.ducasse@inria.fr>
Thanks for your steady building approach
+111111111111111 This is the attitude, Thanks Dale!
Are you in base 1r from Cuis 2.0 ? Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (11)
-
Dale Henrichs -
Germán Arduino -
Göran Krampe -
Henrik Johansen -
Henrik Sperre Johansen
-
Janko Mivšek -
laurent laffont -
Mariano Martinez Peck -
Nicolas Cellier -
Stéphane Ducasse -
Torsten Bergmann