- Pharo-users - lists.pharo.org

Re: [Pharo-users] Global package cache

by Mariano Martinez Peck

> >> This is the one I used... > > StartupLoader default executeAtomicItems: { > StartupAction name: 'Shared Package Cache' code: > [ MCCacheRepository default directory setPathName: > 'C:\Smalltalk\#Shared-Package-**Cache'. > MCDirectoryRepository defaultDirectoryName: > 'C:\Smalltalk\#Shared-Package-**Cache'. > ]. > }. > > I'm not sure of the function of the fourth line (I copied it from > http://marianopeck.wordpress.**com/2012/05/12/startuploader-** > running-startup-scripts-in-**pharo/<http://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-s…> > ) > > The fourth line is just the default directory that appears in the popup when you do "+repository" -> "directory" in the MC browser. -- Mariano http://marianopeck.wordpress.com

Nov. 11, 2012

Re: [Pharo-users] Global package cache

by Ben Coman

Francois Stephany wrote: > In an 1.4 summer image, executing: > >> MCCacheRepository default: (FileDirectory on: >> '/Users/fstephany/package-cache/'). > > in a workspace works fine. > > But: > >> StartupLoader default executeAtomicItems: { >> StartupAction name: 'Global Monticello package-cache' code: [ >> MCCacheRepository default: (FileDirectory on: >> '/Users/fstephany/package-cache/')]. > > ... other StartupAction }. > > doesn't. > > The other StartupActions are executed fine (meaning that StartupLoader > works). > > Is there something reseting the package-cache at startup? > > This is the one I used... StartupLoader default executeAtomicItems: { StartupAction name: 'Shared Package Cache' code: [ MCCacheRepository default directory setPathName: 'C:\Smalltalk\#Shared-Package-Cache'. MCDirectoryRepository defaultDirectoryName: 'C:\Smalltalk\#Shared-Package-Cache'. ]. }. I'm not sure of the function of the fourth line (I copied it from http://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-s…)

Nov. 11, 2012

Global package cache

by Francois Stephany

In an 1.4 summer image, executing: > MCCacheRepository default: (FileDirectory on: '/Users/fstephany/package-cache/'). in a workspace works fine. But: > StartupLoader default executeAtomicItems: { > StartupAction name: 'Global Monticello package-cache' code: [ > MCCacheRepository default: (FileDirectory on: '/Users/fstephany/package-cache/')]. > ... other StartupAction }. doesn't. The other StartupActions are executed fine (meaning that StartupLoader works). Is there something reseting the package-cache at startup?

Nov. 11, 2012

Re: [Pharo-users] [Pharo-consortium] Pharo consortium agreement

by StÃ©phane Ducasse

>> > i doing it.. but too slow. > i need a socket in head to copy data on flash :) the best way is one at a time and doing a tutorial with us like the last time and I generate slides then we turn slides into text. Writing 40 slides in one hour is a good rate :) Stef > > -- > Best regards, > Igor Stasenko.

Nov. 10, 2012

Re: [Pharo-users] [Pharo-consortium] Pharo consortium agreement

by Igor Stasenko

On 8 November 2012 16:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Nov 8, 2012, at 4:03 AM, Igor Stasenko wrote: > >> On 6 November 2012 15:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Very good that there is progress on this front ! >>> >>> Even better news about Igor ;-) >>> >> i always asking myself, if this horse worth its bets. >> Thank you, Stephane & others for putting trust in me more than i do :) > > As a thank, write a tutorial and doc on FFI and NativeBoost > with a lot of documented examples ;D > i doing it.. but too slow. i need a socket in head to copy data on flash :) -- Best regards, Igor Stasenko.

Nov. 10, 2012

Re: [Pharo-users] Pharo consortium agreement

by phil＠highoctane.be

Guess you'll have one more Bronze member then. Will send the stuff next week (pretty much underwater ATM) Philippe Back 2012/11/7 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 06 Nov 2012, at 19:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> I will read the document this evening. > > It is a lot of pages and it looked daunting, but it is actually very well written: very clear, non-legal language. I am impressed. > > It might have taken a bit long to get the paperwork in order, but it was worth it. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > >

