Re: [Pharo-dev] Epicea user experience report

[Norbert Hartl]

I don't like the extra menu. I think going three levels in a menu should only 
be done for thing used rarely. Feels awkward very time.
Do we have three cases wirh epicea? 

- this session meaning all changed since start of the image?
- last session/aborted session the last session that did not finished because 
of unexpected image stop. This should open automatically which does not work in 
current pharo6
- all other sessions

In this situation when the aborted session opens automatically it means I 
deliberately open epicea through the menu for other reasons. In this case I'm 
with Doru that it should be a single menu entry which opens epicea and someone 
can choose there what to see. In case of list display this session will be the 
top most entry anyway so it can be discussed if it is important to separate 
this session and the others really. 

Norbert

> Am 20.12.2016 um 17:17 schrieb Martin Dias :
> 
> Hi all,
> 
> One point of Ben's feedback is how Epicea code changes tool is presented in 
> the World Menu. Below you can see the current state + 3 options to discuss it.
> 
> 
> 1. "Epicea" main entry > "Session Changes" + "All Changes" children [current 
> state]
> 
> 
> 
> 
> 2. Attach purpose to the name: "Epicea Code Changes"
> 
> 
> 
> 
> 3. Just "Code Changes" + rephrase children:
> 
> ​
> ​
> 
> 4. Flatten
> 
> 
> ​
> 
> 
> Reminder: In World Menu > Help > Help Browser > Epicea you can find a 
> description of the tool and it's model.
> 
> Cheers.
> Martin
> 
>> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias  wrote:
>> Hello Ben,
>> 
>> About discussion points in 2 (a, b and c): I agree with your arguments... 
>> somebody that just moved from Pharo 5 to 6 and crashed an image will look 
>> for a "Recover lost changes" in the menu and can have a problem to discover 
>> it the replacement in a World->Tools->Epicea->... entry.
>> 
>> Then, as a first step we could flatten the 2 menu entries and then at least 
>> anybody will easily find an entry related to changes in World->Tools. 
>> 
>> Second, we could try to merge both Epicea GUIs into one (suggestions are 
>> welcome).
>> 
>> I still have to read more in detail the remaining of your report to answer. 
>> Anyway, thanks a lot for it.
>> 
>> Cheers,
>> Martin
>> 
>> 
>>> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman  wrote:
>>> 1. Created fresh Pharo image (build 60269)
>>> 
>>> 
>>> 2. Opened World > Tools > Epicea > All changes
>>> 
>>> Points for discussion...
>>> 
>>>   a. How many submenu items are expected for Epicea? Can we push the
>>> current ones up so the Tools menu remains a flat menu.
>>> 
>>>   b. Do we need the two current menu items?  "Current session" is
>>> encompassed by "All changes"?  What expectations do people have of how
>>> often they'll use the former rather than the latter?
>>> 
>>>   c. When people move from Pharo 5 to Pharo 6 and in a panic want to
>>> "recover changes" for a crashed image, they'll be looking for that
>>> familiar feature name, not a new app name. Could the app name be left
>>> out or placed in brackets "Changes (Epicea)".
>>> 
>>> btw, the interface looks really slick! nice work.
>>> 
>>> 
>>> 3. Opened World > System Browser.
>>> 
>>> 4. Added package AAA
>>> All Changes window - no dynamic change.
>>> On , still no change, i.e. no sessions
>>> #New All Changes window - not visible, no sessions.
>>> 
>>> 5. Added class AA.
>>> All Changes window - no dynamic change.
>>> On , shows new session with AAA & AA.
>>> 
>>> 5. Added method...
>>> AA>a
>>>^'something'
>>> Prompted for author, entered 'BenComan'
>>> All Changes window with session selected - dynamic update showing AA>>a.
>>> 
>>> 6. Added package BBB.
>>> All Changes window - no dynamic update.
>>> On , BBB still not visible in session.
>>> 
>>> 7. Added class A to package AAA.
>>> All Changes window - dynamic update showing A.
>>> On , BBB still not visible in session.
>>> 
>>> 8. Added class BB to package BBB.
>>> All Changes window - dynamic update showing BBB & BB.
>>> 
>>>   a. Package creation event seems not handled properly, being only
>>> pushed through when a class is created in it.
>>> 
>>>   b. Since there is a dynamic update for class and method
>>> modifications, could the session creation also dynamically update it
>>> UI.
>>> 
>>> ---
>>> 9. Killed the vm from command line
>>> $ ps -ef | grep pharo
>>> $ kill 29349
>>>Restarted Pharo image
>>> 
>>> 10. World > Tools > Epica > All changes.
>>> Authorship is inconsistent:
>>> * AAA and AA have blank author
>>> * AA>>a, A, BBB, B have author 'BenComan'.
>>> 
>>>  a. I understand this follows on from Author not being requested until
>>> the first method was defined. Did the old changes track the author of
>>> packages and classes at all?
>>> 
>>>  b. Since Epicea can track package and class authors, can we trigger
>>> the author prompt earlier for them?
>>> 
>>> 11. Selected all previous 

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

[Nicolai Hess]

Am 21.12.2016 8:10 vorm. schrieb "Alexandre Bergel" :

I had plenty of elements in my Roassal visualization, and on some point it
just crashed.
I have the impression that having many elements and / or animations (as in
the case of Johan Fabry) triggers the crash.



