Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

[Dale Henrichs]

On 04/25/2017 08:09 AM, Thierry Goubier wrote:



2017-04-25 16:11 GMT+02:00 Dale Henrichs 
>:


[ Shortened for brevity ... ]



Hum. I'm not trying to determine a version for the
configurations present in the image... and
#primeRegistryFromImage seems to, and then I seem to get
errors because it selects a wrong version (at least I got an
error doing that with ConfigurationOfEpicea, set at version
7.8.p4 where it should be version 8.1.3, and Metacello fails
with a version not found).

I'll look a bit deeper to see what is happening and how to
reproduce it.

It is very  likely that you are running into the very type of bug
that caused me to go with the Metacello registry in the first
place ... It can be impossible for Metacello to guess the correct
version of a loaded configuration ... I'm not sure it is worth
much effort to try to characterize the problem ... better would be
for Pharo to use "Metacello new" to build the image, so that the
loaded versions are registered in the first place ...


Of course...

Now, I just compute the closure of all the configuration version specs 
over the set of packages present in the image, by name. If a package 
name is present in one of the version specs, then it is considered as 
part of the project.



If you insist on looking deeper:) a common cause of wrong guesses
is that the configuration specifies a project version dependency
or a version of package that is later than the versions actually
loaded in the image --- this can happen when only a partial load
of the configuration is done where those projects or packages are
not actually loaded by the configuration itself --- without the
actual registration information from the load, Metacello looks at
the loaded projects/packages and tries to match it with a version
of the configuration and this "false" dependency information
causes Metacello to look for an earlier version that matches ...


Yes, this is the reason. In the case of Epicea in the latest image, 
the last version is 8.1.3, but ConfigurationOfEpicea>>#currentVersion 
returns 7.8p4.


7.8p4 is the highest version for which there is a dependency on the 
STON project, dependency which is respected in the image (version 
requested is 0.17, version present is 0.23). 7.8p4 and all higher 
versions also have a dependency on Smark, which isn't loaded.
So Smark is the "culprit". Since Epicea is loaded and functioning, the 
Smark project is not absolutely required, but since there is a 
dependency in the Configuration Metacello doesn't know that the project 
isn't strictly required ... I would be academically interested in the 
dependency on Smark ... it is possible the Smark is just in the list of 
projects, which makes it part of the default list ... since old-style 
Metacello loads do not record the "loads list" for a project, Metacello 
has to assume that the default list is loaded ... which could make Smark 
required ...


Would that mean that:
- If one of the project in requirements is present in the image, then 
the version is considered current (here, for 7.8p4, Ston is present, 
Smark is not) if, for the packages of the project, all are present 
with versions higher than the current configuration version spec?
Yes. When calculating the current version, Metacello can only assume 
that the default list is loaded ... I considered "improving" the current 
version calculation, but  I knew that actually recording the exact 
project specification that was loaded was far superior to any 
complicated guessing game that I could devise for Metacello and I took 
that route ... besides the current version calculation can be extremely 
expensive ...
- If none of the projects in requirements are present in the image, 
then the version is not considered current (in 8.1.3, Smark is not 
present but I see no dependency on Ston[*]) ?

Yep ... for old-style loading ...


I have a feeling this is a strange result, and I'd prefer 8.1.3 to 
have the same validity as 7.8p4.
... I prefer to record the exact project spec that is loaded ... I don't 
think it is possible to create a current version algorithm that is 
superior to recording the exact version that is loaded ... when it is 
loaded ...


Is this MetacelloProject>>#currentVersion used to determine if a 
project should be upgraded?
Yes ... Remember, we are talking old-style Metacello loading here ... 
#currentVersion  is only used when one does not use `Metacello new` 
style loading and old-style Metacello loading has been obsolete for 4 
years ...


Another question, related to the original topic: if the current 
configurations in the image are in this state, is it a good idea to 
leave them in? Would it have a chance of triggering incorrect updates 
or suspicious errors[**] if we start using them to load 

Re: [Pharo-dev] Epicea browser not starting when image is crashed

[Denis Kudriashov]

Hi.

I think it is known issue 19957

.

Anyway thank's for report

2017-04-25 19:04 GMT+02:00 Rajula Vineet :

