[Pharo-users] Glorp reconnection management (was: Re: Glorp: how to reconnect after image shutdown / load?)

[Herby Vojčík]

jtuc...@objektfabrik.de wrote:

Herby,

I am not aware of any automatic reconnect tools. Kepping a DB connection
alive after an image is closed is surely not desired and chances are the
DB will close the inactive session eventually anyways.


Hm. When I though about it, image save / load cycle is just one example 
of losing a connection to db. So the question is more on "how to manage 
possible disconnections / reconnections"?



So it's probably best to make the DB connections reconnect on demand.
That means that whenever you open a session, check if a DB connection is
available or establish a new one otherwise.


Hm, I though that once I open a session it does actually connect on 
demand (it has Login, system and all the information for it). Does it 
actually mean that if I want to stay connected I must do `session login` 
before each `session inUnitOfWorkDo:`?



There are many scenarios that can lead to the loss of a DB connection
that you usually cannot influence (network connection drops, DB server
has some error condition etc.) , so this is a good idea anyways.


As written above, I thought glorp manages this kind of reconnection 
itself. If not, can someone point me to the some example where this is 
managed? I am asking because in Glorp book I did not find anything about 
this (I have read it).


Thanks, Herby


HTH

Joachim


Am 01.08.17 um 22:29 schrieb Herby Vojčík:

Hello!

ZnServers have its own register mechanism by which they listen when
they are tagged as such after image save and load.

I wonder if there is some way to connect to database in Glorp and then
"keep the connection" between image save/load. Or how is this managed
notmally in apps that use databases? Is image "preconfigured" with
live self-healing connection or does some special piece of startup
code be installed so it runs after deployment and image start?

Thanks, Herby

[Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

[Tim Mackinnon]

Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a fresh 
directory) - that when I launch it, the setting Tools | Software Config Mgnmnt 
| Monticello | Local Cache Directory has a value that points to a directory 
from one of my earlier images.

Is this normal (does it store this information somewhere on my computer so that 
different setups can access it)?

At first I thought this was annoying - but I’m now wondering if this is useful 
as I’m guessing that there isn’t any reason to have separate caches for version 
controlled libraries and so maybe I should actually set it to some common 
directory?

What is the recommended strategy?

Tim

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

[Mariano Martinez Peck]

On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon  wrote:

> Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a
> fresh directory) - that when I launch it, the setting Tools | Software
> Config Mgnmnt | Monticello | Local Cache Directory has a value that points
> to a directory from one of my earlier images.
>
> Is this normal (does it store this information somewhere on my computer so
> that different setups can access it)?
>
> At first I thought this was annoying - but I’m now wondering if this is
> useful as I’m guessing that there isn’t any reason to have separate caches
> for version controlled libraries and so maybe I should actually set it to
> some common directory?
>
> What is the recommended strategy?
>
>
My strategy is to use a shared repository for all my images. As part of my
build image scripts I do something like this:


" === Personal Settings  "
MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/'
asFileReference.MCGitHubRepository cacheDirectory:
'/Users/mariano/Pharo/localRepo/' asFileReference.GTPlayBook
cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference.

GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/'
asFileReference.


I guess you save stuff:

find /Users/mariano/Pharo/localRepo/ -type f | wc -l

   *32301*

 du -sh /Users/mariano/Pharo/localRepo
*6.1G*/Users/mariano/Pharo/localRepo


Not only you save disk space, but also:
1) Each image build is likely to take less time as many files will be
already in the cache (no need to redownload it).
2) it works as a yet another backup of your code and other packages.



-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

[Tim Mackinnon]

Hey thanks - that seems like a good strategy (I hadn’t though of sharing the GT 
ones as well).

However, I’m still curious how/why a new image would pick up settings from what 
I did in another image (at least I think thats what its done - certainly the 
directory it shows in my fresh image is not File @pharo-local/package-cache 
like I would expect it to be?

With regards to the GT settings - how does it work if you share them - do they 
happily co-exist? The stash one is also quite new to me - Sven mentioned it a 
few weeks ago as I was confused how the playground got saved (I’m still not 
clear) - but he suggested double-clicking the title and giving the tab a name. 
Are these named ones the stashed ones (it looks like it). And do stashed ones 
honour cmd-s to save them? Which then leads to the question, that in different 
images - if you share the stash then I guess if you want to reload a file, you 
close that playground and then pick it again from the list?

Its quite a cool way of working (not perfect) but a real time saver. Thanks for 
sharing.

Tim

> On 2 Aug 2017, at 13:24, Mariano Martinez Peck  wrote:
> 
> 
> 
> On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon  > wrote:
> Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a 
> fresh directory) - that when I launch it, the setting Tools | Software Config 
> Mgnmnt | Monticello | Local Cache Directory has a value that points to a 
> directory from one of my earlier images.
> 
> Is this normal (does it store this information somewhere on my computer so 
> that different setups can access it)?
> 
> At first I thought this was annoying - but I’m now wondering if this is 
> useful as I’m guessing that there isn’t any reason to have separate caches 
> for version controlled libraries and so maybe I should actually set it to 
> some common directory?
> 
> What is the recommended strategy?
> 
> 
> My strategy is to use a shared repository for all my images. As part of my 
> build image scripts I do something like this:
> 
> 
> " === Personal Settings  "
> 
> MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' 
> asFileReference.
> MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' 
> asFileReference.
> GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' 
> asFileReference. 
> GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' 
> asFileReference. 
> 
> 
> I guess you save stuff:
> 
> find /Users/mariano/Pharo/localRepo/ -type f | wc -l  
>   
>32301
> 
>  du -sh /Users/mariano/Pharo/localRepo
> 6.1G/Users/mariano/Pharo/localRepo
> 
> 
> Not only you save disk space, but also:
> 1) Each image build is likely to take less time as many files will be already 
> in the cache (no need to redownload it).
> 2) it works as a yet another backup of your code and other packages. 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com 

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