One problem, the one peter (partly) fixed, is n issue with bitblt, Cairo
(as a surface plugin) and garbage collection.
Bitblt my call the surface plugin to request some information about the
Form.
NB-based ffi for Cairo just called gen. asm code. But with UFFI, we now
callback to Smalltalk code, which may trigger a GC.
So every time bitblt, makes a call to the surface plugin (Cairo) and this
callback allocates a new ST-Object, the GC may run and moves(!)the objects,
to which bitblt still holds a reference.
Accessing this objects in bitblt, after the callback returns (may) result
in a segfault.
Depending on the concrete bltoperation, the object memory layout, the
size(!) of the initial Cairo surface.
With peters fix/hack, the code does not crash but it still may access and
operates on moved objects.
Pining the objects may help, but you need to know where in the (vm image)
code a form is used for drawing, and if it is a real form or external data
managed by the surface plugin.
And of course, when to "unpin" the object.

A saver way would be, to just disable any GC during the executing of the
callback, if it was called by a plugin (here:bitblt)



Alexandre


> On Dec 20, 2016, at 9:12 AM, Stephane Ducasse 
wrote:
>
> So what was your crash problem?
>
>
> On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel 
wrote:
> > so did it work?
> > Is there something that we should do?
>
> I had no problem, but as Henrik and Peter said, the problem is likely to
be more complex
>
> Alexandre
>
>
> >
> > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel <
alexandre.ber...@me.com> wrote:
> > Okay, trying…
> >
> > Alexandre
> >
> >
> > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel 
wrote:
> > >
> > > According to crash.dmp TRMorph>drawOn: draws an image using
FormCanvas>>#image:at:sourceRect:rule:  at a coordinate represented by a
Float point.
> > > Try to round it to integer point.
> > >
> > > Cheers,
> > > Alex
> > >
> > > On 16 December 2016 at 16:34, Alexandre Bergel <
alexandre.ber...@me.com> wrote:
> > > Hi!
> > >
> > > Vincent and I are experiencing many crashes from GrafPort>copyBits.
It crashes every couple of minutes.
> > >
> > > I know that not much can be done so far. Stability is my biggest
concern with Pharo :-(
> > > I use the latest VM.
> > >
> > > Cheers,
> > > Alexandre
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > > Alexandre Bergel  http://www.bergel.eu
> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> > >
> > >
> > >
> > >
> > > ___
> > > Moose-dev mailing list
> > > moose-...@list.inf.unibe.ch
> > > https://www.list.inf.unibe.ch/listinfo/moose-dev
> > >
> > >
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

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

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

[Alexandre Bergel]

Just to make clear, I am using the latest VM on Mac OS X, El capitan, latest 
Pharo.
The crashes I experienced are not new. My original email was not a complain 
(even if it may be perceived as one), but more to trigger a discussion. Peter 
did an excellent report of the current state of this issue. 

Cheers,
Alexandre


> On Dec 16, 2016, at 4:34 PM, Alexandre Bergel  wrote:
> 
> Hi!
> 
> Vincent and I are experiencing many crashes from GrafPort>copyBits. It 
> crashes every couple of minutes.
> 
> I know that not much can be done so far. Stability is my biggest concern with 
> Pharo :-(
> I use the latest VM.
> 
> Cheers,
> Alexandre
> 
> 
> 
> 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

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

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

[Alexandre Bergel]

I had plenty of elements in my Roassal visualization, and on some point it just 
crashed.
I have the impression that having many elements and / or animations (as in the 
case of Johan Fabry) triggers the crash.

Alexandre


> On Dec 20, 2016, at 9:12 AM, Stephane Ducasse  wrote:
> 
> So what was your crash problem?
> 
> 
> On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel  
> wrote:
> > so did it work?
> > Is there something that we should do?
> 
> I had no problem, but as Henrik and Peter said, the problem is likely to be 
> more complex
> 
> Alexandre
> 
> 
> >
> > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel  
> > wrote:
> > Okay, trying…
> >
> > Alexandre
> >
> >
> > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel  wrote:
> > >
> > > According to crash.dmp TRMorph>drawOn: draws an image using 
> > > FormCanvas>>#image:at:sourceRect:rule:  at a coordinate represented by a 
> > > Float point.
> > > Try to round it to integer point.
> > >
> > > Cheers,
> > > Alex
> > >
> > > On 16 December 2016 at 16:34, Alexandre Bergel  
> > > wrote:
> > > Hi!
> > >
> > > Vincent and I are experiencing many crashes from GrafPort>copyBits. It 
> > > crashes every couple of minutes.
> > >
> > > I know that not much can be done so far. Stability is my biggest concern 
> > > with Pharo :-(
> > > I use the latest VM.
> > >
> > > Cheers,
> > > Alexandre
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > > Alexandre Bergel  http://www.bergel.eu
> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> > >
> > >
> > >
> > >
> > > ___
> > > Moose-dev mailing list
> > > moose-...@list.inf.unibe.ch
> > > https://www.list.inf.unibe.ch/listinfo/moose-dev
> > >
> > >
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> >
> 
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 
> 

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

Re: [Pharo-dev] Epicea user experience report

[Tudor Girba]

Hi,

I think I would prefer to not have to think about this choice at all when in 
the world menu level. The user interface from the Epicea window already allows 
me to switch between current session and all sessions, and usually the decision 
of what to look at is based on whether I find what I am looking for or not. So, 
rather then asking the user to think about it upfront, I would prefer to have 
one command that opens the Epicea window on the current session and allow the 
user to dive deeper. This would also imply that we would have only one command 
in the menu item. What do you think?

Cheers,
Doru


> On Dec 20, 2016, at 10:16 PM, stepharong  wrote:
> 
> I like the second because it associates the name with the function. 
> 
> Stef
>  
>  
> Hi all,
> 
> One point of Ben's feedback is how Epicea code changes tool is presented in 
> the World Menu. Below you can see the current state + 3 options to discuss it.
> 
> 
> 1. "Epicea" main entry > "Session Changes" + "All Changes" children [current 
> state]
> 
> 
> 
> 
> 2. Attach purpose to the name: "Epicea Code Changes"
> 
> 
> 
> 
> 3. Just "Code Changes" + rephrase children:
> 
> ​
> ​
> 
> 4. Flatten
> 
> 
> ​
> 
> 
> Reminder: In World Menu > Help > Help Browser > Epicea you can find a 
> description of the tool and it's model.
> 
> Cheers.
> Martin
> 
> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias  wrote:
> Hello Ben,
> 
> About discussion points in 2 (a, b and c): I agree with your arguments... 
> somebody that just moved from Pharo 5 to 6 and crashed an image will look for 
> a "Recover lost changes" in the menu and can have a problem to discover it 
> the replacement in a World->Tools->Epicea->... entry.
> 
> Then, as a first step we could flatten the 2 menu entries and then at least 
> anybody will easily find an entry related to changes in World->Tools. 
> 
> Second, we could try to merge both Epicea GUIs into one (suggestions are 
> welcome).
> 
> I still have to read more in detail the remaining of your report to answer. 
> Anyway, thanks a lot for it.
> 
> Cheers,
> Martin
> 
> 
> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman  wrote:
> 1. Created fresh Pharo image (build 60269)
> 
> 
> 2. Opened World > Tools > Epicea > All changes
> 
> Points for discussion...
> 
>   a. How many submenu items are expected for Epicea? Can we push the
> current ones up so the Tools menu remains a flat menu.
> 
>   b. Do we need the two current menu items?  "Current session" is
> encompassed by "All changes"?  What expectations do people have of how
> often they'll use the former rather than the latter?
> 
>   c. When people move from Pharo 5 to Pharo 6 and in a panic want to
> "recover changes" for a crashed image, they'll be looking for that
> familiar feature name, not a new app name. Could the app name be left
> out or placed in brackets "Changes (Epicea)".
> 
> btw, the interface looks really slick! nice work.
> 
> 
> 3. Opened World > System Browser.
> 
> 4. Added package AAA
> All Changes window - no dynamic change.
> On , still no change, i.e. no sessions
> #New All Changes window - not visible, no sessions.
> 
> 5. Added class AA.
> All Changes window - no dynamic change.
> On , shows new session with AAA & AA.
> 
> 5. Added method...
> AA>a
>^'something'
> Prompted for author, entered 'BenComan'
> All Changes window with session selected - dynamic update showing AA>>a.
> 
> 6. Added package BBB.
> All Changes window - no dynamic update.
> On , BBB still not visible in session.
> 
> 7. Added class A to package AAA.
> All Changes window - dynamic update showing A.
> On , BBB still not visible in session.
> 
> 8. Added class BB to package BBB.
> All Changes window - dynamic update showing BBB & BB.
> 
>   a. Package creation event seems not handled properly, being only
> pushed through when a class is created in it.
> 
>   b. Since there is a dynamic update for class and method
> modifications, could the session creation also dynamically update it
> UI.
> 
> ---
> 9. Killed the vm from command line
> $ ps -ef | grep pharo
> $ kill 29349
>Restarted Pharo image
> 
> 10. World > Tools > Epica > All changes.
> Authorship is inconsistent:
> * AAA and AA have blank author
> * AA>>a, A, BBB, B have author 'BenComan'.
> 
>  a. I understand this follows on from Author not being requested until
> the first method was defined. Did the old changes track the author of
> packages and classes at all?
> 
>  b. Since Epicea can track package and class authors, can we trigger
> the author prompt earlier for them?
> 
> 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB
> and did .
> Prompted for author. Entered 'DrWho'
> Existing All Changes window - no change
> New All Changes window - shows new session with all six changes.
> Authorship is a little inconsistent:
> * AAA and AA have author 'Unknown'.
> * AA>>a, A, BBB, B have blank author.
> 
> 12. Killed the vm 

Re: [Pharo-dev] a request to change the meaning of pragma

[Sean P. DeNigris]

Stephane Ducasse-3 wrote
> In nautilus in Pharo 60 when you use
>  
> 
>  you can get an inspector on the object returned by the
> method

Cool! Great feature :)



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/a-request-to-change-the-meaning-of-example-pragma-tp4927360p4927703.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] About Fraction and parentheses

[stepharong]

On Tue, 20 Dec 2016 09:24:57 +0100, Sven Van Caekenberghe   
wrote:



Ah, OK, sorry about the misunderstanding.


you are welcome :)
Now I do not get why there would be ((1/3))
I have to check