> The method openBrowserIfLostChanges in the class EpLostChangeDetector not
> opening the Epicea browser when the image is crashed.
>
> I have tried the following.
> I changed a method, deleted some comment and I quit without saving. Epicea
> did not open. I also tried crashing the image using Ctrl+C. But the Epicea
> browser didn`t open. I also tried adding a new method, and quitting without
> saving.
>
> Versions: Pharo version 6.0
>Image version #60649
>   VM Version vmLatest60
>
>
>
>
>
> --
> View this message in context: http://forum.world.st/Epicea-
> browser-not-starting-when-image-is-crashed-tp4944060.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

[Pharo-dev] Epicea browser not starting when image is crashed

[Rajula Vineet]

The method openBrowserIfLostChanges in the class EpLostChangeDetector not
opening the Epicea browser when the image is crashed.

I have tried the following.
I changed a method, deleted some comment and I quit without saving. Epicea
did not open. I also tried crashing the image using Ctrl+C. But the Epicea
browser didn`t open. I also tried adding a new method, and quitting without
saving.

Versions: Pharo version 6.0 
   Image version #60649
  VM Version vmLatest60 





--
View this message in context: 
http://forum.world.st/Epicea-browser-not-starting-when-image-is-crashed-tp4944060.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Traits methods flattened

[Hilaire]

Can you produce tests exposing these fails?

Hilaire


Le 25/04/2017 à 10:47, Nicolai Hess a écrit :
> Keep in mind.
> 1. the way new trait methods are handled is still wrong
>if non-local methods (methods from  a trait) aren't added to the
> rpackage when creating the user of this trait, why are  new trait
> methods "flattened" into this package
> 2. we already have some "corrupted" (flattened) packages in the image.
> (some methods of users of Traits are copied from the trait).
> For example,
> traits using the trait GLMBrickExtensionTrait or
> test case traits using other traits (TRemoveForMultiplenessTest /
> TRemoveTest, TDictionaryCopyingTest/TCloneTest)
>  

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] [ANN] Pharo TechTalk: Pharo 6.0 release today 25/05 16UTC

[Esteban Lorenzano]

ah, and remember we are also at discord: 

discord 

cheers,
Esteban

> On 25 Apr 2017, at 16:29, Esteban Lorenzano  wrote:
> 
> Hi, 
> 
> So, today (in 1.5hs) I will handle the talk I didn’t handle last month ;)
> In fact, it will be just a small roadmap and then an open session of 
> questions and answers.
> 
> link for the talk is here: 
> https://www.youtube.com/c/EstebanLorenzano/live 
> 
> 
> cheers, 
> Esteban

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

[Thierry Goubier]

2017-04-25 16:11 GMT+02:00 Dale Henrichs :

[ Shortened for brevity ... ]

>
>>>
>> Hum. I'm not trying to determine a version for the configurations present
>> in the image... and #primeRegistryFromImage seems to, and then I seem to
>> get errors because it selects a wrong version (at least I got an error
>> doing that with ConfigurationOfEpicea, set at version 7.8.p4 where it
>> should be version 8.1.3, and Metacello fails with a version not found).
>>
>> I'll look a bit deeper to see what is happening and how to reproduce it.
>>
> It is very  likely that you are running into the very type of bug that
> caused me to go with the Metacello registry in the first place ... It can
> be impossible for Metacello to guess the correct version of a loaded
> configuration ... I'm not sure it is worth much effort to try to
> characterize the problem ... better would be for Pharo to use "Metacello
> new" to build the image, so that the loaded versions are registered in the
> first place ...
>

Of course...

Now, I just compute the closure of all the configuration version specs over
the set of packages present in the image, by name. If a package name is
present in one of the version specs, then it is considered as part of the
project.


>
> If you insist on looking deeper:) a common cause of wrong guesses is that
> the configuration specifies a project version dependency or a version of
> package that is later than the versions actually loaded in the image ---
> this can happen when only a partial load of the configuration is done where
> those projects or packages are not actually loaded by the configuration
> itself --- without the actual registration information from the load,
> Metacello looks at the loaded projects/packages and tries to match it with
> a version of the configuration and this "false" dependency information
> causes Metacello to look for an earlier version that matches ...


Yes, this is the reason. In the case of Epicea in the latest image, the
last version is 8.1.3, but ConfigurationOfEpicea>>#currentVersion returns
7.8p4.

7.8p4 is the highest version for which there is a dependency on the STON
project, dependency which is respected in the image (version requested is
0.17, version present is 0.23). 7.8p4 and all higher versions also have a
dependency on Smark, which isn't loaded.