[Pavel Krivanek]

Try to run the image with --no-default-preferences.

-- Pavel

2017-08-02 14:37 GMT+02:00 Tim Mackinnon :

> Hey thanks - that seems like a good strategy (I hadn’t though of sharing
> the GT ones as well).
>
> *However, I’m still curious how/why a new image would pick up settings
> from what I did in another image (at least I think thats what its done -
> certainly the directory it shows in my fresh image is not File
> @pharo-local/package-cache like I would expect it to be?*
>
> With regards to the GT settings - how does it work if you share them - do
> they happily co-exist? The stash one is also quite new to me - Sven
> mentioned it a few weeks ago as I was confused how the playground got saved
> (I’m still not clear) - but he suggested double-clicking the title and
> giving the tab a name. Are these named ones the stashed ones (it looks like
> it). And do stashed ones honour cmd-s to save them? Which then leads to the
> question, that in different images - if you share the stash then I guess if
> you want to reload a file, you close that playground and then pick it again
> from the list?
>
> Its quite a cool way of working (not perfect) but a real time saver.
> Thanks for sharing.
>
> Tim
>
> On 2 Aug 2017, at 13:24, Mariano Martinez Peck 
> wrote:
>
>
>
> On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon  wrote:
>
>> Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a
>> fresh directory) - that when I launch it, the setting Tools | Software
>> Config Mgnmnt | Monticello | Local Cache Directory has a value that points
>> to a directory from one of my earlier images.
>>
>> Is this normal (does it store this information somewhere on my computer
>> so that different setups can access it)?
>>
>> At first I thought this was annoying - but I’m now wondering if this is
>> useful as I’m guessing that there isn’t any reason to have separate caches
>> for version controlled libraries and so maybe I should actually set it to
>> some common directory?
>>
>> What is the recommended strategy?
>>
>>
> My strategy is to use a shared repository for all my images. As part of my
> build image scripts I do something like this:
>
>
> " === Personal Settings  "
> MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' 
> asFileReference.MCGitHubRepository cacheDirectory: 
> '/Users/mariano/Pharo/localRepo/' asFileReference.GTPlayBook cacheDirectory: 
> '/Users/mariano/Pharo/play-cache/' asFileReference.
>
> GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/'
> asFileReference.
>
>
> I guess you save stuff:
>
> find /Users/mariano/Pharo/localRepo/ -type f | wc -l
>
>*32301*
>
>  du -sh /Users/mariano/Pharo/localRepo
> *6.1G*/Users/mariano/Pharo/localRepo
>
>
> Not only you save disk space, but also:
> 1) Each image build is likely to take less time as many files will be
> already in the cache (no need to redownload it).
> 2) it works as a yet another backup of your code and other packages.
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

[Tim Mackinnon]

A that’s how it works… StartupPreferencesHandler and its in my 
user/Library/Preferences/Pharo/6.0 folder…

You learn something new every day (minute it seems lately)

Tim

> On 2 Aug 2017, at 14:04, Pavel Krivanek  wrote:
> 
> Try to run the image with --no-default-preferences.
> 
> -- Pavel
> 
> 2017-08-02 14:37 GMT+02:00 Tim Mackinnon  >:
> Hey thanks - that seems like a good strategy (I hadn’t though of sharing the 
> GT ones as well).
> 
> However, I’m still curious how/why a new image would pick up settings from 
> what I did in another image (at least I think thats what its done - certainly 
> the directory it shows in my fresh image is not File 
> @pharo-local/package-cache like I would expect it to be?
> 
> With regards to the GT settings - how does it work if you share them - do 
> they happily co-exist? The stash one is also quite new to me - Sven mentioned 
> it a few weeks ago as I was confused how the playground got saved (I’m still 
> not clear) - but he suggested double-clicking the title and giving the tab a 
> name. Are these named ones the stashed ones (it looks like it). And do 
> stashed ones honour cmd-s to save them? Which then leads to the question, 
> that in different images - if you share the stash then I guess if you want to 
> reload a file, you close that playground and then pick it again from the list?
> 
> Its quite a cool way of working (not perfect) but a real time saver. Thanks 
> for sharing.
> 
> Tim
> 
>> On 2 Aug 2017, at 13:24, Mariano Martinez Peck > > wrote:
>> 
>> 
>> 
>> On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon > > wrote:
>> Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a 
>> fresh directory) - that when I launch it, the setting Tools | Software 
>> Config Mgnmnt | Monticello | Local Cache Directory has a value that points 
>> to a directory from one of my earlier images.
>> 
>> Is this normal (does it store this information somewhere on my computer so 
>> that different setups can access it)?
>> 
>> At first I thought this was annoying - but I’m now wondering if this is 
>> useful as I’m guessing that there isn’t any reason to have separate caches 
>> for version controlled libraries and so maybe I should actually set it to 
>> some common directory?
>> 
>> What is the recommended strategy?
>> 
>> 
>> My strategy is to use a shared repository for all my images. As part of my 
>> build image scripts I do something like this:
>> 
>> 
>> " === Personal Settings  "
>> 
>> MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' 
>> asFileReference.
>> MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' 
>> asFileReference.
>> GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' 
>> asFileReference. 
>> GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' 
>> asFileReference. 
>> 
>> 
>> I guess you save stuff:
>> 
>> find /Users/mariano/Pharo/localRepo/ -type f | wc -l 
>>
>>32301
>> 
>>  du -sh /Users/mariano/Pharo/localRepo
>> 6.1G/Users/mariano/Pharo/localRepo
>> 
>> 
>> Not only you save disk space, but also:
>> 1) Each image build is likely to take less time as many files will be 
>> already in the cache (no need to redownload it).
>> 2) it works as a yet another backup of your code and other packages. 
>> 
>> 
>> 
>> -- 
>> Mariano
>> http://marianopeck.wordpress.com 
> 
> 

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

