November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Not a disaster (this time)

by Schwab,Wilhelm K

Adrian, You are correct, it does contain them (thanks for mentioning that). Saving my own copies _is_ a problem, but fortunately I do not need to do so. How do you enforce local loads? Do you insist on downloading everything yourselves, or do you have some type of lazy download with cancel capability? In an ideal world, I would hope to see a tool that tries to download the latest versions, shows progress toward same, and accepts user interaction to head off a hopeless situation like today. If the user cancels the download, then there would be an option to install from the local repository. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Monday, November 09, 2009 2:31 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time) Hi Bill, At netstyle.ch and Cmsbox we have the rule that all projects have to be completely loadable from our own MC repository. I suggest to do the same for the reasons you mention below. You never know what happens to external resources... Storing a local copy with MC should not be a problem. Actually, the package-cache folder should already contain the file. Cheers, Adrian On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote: > Hello all, > > I am trying to be a good tester, and have been shot in the foot now > for a couple of days. That's no great loss, but a similar set of > circumstances could be very ugly in the future. My ailing build > process for RC1 is thwarted by source.squeakfoundation.org's being > offline. Imagine a deadline (paying customer, mission-critical gizmo, > grant submission - whatever haunts you) and being stuck. > > I have even tried to save the FFI packages locally, and that seems to > go haywire over talking to the server. Having chosen the package name > and a local repository, I would expect MC to take the code it has > locally and save it to my local drive, but apparently that's not what > it does. > > There is no need for urgent action (this is only a drill<g>), but > there should be some redundancy in where the code is stored, and MC > should not prevent my saving code I already have to my local drive. > There isn't (at least not that I can find), and it does :( > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Michael Rueger

Lukas Renggli wrote: >> There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. There isn't (at least not that I can find), and it does :( > > Parse error. > > Monticello is a distributed versioning system, so it is highly > redundant by definition. You can't really blame anybody else if a > version your are interested in is not reachable. I usually copy > important code into my local repository. Well, on the other hand it is extremely bad publicity if the Squeak community's main source repository, written in Squeak, is extremely unreliable. How can one expect someone to switch to Squeak when the first thing is encountering it being unreliable? Michael

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Lukas Renggli

> If i understanding the problem clearly, MC checks the current contents > of all repositories, defined for package, > before saving a package, even locally. No. Monticello saves into the selected repository and into the local package-cache only. This is the same as you get with Git (and other similar distributed versioning systems), when you do a "git commit" and "git push <repository>" . > So, if one of repositories can't be reached, this leads to error and > unability to save a local copy on hard drive. Monticello only loads from a selected repository, it does not try multiple repositories. It could lead to different results depending on from what repository you load. Again that is the same same as with "git pull <repository>". Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Schwab,Wilhelm K

Lukas, The whole server is down, and MC (at least out of the box and with some help from ScriptLoader) comes uglued over it. I don't blame the servers; I *do* blame the design. Adrian seems to have the defects and the workaround in mind. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Monday, November 09, 2009 2:19 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time) > There is no need for urgent action (this is only a drill<g>), but > there should be some redundancy in where the code is stored, and MC > should not prevent my saving code I already have to my local drive. Â > There isn't (at least not that I can find), and it does :( Parse error. Monticello is a distributed versioning system, so it is highly redundant by definition. You can't really blame anybody else if a version your are interested in is not reachable. I usually copy important code into my local repository. http://en.wikipedia.org/wiki/Revision_control#Distributed_revision_control Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Igor Stasenko

2009/11/9 Lukas Renggli <renggli(a)gmail.com>: >> There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. Â There isn't (at least not that I can find), and it does :( > > Parse error. > > Monticello is a distributed versioning system, so it is highly > redundant by definition. You can't really blame anybody else if a > version your are interested in is not reachable. I usually copy > important code into my local repository. > > Â Â http://en.wikipedia.org/wiki/Revision_control#Distributed_revision_control > If i understanding the problem clearly, MC checks the current contents of all repositories, defined for package, before saving a package, even locally. So, if one of repositories can't be reached, this leads to error and unability to save a local copy on hard drive. I think that this check can be reduced to check/refresh the contents of repository where user wants to save the package, but not all of them. Correct me, if i wrong. > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Adrian Lienhard

Hi Bill, At netstyle.ch and Cmsbox we have the rule that all projects have to be completely loadable from our own MC repository. I suggest to do the same for the reasons you mention below. You never know what happens to external resources... Storing a local copy with MC should not be a problem. Actually, the package-cache folder should already contain the file. Cheers, Adrian On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote: > Hello all, > > I am trying to be a good tester, and have been shot in the foot now > for a couple of days. That's no great loss, but a similar set of > circumstances could be very ugly in the future. My ailing build > process for RC1 is thwarted by source.squeakfoundation.org's being > offline. Imagine a deadline (paying customer, mission-critical > gizmo, grant submission - whatever haunts you) and being stuck. > > I have even tried to save the FFI packages locally, and that seems > to go haywire over talking to the server. Having chosen the package > name and a local repository, I would expect MC to take the code it > has locally and save it to my local drive, but apparently that's not > what it does. > > There is no need for urgent action (this is only a drill<g>), but > there should be some redundancy in where the code is stored, and MC > should not prevent my saving code I already have to my local drive. > There isn't (at least not that I can find), and it does :( > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Lukas Renggli

> There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. Â There isn't (at least not that I can find), and it does :( Parse error. Monticello is a distributed versioning system, so it is highly redundant by definition. You can't really blame anybody else if a version your are interested in is not reachable. I usually copy important code into my local repository. http://en.wikipedia.org/wiki/Revision_control#Distributed_revision_control Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 9, 2009

[Pharo-project] Not a disaster (this time)

by Schwab,Wilhelm K

Hello all, I am trying to be a good tester, and have been shot in the foot now for a couple of days. That's no great loss, but a similar set of circumstances could be very ugly in the future. My ailing build process for RC1 is thwarted by source.squeakfoundation.org's being offline. Imagine a deadline (paying customer, mission-critical gizmo, grant submission - whatever haunts you) and being stuck. I have even tried to save the FFI packages locally, and that seems to go haywire over talking to the server. Having chosen the package name and a local repository, I would expect MC to take the code it has locally and save it to my local drive, but apparently that's not what it does. There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. There isn't (at least not that I can find), and it does :( Bill

Nov. 9, 2009

[Pharo-project] [update 1.1] #11037

by Marcus Denker

11037 ----- Issue 1418: clean Morph>>#okayToDuplicate Issue 571: unnecessary temporary variable assignment Issue 1419: remove convertNovember2000DropShadow... Issue 1420: remove methods of old (non-Eliot) closures Issue 1423: not Installed CompiledMethod have invalid sourcePointer after condenseChanges and conenseSources Marcus

Nov. 9, 2009

Re: [Pharo-project] Satisfying LatexMorph depencies

by Henrik Johansen

I believe the plan is for people to provide Metacello-configurations for loading different packages (prerequisites, version numbers, etc, basically the same as Sake), have the automated buildsystem test which actually work, and build a list for which a browser can be made based on those. For now though, the wiki page http://code.google.com/p/pharo/wiki/PackagesTestedInPharo is probably the best place to report versions that load correctly. Marking packages as loadable in Pharo is not possible afaik, unless you want to specifically state so in the Package name. Cheers, Henry On Nov 9, 2009, at 12:27 18PM, alesch wrote: > > Is there a way of marking what packages are ok to load into Pharo? > > > Henrik Sperre Johansen wrote: >> >> I'd suggest splitting it into two packages, one containing the core >> LatexMorphic - code, and one containing Etoys-specific extensions to >> player. >> (Basically one package for each of the class categories in the >> current >> LatexMorph-package). >> >> Cheers, >> Henry >> >> >> PS: Maybe it's just me, but I often mix DNU/MNU depending on which I >> think of first, independent of which is actually semantically >> correct... >> In my head, they mean: >> DNU - a doesNotUnderstand send, which again raises an MNU >> (MessageNotUnderstood) exception. >> >> On Nov 9, 2009, at 11:08 49AM, alesch wrote: >> >>> Thanks for your answer. >>> I do not know what a DNU is, but your suggestion worked. >>> >>> What is the procedure now to fix this package? >>> The Pharo version should remove the dependecy, but the Squeak >>> version might want to keep it. What is the policy in Pharo when this >>> happens? >>> >>> I'm mailing in the signed license agreement today, and going through >>> the commit procedure described here: >>> http://code.google.com/p/pharo/wiki/HowToContribute >>> >>> >>> >>> On Mon, Nov 9, 2009 at 10:51, Henrik Sperre Johansen [via Smalltalk] >>> <[hidden email]> wrote: >>> You can't, since Player has been removed and there's no plans for >>> bringing it back.. >>> >>> However, that also means you don't really need those methods, if you >>> browse them, you can see they're really only utility methods for >>> setting the properties of a LatexMorph from a player. >>> >>> So to load in Pharo, you can click the "Browse" button in >>> Monticello, >>> then right-click the LatexMorph-category and do "Load class >>> category"... >>> >>> Well, you *should* be able to at least, both squeak and Pharo seem >>> to >>> give a DNU if the classes don't exist in system yet... So instead, >>> select the LatexMorph category, select each of the three classes in >>> turn, and do "Load class" from the right-click menu. >>> >>> Cheers, >>> Henry >>> >>> On Nov 9, 2009, at 10:13 02AM, alesch wrote: >>> >>>> >>>> Hi list: >>>> >>>> I'm trying to load LatexMorph and I get the following dependency >>>> message. >>>> >>>> This package depends on the following classes: >>>> Player >>>> You must resolve these dependencies before you will be able to load >>>> these >>>> definitions: >>>> Player>>getCode >>>> Player>>getDPI >>>> Player>>getImage >>>> Player>>getTemplate >>>> Player>>grabImage >>>> Player>>setCode: >>>> Player>>setDPI: >>>> Player>>setTemplate: >>>> >>>> >>>> Where can I find this class? >>>> Thanks in advance! >>>> -- >>>> View this message in context: >>> http://n2.nabble.com/Satisfying-LatexMorph-depencies-tp3971944p3971944.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> View this message in context: Re: [Pharo-project] Satisfying >>> LatexMorph depencies >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > View this message in context: http://n2.nabble.com/Satisfying-LatexMorph-depencies-tp3971944p3972423.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 9, 2009