On 20 Dec 2016, at 09:21, Stephane Ducasse   
wrote:


I think that I know that :)
And this is why I mentioned that if you print 1/3 it prints (1/3) so  
that we can continue typing + (2/3)


On Mon, Dec 19, 2016 at 11:02 PM, Sven Van Caekenberghe   
wrote:


> On 19 Dec 2016, at 22:00, Stephane Ducasse   
wrote:

>
> Hi serge
>
> the printing should be normal because like that you are ready to type
> 1/3 + 2/3 and get 1.

No, not at all:

1/3 + 2/3

  "(7/9)"

These are all just binary messages evaluated left to right, like this:

((1/3) + 2)/3

  "(7/9)"

That is why you need the parenthesis in certain contexts.
Now adding two of them is definitively wrong.

(1/3) + (2/3)

  "1"

(The first parenthesis are not needed, btw).

> Now I do not get why you get ((1/2)) thanks for reporting it.
>
> Stef
>
> On Mon, Dec 19, 2016 at 9:08 AM, Serge Stinckwich  
 wrote:

> I have one question about Fraction.
>
> When I print a fraction like 1/2 in the Playground I obtain (1/2) and
> when I inspect I obtain ((1/2)). Why do we need all these parentheses
> ?
>
> I didn't try with a current Pharo 6.0 image, because my bandwidth is
> quite limited right now (Vietnam).
>
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>
>