[Tim Mackinnon]

Mariano - out of curiosity, how do you build your image - do you use zero conf 
and then apply a known .st script? (I used to use pharo launcher back in the 
day - but now I find that zeroconf is actually handier anyway).

Tim

> On 2 Aug 2017, at 13:24, Mariano Martinez Peck  > wrote:
> 
> 
> 
> On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon  > wrote:
> Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a 
> fresh directory) - that when I launch it, the setting Tools | Software Config 
> Mgnmnt | Monticello | Local Cache Directory has a value that points to a 
> directory from one of my earlier images.
> 
> Is this normal (does it store this information somewhere on my computer so 
> that different setups can access it)?
> 
> At first I thought this was annoying - but I’m now wondering if this is 
> useful as I’m guessing that there isn’t any reason to have separate caches 
> for version controlled libraries and so maybe I should actually set it to 
> some common directory?
> 
> What is the recommended strategy?
> 
> 
> My strategy is to use a shared repository for all my images. As part of my 
> build image scripts I do something like this:
> 
> 
> " === Personal Settings  "
> 
> MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' 
> asFileReference.
> MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' 
> asFileReference.
> GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' 
> asFileReference. 
> GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' 
> asFileReference. 
> 
> 
> I guess you save stuff:
> 
> find /Users/mariano/Pharo/localRepo/ -type f | wc -l  
>   
>32301
> 
>  du -sh /Users/mariano/Pharo/localRepo
> 6.1G/Users/mariano/Pharo/localRepo
> 
> 
> Not only you save disk space, but also:
> 1) Each image build is likely to take less time as many files will be already 
> in the cache (no need to redownload it).
> 2) it works as a yet another backup of your code and other packages. 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com 

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

[Mariano Martinez Peck]

On Wed, Aug 2, 2017 at 10:50 AM, Tim Mackinnon  wrote:

> Mariano - out of curiosity, how do you build your image - do you use zero
> conf and then apply a known .st script? (I used to use pharo launcher back
> in the day - but now I find that zeroconf is actually handier anyway).
>
>
My work flow explained below is only for when I am using stable Pharo for a
paid client. In this case, I am not grabbing Pharo latest code all the
time. Only every in a while. So, my workflow is as follow:

1) with zero conf I simply grab image and vm (I try to keep my app working
with latest stable)

2) Apply a known load script that we keep maintained (this is somehwere in
a wiki). This script contains:
   2.1) settings of Author, Monticello username and pass etc.
   2.2) Several custom settings/preferences that I like to change to
the default image (this could be replaced by startup preferences thingy).
   2.3) Workaround for bugs I hit and that are not backported to stable
version.
   2.4) Install 3er party libs I want for my development image (Calypso
browser, code critics (now integrated), etc etc).
   2.5) Finally, I load my app code.


3) Once I am done loading all of it, I save that image as
"PharoMyAppTemplate.image". And I never do real work with that image.

4) Each time I need a new image (to make a new feature, a bug fix,
whatever) I take "PharoMyAppTemplate.image" and I do a "save as" with
either number like "PharoMyApp1.image" or "PharoMyAppBug3232.image" or
""PharoMyAppNewFeature.image" etc. I create these images many times and I
don't have a strong policy on when to create new ones. Whenever I create
one of these images, I upload my app code to latest code.

5) Every in a while, I update my template image. Mostly when I change my
dependencies.

I can share the script if you want.

Cheers,




> Tim
>
> On 2 Aug 2017, at 13:24, Mariano Martinez Peck 
> wrote:
>
>
>
> On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon  wrote:
>
>> Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a
>> fresh directory) - that when I launch it, the setting Tools | Software
>> Config Mgnmnt | Monticello | Local Cache Directory has a value that points
>> to a directory from one of my earlier images.
>>
>> Is this normal (does it store this information somewhere on my computer
>> so that different setups can access it)?
>>
>> At first I thought this was annoying - but I’m now wondering if this is
>> useful as I’m guessing that there isn’t any reason to have separate caches
>> for version controlled libraries and so maybe I should actually set it to
>> some common directory?
>>
>> What is the recommended strategy?
>>
>>
> My strategy is to use a shared repository for all my images. As part of my
> build image scripts I do something like this:
>
>
> " === Personal Settings  "
> MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' 
> asFileReference.MCGitHubRepository cacheDirectory: 
> '/Users/mariano/Pharo/localRepo/' asFileReference.GTPlayBook cacheDirectory: 
> '/Users/mariano/Pharo/play-cache/' asFileReference.
>
> GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/'
> asFileReference.
>
>
> I guess you save stuff:
>
> find /Users/mariano/Pharo/localRepo/ -type f | wc -l
>
>*32301*
>
>  du -sh /Users/mariano/Pharo/localRepo
> *6.1G*/Users/mariano/Pharo/localRepo
>
>
> Not only you save disk space, but also:
> 1) Each image build is likely to take less time as many files will be
> already in the cache (no need to redownload it).
> 2) it works as a yet another backup of your code and other packages.
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

[Pharo-users] Settings - Server Mode - should I use it?

[Tim Mackinnon]

Hi - I hadn’t looked in the settings browser much before, but I was looking at 
what settings there were and noticed “server mode”.

