- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Smalltalkhub project deletion

by Norbert Hartl

Am 15.01.2013 um 21:42 schrieb Igor Stasenko <siguctua(a)gmail.com>: > On 15 January 2013 15:43, Nicolas Petton <petton.nicolas(a)gmail.com> wrote: >> I won't mess with the prod db, but thanks anyway ;) >> > you should reconsider. Messing with prod db is one of the most funnier things :) > Unless have to maintain it :) Norbert > >> Camillo Bruni <camillobruni(a)gmail.com> writes: >> >>> BTW you can mess with the 'p' repository, I created a new 'p4' where I copy all the files for now :) >>> >>> >>> On 2013-01-15, at 15:37, Nicolas Petton <petton.nicolas(a)gmail.com> wrote: >>> >>>> Nope, this is not supposed to work this way :) >>>> I'll see what's wrong. >>>> >>>> Nico >>>> >>>> Camillo Bruni <camillobruni(a)gmail.com> writes: >>>> >>>>> I just tried to delete my project to wipe out all versions, but it looks like >>>>> that the versions all re-appear after you create a new project with the same name >>>>> as the old one. >>>>> >>>>> Is that on purpose? >>>>> >>>>> best >>>>> cami >>>> >>>> -- >>>> Nicolas Petton >>>> http://nicolas-petton.fr >>>> >>> >>> >> >> -- >> Nicolas Petton >> http://nicolas-petton.fr >> > > > > -- > Best regards, > Igor Stasenko. >

Jan. 15, 2013

Re: [Pharo-project] Smalltalkhub project deletion

by Igor Stasenko

On 15 January 2013 15:43, Nicolas Petton <petton.nicolas(a)gmail.com> wrote: > I won't mess with the prod db, but thanks anyway ;) > you should reconsider. Messing with prod db is one of the most funnier things :) > Camillo Bruni <camillobruni(a)gmail.com> writes: > >> BTW you can mess with the 'p' repository, I created a new 'p4' where I copy all the files for now :) >> >> >> On 2013-01-15, at 15:37, Nicolas Petton <petton.nicolas(a)gmail.com> wrote: >> >>> Nope, this is not supposed to work this way :) >>> I'll see what's wrong. >>> >>> Nico >>> >>> Camillo Bruni <camillobruni(a)gmail.com> writes: >>> >>>> I just tried to delete my project to wipe out all versions, but it looks like >>>> that the versions all re-appear after you create a new project with the same name >>>> as the old one. >>>> >>>> Is that on purpose? >>>> >>>> best >>>> cami >>> >>> -- >>> Nicolas Petton >>> http://nicolas-petton.fr >>> >> >> > > -- > Nicolas Petton > http://nicolas-petton.fr > -- Best regards, Igor Stasenko.

Jan. 15, 2013

Re: [Pharo-project] Class initialisation after loading

by Sven Van Caekenberghe

On 14 Jan 2013, at 11:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 14 Jan 2013, at 09:38, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Am 14.01.2013 um 09:24 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> On 14 Jan 2013, at 09:09, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>>> Am 14.01.2013 um 07:54 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> >>>>> Morning, Norbert, >>>>> >>>>> On 14 Jan 2013, at 07:44, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>> >>>>>> As for every other objects initialize is called when the object is created. Upgrading code might change the shape of the object but then there is no initialize call. Do you want to have initialize called every tiny code change? >>>>>> Using *cello you can use postLoadDoits to tweak stuff. >>>>> >>>>> You mean that, in your opinion, making sure that the #initialize is called in every scenario (new/existing class) can only be done with an explicit action ? >>>> >>>> I think that the primary purpose is to initialize newly created space. In case of shape change this doesn't happen. So taking the example you initialize e.g. an instvar with a collection. Do you want to reinitialize it even if you corrected a typo in the comment of a method? >>>> If I wanted to have control over those things I would on class initialization register a class of mine to the local change notification system in the image. But this isn't easy to do in a cross platform manner. Maybe there are better ways. I'm sure someone will speak up then. >>> >>> Let's make it more concrete. Zinc-Resource-Meta-Core is a package that among other thins contains ZnMimeType. ZnMimeType class>>initialize sets up some constants (lists of known mime types, file extension to mime type mappings, you get the idea). When I add new constants in a new source version, I want them to be added when doing an automated CI build, obviously. Right now, this does *not* happen, probably because the class and #initialize method already exist in the image where it is being load in. >> >> I understand. The problem is introduced by having a cache of those mime types. That is often a problem because the cache is designed as infinite valid but there is a use case that needs a little less infinite :) I think it depends how often that "adding" takes place. And it seems to me it does not occur very often. Apart from that cache invalidation is one of the more unpleasant things we face. If you want your cache to update you need to check something. But that is what you want to avoid for performance reasons. >> So I would see a postLoadIt for these rare jobs is a good match. > > Thanks for the discussion, Norbert, I still feel that in most cases, when loading code, or when building new images, I want the class initializers of loaded classes to run to make sure everything is in a known, up to date state. Loading code or building images does not happen a lot and it feels strange to load something but not have it initialized. > > We'll see if somebody else has anything to say about this. In a private email conversation, Lukas Renggli helped me out. This is what I learned, in my words: It is indeed so that after a Monticello load, a class initializer is only run for totally new classes or when the source code string of the class #initialize method coming in is different from the one already present. So adding/changing a comment or whitespace is all that is needed to force it to run. See, apparently, MCMethodDefinition>>#postloadOver: Now, this Zinc build based on Pharo 1.3 is all green again: http://jenkins.lukas-renggli.ch/job/Zinc/ I learned something important that was bugging me for some time. Sven >>> Indeed, you would not always want costly initializations to run, but there should at least be a hook to do it, no ? >>> >>>>>> Am 14.01.2013 um 07:20 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> For a long time I have been having troubles with #initialize (not) being sent to classes that just got loaded. >>>>>>> >>>>>>> Apparently #initialize is only sent to *newly* loaded classes that did not exist before ? >>>>>>> >>>>>>> It does not get sent to existing classes being reloaded/overwritten ? >>>>>>> >>>>>>> Does the fact that the #initialize class method itself gets overwritten (actually changes) have anything to do with it ? >>>>>>> >>>>>>> What would be the best practice here ? The most portable one ? >>>>>>> >>>>>>> I want to be able to make sure #initialize is sent when I want it. >>>>>>> >>>>>>> Thx, >>>>>>> >>>>>>> Sven >>>>>>> >>>>>>> PS: I am looking for a solution that would work for Monticello package loading, via Gofer or Metacello as well as regular #fileIn. >>>>>>> >>>>>>> -- >>>>>>> Sven Van Caekenberghe >>>>>>> http://stfx.eu >>>>>>> Smalltalk is the Red Pill

