[cc: Seaside and Pier mailing lists]
Postmortem, no polished code...
First tried the "space" analysis tool from the "status" application tool
of Seaside. It showed only objects with more than 100 instances, which
did not give much useful info. with my data set. I suppose I could have
changed
SystemProgressMorph show: 'Doing...' from: 0 to: 1 during: [ :bar |
1 to: 2 do: [ :x |
bar current: x.
(Delay forMilliseconds: 20) wait "Just to slow it down so we
can see what's going on" ] ].
Works while
SystemProgressMorph show: 'Doing...' from: 1 to:
I think that the definition of progress is wrong since I was not running the
JobTest.
But in addition I think that you are right, close the bars looks to me a bad
idea.
Stef
On Nov 3, 2012, at 10:12 PM, Ciprian Teodorov wrote:
> Hi Stef,
>
> I have seen this problem too, and I think that Jo
Ouch two problems!
I'm also wondering why we have
SystemProgressItemMorph and ProgressBarMorph
in addition to SystemProgressMorph
and of course JobProgressMorph and JobProgressBarMorph
to me it looks like this is ok to have
- one with the forbidden flag = JobProgressMorph
Job ProgressBar logic is bogus
here we have:
progress
^ (currentValue - min) / (max - min)
raises ZeroDivide.
and progress is invoked by basicProgress:
basicProgress: aNormalizedFloat
"Set the progress: 0.0 - 1.0 without triggering an update"
currentValue := (min + ((m
Yes apparently the code run by the test uses the progress bar (do display
progress) and at some point put its max to 1 (since there is only one
definition to process)
=> boum.
since in that case we get a zeroDivide.
Stef
On Nov 3, 2012, at 9:51 PM, Stéphane Ducasse wrote:
> I'm wondering if
I'm wondering if the progress bar code is not bogus and that it is created with
wrong values.
> Apparently there was failing test which invoked a on:fork:….
>
> This is strange since the processTest were red.
> Now running them alone brings green tests.
>
>
> Stef
> On Nov 3, 2012, at 12:53 PM
Executing this test method leads to an error
MCStReaderTest debug: #testCommentWithStyle
SmallInteger>>/
Job>>progress
JobChange>>progress
SystemProgressMorph class>>updateJob:
MessageSend>>value:
MessageSend>>cull:
MessageSend>>cull:cull:
AnnouncementSubscription>>deliver: in Block: [ac
Out of curiosity, what are some of the undeclared references?
There shouldn't be any undeclared references, unless you ignored the required
packages or ??? offhand I can't imagine what they might be...
Dale
- Original Message -
| From: "Esteban Lorenzano"
| To: Pharo-project@lists.gfor
Apparently there was failing test which invoked a on:fork:….
This is strange since the processTest were red.
Now running them alone brings green tests.
Screen Shot 2012-11-03 at 7.42.47 PM.pdf
Description: Adobe PDF document
Stef
On Nov 3, 2012, at 12:53 PM, Stéphane Ducasse wrote:
> There is
Folks:
I wish know how old a object is.
Any have code for this ?
Thanks in advance
Edgar
There is a bug blocking the image.
SubscriptOutOfBounds: 0
in the SystemProgressMorph class updateJob:
20381
-
- Issue 6916: Fix smart characters to have different behavior depending on
space presence. Thanks Stef and Anne :)
http://code.google.com/p/pharo/issues/detail?id=6916
- Issue 6675: ZnNetworkUtils is not using proxy exceptions. Thanks Santiago
and sven.
On 03 Nov 2012, at 10:19, Stéphane Ducasse wrote:
> Hi sprinters
>
> the sprint was good and we made nice progress.
> Thanks a lot.
>
> Stef
Yes, it was very nice: warm welcome, cool offices, good company.
Sven
+1
I'd be very interested in that sort of thing.
On 02.11.2012, at 19:08, Yanni Chiu wrote:
> This scenario has happened a few times... Stuff is serialized and
> de-serialized (to/from files) without problem. Code changes are made. At some
> later date, I notice that the Fuel file is orders of
Hi sprinters
the sprint was good and we made nice progress.
Thanks a lot.
Stef
16 matches
Mail list logo