Should I be enabling this when building a headless server image to run on 
Lambda? I saw a 2016 post by John Brant that indicated it made a difference 
when doing some benchmarking in the image (presumably headful) - but I’m 
wondering if when running headless on a server whether it really makes a 
difference. 

Has anyone played with this much before?

Tim

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

[Tim Mackinnon]

I’d be curious about your script if it is easily handy (I did notice a blog 
article you wrote on StartupLoader a while back).

By the way - I really appreciated your article "Moving contexts and debuggers 
between images with Fuel” - it inspired me to figure it out for debugging on 
AWS lambda (which is very cool BTW - and I’ll write it up soon when I have it 
bedded in)

Tim

> On 2 Aug 2017, at 15:10, Mariano Martinez Peck  > wrote:
> 
> 
> 
> On Wed, Aug 2, 2017 at 10:50 AM, Tim Mackinnon  > wrote:
> Mariano - out of curiosity, how do you build your image - do you use zero 
> conf and then apply a known .st script? (I used to use pharo launcher back in 
> the day - but now I find that zeroconf is actually handier anyway).
> 
> 
> My work flow explained below is only for when I am using stable Pharo for a 
> paid client. In this case, I am not grabbing Pharo latest code all the time. 
> Only every in a while. So, my workflow is as follow:
> 
> 1) with zero conf I simply grab image and vm (I try to keep my app working 
> with latest stable)
>  
> 2) Apply a known load script that we keep maintained (this is somehwere in a 
> wiki). This script contains:
>2.1) settings of Author, Monticello username and pass etc.
>2.2) Several custom settings/preferences that I like to change to the 
> default image (this could be replaced by startup preferences thingy).
>2.3) Workaround for bugs I hit and that are not backported to stable 
> version.
>2.4) Install 3er party libs I want for my development image (Calypso 
> browser, code critics (now integrated), etc etc).
>2.5) Finally, I load my app code.
> 
> 
> 3) Once I am done loading all of it, I save that image as 
> "PharoMyAppTemplate.image". And I never do real work with that image. 
> 
> 4) Each time I need a new image (to make a new feature, a bug fix, whatever) 
> I take "PharoMyAppTemplate.image" and I do a "save as" with either number 
> like "PharoMyApp1.image" or "PharoMyAppBug3232.image" or 
> ""PharoMyAppNewFeature.image" etc. I create these images many times and I 
> don't have a strong policy on when to create new ones. Whenever I create one 
> of these images, I upload my app code to latest code. 
> 
> 5) Every in a while, I update my template image. Mostly when I change my 
> dependencies. 
> 
> I can share the script if you want. 
> 
> Cheers,
> 
> 
>  
> Tim
> 
>> On 2 Aug 2017, at 13:24, Mariano Martinez Peck > > wrote:
>> 
>> 
>> 
>> On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon > > wrote:
>> Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a 
>> fresh directory) - that when I launch it, the setting Tools | Software 
>> Config Mgnmnt | Monticello | Local Cache Directory has a value that points 
>> to a directory from one of my earlier images.
>> 
>> Is this normal (does it store this information somewhere on my computer so 
>> that different setups can access it)?
>> 
>> At first I thought this was annoying - but I’m now wondering if this is 
>> useful as I’m guessing that there isn’t any reason to have separate caches 
>> for version controlled libraries and so maybe I should actually set it to 
>> some common directory?
>> 
>> What is the recommended strategy?
>> 
>> 
>> My strategy is to use a shared repository for all my images. As part of my 
>> build image scripts I do something like this:
>> 
>> 
>> " === Personal Settings  "
>> 
>> MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' 
>> asFileReference.
>> MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' 
>> asFileReference.
>> GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' 
>> asFileReference. 
>> GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' 
>> asFileReference. 
>> 
>> 
>> I guess you save stuff:
>> 
>> find /Users/mariano/Pharo/localRepo/ -type f | wc -l 
>>
>>32301
>> 
>>  du -sh /Users/mariano/Pharo/localRepo
>> 6.1G/Users/mariano/Pharo/localRepo
>> 
>> 
>> Not only you save disk space, but also:
>> 1) Each image build is likely to take less time as many files will be 
>> already in the cache (no need to redownload it).
>> 2) it works as a yet another backup of your code and other packages. 
>> 
>> 
>> 
>> -- 
>> Mariano
>> http://marianopeck.wordpress.com 
> 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com 

[Pharo-users] GT Playground, pages dropdown menu - how does it work?

[Tim Mackinnon]

Hi - overtime I think I understand how the pages dropdown for the playground 
works, it then doesn’t do what I expect?

I have learned that double clicking a page tab will put the page into the stash 
directory with a name (which is cool), but then it doesn’t always seem to 
appear in the dropdown list - however I have learned that Spotter will find 
these pages if I use #playg…

So if spotter can find them, why does the playground dropdown seem to 
temperamental, or am I missing some obvious trick for clearing a cache or 
something like that? Or maybe its a bug? It would be nice if it would work, as 
its very handy as quick way to swap to a script.

Tim

[Pharo-users] about a pillar based output format for Epicea

[Stephane Ducasse]

Hi martin

I would like to wlak over epicea objects and save the changed methods
to be able to write booklets faster.
What advices can you give me?
Create a special visitor?

Stef

Re: [Pharo-users] Spotter question. "Spotter" search keyword need font setting from Pharo Setting Value.

[Alexandre Bergel]

Add your screenshot to the fogbuz entry.
Do you have the url of the entry?

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Aug 2, 2017, at 3:11 AM, peter yoo  wrote:
> 
> of course. i can report. look attached image please. i try this process.
> 
> 1. open spotter(shift + enter)
> 2. press "shift + ctrl + mouse click" to spotter keyword area
> 3. explore object.
> 
> can look this.. it's bad try?
> <스크린샷, 2017-08-02 16-07-34.png>