--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] Epicea user experience report

[stepharong]

I like the second because it associates the name with the function.

Stef



Hi all,

One point of Ben's feedback is how Epicea code changes tool is presented  
in the World Menu. Below you can see the current state + 3 options to  
discuss it.



1. "Epicea" main entry > "Session Changes" + "All Changes" children  
[current state]





2. Attach purpose to the name: "Epicea Code Changes"




3. Just "Code Changes" + rephrase children:

​
​

4. Flatten


​


Reminder: In World Menu > Help > Help Browser > Epicea you can find a  
description of the tool and it's model.


Cheers.
Martin

On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias   
wrote:

Hello Ben,

About discussion points in 2 (a, b and c): I agree with your  
arguments... somebody that just moved from Pharo 5 to 6 and crashed an  
image will look for a "Recover lost changes" in the menu >>and can have  
a problem to discover it the replacement in a World->Tools->Epicea->...  
entry.


Then, as a first step we could flatten the 2 menu entries and then at  
least anybody will easily find an entry related to changes in  
World->Tools.
Second, we could try to merge both Epicea GUIs into one (suggestions  
are welcome).


I still have to read more in detail the remaining of your report to  
answer. Anyway, thanks a lot for it.


Cheers,
Martin


On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman  wrote:

1. Created fresh Pharo image (build 60269)


2. Opened World > Tools > Epicea > All changes

Points for discussion...

 a. How many submenu items are expected for Epicea? Can we push the
current ones up so the Tools menu remains a flat menu.

 b. Do we need the two current menu items?  "Current session" is
encompassed by "All changes"?  What expectations do people have of how
often they'll use the former rather than the latter?

 c. When people move from Pharo 5 to Pharo 6 and in a panic want to
"recover changes" for a crashed image, they'll be looking for that
familiar feature name, not a new app name. Could the app name be left
out or placed in brackets "Changes (Epicea)".

btw, the interface looks really slick! nice work.


3. Opened World > System Browser.

4. Added package AAA
All Changes window - no dynamic change.
On , still no change, i.e. no sessions
#New All Changes window - not visible, no sessions.

5. Added class AA.
All Changes window - no dynamic change.
On , shows new session with AAA & AA.

5. Added method...
   AA>a
  ^'something'
Prompted for author, entered 'BenComan'
All Changes window with session selected - dynamic update showing  
AA>>a.


6. Added package BBB.
All Changes window - no dynamic update.
On , BBB still not visible in session.

7. Added class A to package AAA.
All Changes window - dynamic update showing A.
On , BBB still not visible in session.

8. Added class BB to package BBB.
All Changes window - dynamic update showing BBB & BB.

 a. Package creation event seems not handled properly, being only
pushed through when a class is created in it.

 b. Since there is a dynamic update for class and method
modifications, could the session creation also dynamically update it
UI.

---
9. Killed the vm from command line
   $ ps -ef | grep pharo
   $ kill 29349
  Restarted Pharo image

10. World > Tools > Epica > All changes.
Authorship is inconsistent:
* AAA and AA have blank author
* AA>>a, A, BBB, B have author 'BenComan'.

a. I understand this follows on from Author not being requested until
the first method was defined. Did the old changes track the author of
packages and classes at all?

b. Since Epicea can track package and class authors, can we trigger
the author prompt earlier for them?

11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB
and did .
Prompted for author. Entered 'DrWho'
Existing All Changes window - no change
New All Changes window - shows new session with all six changes.
Authorship is a little inconsistent:
* AAA and AA have author 'Unknown'.
* AA>>a, A, BBB, B have blank author.

12. Killed the vm from command line
   $ ps -ef | grep pharo
   $ kill 30696
  Restarted Pharo image

13. World > Tools > Epica > All changes.
Authorship is a little inconsistent:
First session
* AAA and AA have blank author
* AA>>a, A, BBB, B have author 'BenComan'.
Second session
* AAA and AA have blank author
* AA>>a, A, BBB, B have author 'DrWho'.

a. Epicea changes are reapplied as the current author.  This seems a
semantic change from Pharo 5 where changes were reapplied as their
original author. Is this accidental or by design?  Can we have some
community discussion on this point (I don't remember seeing any)?

cheers -ben

P.S. I'll wait to see what arises out of discussion before creating  
any issues.










--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] Epicea user experience report

[Sean P. DeNigris]

Marcus Denker-4 wrote
>> 3. Just "Code Changes" + rephrase children:
> I like that most. It is the easiest to understand for newcomers.