Jan. 15, 2013

Re: [Pharo-project] CI down?

by Camillo Bruni

On 2013-01-15, at 20:10, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Camillo Bruni-3 wrote >> and done! > > Thanks, Cami!! It looks like there are two newer versions on Jenkins... right, slightly messy everything :/, uploading those as well right now

Jan. 15, 2013

Re: [Pharo-project] Spreadsheet widget

by Hilaire Fernandes

It is a nice start. Hilaire Le 14/01/2013 22:22, StÃ©phane Ducasse a Ã©crit : > Hi hilaire > > I updated a bit the code of Hans. > > - remove clone > - remove fractions:offset: to work in latest 2.0 > - postCopy should call super postCopy. > > > > SpreadsheetGridMorph new openInWorld > > > Open a new spreadsheet with "SpreadsheetGridMorph new openInWorld". > You can enter numbers into the cells, and you may enter rules (start > with "=", cell refs are written as A1, B1 etc). > Currently implemented are +-*/ operations. > The update machinery (which is the heart of a spreadsheet) works nicely. > > > > > > Would be good to publish the code somewhere. > > > Stef >

Jan. 15, 2013

Re: [Pharo-project] CI down?

by Sean P. DeNigris

Camillo Bruni-3 wrote > and done! Thanks, Cami!! It looks like there are two newer versions on Jenkins... -- View this message in context: http://forum.world.st/CI-down-tp4659453p4663596.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 15, 2013

Re: [Pharo-project] CI down?

by Camillo Bruni

>>> I will look into it. Could be that I did not push all my 1.4 images, >>> since I had to recreate all of them first ;) >> >> Bump :) Maybe just copy 14459 there as a start? > > uploading the files from the old gforge download: 14433-14557 > > intermediate updates missing... and done!

Jan. 15, 2013

Re: [Pharo-project] CI down?

by Camillo Bruni

On 2013-01-15, at 19:12, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Camillo Bruni-3 wrote >> On 2012-12-17, at 20:39, "Sean P. DeNigris" < > >> sean@ > >> > wrote: >> >>> Camillo Bruni-3 wrote >>>> Use our static file server: http://pharo.gforge.inria.fr/ci/ >>> >>> The copy of 1.4 there looks crazy old (14415 vs. at least 14459)... >> >> I will look into it. Could be that I did not push all my 1.4 images, >> since I had to recreate all of them first ;) > > Bump :) Maybe just copy 14459 there as a start? uploading the files from the old gforge download: 14433-14557 intermediate updates missing...

Jan. 15, 2013

Re: [Pharo-project] CI down?

by Sean P. DeNigris

Camillo Bruni-3 wrote > On 2012-12-17, at 20:39, "Sean P. DeNigris" < > sean@ > > wrote: > >> Camillo Bruni-3 wrote >>> Use our static file server: http://pharo.gforge.inria.fr/ci/ >> >> The copy of 1.4 there looks crazy old (14415 vs. at least 14459)... > > I will look into it. Could be that I did not push all my 1.4 images, > since I had to recreate all of them first ;) Bump :) Maybe just copy 14459 there as a start? -- View this message in context: http://forum.world.st/CI-down-tp4659453p4663582.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 15, 2013

Re: [Pharo-project] New Cog VMs available

by Sean P. DeNigris

Eliot Miranda-2 wrote > CogVM binaries as per VMMaker.oscog-eem.255/r2672 Thanks, Eliot!! -- View this message in context: http://forum.world.st/New-Cog-VMs-available-tp4663415p4663571.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 15, 2013