Re: [Pharo-users] about a pillar based output format for Epicea

[Alexandre Bergel]

Pillar is becoming central in the way I produce documents. 
Is there anyone working on improving Pillar?

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Aug 2, 2017, at 11:55 AM, Stephane Ducasse  wrote:
> 
> Hi martin
> 
> I would like to wlak over epicea objects and save the changed methods
> to be able to write booklets faster.
> What advices can you give me?
> Create a special visitor?
> 
> Stef
> 

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

[Mariano Martinez Peck]

On Wed, Aug 2, 2017 at 12:04 PM, Tim Mackinnon  wrote:

> I’d be curious about your script if it is easily handy
>

As said, nothing fancy at all [1].
And it keeps evolving all the time as Pharo evolves too.



> (I did notice a blog article you wrote on StartupLoader a while back).
>
>
Yeah, but that post is not a bit outdated as StartupLoader changed quite a
bit since I wrote the article.  But the idea is still the same.



> By the way - I really appreciated your article "Moving contexts
> and debuggers between images with Fuel” -
>

Thanks. Yes, that fact made us won the first price [2]. I still remember I
was sit on my living room, preparing the demo for ESUG I was thinking how
could I show Fuel in a cool manner. I knew at that point we were able to
serialize closures, methods, classes, etc... but I just thought "what If I
serialize the debugger?". I took me 5 minutes to try it out and realized it
worked from the first run hahaa. That was one of my top 5 best programming
days of my life hahaha.

This feature was then used for the "Fuel out stack" and to revive  CI
failure tests locally.



> it inspired me to figure it out for debugging on AWS lambda (which is very
> cool BTW - and I’ll write it up soon when I have it bedded in)
>
>
Cool. I have been following your emails about having a small image and a
small vm and I am very interesting on that. Well, I should be considering
which was my PhD [3] hahaha


[1]  http://ws.stfx.eu/OCV4GOA5D6DR
[2]
http://www.esug.org/wiki/pier/Conferences/2011/InnovationTechnologyAwards
[3] https://marianopeck.wordpress.com/2012/11/07/dr-mariano-martinez-peck/


Cheers,



> Tim
>
> On 2 Aug 2017, at 15:10, Mariano Martinez Peck 
> wrote:
>
>
>
> On Wed, Aug 2, 2017 at 10:50 AM, Tim Mackinnon  wrote:
>
>> Mariano - out of curiosity, how do you build your image - do you use zero
>> conf and then apply a known .st script? (I used to use pharo launcher back
>> in the day - but now I find that zeroconf is actually handier anyway).
>>
>>
> My work flow explained below is only for when I am using stable Pharo for
> a paid client. In this case, I am not grabbing Pharo latest code all the
> time. Only every in a while. So, my workflow is as follow:
>
> 1) with zero conf I simply grab image and vm (I try to keep my app working
> with latest stable)
>
> 2) Apply a known load script that we keep maintained (this is somehwere in
> a wiki). This script contains:
>2.1) settings of Author, Monticello username and pass etc.
>2.2) Several custom settings/preferences that I like to change to
> the default image (this could be replaced by startup preferences thingy).
>2.3) Workaround for bugs I hit and that are not backported to
> stable version.
>2.4) Install 3er party libs I want for my development image
> (Calypso browser, code critics (now integrated), etc etc).
>2.5) Finally, I load my app code.
>
>
> 3) Once I am done loading all of it, I save that image as
> "PharoMyAppTemplate.image". And I never do real work with that image.
>
> 4) Each time I need a new image (to make a new feature, a bug fix,
> whatever) I take "PharoMyAppTemplate.image" and I do a "save as" with
> either number like "PharoMyApp1.image" or "PharoMyAppBug3232.image" or
> ""PharoMyAppNewFeature.image" etc. I create these images many times and I
> don't have a strong policy on when to create new ones. Whenever I create
> one of these images, I upload my app code to latest code.
>
> 5) Every in a while, I update my template image. Mostly when I change my
> dependencies.
>
> I can share the script if you want.
>
> Cheers,
>
>
>
>
>> Tim
>>
>> On 2 Aug 2017, at 13:24, Mariano Martinez Peck 
>> wrote:
>>
>>
>>
>> On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon  wrote:
>>
>>> Hi - I’ve noticed that when I download a new image+vm with zeroconf (in
>>> a fresh directory) - that when I launch it, the setting Tools | Software
>>> Config Mgnmnt | Monticello | Local Cache Directory has a value that points
>>> to a directory from one of my earlier images.
>>>
>>> Is this normal (does it store this information somewhere on my computer
>>> so that different setups can access it)?
>>>
>>> At first I thought this was annoying - but I’m now wondering if this is
>>> useful as I’m guessing that there isn’t any reason to have separate caches
>>> for version controlled libraries and so maybe I should actually set it to
>>> some common directory?
>>>
>>> What is the recommended strategy?
>>>
>>>
>> My strategy is to use a shared repository for all my images. As part of
>> my build image scripts I do something like this:
>>
>>
>> " === Personal Settings  "
>> MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' 
>> asFileReference.MCGitHubRepository cacheDirectory: 
>> '/Users/mariano/Pharo/localRepo/' asFileReference.GTPlayBook cacheDirectory: 
>> '/Users/mariano/Pharo/play-cache/' asFileReference.
>>
>> GTPlayBook stashDirectory: '/Users/mariano/Pharo/pla

Re: [Pharo-users] Settings - Server Mode - should I use it?

[Ben Coman]

hi Tim,