+1



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Epicea-user-experience-report-tp4920653p4927604.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] all black pharo 6.0 window on startup - unresponsive

[Dale Henrichs]

#60332 is indeed working, thanks again!


On 12/20/2016 10:19 AM, Dale Henrichs wrote:

Thanks Marcus, I will download and try again...


On 12/20/2016 10:17 AM, Marcus Denker wrote:

Hi,

This happend for 60330, but we have reverted and it should be working
now again (e.g. with 60332)

On 20 Dec 2016, at 15:09, Dale Henrichs 
 wrote:


Running Ubuntu 14.04 and a fresh download (as of yesterday) when 
pharo comes up I get an unresponsive and all black window -- I have 
to kill the process.


I have an older download of pharo6.0 that works fine ...

Both vms are the same version:

5.0 #1 Tue Jun 21 12:37:33 CEST 2016 gcc 4.6.3 [Production Spur ITHB 
VM]
CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 
16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016
StackToRegisterMappingCogit 
VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 
16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016
https://github.com/pharo-project/pharo-vm.git Commit: 
9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 
+0200 By: GitHub  Jenkins build #594
Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 
16:39:45 UTC 2012 i686 i686 i386 GNU/Linux
plugin path: 
/export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/ 
[default: 
/export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/]


.. so there must be something wrong in the image itself ...

The image that works is: Latest update: #60265

Not sure how to find out what update I am using, since the GUI isn't 
functional.


Dale

Re: [Pharo-dev] all black pharo 6.0 window on startup - unresponsive

[Dale Henrichs]

Thanks Marcus, I will download and try again...


On 12/20/2016 10:17 AM, Marcus Denker wrote:

Hi,

This happend for 60330, but we have reverted and it should be working
now again (e.g. with 60332)


On 20 Dec 2016, at 15:09, Dale Henrichs  
wrote:

Running Ubuntu 14.04 and a fresh download (as of yesterday) when pharo comes up 
I get an unresponsive and all black window -- I have to kill the process.

I have an older download of pharo6.0 that works fine ...

Both vms are the same version:

5.0 #1 Tue Jun 21 12:37:33 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM]
CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 
16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016
StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 
16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016
https://github.com/pharo-project/pharo-vm.git Commit: 
9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 +0200 By: GitHub 
 Jenkins build #594
Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 
2012 i686 i686 i386 GNU/Linux
plugin path: 
/export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/ [default: 
/export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/]

.. so there must be something wrong in the image itself ...

The image that works is: Latest update: #60265

Not sure how to find out what update I am using, since the GUI isn't functional.

Dale

Re: [Pharo-dev] all black pharo 6.0 window on startup - unresponsive

[Marcus Denker]

Hi,

This happend for 60330, but we have reverted and it should be working
now again (e.g. with 60332)

> On 20 Dec 2016, at 15:09, Dale Henrichs  
> wrote:
> 
> Running Ubuntu 14.04 and a fresh download (as of yesterday) when pharo comes 
> up I get an unresponsive and all black window -- I have to kill the process.
> 
> I have an older download of pharo6.0 that works fine ...
> 
> Both vms are the same version:
> 
> 5.0 #1 Tue Jun 21 12:37:33 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM]
> CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 
> 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016
> StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 
> 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016
> https://github.com/pharo-project/pharo-vm.git Commit: 
> 9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 +0200 By: 
> GitHub  Jenkins build #594
> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 
> 2012 i686 i686 i386 GNU/Linux
> plugin path: 
> /export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/ 
> [default: 
> /export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/]
> 
> .. so there must be something wrong in the image itself ...
> 
> The image that works is: Latest update: #60265
> 
> Not sure how to find out what update I am using, since the GUI isn't 
> functional.
> 
> Dale
> 
> 

[Pharo-dev] all black pharo 6.0 window on startup - unresponsive

[Dale Henrichs]

Running Ubuntu 14.04 and a fresh download (as of yesterday) when pharo 
comes up I get an unresponsive and all black window -- I have to kill 
the process.


I have an older download of pharo6.0 that works fine ...

Both vms are the same version:

5.0 #1 Tue Jun 21 12:37:33 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM]
CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 
16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016
StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 
uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016
https://github.com/pharo-project/pharo-vm.git Commit: 
9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 +0200 
By: GitHub  Jenkins build #594
Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 
UTC 2012 i686 i686 i386 GNU/Linux
plugin path: 
/export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/ 
[default: 
/export/foos1/users/dhenrich/dev/_home/dev/clients/pharo60/pharo-vm/]


.. so there must be something wrong in the image itself ...

The image that works is: Latest update: #60265

Not sure how to find out what update I am using, since the GUI isn't 
functional.


Dale

Re: [Pharo-dev] Epicea user experience report

[Marcus Denker]

> 
> 
> 3. Just "Code Changes" + rephrase children:
> 
> ​
> ​
> 

I like that most. It is the easiest to understand for newcomers.

Marcus

Re: [Pharo-dev] Epicea user experience report

[Martin Dias]

Hi all,

One point of Ben's feedback is how Epicea code changes tool is presented in
the World Menu. Below you can see the current state + 3 options to discuss
it.


1. "Epicea" main entry > "Session Changes" + "All Changes" children
[current state]



2. Attach purpose to the name: "Epicea Code Changes"




3. Just "Code Changes" + rephrase children:

​
​

4. Flatten


​