Nov. 8, 2012

Re: [Pharo-users] Recovering Changes from a broken image

by Chris

On 08/11/2012 20:54, Sven Van Caekenberghe wrote: > On 08 Nov 2012, at 21:37, Chris <cpmbailey(a)btinternet.com> wrote: > >> I always thought class create and method delete worked fine. > I don't see them in my .changes file in Pharo 2.0 > > I also thought these were recorded as simple doits. Yes you're right. Just tried it in 1.4 and 2.0 and it only seems to be working in the former.

Nov. 8, 2012

Re: [Pharo-users] Recovering Changes from a broken image

by Sven Van Caekenberghe

On 08 Nov 2012, at 21:37, Chris <cpmbailey(a)btinternet.com> wrote: > I always thought class create and method delete worked fine. I don't see them in my .changes file in Pharo 2.0 I also thought these were recorded as simple doits.

Nov. 8, 2012

Re: [Pharo-users] Recovering Changes from a broken image

by Chris

On 08/11/2012 20:15, Benjamin wrote: > On Nov 8, 2012, at 9:09 PM, StÃ©phane Ducasse wrote: > >> On Nov 8, 2012, at 9:03 PM, Sven Van Caekenberghe wrote: >> >>> Hi, >>> >>> One of the cool things of Smalltalk's images/changes file is that you can do a World Menu > Tools > Recover lost changesâ¦ to get back most [1] of your code in case your image/OS/machine suddenly crashed or you forgot to save your image or commit your Monticello packages. >>> >>> But we all have encountered the situation where the image is broken, saved in such a state that it no longer starts up properly. In that case your code might seem lost forever. >>> >>> No, it is not ! >>> >>> Two days ago I had this problem myself and I remembered something Marcus said some time ago: you can access the changes file of one (in casu your broken image) from another (working) image to select/recover the changes you want. It worked perfectly. >>> >>> The easiest procedure it to copy the .changes file from the broken image and rename its extension to .cs and then open it from a World Menu > Tools > File Browser and open a Changes browser on it. >> We should add a recover from another image shortcut. >>> I found this very useful. This is a really important technique to be aware of. >>> >>> Sven >>> >>> [1] Sadly, not everything is logged in the changes file: creation of new classes, method deletions are not recorded. >> Yes we should change that. >> Ezequiel started to work on a new description of changes. > I though they were logged as "do it" , am i wrong ? > > Ben I always thought class create and method delete worked fine. There are a few issues with the current system that would be great to see addressed; instance variables created from the source code itself, class renames, repackaging etc > >>> -- >>> Sven Van Caekenberghe >>> http://stfx.eu >>> Smalltalk is the Red Pill >>> >>> >>> >>> >> > >

Nov. 8, 2012

Re: [Pharo-users] Recovering Changes from a broken image

by Benjamin

On Nov 8, 2012, at 9:09 PM, StÃ©phane Ducasse wrote: > > On Nov 8, 2012, at 9:03 PM, Sven Van Caekenberghe wrote: > >> Hi, >> >> One of the cool things of Smalltalk's images/changes file is that you can do a World Menu > Tools > Recover lost changesâ¦ to get back most [1] of your code in case your image/OS/machine suddenly crashed or you forgot to save your image or commit your Monticello packages. >> >> But we all have encountered the situation where the image is broken, saved in such a state that it no longer starts up properly. In that case your code might seem lost forever. >> >> No, it is not ! >> >> Two days ago I had this problem myself and I remembered something Marcus said some time ago: you can access the changes file of one (in casu your broken image) from another (working) image to select/recover the changes you want. It worked perfectly. >> >> The easiest procedure it to copy the .changes file from the broken image and rename its extension to .cs and then open it from a World Menu > Tools > File Browser and open a Changes browser on it. > > We should add a recover from another image shortcut. >> >> I found this very useful. This is a really important technique to be aware of. >> >> Sven >> >> [1] Sadly, not everything is logged in the changes file: creation of new classes, method deletions are not recorded. > > Yes we should change that. > Ezequiel started to work on a new description of changes. I though they were logged as "do it" , am i wrong ? Ben > >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >> >> > >

Nov. 8, 2012