This is Pharo! You can dig in to understand it yourself. ;)
1. On the setting, right-click and "Browse".
2. Scroll down to... label: 'Server mode'
then on #serverMode, right-click > Code Search > Implementors of it
3. Looking at WorldState>>serverMode, click "Senders"
and you'll come to WorldState>>interCyclePause:
Look for senders of this and inspect MinCycleLapse.

Basically that setting makes the UI loop delay for a longer time ==> less
CPU
but I don't know whether that loop still runs in headless mode.
I guess if you are bootstrapping your Lambda image, you can choose.

But since your Lambda is meant to finish quite quickly, alternatively maybe
during image shutdown you could set a flag such that next startup
#interCyclePause: blocks for 500ms and if the image exits cleanly and
quickly, #doOneCycleNowFor: is never executed at all.

cheers -ben

On Wed, Aug 2, 2017 at 10:39 PM, Tim Mackinnon  wrote:

> Hi - I hadn’t looked in the settings browser much before, but I was
> looking at what settings there were and noticed “server mode”.
>
> Should I be enabling this when building a headless server image to run on
> Lambda? I saw a 2016 post by John Brant that indicated it made a difference
> when doing some benchmarking in the image (presumably headful) - but I’m
> wondering if when running headless on a server whether it really makes a
> difference.
>
> Has anyone played with this much before?
>
> Tim
>

Re: [Pharo-users] Spotter question. "Spotter" search keyword need font setting from Pharo Setting Value.

[Ben Coman]

Thanks for taking the time to let us know of your problem.

By "report", I think Alex meant create on Issue on our tracker.
Take a look at the top part of http://pharo.org/contribute-propose-fix
and the video.

cheers -ben

On Wed, Aug 2, 2017 at 3:11 PM, peter yoo  wrote:

> of course. i can report. look attached image please. i try this process.
>
> 1. open spotter(shift + enter)
> 2. press "shift + ctrl + mouse click" to spotter keyword area
> 3. explore object.
>
> can look this.. it's bad try?
>

Re: [Pharo-users] about a pillar based output format for Epicea

[Stephane Ducasse]

I'm because Pillar is central to all my writings around Pharo (books,
slides,...).
We also want to use it for a lecture on open-source development.

Pillar got too complex and we should simplify its architecture.

I'm working on a new version of Cocoon but this tedious and I got
stuck in managing
initialisation of fields (from text to objects). now I will continue
to work but task switching is killing me.
Guillermo is helping me from time to time and damien helps me with the
makefile/latex.

I will first finish all the slides for my lectures at Prague first.

Now we made
- sure that we can run archetype without being forced to passed by the
command-line.
- and many changes and cleanup.
Now we should work on

- Make sure that we identify for real bugs showing up in the three
different archetypes (slides, books...).
- Avoid to convert to JSON files to apply mustache.

- Rethink the architecture.
  - Like removing the dependency on magritte from the core.
  - Avoid a lot of strange behavior related to metadata handling.

Stef


On Wed, Aug 2, 2017 at 6:15 PM, Alexandre Bergel
 wrote:
> Pillar is becoming central in the way I produce documents.
> Is there anyone working on improving Pillar?
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>> On Aug 2, 2017, at 11:55 AM, Stephane Ducasse  
>> wrote:
>>
>> Hi martin
>>
>> I would like to wlak over epicea objects and save the changed methods
>> to be able to write booklets faster.
>> What advices can you give me?
>> Create a special visitor?
>>
>> Stef
>>
>
>

Re: [Pharo-users] Spotter question. "Spotter" search keyword need font setting from Pharo Setting Value.

[Stephane Ducasse]

Hi Peter

I was thinking more on the place in the code where the fonts where set.

Stef

On Wed, Aug 2, 2017 at 9:11 AM, peter yoo  wrote:
> of course. i can report. look attached image please. i try this process.
>
> 1. open spotter(shift + enter)
> 2. press "shift + ctrl + mouse click" to spotter keyword area
> 3. explore object.
>
> can look this.. it's bad try?

[Pharo-users] ConfigurationOfZincHTTPComponents in Pharo 7

[Alistair Grant]

Hi Everyone,

Pharo 6 included ConfigurationOfZincHTTPComponents as part of the core
image, but it is no longer included in Pharo 7.

Can someone tell me where to load ConfigurationOfZincHTTPComponents
from, or what its replacement is?

In particular, I would like to load the WebSockets code.

Thanks very much,
Alistair

[Pharo-users] Syntax Error: Message pattern expected

[jb]

Hi everyone!

I get this error when I try to load a package from my Monticello rep. I have
never seen this before and have not a clue where to look for the mistake.

The error message window show:
Object 

Any hints what to do?

Johannes



--
View this message in context: 
http://forum.world.st/Syntax-Error-Message-pattern-expected-tp4958351.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Syntax Error: Message pattern expected

[Alistair Grant]

On Wed, Aug 02, 2017 at 12:22:38PM -0700, jb wrote:
> Hi everyone!
> 
> I get this error when I try to load a package from my Monticello rep. I have
> never seen this before and have not a clue where to look for the mistake.
> 
> The error message window show:
> Object 
> 
> Any hints what to do?
> 
> Johannes

Someone may recognise this and be able to answer it straight off, but
otherwise...

Supply:

- Pharo version and image number (World Menu -> System -> About)
- OS
- PharoDebug.log (if possible delete the old version and recreate the
  error)

:-)

Cheers,
Alistair

Re: [Pharo-users] about a pillar based output format for Epicea

[Tim Mackinnon]

Out of curiosity (as Pillar - well actually Ecstatic, was on my next hitlist to 
research), but is it so different from something like JavaScripts Metalsmith.io 
 ? I found metalsmith’s publishing pipeline and plugin 