Would that mean that:
- If one of the project in requirements is present in the image, then the
version is considered current (here, for 7.8p4, Ston is present, Smark is
not) if, for the packages of the project, all are present with versions
higher than the current configuration version spec?
- If none of the projects in requirements are present in the image, then
the version is not considered current (in 8.1.3, Smark is not present but I
see no dependency on Ston[*]) ?

I have a feeling this is a strange result, and I'd prefer 8.1.3 to have the
same validity as 7.8p4.

Is this MetacelloProject>>#currentVersion used to determine if a project
should be upgraded?

Another question, related to the original topic: if the current
configurations in the image are in this state, is it a good idea to leave
them in? Would it have a chance of triggering incorrect updates or
suspicious errors[**] if we start using them to load Metacello projects
that depends on them?

Thierry

[*] The dependency on Ston is removed starting version 7.8p5

[**] for example, a project requiring Epicea >= 8.0



>
>
> Dale
>
>
>
>

[Pharo-dev] [ANN] Pharo TechTalk: Pharo 6.0 release today 25/05 16UTC

[Esteban Lorenzano]

Hi, 

So, today (in 1.5hs) I will handle the talk I didn’t handle last month ;)
In fact, it will be just a small roadmap and then an open session of questions 
and answers.

link for the talk is here: 
https://www.youtube.com/c/EstebanLorenzano/live 


cheers, 
Esteban

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

[Dale Henrichs]

On 4/24/17 9:40 PM, Thierry Goubier wrote:

Hi Dale,

Le 25/04/2017 à 00:02, Dale Henrichs a écrit :



On 04/24/2017 01:49 PM, Thierry Goubier wrote:

Le 17/04/2017 à 22:13, Dale Henrichs a écrit :



On 04/17/2017 12:47 PM, Thierry Goubier wrote:

Hi Dale,

Le 17/04/2017 à 21:05, Dale Henrichs a écrit :

I would think that a `project list` view that made the Metacello
project
registration visible would help developers keep things straight.

It seems that the issue here is that developers can't tell what
projects
are already loaded in the current image and also cannot tell what
version of the project is loaded ... if you are using the `Metacello
new` to load projects, then Metacello knows what projects and what
versions are loaded in the image  and that informatation really
needs to be exposed to the developers ...

If you have a `project list` then you can do things like 
automatically
do a get on a configuration/baseline when a project is loaded via 
the

`project list tool` ... there are additional details that need to be
tracked and managed, but without the a basic `project list` the
developer is responsible for "knowing what to do" and the first
step is
to let the developer know exactly which versions of which 
projects are

loaded in the base image ...


I wrote some code to that effect in the AltBrowser (gives access to
the project, and all packages loaded via that project, via a 
Metacello

registry tag).

It didn't work as well as I expected, in part due to the interaction
between the Metacello registry and package loading into the image.
Nothing undoable, but due to the total lack of Metacello state in the
default Pharo image (nothing is loaded via Metacello in there) and 
the
Catalog browser not using Metacello as well, it was a bit too 
early to

invest into that.

In short, the Metacello registry provides a nice entry point for a
system browser view of loaded projects and versions, but the Pharo
image building process is not yet there.

If someone is interested, one need to look into the GT extensions for
Metacello objects ... those extensions are a nice source of knowledge
about extracting information from the loaded projects.

This is unfortunate ... I'm willing to help anyone who wants to tackle
this problem as well --- I know a thing or two about Metacello myself
and I've had a working `project list` in tODE for 3-4 years now ... oh
well ...


The code isn't lost anyway. I've reintegrated it as classifying based
on exiting ConfigurationOf / BaselineOf objects, relying on the spec
if there is no registering in Metacello (kind of funky in the case of a
ConfigurationOf, since you don't know which version was effectively
loaded... so you just play guesses with the various versions available
in the project).

Yeah, bootstrapping the registration is dicey business, because you can
fall prey to the very bugs you are trying to avoid --- Metacello does a
prime registry as a project load doit when the registration code is
initially ... you might look at
MetacelloProjectRegistry>>primeRegistryFromImage:baselineClasses:prioritizeConfiguration:, 


but it sounds like you are doing something very similar ...


Hum. I'm not trying to determine a version for the configurations 
present in the image... and #primeRegistryFromImage seems to, and then 
I seem to get errors because it selects a wrong version (at least I 
got an error doing that with ConfigurationOfEpicea, set at version 
7.8.p4 where it should be version 8.1.3, and Metacello fails with a 
version not found).


