maybe it is at the seaside.gemstone.com/ss repo?
Am 2011-04-30 um 04:05 schrieb Yanni Chiu:
More data from my build cache:
~/pub/builder/cache$ ls -l */Seaside-Core-as*
... 275758 Feb 7 07:32 Seaside 3.0/Seaside-Core-as.695.mcz
... 281915 Mar 10 07:32 Seaside 3.0/Seaside-Core-as.712.mcz
What is the status of the projects hosted there?
Do they got synched from squeaksource?
Stefs
maybe it is at the seaside.gemstone.com/ss repo?
Am 2011-04-30 um 04:05 schrieb Yanni Chiu:
More data from my build cache:
~/pub/builder/cache$ ls -l */Seaside-Core-as*
... 275758 Feb 7 07:32
On Apr 30, 2011, at 4:21 AM, Yanni Chiu wrote:
Can the equivalent builds based on Pharo 1.3 be created?
Yes, it's on the TODO list...
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
Mariano
let it like it is.
we did it because windows is not the same as the other one and got in our
way
so either we remove windows or we let it like that. the three others are nicely
grouped.
Stef
On Apr 30, 2011, at 12:40 AM, Mariano Martinez Peck wrote:
Right now, there is a special
I vote for removing. The only thing that is remotely useful is close all
debuggers, but that would work better under the System menu together with
enable halt inspect once.
Cheers,
Doru
On 30 Apr 2011, at 09:08, Stéphane Ducasse wrote:
Mariano
let it like it is.
we did it because windows
13177
-
Issue 4127: little bit faster traitNames, allTraitsDo:, allClassesDo:,
allClassesAndTraitsDo:
Issue 4126: Speeding up HelpBrowser by 50%
Issue 4115: Deprecate IdentityGlyphMap and HostFont
Issue 4098: Fileout - choose another name cancel crashs
--
Marcus Denker --
+1
On Apr 30, 2011, at 10:40 AM, Tudor Girba wrote:
I vote for removing. The only thing that is remotely useful is close all
debuggers, but that would work better under the System menu together with
enable halt inspect once.
Cheers,
Doru
On 30 Apr 2011, at 09:08, Stéphane Ducasse
On Sat, Apr 30, 2011 at 9:08 AM, Stéphane Ducasse stephane.duca...@inria.fr
wrote:
Mariano
let it like it is.
we did it because windows is not the same as the other one and got in our
way
so either we remove windows or we let it like that. the three others are
nicely grouped.
Cool! Thanks Alexandre. Now...the problem with the cache is always the
same...when to invalidate them.
In this case, when do I need to set helpTopicCache to nil. I guess that if
you create a help, then it is automatically detected when you open the
browser.
Now, you have to explicitly flush the
On Sat, Apr 30, 2011 at 2:14 AM, Torsten Bergmann asta...@gmx.de wrote:
This is because the help book Pharo includes an API
reference for the WHOLE system (starting from ProtoObject
all subclasses down) and converts all class comments
in the system into help text. Accessing sources is slow...
Cool! It seems we have too much information about announcements hehhehe
1) http://dougedmunds.com/pmwiki.php?n=Pharo.AnnouncementsTutorial
2) The Help System chapter - just take your image, world menu - Help -
Help Browser - Announcements framework
3) Pharo collabortive book chapter:
You're right Mariano. However, I do not know if the help browser gets updated
if you have a browser opened and add a new help in the system. In any case,
this is a requirement that is not formalized by the unit tests.
I think that ideally, the reset cache should be done when receiving an event
Yes, but I have no idea. Another thing is that now HelpBrowser should
implement something like:
HelpBrowser cleanUp
self resetChache
resetCache
helpTopicCache := nil
So that the class is automatically cleaned in #cleanUpForRelease and
friends... right now since Smalltalk cleanUp sends to all
Yes, but this depends what is the expected behavior of the browser. I like the
Agile approach that says you're done when all the tests are green :-)
Alexandre
On 30 Apr 2011, at 10:02, Mariano Martinez Peck wrote:
Yes, but I have no idea. Another thing is that now HelpBrowser should
Excellent!
We should see how to integrate this into PBE
Alexandre
On 29 Apr 2011, at 21:57, DougEdmunds wrote:
http://dougedmunds.com/pmwiki.php?n=Pharo.AnnouncementsTutorial
What you can get out of this tutorial and sample code
How to use Announcements
Ideas on building a GUI
Hi guys. I always code my tests something like this:
testBlah
| universalAnswer |
universalAnswer := 30.
universalAnswer := universalAnswer + 11.
self assert: universalAnswer equals: 42.
In this case, 42 is the expected and universalAnswer is the actual
value.
I feel weird
in fact cannot the cache be class side? beucase now each time you do
HelpBrowser open, you compute again the cachebut I am not sure if they
should change amont different opened browsers
cheers
mariano
On Sat, Apr 30, 2011 at 5:07 PM, Alexandre Bergel
alexandre.ber...@me.comwrote:
Yes,
Yanni,
We have had a bit of a dance lately with packages in the Seaside30 repo and the
configuration.
I don't know the actual details, but at various points in time over the last
month those mystery packages have appeared, disappeared, reappeared, then
disappeared again and I was lucky enough
It feels backwards to me too, in the same way that one plus one equals two
feels more natural than two equals one plus one.
--
Cheers,
Peter.
On 30 apr 2011, at 16:20, Mariano Martinez Peck marianop...@gmail.com wrote:
Hi guys. I always code my tests something like this:
testBlah
|
Note that HelpBrowser has a Refresh button so it should clear the cache.
Laurent
On Sat, Apr 30, 2011 at 4:27 PM, Mariano Martinez Peck
marianop...@gmail.com wrote:
in fact cannot the cache be class side? beucase now each time you do
HelpBrowser open, you compute again the cachebut I
You are not alone on this.
On Sat, Apr 30, 2011 at 10:20 AM, Mariano Martinez Peck
marianop...@gmail.com wrote:
Hi guys. I always code my tests something like this:
testBlah
| universalAnswer |
universalAnswer := 30.
universalAnswer := universalAnswer + 11.
self assert:
Mariano, I agree, I have NEVER written
self assert: expected = actual description: 'expected should equal
this result but is not'.
That makes me think of this story:
In my company, C++ experts decided to nether write
bool isActive
...
if (isActive) { ... }
because they pretend
mariano since the API is the same I guess that we can change to get the
behavior you expect.
I'm still convinced that we should develop another testing framework because
just to be compatible
with SUnit we are bound to never change. At brest I discuss and gave a list of
features to niall
and
I am developing a time sensitive application. I poll a server every
minute for new data. The data is time sensitive and the sooner I can get
the data to the release of the data the better.
I have noticed that Pharo's system time drifts away from the OS system
time. I would really like the
On Sat, Apr 30, 2011 at 4:20 PM, Mariano Martinez Peck
marianop...@gmail.com wrote:
testBlah
| universalAnswer |
universalAnswer := 30.
universalAnswer := universalAnswer + 11.
self assert: universalAnswer equals: 42.
In this case, 42 is the expected and universalAnswer is
I am developing a time sensitive application. I poll a server every minute
for new data. The data is time sensitive and the sooner I can get the data to
the release of the data the better.
I have noticed that Pharo's system time drifts away from the OS system time.
I would really like
Thanks everybody, it is nice to see I am not alone..
Yes, Stef, the API is the same, but the sematics is not. I mean, I muuuch
prefer to change it, but indeed, there will be a change in the behavior.
What I mean is that all test cases that were using #assert:equals: in the
correct way (correct I
I use temporary value names such as expectedAnswer and actualValue.
Then I feel there's no confusion.
On 4/30/11 7:20 , Mariano Martinez Peck wrote:
Hi guys. I always code my tests something like this:
testBlah
| universalAnswer |
universalAnswer := 30.
universalAnswer :=
When the expected answer is not a literal, then the order is not so
important. Usually, complex tests have expected answers that are not
literals, and you end up with a method along the lines of
expectedAnswer := self doItOneWay.
actualAnswer := self doItTheOtherWay.
self assert:
On 4/30/2011 11:50 AM, Stéphane Ducasse wrote:
I am developing a time sensitive application. I poll a server every minute for
new data. The data is time sensitive and the sooner I can get the data to the
release of the data the better.
I have noticed that Pharo's system time drifts away from
in fact cannot the cache be class side? beucase now each time you do
HelpBrowser open, you compute again the cachebut I am not sure if they
should change amont different opened browsers
Could be. It is important to have a scenario.
The problem is getting the pragmas from the whole
'Time now' gives me the same result than OSX
Alexandre
On 30 Apr 2011, at 16:15, Jimmie Houchin wrote:
On 4/30/2011 11:50 AM, Stéphane Ducasse wrote:
I am developing a time sensitive application. I poll a server every minute
for new data. The data is time sensitive and the sooner I can get
13178
-
- Issue 4125: option to copy a stacktrace to clipboard in the debugger context
menu. Thanks Mariano Martinez-Peck.
- Issue 3952: SystemNavigation deeper use of environment. Thanks Benjamin van
Ryseghem.
- Issue 3445: [Repackage] SUnit should be well structured. Thanks Torsten
Doug, do you want a username to edit the book? I can create one for
you...just tell me.
cheers
mariano
On Thu, Apr 21, 2011 at 7:54 AM, laurent laffont
laurent.laff...@gmail.comwrote:
If someone can look at this
Laurent
-- Forwarded message --
From: Doug Edmunds
Hello,
My OS for this application is Windows. On a freshly opened image, the
image and OS time are in sync. Over a period of time the image drifted
34 seconds away from OS time. I do not know how long I had this image
open, but it has been a number of days, possibly a week plus.
I saved the
35 matches
Mail list logo