system quite intuitive and easy to use but I just didn’t like nodejs so much 
(and the crappy webpack/brunch auto reloading systems).

It struck me that what they were doing was quite trivial in Smalltalk and I 
assumed Pillar (and Ecstatic) were similar in concept. However when I had a 
peak it did look quite complicated and made me think that porting Metalsmith 
might be easier and in interesting personal project.

Anyway, might be worth a look if you want architectural inspiration.

Tim

Sent from my iPhone

> On 2 Aug 2017, at 18:19, Stephane Ducasse  wrote:
> 
> I'm because Pillar is central to all my writings around Pharo (books,
> slides,...).
> We also want to use it for a lecture on open-source development.
> 
> Pillar got too complex and we should simplify its architecture.
> 
> I'm working on a new version of Cocoon but this tedious and I got
> stuck in managing
> initialisation of fields (from text to objects). now I will continue
> to work but task switching is killing me.
> Guillermo is helping me from time to time and damien helps me with the
> makefile/latex.
> 
> I will first finish all the slides for my lectures at Prague first.
> 
> Now we made
> - sure that we can run archetype without being forced to passed by the
> command-line.
> - and many changes and cleanup.
> Now we should work on
> 
> - Make sure that we identify for real bugs showing up in the three
> different archetypes (slides, books...).
> - Avoid to convert to JSON files to apply mustache.
> 
> - Rethink the architecture.
> - Like removing the dependency on magritte from the core.
> - Avoid a lot of strange behavior related to metadata handling.
> 
> Stef
> 
> 
> On Wed, Aug 2, 2017 at 6:15 PM, Alexandre Bergel
>  wrote:
>> Pillar is becoming central in the way I produce documents.
>> Is there anyone working on improving Pillar?
>> 
>> Alexandre
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>>> On Aug 2, 2017, at 11:55 AM, Stephane Ducasse  
>>> wrote:
>>> 
>>> Hi martin
>>> 
>>> I would like to wlak over epicea objects and save the changed methods
>>> to be able to write booklets faster.
>>> What advices can you give me?
>>> Create a special visitor?
>>> 
>>> Stef
>>> 
>> 
>> 
> 

Re: [Pharo-users] Syntax Error: Message pattern expected

[Johannes Brauer]

> Am 02.08.2017 um 21:44 schrieb Alistair Grant :
> 
> On Wed, Aug 02, 2017 at 12:22:38PM -0700, jb wrote:
>> Hi everyone!
>> 
>> I get this error when I try to load a package from my Monticello rep. I have
>> never seen this before and have not a clue where to look for the mistake.
>> 
>> The error message window show:
>> Object 
>> 
>> Any hints what to do?
>> 
>> Johannes
> 
> Someone may recognise this and be able to answer it straight off, but
> otherwise...
> 
> Supply:
> 
> - Pharo version and image number (World Menu -> System -> About)
Pharo4.0
Latest update: #40626
> - OS
macOs 10.12.6
> - PharoDebug.log (if possible delete the old version and recreate the
>  error)
PharoDebug.log is empty

BTW, I tried to do the same with
Pharo 6.0
Latest update: #60508

Same behavior

Johannes

[Pharo-users] How to load a baseline in Iceberg? Get #addTo: sent to nil?

[Tim Mackinnon]

I’m wondering if I’m missing a trick somewhere - but I have a simple project 
with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg (technically I 
don’t need the BaseLineOf, but I was learning how to use them and I simply 
added a postLoad hook to run some code in it).

Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the UI. 
If I right click on the BaseLine one, and click the “install baseline 
(default)” option, I was expecting it to load both packages for me - however I 
get the talkback error “#addTo: was sent to nil from the 
MCRepositoryGroup>>addRepository: method”.

In trying to debug the code I can see its trying to find a handler for 
gitlocal:/// , doesn’t find one and then tries to create a repo 
and bails… this seems like a bug? I did notice in tracing the code that there 
is a reference to a Setting that I saw - “Enable Metacello Integration” - 
should I set that to true (its false by default)?

I’m wondering how other people are loading their projects in Iceberg if this 
doesn’t work?

Tim

Re: [Pharo-users] How to load a baseline in Iceberg? Get #addTo: sent to nil?

[Tim Mackinnon]

Answering a portion of my own question - enabling the Metacello Integration 
setting, does get a bit further, but then it expects my BaselineOF package to 
have a project method (which I guess configurationOF packages have) - but as 
this is a baseline I didn’t think it was supposed to have one of these?

So I guess that setting isn’t applicable?

Tim

> On 2 Aug 2017, at 22:31, Tim Mackinnon  wrote:
> 
> I’m wondering if I’m missing a trick somewhere - but I have a simple project 
> with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg (technically 
> I don’t need the BaseLineOf, but I was learning how to use them and I simply 
> added a postLoad hook to run some code in it).
> 
> Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the UI. 
> If I right click on the BaseLine one, and click the “install baseline 
> (default)” option, I was expecting it to load both packages for me - however 
> I get the talkback error “#addTo: was sent to nil from the 
> MCRepositoryGroup>>addRepository: method”.
> 
> In trying to debug the code I can see its trying to find a handler for 
> gitlocal:/// , doesn’t find one and then tries to create a repo 
> and bails… this seems like a bug? I did notice in tracing the code that there 
> is a reference to a Setting that I saw - “Enable Metacello Integration” - 
> should I set that to true (its false by default)?
> 
> I’m wondering how other people are loading their projects in Iceberg if this 
> doesn’t work?
> 
> Tim

Re: [Pharo-users] Iceberg and removing packages