I'll look a bit deeper to see what is happening and how to reproduce it.
It is very  likely that you are running into the very type of bug that 
caused me to go with the Metacello registry in the first place ... It 
can be impossible for Metacello to guess the correct version of a loaded 
configuration ... I'm not sure it is worth much effort to try to 
characterize the problem ... better would be for Pharo to use "Metacello 
new" to build the image, so that the loaded versions are registered in 
the first place ...


If you insist on looking deeper:) a common cause of wrong guesses is 
that the configuration specifies a project version dependency or a 
version of package that is later than the versions actually loaded in 
the image --- this can happen when only a partial load of the 
configuration is done where those projects or packages are not actually 
loaded by the configuration itself --- without the actual registration 
information from the load, Metacello looks at the loaded 
projects/packages and tries to match it with a version of the 
configuration and this "false" dependency information causes Metacello 
to look for an earlier version that matches ...


Dale

Re: [Pharo-dev] [ANN] Pharo Spring Friday, April 28

[marcus.den...@inrira.fr]

Hello,

I can change all the pages as wanted..  (sorry for being a bit absent right 
now).

For links to the events, there should be a way… I will check (sometimes this 
week).

> On 24 Apr 2017, at 16:42, Juraj Kubelka  wrote:
> 
> Hi Marcus,
> 
> it is a detail, but the events mentions Slack. Maybe it should mention 
> Discord.
> 
> I would like to improve the page http://pharo.org/contribute-events 
>  
> by adding a workflow and link to the Pharo Sprint App. How can I do it? 
> 
> Also it would be nice to have the https://association.pharo.org/event-2492488 
>  (and others) visible on that 
> page. 
> Is it possible? Is there any calendar plugin that we can plug to the 
> http://pharo.org/contribute-events ? 
> 
> I am happy to collaborate on this, if you (or someone else) explain me how to 
> contribute to the web page.
> 
> Thanks!
> Juraj
> 
>> On Apr 24, 2017, at 10:55, marcus.den...@inrira.fr 
>>  > > wrote:
>> 
>> Hi,
>> 
>> There will be again a Sprint this Friday.
>> 
>> More infos here:
>> 
>>  https://association.pharo.org/event-2492488 
>> 
>> 
> 

Re: [Pharo-dev] Pharo 6 screenshot

[Damien Pollet]

Nice ! but… no debugger window ?

On 25 April 2017 at 12:13, Igor Stasenko  wrote:

> Great!
>
> On 25 April 2017 at 10:52, Alexandre Bergel 
> wrote:
>
>> You are an artist!
>>
>> Alexandre
>>
>>
>> > On Apr 24, 2017, at 11:48 PM, Pavel Krivanek 
>> wrote:
>> >
>> > Right, next try...
>> >
>> > https://goo.gl/photos/YnGoZTrpKjJnSbFU9
>> >
>> > -- Pavel
>> >
>> >
>> >
>> > 2017-04-24 22:22 GMT+02:00 Cyril Ferlicot D. > >:
>> > Le 24/04/2017 à 22:13, Pavel Krivanek a écrit :
>> > > New version:
>> > >
>> > > https://goo.gl/photos/66Yz3pSSK62aTYV66
>> > >
>> > > -- Pavel
>> > >
>> >
>> > Pretty nice but too blurry for me. Especially on the right of the
>> screen.
>> >
>> > But maybe it's just me.
>> >
>> > --
>> > Cyril Ferlicot
>> > https://ferlicot.fr
>> >
>> > http://www.synectique.eu
>> > 2 rue Jacques Prévert 01,
>> > 59650 Villeneuve d'ascq France
>> >
>> >
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>



-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] Pharo 6 screenshot

[Igor Stasenko]

Great!

On 25 April 2017 at 10:52, Alexandre Bergel  wrote:

> You are an artist!
>
> Alexandre
>
>
> > On Apr 24, 2017, at 11:48 PM, Pavel Krivanek 
> wrote:
> >
> > Right, next try...
> >
> > https://goo.gl/photos/YnGoZTrpKjJnSbFU9
> >
> > -- Pavel
> >
> >
> >
> > 2017-04-24 22:22 GMT+02:00 Cyril Ferlicot D. :
> > Le 24/04/2017 à 22:13, Pavel Krivanek a écrit :
> > > New version:
> > >
> > > https://goo.gl/photos/66Yz3pSSK62aTYV66
> > >
> > > -- Pavel
> > >
> >
> > Pretty nice but too blurry for me. Especially on the right of the screen.
> >
> > But maybe it's just me.
> >
> > --
> > Cyril Ferlicot
> > https://ferlicot.fr
> >
> > http://www.synectique.eu
> > 2 rue Jacques Prévert 01,
> > 59650 Villeneuve d'ascq France
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>