Reminder: In World Menu > Help > Help Browser > Epicea you can find a
description of the tool and it's model.

Cheers.
Martin

On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias  wrote:

> Hello Ben,
>
> About discussion points in 2 (a, b and c): I agree with your arguments...
> somebody that just moved from Pharo 5 to 6 and crashed an image will look
> for a "Recover lost changes" in the menu and can have a problem to discover
> it the replacement in a World->Tools->Epicea->... entry.
>
> Then, as a first step we could flatten the 2 menu entries and then at
> least anybody will easily find an entry related to changes in World->Tools.
>
> Second, we could try to merge both Epicea GUIs into one (suggestions are
> welcome).
>
> I still have to read more in detail the remaining of your report to
> answer. Anyway, thanks a lot for it.
>
> Cheers,
> Martin
>
>
> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman  wrote:
>
>> 1. Created fresh Pharo image (build 60269)
>>
>>
>> 2. Opened World > Tools > Epicea > All changes
>>
>> Points for discussion...
>>
>>   a. How many submenu items are expected for Epicea? Can we push the
>> current ones up so the Tools menu remains a flat menu.
>>
>>   b. Do we need the two current menu items?  "Current session" is
>> encompassed by "All changes"?  What expectations do people have of how
>> often they'll use the former rather than the latter?
>>
>>   c. When people move from Pharo 5 to Pharo 6 and in a panic want to
>> "recover changes" for a crashed image, they'll be looking for that
>> familiar feature name, not a new app name. Could the app name be left
>> out or placed in brackets "Changes (Epicea)".
>>
>> btw, the interface looks really slick! nice work.
>>
>>
>> 3. Opened World > System Browser.
>>
>> 4. Added package AAA
>> All Changes window - no dynamic change.
>> On , still no change, i.e. no sessions
>> #New All Changes window - not visible, no sessions.
>>
>> 5. Added class AA.
>> All Changes window - no dynamic change.
>> On , shows new session with AAA & AA.
>>
>> 5. Added method...
>> AA>a
>>^'something'
>> Prompted for author, entered 'BenComan'
>> All Changes window with session selected - dynamic update showing AA>>a.
>>
>> 6. Added package BBB.
>> All Changes window - no dynamic update.
>> On , BBB still not visible in session.
>>
>> 7. Added class A to package AAA.
>> All Changes window - dynamic update showing A.
>> On , BBB still not visible in session.
>>
>> 8. Added class BB to package BBB.
>> All Changes window - dynamic update showing BBB & BB.
>>
>>   a. Package creation event seems not handled properly, being only
>> pushed through when a class is created in it.
>>
>>   b. Since there is a dynamic update for class and method
>> modifications, could the session creation also dynamically update it
>> UI.
>>
>> ---
>> 9. Killed the vm from command line
>> $ ps -ef | grep pharo
>> $ kill 29349
>>Restarted Pharo image
>>
>> 10. World > Tools > Epica > All changes.
>> Authorship is inconsistent:
>> * AAA and AA have blank author
>> * AA>>a, A, BBB, B have author 'BenComan'.
>>
>>  a. I understand this follows on from Author not being requested until
>> the first method was defined. Did the old changes track the author of
>> packages and classes at all?
>>
>>  b. Since Epicea can track package and class authors, can we trigger
>> the author prompt earlier for them?
>>
>> 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB
>> and did .
>> Prompted for author. Entered 'DrWho'
>> Existing All Changes window - no change
>> New All Changes window - shows new session with all six changes.
>> Authorship is a little inconsistent:
>> * AAA and AA have author 'Unknown'.
>> * AA>>a, A, BBB, B have blank author.
>>
>> 12. Killed the vm from command line
>> $ ps -ef | grep pharo
>> $ kill 30696
>>Restarted Pharo image
>>
>> 13. World > Tools > Epica > All changes.
>> Authorship is a little inconsistent:
>> First session
>> * AAA and AA have blank author
>> * AA>>a, A, BBB, B have author 'BenComan'.
>> Second session
>> * AAA and AA have blank author
>> * AA>>a, A, BBB, B have author 'DrWho'.
>>
>>  a. Epicea changes are reapplied as the current author.  This seems a
>> semantic change from Pharo 5 where changes were reapplied as their
>> original author. Is this accidental or by design?  Can we have some
>> community discussion on this point (I don't remember seeing any)?
>>
>> cheers -ben
>>
>> P.S. I'll wait to see what arises out of discussion before creating any
>> issues.
>>
>>
>

[Pharo-dev] [pharo-project/pharo-core] 86be50: 60332

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 86be50c96618776323023836fb3a36754b632cdd
  
https://github.com/pharo-project/pharo-core/commit/86be50c96618776323023836fb3a36754b632cdd
  Author: Jenkins Build Server 
  Date:   2016-12-20 (Tue, 20 Dec 2016)

  Changed paths:
M 
ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version427_.st
M 
Glamour-FastTable.package/GLMMorphicFTRenderer.class/instance/rendering/render_.st
M 
Glamour-Morphic-Brick.package/GLMAlertBrick.class/instance/scripting/alert_.st
M 
Glamour-Morphic-Brick.package/GLMBrickStructureTrait.class/instance/brick-structure-opening/openInBrickWindowLabeled_.st
M 
Glamour-Morphic-Brick.package/GLMBrickStructureTrait.class/instance/brick-structure-opening/window.st
M 
Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/instance/preferences/sendUsageData.st
M 
Glamour-Morphic-Widgets.package/GLMPrintPopper.class/instance/public/openFromRubric_withResult_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60331.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60332.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60331.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60332.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60332
19480 Update Glamour to version 4.27
https://pharo.fogbugz.com/f/cases/19480

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

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

[GitHub]

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

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

[Peter Uhnak]

FreeType crashes are different, and I do experience them ocassionally (unlike 
Roassal ones), but they should be discussed in another thread.

Peter


On Tue, Dec 20, 2016 at 12:46:30PM +0100, p...@highoctane.be wrote:
> Clement told me that a number of these crashes have been solved eons ago in
> the opensmalltalkvm and that we are lagging behind with the integration of
> these things.
> 
> I am a clueless n00b on what this was about, so, what is the exact status?
> I possibly face the same kind of issues in other areas and have been using
> a Windows VM with StrikeFonts to have it stable.
> 
> Phil
> 
> 
> 
> 
> On Tue, Dec 20, 2016 at 9:12 AM, Stephane Ducasse 
> wrote:
> 
> > So what was your crash problem?
> >
> >
> > On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel  > > wrote:
> >
> >> > so did it work?
> >> > Is there something that we should do?
> >>
> >> I had no problem, but as Henrik and Peter said, the problem is likely to
> >> be more complex
> >>
> >> Alexandre
> >>
> >>
> >> >
> >> > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel <
> >> alexandre.ber...@me.com> wrote:
> >> > Okay, trying…
> >> >
> >> > Alexandre
> >> >
> >> >
> >> > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel 
> >> wrote:
> >> > >
> >> > > According to crash.dmp TRMorph>drawOn: draws an image using
> >> FormCanvas>>#image:at:sourceRect:rule:  at a coordinate represented by a
> >> Float point.
> >> > > Try to round it to integer point.
> >> > >
> >> > > Cheers,
> >> > > Alex
> >> > >
> >> > > On 16 December 2016 at 16:34, Alexandre Bergel <
> >> alexandre.ber...@me.com> wrote:
> >> > > Hi!
> >> > >
> >> > > Vincent and I are experiencing many crashes from GrafPort>copyBits.
> >> It crashes every couple of minutes.
> >> > >
> >> > > I know that not much can be done so far. Stability is my biggest
> >> concern with Pharo :-(
> >> > > I use the latest VM.
> >> > >
> >> > > Cheers,
> >> > > Alexandre
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> >> > > Alexandre Bergel  http://www.bergel.eu
> >> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > ___
> >> > > Moose-dev mailing list
> >> > > moose-...@list.inf.unibe.ch
> >> > > https://www.list.inf.unibe.ch/listinfo/moose-dev
> >> > >
> >> > >
> >> >
> >> > --
> >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> >> > Alexandre Bergel  http://www.bergel.eu
> >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >> --
> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> >> Alexandre Bergel  http://www.bergel.eu
> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >>
> >>
> >>
> >>
> >>
> >

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

[p...@highoctane.be]

Clement told me that a number of these crashes have been solved eons ago in
the opensmalltalkvm and that we are lagging behind with the integration of
these things.

I am a clueless n00b on what this was about, so, what is the exact status?
I possibly face the same kind of issues in other areas and have been using
a Windows VM with StrikeFonts to have it stable.

Phil




On Tue, Dec 20, 2016 at 9:12 AM, Stephane Ducasse 
wrote:

> So what was your crash problem?
>
>
> On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel  > wrote:
>
>> > so did it work?
>> > Is there something that we should do?
>>
>> I had no problem, but as Henrik and Peter said, the problem is likely to
>> be more complex
>>
>> Alexandre
>>
>>
>> >
>> > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel <
>> alexandre.ber...@me.com> wrote:
>> > Okay, trying…
>> >
>> > Alexandre
>> >
>> >
>> > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel 
>> wrote:
>> > >
>> > > According to crash.dmp TRMorph>drawOn: draws an image using
>> FormCanvas>>#image:at:sourceRect:rule:  at a coordinate represented by a
>> Float point.
>> > > Try to round it to integer point.
>> > >
>> > > Cheers,
>> > > Alex
>> > >
>> > > On 16 December 2016 at 16:34, Alexandre Bergel <
>> alexandre.ber...@me.com> wrote:
>> > > Hi!
>> > >
>> > > Vincent and I are experiencing many crashes from GrafPort>copyBits.
>> It crashes every couple of minutes.
>> > >
>> > > I know that not much can be done so far. Stability is my biggest
>> concern with Pharo :-(
>> > > I use the latest VM.
>> > >
>> > > Cheers,
>> > > Alexandre
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> > > Alexandre Bergel  http://www.bergel.eu
>> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> > >
>> > >
>> > >
>> > >
>> > > ___
>> > > Moose-dev mailing list
>> > > moose-...@list.inf.unibe.ch
>> > > https://www.list.inf.unibe.ch/listinfo/moose-dev
>> > >
>> > >
>> >
>> > --
>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> > Alexandre Bergel  http://www.bergel.eu
>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> >
>> >
>> >
>> >
>> >
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>

[Pharo-dev] [pharo-project/pharo-core] 37f27a: 60331

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 37f27a06b50b8c74abc810d24e3cf9d838dbc413
  
https://github.com/pharo-project/pharo-core/commit/37f27a06b50b8c74abc810d24e3cf9d838dbc413
  Author: Jenkins Build Server 
  Date:   2016-12-20 (Tue, 20 Dec 2016)

  Changed paths:
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60330.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60331.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60330.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60331.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60331
18735 DNU on suggestions shortcut in GTDebugger
https://pharo.fogbugz.com/f/cases/18735

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

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

[GitHub]

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

Re: [Pharo-dev] About Fraction and parentheses

[Sven Van Caekenberghe]

Ah, OK, sorry about the misunderstanding.

> On 20 Dec 2016, at 09:21, Stephane Ducasse  wrote:
> 
> I think that I know that :)
> And this is why I mentioned that if you print 1/3 it prints (1/3) so that we 
> can continue typing + (2/3)
> 
> On Mon, Dec 19, 2016 at 11:02 PM, Sven Van Caekenberghe  wrote:
> 
> > On 19 Dec 2016, at 22:00, Stephane Ducasse  wrote:
> >
> > Hi serge
> >
> > the printing should be normal because like that you are ready to type
> > 1/3 + 2/3 and get 1.
> 
> No, not at all:
> 
> 1/3 + 2/3
> 
>   "(7/9)"
> 
> These are all just binary messages evaluated left to right, like this:
> 
> ((1/3) + 2)/3
> 
>   "(7/9)"
> 
> That is why you need the parenthesis in certain contexts.
> Now adding two of them is definitively wrong.
> 
> (1/3) + (2/3)
> 
>   "1"
> 
> (The first parenthesis are not needed, btw).
> 
> > Now I do not get why you get ((1/2)) thanks for reporting it.
> >
> > Stef
> >
> > On Mon, Dec 19, 2016 at 9:08 AM, Serge Stinckwich 
> >  wrote:
> > I have one question about Fraction.
> >
> > When I print a fraction like 1/2 in the Playground I obtain (1/2) and
> > when I inspect I obtain ((1/2)). Why do we need all these parentheses
> > ?
> >
> > I didn't try with a current Pharo 6.0 image, because my bandwidth is
> > quite limited right now (Vietnam).
> >
> > --
> > Serge Stinckwich
> > UCBN & UMI UMMISCO 209 (IRD/UPMC)
> > Every DSL ends up being Smalltalk
> > http://www.doesnotunderstand.org/
> >
> >
> 
> 
> 

Re: [Pharo-dev] About Fraction and parentheses

[Stephane Ducasse]

I think that I know that :)
And this is why I mentioned that if you print 1/3 it prints (1/3) so that
we can continue typing + (2/3)

On Mon, Dec 19, 2016 at 11:02 PM, Sven Van Caekenberghe 
wrote:

>
> > On 19 Dec 2016, at 22:00, Stephane Ducasse 
> wrote:
> >
> > Hi serge
> >
> > the printing should be normal because like that you are ready to type
> > 1/3 + 2/3 and get 1.
>
> No, not at all:
>
> 1/3 + 2/3
>
>   "(7/9)"
>
> These are all just binary messages evaluated left to right, like this:
>
> ((1/3) + 2)/3
>
>   "(7/9)"
>
> That is why you need the parenthesis in certain contexts.
> Now adding two of them is definitively wrong.
>
> (1/3) + (2/3)
>
>   "1"
>
> (The first parenthesis are not needed, btw).
>
> > Now I do not get why you get ((1/2)) thanks for reporting it.
> >
> > Stef
> >
> > On Mon, Dec 19, 2016 at 9:08 AM, Serge Stinckwich <
> serge.stinckw...@gmail.com> wrote:
> > I have one question about Fraction.
> >
> > When I print a fraction like 1/2 in the Playground I obtain (1/2) and
> > when I inspect I obtain ((1/2)). Why do we need all these parentheses
> > ?
> >
> > I didn't try with a current Pharo 6.0 image, because my bandwidth is
> > quite limited right now (Vietnam).
> >
> > --
> > Serge Stinckwich
> > UCBN & UMI UMMISCO 209 (IRD/UPMC)
> > Every DSL ends up being Smalltalk
> > http://www.doesnotunderstand.org/
> >
> >
>
>
>

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

[Stephane Ducasse]

So what was your crash problem?


On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel 
wrote:

> > so did it work?
> > Is there something that we should do?
>
> I had no problem, but as Henrik and Peter said, the problem is likely to
> be more complex
>
> Alexandre
>
>
> >
> > On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel <
> alexandre.ber...@me.com> wrote:
> > Okay, trying…
> >
> > Alexandre
> >
> >
> > > On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel 
> wrote:
> > >
> > > According to crash.dmp TRMorph>drawOn: draws an image using
> FormCanvas>>#image:at:sourceRect:rule:  at a coordinate represented by a
> Float point.
> > > Try to round it to integer point.
> > >
> > > Cheers,
> > > Alex
> > >
> > > On 16 December 2016 at 16:34, Alexandre Bergel <
> alexandre.ber...@me.com> wrote:
> > > Hi!
> > >
> > > Vincent and I are experiencing many crashes from GrafPort>copyBits. It
> crashes every couple of minutes.
> > >
> > > I know that not much can be done so far. Stability is my biggest
> concern with Pharo :-(
> > > I use the latest VM.
> > >
> > > Cheers,
> > > Alexandre
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > > Alexandre Bergel  http://www.bergel.eu
> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> > >
> > >
> > >
> > >
> > > ___
> > > Moose-dev mailing list
> > > moose-...@list.inf.unibe.ch
> > > https://www.list.inf.unibe.ch/listinfo/moose-dev
> > >
> > >
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>