[Tim Mackinnon]

I just hit the same problem - I wanted to remove a package that I no longer 
wanted - I went to the iceberg packages tab for the project and picked remove 
from disk and then I did a synchronise and commit. At the time I did notice 
that it didn’t show a package removal change (but I assumed that as it was 
gone, maybe you don’t show that?).

Tim

> On 31 Jul 2017, at 13:30, Esteban Lorenzano  wrote:
> 
> Did you commit?
> 
>> On 31 Jul 2017, at 14:06, Esteban A. Maringolo  wrote:
>> 
>> That's exactly what I did. But after synchronizing the repo, the
>> package wasn't listed on Iceberg but it still was in in the repo.
>> It happened with another package in another repo as well.
>> 
>> If it happens again I'll let you know.
>> 
>> Regards!
>> 
>> Esteban A. Maringolo
>> 
>> 
>> 2017-07-31 7:03 GMT-03:00 Esteban Lorenzano :
>>> Hi,
>>> 
>>> In iceberg, you have to go to package tab and say "remove package from disk"
>>> 
>>> Esteban
>>> 
 On 30 Jul 2017, at 17:01, Esteban A. Maringolo  
 wrote:
 
 I got into the pharo-local/iceberg/... and git rm'ed the directory,
 commited and synchronized the project in Iceberg.
 
 I hope it doesn't break anything since I don't know how much "magic"
 does Iceberg behind the scenes other than automating the git commands
 and providing a centralized UI.
 
 What is the "This is all you need to read to understand Iceberg?"
 document I should read? I read its wiki, but it seems there is more to
 go.
 
 Regards!
 
 Esteban A. Maringolo
 
 
 2017-07-30 11:28 GMT-03:00 Peter Uhnak :
> This was supposedly fixed in April 
> https://github.com/pharo-vcs/iceberg/issues/317
> 
> however I had the same issue ~two months ago, so I had to delete the 
> packages by hand.
> 
> P
> 
> 
>> On Sun, Jul 30, 2017 at 11:04:20AM -0300, Esteban A. Maringolo wrote:
>> Hi,
>> 
>> I'm playing around with Iceberg in Pharo 6, and even when I find the
>> workflow streamlined, but since it doesn't map 1:1 with git workflow
>> from other IDEs or command line, I find myself not knowing how to do
>> certain tasks.
>> 
>> One thing that happened is that I published a few packages to one of
>> my repos in Github, then I decided to remove one of the packages from
>> the repo, then I synchronized it but in the repo there is still is the
>> package folder for the package I removed.
>> 
>> What should I do to definitely remove those files from the commit?
>> 
>> Regards!
>> 
>> Esteban A. Maringolo
>> 
> 
 
>>> 
>> 
> 

Re: [Pharo-users] How to load a baseline in Iceberg? Get #addTo: sent to nil?

[Esteban A. Maringolo]

What is the Metacello integration setting?

Esteban A. Maringolo

2017-08-02 19:01 GMT-03:00 Tim Mackinnon :

> Answering a portion of my own question - enabling the Metacello
> Integration setting, does get a bit further, but then it expects my
> BaselineOF package to have a project method (which I guess configurationOF
> packages have) - but as this is a baseline I didn’t think it was supposed
> to have one of these?
>
> So I guess that setting isn’t applicable?
>
> Tim
>
> On 2 Aug 2017, at 22:31, Tim Mackinnon  wrote:
>
> I’m wondering if I’m missing a trick somewhere - but I have a simple
> project with 2 packages, one is a BaseLineOfMyPkg and the other is MyPkg
> (technically I don’t need the BaseLineOf, but I was learning how to use
> them and I simply added a postLoad hook to run some code in it).
>
> Anyway, If I clone my repo with Iceberg, I get 2 unloaded packages in the
> UI. If I right click on the BaseLine one, and click the “install baseline
> (default)” option, I was expecting it to load both packages for me -
> however I get the talkback error “#addTo: was sent to nil from the
> MCRepositoryGroup>>addRepository: method”.
>
> In trying to debug the code I can see its trying to find a handler for
> gitlocal:///, doesn’t find one and then tries to create a repo and bails…
> this seems like a bug? I did notice in tracing the code that there is a
> reference to a Setting that I saw - “Enable Metacello Integration” - should
> I set that to true (its false by default)?
>
> I’m wondering how other people are loading their projects in Iceberg if
> this doesn’t work?
>
> Tim
>
>
>

Re: [Pharo-users] GT Playground, pages dropdown menu - how does it work?

[Tudor Girba]

Hi,

The dropdown only shows the cached pages. It should be enhanced. Would you be 
interested in diving in to propose a change?

Doru



> On Aug 2, 2017, at 5:54 PM, Tim Mackinnon  wrote:
> 
> Hi - overtime I think I understand how the pages dropdown for the playground 
> works, it then doesn’t do what I expect?
> 
> I have learned that double clicking a page tab will put the page into the 
> stash directory with a name (which is cool), but then it doesn’t always seem 
> to appear in the dropdown list - however I have learned that Spotter will 
> find these pages if I use #playg…
> 
> So if spotter can find them, why does the playground dropdown seem to 
> temperamental, or am I missing some obvious trick for clearing a cache or 
> something like that? Or maybe its a bug? It would be nice if it would work, 
> as its very handy as quick way to swap to a script.
> 
> Tim

--
www.tudorgirba.com
www.feenk.com

"Quality cannot be an afterthought."

Re: [Pharo-users] Spotter question. "Spotter" search keyword need font setting from Pharo Setting Value.

[peter yoo]

https://pharo.fogbugz.com/f/cases/20283/

wow. this report is my "first case".


thanks to all. it's real :D