-- 
Best regards,
Igor Stasenko.

[Pharo-dev] [pharo-project/pharo-core] 899b87: 60469

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 899b874b1a8d9484dde90c538f2a82dd2ef0198d
  
https://github.com/pharo-project/pharo-core/commit/899b874b1a8d9484dde90c538f2a82dd2ef0198d
  Author: Jenkins Build Server 
  Date:   2017-04-25 (Tue, 25 Apr 2017)

  Changed paths:
A HelpSystem-Core.package/CustomHelp.class/class/formatting/bold_.st
A HelpSystem-Core.package/CustomHelp.class/class/formatting/doItFrom_.st
A 
HelpSystem-Core.package/CustomHelp.class/class/formatting/doItScriptFrom_.st
A HelpSystem-Core.package/CustomHelp.class/class/formatting/heading_.st
A HelpSystem-Core.package/CustomHelp.class/class/formatting/subheading_.st
A HelpSystem-Core.package/CustomHelp.class/class/formatting/underlined_.st
A HelpSystem-Core.package/CustomHelp.class/class/formatting/url_.st
A HelpSystem-Core.package/CustomHelp.class/class/instance 
creation/newColoredText_withClipboardAction_.st
A HelpSystem-Core.package/CustomHelp.class/class/instance 
creation/newColoredText_withRunAction_.st
A 
Morphic-Widgets-Basic.package/SimpleButtonMorph.class/instance/testing/isDefault.st
R Pharo-Help.package/WelcomeHelp.class/class/formatting/bold_.st
R Pharo-Help.package/WelcomeHelp.class/class/formatting/doItFrom_.st
R Pharo-Help.package/WelcomeHelp.class/class/formatting/heading_.st
R Pharo-Help.package/WelcomeHelp.class/class/formatting/subheading_.st
R Pharo-Help.package/WelcomeHelp.class/class/formatting/underlined_.st
R Pharo-Help.package/WelcomeHelp.class/class/formatting/url_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60468.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60469.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60468.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60469.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Shout.package/SHTextStylerST80.class/class/style table/darkStyleTable.st

  Log Message:
  ---
  60469
19960 Comments in changed code in Diff tool
https://pharo.fogbugz.com/f/cases/19960

19962 Watery theme is broken because SimpleButtonMorph does not understand 
isDefault
https://pharo.fogbugz.com/f/cases/19962

19970 Formatting methods recently introduced for WelcomeHelp should be 
accessible to all Help classes
https://pharo.fogbugz.com/f/cases/19970

http://files.pharo.org/image/60/60469.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/60469
  Home:   https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] Traits methods flattened

[Nicolai Hess]

2017-04-25 10:12 GMT+02:00 Hilaire :

> Ah, no sorry. After another try I got it right, I have to unload the
> package then file it in again to get it right.
>
> So the fix work for my problem too, issue definitely fixed and closed.
>
> Thanks
>
>
Keep in mind.
1. the way new trait methods are handled is still wrong
   if non-local methods (methods from  a trait) aren't added to the
rpackage when creating the user of this trait, why are  new trait methods
"flattened" into this package
2. we already have some "corrupted" (flattened) packages in the image.
(some methods of users of Traits are copied from the trait).
For example,
traits using the trait GLMBrickExtensionTrait or
test case traits using other traits (TRemoveForMultiplenessTest /
TRemoveTest, TDictionaryCopyingTest/TCloneTest)


>
> Le 25/04/2017 à 09:37, Hilaire a écrit :
> > Is there a way I can test on a Pharo6 image, because the backport does
> > not fix my problem with Traits on Pharo5?
> >
> > I am reopening the ticket.
> >
> > Hilaire
> >
> >
> > Le 22/04/2017 à 16:42, Pavel Krivanek a écrit :
> >> backported:
> >> https://pharo.fogbugz.com/f/cases/19974/backport-Traits-
> methods-flattened-case-19938
> >>
> >> Test please...
> >> -- Pavel
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-dev] Traits methods flattened

