On Wed, Dec 3, 2008 at 7:24 AM, Bill Schwab [EMAIL PROTECTED] wrote:
As Pharo 1.0 takes shape, what is the plan for getting packages loaded
the way each of us wants? Is Installer the preferred route? Would I be
expected to script it (I find myself hoping so - load the latest of
this, that,
Hi guys
This is something really interesting to me so if you dont have time, I
can take a look at it, either to the paper or the code if Romain can
put it somewhere.
David, do you have some pointers about the recent modification list in
OB?
As a newcomer, I dont know who is the
On Wed, Dec 3, 2008 at 1:07 PM, Simon Denier [EMAIL PROTECTED] wrote:
As a newcomer, I dont know who is the developper/maintainer for eCompletion.
There is no maintainer of eCompletion actually. Ruben Bakker
implemented it. I have write access to the repository if you have
something to commit.
Begin forwarded message:
From: Marcus Denker [EMAIL PROTECTED]
Date: December 3, 2008 12:30:37 PM CEST
To: Stéphane Ducasse [EMAIL PROTECTED]
Subject: Re: do you have a todo for the new compiler
On 29.11.2008, at 20:23, Stéphane Ducasse wrote:
Hi marcus
several people asked me today how
On Wed, Dec 3, 2008 at 02:19, Alexandre Bergel [EMAIL PROTECTED] wrote:
But we could imagine that the root password is necessary to open the port.
Now, the root password is necessary to give all permissions to the process,
whereas only opening once the port 80 is necessary.
I am sure a better
Damien,
SqueakMap appears to be absent from that list - I had missed that. I
just took another run at it, bypassing the one-click image, and the
package loader was happier. Update the list from the net, and it seems
to work. Shout complained about dependencies, but since it is on the
list, I
please use the issue tracker
The mail was intended for Gary to review and include the changes into the
normal PM package
(with the list as CC). He is the only one with commit rights on the SqSrc
project and pharo is
also useable from standard Squeak.
If he accepts it we just have to integrate
On Wed, Dec 3, 2008 at 2:49 PM, Alexandre Bergel [EMAIL PROTECTED] wrote:
Just to make sure that I fully understand your email. Are you suggesting the
history feature should be integrated into the Standard SUnit?
I haven't got the time to check what is in [EMAIL PROTECTED] yet. I hope
to do
So, it seems that adding an empty dispatchResultsIntoHistory in
[EMAIL PROTECTED] will prevent having two versions of OBCmdTestClass
I will do it in a minutes...
Alexandre
On 3 Dec 2008, at 10:53, Damien Cassou wrote:
On Wed, Dec 3, 2008 at 2:49 PM, Alexandre Bergel
[EMAIL PROTECTED]
David,
dont use the changeset. If you have the latest pharo image (#10185) you can use
use
ScriptManager loadSeaside29
to get the latest.
Note: before running that just remove the line in this method that installs
RSS-Squeak-Core.
This package was kicked on Monday by pmm (see [1]). An
The problem we are facing right now is that OB-Enhancements is at
the moment dependent on a particular version of SUnit, one that
contains these history enhancements. As OB-Enhancements is supposed
to work in Pharo and Squeak, we can now either update the SUnit
version in Squeak-dev to
Well, I will try to maintain things such that Polymorph is compatible with
both for now (an extra package for Squeak). If Markus can let me know the
differences I'll move the affected methods out.
As for the PasswordDialogWindow... just putting in now. Reworked to be more
in keeping with
Ok, it works with the last version.
Now, I have a problem with the method browse:
Installer ss project:'Installer'; browse: 'InstallerAll'.
The browser open on the class Loading.MCVersionLoader.
Is there any reason ?
Thanks
Jannik
Le 2 déc. 08 à 21:20, Keith Hodges a écrit :
multiply it by a factor of 100. Then you get to what the current state is in
Squeak.
You dont have to tell me. Since I know Squeak since Version 1.0 and later (see
[1]) the factor
I would apply would definitely be greater than 100 ;)
Yes. The bug-tracker is like a TODO list.
OK:
On 03.12.2008, at 15:33, Torsten Bergmann wrote:
It's not a question of compatibility, the question is where will
Polymorph be continued - in SqS/Pharo or SqS/UIEnhancements or both?
I didnt notice (until now) that the integrated plymorph packages are
now also
in the SqS/Pharo repository.
On 3 déc. 08, at 13:38, Damien Cassou wrote:
On Wed, Dec 3, 2008 at 1:07 PM, Simon Denier [EMAIL PROTECTED]
wrote:
As a newcomer, I dont know who is the developper/maintainer for
eCompletion.
There is no maintainer of eCompletion actually. Ruben Bakker
implemented it. I have write access
jannik.laval.gmail wrote:
Ok, it works with the last version.
Now, I have a problem with the method browse:
Installer ss project:'Installer'; browse: 'InstallerAll'.
The browser open on the class Loading.MCVersionLoader.
Is there any reason ?
Thanks
Jannik
The reason being that earlier
On 03.12.2008, at 15:49, Gary Chambers wrote:
Well, I will try to maintain things such that Polymorph is
compatible with both for now (an extra package for Squeak). If
Markus can let me know the differences I'll move the affected
methods out.
1) FileList2 is gone. the method
Thanks, Alex, but shouldn't it read:
ifSUnitSupportHistory: aBlock
(TestResult includesSelector: #updateResultsInHistory) ifTrue: [aBlock
value]
Because in your version aBlock never gets executed, not even when
#updateResultsInHistory exists.
Can you check?
David
The comment is:
You're right, sorry about that.
Fixed.
Alexandre
On 3 Dec 2008, at 16:59, David Röthlisberger wrote:
Thanks, Alex, but shouldn't it read:
ifSUnitSupportHistory: aBlock
(TestResult includesSelector: #updateResultsInHistory) ifTrue:
[aBlock value]
Because in your version aBlock never
Yes but when we load a package we load the package and its extensions
and in Pharo
we take care about that.
Stef
On Dec 3, 2008, at 12:02 AM, Keith Hodges wrote:
Stéphane Ducasse wrote:
It depends on what is inside MC1.5
It should not.
When you load a package you load all the extensions.
then lukas
what you wrote in the book does not describe the correct problem.
Because when I read I thought it was a problem of the Smalltalk VM
To listen on port 80, the standard port used by the HTTP protocol, the
web server needs to run as root. Running a public service as root
There will be a pharo universe I imagine.
Stef
On Dec 3, 2008, at 10:12 AM, Damien Cassou wrote:
On Wed, Dec 3, 2008 at 7:24 AM, Bill Schwab [EMAIL PROTECTED]
wrote:
As Pharo 1.0 takes shape, what is the plan for getting packages
loaded
the way each of us wants? Is Installer the preferred
The problem is that removing etoys is not a clean thing. We have
first methods
that are needed to be changed for both removing etoys *and*
polymorph. So that's
why the packages need to be in the pharo repository.
In general, if you think about code quality or modularity in the
context
Hi,
I added several new simple issues for removing few unimplemented calls:
http://code.google.com/p/pharo/issues/detail?id=373
http://code.google.com/p/pharo/issues/detail?id=374
http://code.google.com/p/pharo/issues/detail?id=375
http://code.google.com/p/pharo/issues/detail?id=376
Stéphane Ducasse wrote:
There will be a pharo universe I imagine.
Stef
please no... let the suffering end
Keith
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
Yes but when we load a package we load the package and its extensions
and in Pharo
we take care about that.
Stef
So why do you stick with a broken MC then?
Keith
___
Pharo-project mailing list
thanks pavel
We will go over the list and integrates what should be.
On Dec 3, 2008, at 10:15 PM, Pavel Krivanek wrote:
Hi,
I added several new simple issues for removing few unimplemented
calls:
http://code.google.com/p/pharo/issues/detail?id=373
I do not understand what you mean.
I think that universe = a dsitribution is a good idea.
Stef
On Dec 3, 2008, at 10:16 PM, Keith Hodges wrote:
Stéphane Ducasse wrote:
There will be a pharo universe I imagine.
Stef
please no... let the suffering end
Keith
On 03.12.2008, at 22:10, Stéphane Ducasse wrote:
The problem is that removing etoys is not a clean thing. We have
first methods
that are needed to be changed for both removing etoys *and*
polymorph. So that's
why the packages need to be in the pharo repository.
In general, if you think
Should we add an item on the tracker to remove CrLfFileStream?
-- Forwarded message --
From: Keith Hodges [EMAIL PROTECTED]
Date: Wed, Dec 3, 2008 at 8:04 AM
Subject: Re: [squeak-dev] Rio: exceptions documentation
To: The general-purpose Squeak developers list
[EMAIL PROTECTED]
2008/12/3 Stéphane Ducasse [EMAIL PROTECTED]:
I do not understand what you mean.
I think that universe = a dsitribution is a good idea.
which have no guarantees that any package in it will work in your image :)
Stef
On Dec 3, 2008, at 10:16 PM, Keith Hodges wrote:
Stéphane Ducasse wrote:
On Wed, Dec 03, 2008 at 10:24:55PM +0100, St?phane Ducasse wrote:
Because we did not have the time (and nobody took the time to look at
the code
and write a report for us on the extensions and status of MC1.5 and
MC1.6)
I'll take care of this. I am going to write up documentation and
Stéphane Ducasse wrote:
There will be a pharo universe I imagine.
Stef
please no... let the suffering end
Keith
Perhaps I should give a little more detail.
1. Searching Universes is a pain
2. Editing Universe entries is a pain
3. Editing Universe entries takes several minutes for update
refactor instance variables | accessors used to figure out which instance
variables needed to be added and give you a chance to accept or reject the
proposed list. After loading the latest updates, it now presents a list of
instance variables, letting you pick one and only one to add.
The new
We currently have both inspect and explore. It would be nice to have
one tool. I'd vote for explore as a base with some enhancements to pick
up the useful features from inspect.
-david
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
I'd vote for the Explorer too, but I'd prefer to keep the name
Inspector and the action Inspect it.
On Wed, Dec 3, 2008 at 6:32 PM, David Pennell [EMAIL PROTECTED] wrote:
We currently have both inspect and explore. It would be nice to have
one tool. I'd vote for explore as a base with some
I agree.
Just to be clear - I use both because neither does all I need. Explorer is
my default choice, but if I need to look at the innards of a String, I
launch an Inspector. It seems like it would be easy enough to fix these in
Explorer and then make that the default inspector.
I'm just
On Wed, Dec 03, 2008 at 10:26:30PM -0600, David Pennell wrote:
I agree.
Just to be clear - I use both because neither does all I need. Explorer is
my default choice, but if I need to look at the innards of a String, I
launch an Inspector. It seems like it would be easy enough to fix these in
You can modify iVars in Explorer, but it doesn't update the display.
On Wed, Dec 3, 2008 at 11:22 PM, Matthew Fulmer [EMAIL PROTECTED] wrote:
On Wed, Dec 03, 2008 at 10:26:30PM -0600, David Pennell wrote:
I agree.
Just to be clear - I use both because neither does all I need. Explorer
is
40 matches
Mail list logo