[Hilaire]

Ah, no sorry. After another try I got it right, I have to unload the
package then file it in again to get it right.

So the fix work for my problem too, issue definitely fixed and closed.

Thanks


Le 25/04/2017 à 09:37, Hilaire a écrit :
> Is there a way I can test on a Pharo6 image, because the backport does
> not fix my problem with Traits on Pharo5?
>
> I am reopening the ticket.
>
> Hilaire
>
>
> Le 22/04/2017 à 16:42, Pavel Krivanek a écrit :
>> backported: 
>> https://pharo.fogbugz.com/f/cases/19974/backport-Traits-methods-flattened-case-19938
>>
>> Test please...
>> -- Pavel

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] Pharo 6 screenshot

[Alexandre Bergel]

You are an artist!

Alexandre


> On Apr 24, 2017, at 11:48 PM, Pavel Krivanek  wrote:
> 
> Right, next try... 
> 
> https://goo.gl/photos/YnGoZTrpKjJnSbFU9
> 
> -- Pavel
> 
> 
> 
> 2017-04-24 22:22 GMT+02:00 Cyril Ferlicot D. :
> Le 24/04/2017 à 22:13, Pavel Krivanek a écrit :
> > New version:
> >
> > https://goo.gl/photos/66Yz3pSSK62aTYV66
> >
> > -- Pavel
> >
> 
> Pretty nice but too blurry for me. Especially on the right of the screen.
> 
> But maybe it's just me.
> 
> --
> Cyril Ferlicot
> https://ferlicot.fr
> 
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
> 
> 

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

Re: [Pharo-dev] Pharo 6 screenshot

[Tudor Girba]

Really nice, indeed!

Doru


> On Apr 25, 2017, at 9:21 AM, Yuriy Tymchuk  wrote:
> 
> Thank you Pavel! This looks absolutely amazing.
> 
> Uko
> 
>> On 25 Apr 2017, at 00:48, Pavel Krivanek  wrote:
>> 
>> Right, next try... 
>> 
>> https://goo.gl/photos/YnGoZTrpKjJnSbFU9
>> 
>> -- Pavel
>> 
>> 
>> 
>> 2017-04-24 22:22 GMT+02:00 Cyril Ferlicot D. :
>> Le 24/04/2017 à 22:13, Pavel Krivanek a écrit :
>> > New version:
>> >
>> > https://goo.gl/photos/66Yz3pSSK62aTYV66
>> >
>> > -- Pavel
>> >
>> 
>> Pretty nice but too blurry for me. Especially on the right of the screen.
>> 
>> But maybe it's just me.
>> 
>> --
>> Cyril Ferlicot
>> https://ferlicot.fr
>> 
>> http://www.synectique.eu
>> 2 rue Jacques Prévert 01,
>> 59650 Villeneuve d'ascq France
>> 
>> 
> 

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

"Next time you see your life passing by, say 'hi' and get to know her."

Re: [Pharo-dev] Traits methods flattened

[Hilaire]

Is there a way I can test on a Pharo6 image, because the backport does
not fix my problem with Traits on Pharo5?

I am reopening the ticket.

Hilaire


Le 22/04/2017 à 16:42, Pavel Krivanek a écrit :
> backported: 
> https://pharo.fogbugz.com/f/cases/19974/backport-Traits-methods-flattened-case-19938
>
> Test please...
> -- Pavel

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] Pharo 6 screenshot

[Yuriy Tymchuk]

Thank you Pavel! This looks absolutely amazing.

Uko

> On 25 Apr 2017, at 00:48, Pavel Krivanek  wrote:
> 
> Right, next try... 
> 
> https://goo.gl/photos/YnGoZTrpKjJnSbFU9 
> 
> 
> -- Pavel
> 
> 
> 
> 2017-04-24 22:22 GMT+02:00 Cyril Ferlicot D.  >:
> Le 24/04/2017 à 22:13, Pavel Krivanek a écrit :
> > New version:
> >
> > https://goo.gl/photos/66Yz3pSSK62aTYV66 
> > 
> >
> > -- Pavel
> >
> 
> Pretty nice but too blurry for me. Especially on the right of the screen.
> 
> But maybe it's just me.
> 
> --
> Cyril Ferlicot
> https://ferlicot.fr 
> 
> http://www.synectique.eu 
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
> 
>