date:20100627


Fix attached.

Hope this helps!


-
Benoit St-Jean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)







From: laurent.laff...@gmail.com
Date: Sun, 27 Jun 2010 08:33:52 +0200
To: pharo-project@lists.gforge.inria.fr
Subject: [Pharo-project] SystemNavigation#allSendersOf: vs  
SystemNavigation#allReferencesTo:

Hi,
in Autotest I search for all senders of a method. The first version used 
SystemNavigation#allSendersOf: which sometimes returns wrong results (I think). 
For example:
senders := (SystemNavigation default allSendersOf: #methodsFor:).

senders size.  answers 18senders collect: [:aReference| aReference 
compiledMethod].
debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class side 
but allSendersOf: returns #scanCategory reference on class side and instance 
side).


With #allReferencesTo:
senders := (SystemNavigation default allReferencesTo: #methodsFor:).senders 
size.  answers 16


Is this a bug in #allSendersOf: or I don't understand ? 
Cheers,Laurent Laffont

http://pharocasts.blogspot.com/


http://magaloma.blogspot.com/

  
_
Learn more ways to connect with your buddies now
http://go.microsoft.com/?linkid=9734388

SystemNavigation-addSelectorsReferingTointospecialbyte.st
Description: Binary data
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo:

On Sun, Jun 27, 2010 at 10:01 AM, Benoit St-Jean bstj...@hotmail.ca wrote:

  Fix attached.

 Hope this helps!



Thank you.  http://code.google.com/p/pharo/issues/detail?id=2593

http://code.google.com/p/pharo/issues/detail?id=2593Laurent


-
 Benoit St-Jean
 A standpoint is an intellectual horizon of radius zero.
 (Albert Einstein)




 --
 From: laurent.laff...@gmail.com
 Date: Sun, 27 Jun 2010 08:33:52 +0200
 To: pharo-project@lists.gforge.inria.fr
 Subject: [Pharo-project] SystemNavigation#allSendersOf: vs
 SystemNavigation#allReferencesTo:

 Hi,

 in Autotest I search for all senders of a method. The first version
 used SystemNavigation#allSendersOf: which sometimes returns wrong results (I
 think). For example:

 senders := (SystemNavigation default allSendersOf: #methodsFor:).
 senders size.  answers 18
 senders collect: [:aReference| aReference compiledMethod].

 debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class
 side but allSendersOf: returns #scanCategory reference on class side and
 instance side).

 With #allReferencesTo:

 senders := (SystemNavigation default allReferencesTo: #methodsFor:).
 senders size.  answers 16

 Is this a bug in #allSendersOf: or I don't understand ?

 Cheers,

 Laurent Laffont

 http://pharocasts.blogspot.com/
 http://magaloma.blogspot.com/

 --
 Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now!
 http://go.microsoft.com/?linkid=9734383

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo:

http://code.google.com/p/pharo/issues/detail?id=2592
:)


On Jun 27, 2010, at 10:16 AM, laurent laffont wrote:

 On Sun, Jun 27, 2010 at 10:01 AM, Benoit St-Jean bstj...@hotmail.ca wrote:
 Fix attached.
 
 Hope this helps!
 
 
 Thank you.  http://code.google.com/p/pharo/issues/detail?id=2593
 
 Laurent
 
 
 -
 Benoit St-Jean
 A standpoint is an intellectual horizon of radius zero.
 (Albert Einstein)
 
 
 
 
 From: laurent.laff...@gmail.com
 Date: Sun, 27 Jun 2010 08:33:52 +0200
 To: pharo-project@lists.gforge.inria.fr
 Subject: [Pharo-project] SystemNavigation#allSendersOf: vs
 SystemNavigation#allReferencesTo:
 
 Hi,
 
 in Autotest I search for all senders of a method. The first version used 
 SystemNavigation#allSendersOf: which sometimes returns wrong results (I 
 think). For example:
 
 senders := (SystemNavigation default allSendersOf: #methodsFor:).
 senders size.  answers 18
 senders collect: [:aReference| aReference compiledMethod].
 
 debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class 
 side but allSendersOf: returns #scanCategory reference on class side and 
 instance side).
 
 With #allReferencesTo:
 
 senders := (SystemNavigation default allReferencesTo: #methodsFor:).
 senders size.  answers 16
 
 Is this a bug in #allSendersOf: or I don't understand ? 
 
 Cheers,
 
 Laurent Laffont
 
 http://pharocasts.blogspot.com/
 http://magaloma.blogspot.com/
 
 Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now!
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo:

Thanks.
SystemNavigation is the result of a merge between behavior defined in browser 
and systemdictionary
so having a nice pass over it would be great.

http://code.google.com/p/pharo/issues/detail?id=2592

Stef

On Jun 27, 2010, at 10:01 AM, Benoit St-Jean wrote:

 Fix attached.
 
 Hope this helps!

Sure it does
Benoit did you sign the license agreement?

Stef

 
 
 -
 Benoit St-Jean
 A standpoint is an intellectual horizon of radius zero.
 (Albert Einstein)
 
 
 
 
 From: laurent.laff...@gmail.com
 Date: Sun, 27 Jun 2010 08:33:52 +0200
 To: pharo-project@lists.gforge.inria.fr
 Subject: [Pharo-project] SystemNavigation#allSendersOf: vs
 SystemNavigation#allReferencesTo:
 
 Hi,
 
 in Autotest I search for all senders of a method. The first version used 
 SystemNavigation#allSendersOf: which sometimes returns wrong results (I 
 think). For example:
 
 senders := (SystemNavigation default allSendersOf: #methodsFor:).
 senders size.  answers 18
 senders collect: [:aReference| aReference compiledMethod].
 
 debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class 
 side but allSendersOf: returns #scanCategory reference on class side and 
 instance side).
 
 With #allReferencesTo:
 
 senders := (SystemNavigation default allReferencesTo: #methodsFor:).
 senders size.  answers 16
 
 Is this a bug in #allSendersOf: or I don't understand ? 
 
 Cheers,
 
 Laurent Laffont
 
 http://pharocasts.blogspot.com/
 http://magaloma.blogspot.com/
 
 Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now! 
 SystemNavigation-addSelectorsReferingTointospecialbyte.st___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] 1.2 vision

Hi all

Of course we will integrate changes and changes and improvements now I 
believe that it would be nice to build a common
vision. Here what I would like to get in 1.2.

Now it does not mean that this is a definitive list and that we will have the 
energy to do all but like
that you know that you can put energy do build this common vision :)

- better infrastructure for integrating rb composite queries into the 
system 
The idea is to introduce a superclass on top of 
systemDictionary and to define there an API that 
is compatible with the one of RB (and potentially modified the 
one of RB)

- another step towards using announcement for system notification

- better tools for dev

- have a look at the RB change model so that we could get a real undo 
and changes

- clean Monticello so that package logic stays in package so that we 
can plug RPackage into the system.
Right now this looks too brittle to do anything

- make sure that we can have RPackage on the side of PakageInfo (we got 
really nice benchmark)

- New Compiler in beta

- Helvetia hooks

- ROME API

- Sophie Event Hierarchy

- Define some architectural action to get the system more modular

- Hudson infrastructure

- metacello to manage core

- metacelloRepository for 1.0/1.1/1.2
Gofer

- squeak collection optimisation?

- Alien

Open points:

- What do we do with ToolBuilder? Not clear to me.

- What should be done at the level of polymorph?
- What should be done a the level of Pluggable 
can we use the fact that we have now block closure to 
get it better.

As you guess it will not come simply but this is important that we all head 
towards a common understanding


Stef




___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Vm-dev] Re: [squeak-dev] OSCog updated

2010-06-27 Thread Andrey Larionov

Maybe this is network related issue?

On Sun, Jun 27, 2010 at 09:48, Lukas Renggli reng...@gmail.com wrote:
 Sometimes it survives 30 requests, sometimes it crashes
 right after the first request. In the console I get:

  nanosleep: Invalid argument
  Exited with exit code: 1

 How can I further debug this? I cannot reproduce it with the tests. It
 only happens (randomly) when using Seaside through the webbrowser.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] 1.2 vision


Suggestions:

1) Something like VW MemoryPolicy would probably be beneficial in the long-term 
instead of polluting SmalltalkImage with a zillion 
#initializeMemorySettingsProfileForWhatever to customize the Pharo GC 
parameters for Seaside, QF or whatever else.

2) SystemNavigation needs a cleanup/revisit.

3) Utilities needs a cleanup/revisit.

4) The more... menu in the file browser is a mess, a real big mess!  Needs 
cleanup/revisit.

My 2 cents.

-
Benoit St-Jean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)







 From: stephane.duca...@inria.fr
 Date: Sun, 27 Jun 2010 10:31:47 +0200
 To: Pharo-project@lists.gforge.inria.fr
 Subject: [Pharo-project] 1.2 vision
 
 Hi all
 
 Of course we will integrate changes and changes and improvements now I 
 believe that it would be nice to build a common
 vision. Here what I would like to get in 1.2.
 
 Now it does not mean that this is a definitive list and that we will have the 
 energy to do all but like
 that you know that you can put energy do build this common vision :)
 
   - better infrastructure for integrating rb composite queries into the 
 system 
   The idea is to introduce a superclass on top of 
 systemDictionary and to define there an API that 
   is compatible with the one of RB (and potentially modified the 
 one of RB)
 
   - another step towards using announcement for system notification
 
   - better tools for dev
 
   - have a look at the RB change model so that we could get a real undo 
 and changes
 
   - clean Monticello so that package logic stays in package so that we 
 can plug RPackage into the system.
   Right now this looks too brittle to do anything
 
   - make sure that we can have RPackage on the side of PakageInfo (we got 
 really nice benchmark)
 
   - New Compiler in beta
 
   - Helvetia hooks
 
   - ROME API
 
   - Sophie Event Hierarchy
 
   - Define some architectural action to get the system more modular
 
   - Hudson infrastructure
 
   - metacello to manage core
 
   - metacelloRepository for 1.0/1.1/1.2
   Gofer
 
   - squeak collection optimisation?
 
   - Alien
 
 Open points:
 
   - What do we do with ToolBuilder? Not clear to me.
 
   - What should be done at the level of polymorph?
   - What should be done a the level of Pluggable 
   can we use the fact that we have now block closure to 
 get it better.
 
 As you guess it will not come simply but this is important that we all head 
 towards a common understanding
 
 
 Stef
 
 
 
 
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
  
_
Learn more ways to connect with your buddies now
http://go.microsoft.com/?linkid=9734388___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo:

In PharoInbox:
SLICE-Issue-2593-SystemNavigationAddSelectorsReferingTo-LaurentLaffont.1

Apply Benoit St-Jean patch + add non-regression test

Laurent Laffont

On Sun, Jun 27, 2010 at 10:01 AM, Benoit St-Jean bstj...@hotmail.ca wrote:

  Fix attached.

 Hope this helps!



 -
 Benoit St-Jean
 A standpoint is an intellectual horizon of radius zero.
 (Albert Einstein)




 --
 From: laurent.laff...@gmail.com
 Date: Sun, 27 Jun 2010 08:33:52 +0200
 To: pharo-project@lists.gforge.inria.fr
 Subject: [Pharo-project] SystemNavigation#allSendersOf: vs
 SystemNavigation#allReferencesTo:

 Hi,

 in Autotest I search for all senders of a method. The first version
 used SystemNavigation#allSendersOf: which sometimes returns wrong results (I
 think). For example:

 senders := (SystemNavigation default allSendersOf: #methodsFor:).
 senders size.  answers 18
 senders collect: [:aReference| aReference compiledMethod].

 debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class
 side but allSendersOf: returns #scanCategory reference on class side and
 instance side).

 With #allReferencesTo:

 senders := (SystemNavigation default allReferencesTo: #methodsFor:).
 senders size.  answers 16

 Is this a bug in #allSendersOf: or I don't understand ?

 Cheers,

 Laurent Laffont

 http://pharocasts.blogspot.com/
 http://magaloma.blogspot.com/

 --
 Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now!
 http://go.microsoft.com/?linkid=9734383

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] 1.2 vision

+ More HelpSystem.
+ MetacelloRepository GUI, newbies struggle to find a package, must be easy.

Laurent

On Sun, Jun 27, 2010 at 10:31 AM, Stéphane Ducasse 
stephane.duca...@inria.fr wrote:

 Hi all

 Of course we will integrate changes and changes and improvements now I
 believe that it would be nice to build a common
 vision. Here what I would like to get in 1.2.

 Now it does not mean that this is a definitive list and that we will have
 the energy to do all but like
 that you know that you can put energy do build this common vision :)

- better infrastructure for integrating rb composite queries into
 the system
The idea is to introduce a superclass on top of
 systemDictionary and to define there an API that
is compatible with the one of RB (and potentially modified
 the one of RB)

- another step towards using announcement for system notification

- better tools for dev

- have a look at the RB change model so that we could get a real
 undo and changes

- clean Monticello so that package logic stays in package so that we
 can plug RPackage into the system.
Right now this looks too brittle to do anything

- make sure that we can have RPackage on the side of PakageInfo (we
 got really nice benchmark)

- New Compiler in beta

- Helvetia hooks

- ROME API

- Sophie Event Hierarchy

- Define some architectural action to get the system more modular

- Hudson infrastructure

- metacello to manage core

- metacelloRepository for 1.0/1.1/1.2
Gofer

- squeak collection optimisation?

- Alien

 Open points:

- What do we do with ToolBuilder? Not clear to me.

- What should be done at the level of polymorph?
- What should be done a the level of Pluggable
can we use the fact that we have now block closure
 to get it better.

 As you guess it will not come simply but this is important that we all head
 towards a common understanding


 Stef




 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Changing color/fillStyle by morph halo menu in 1.1rc2

improvements are always welcome.
We removed ColorPickerMorph because it was subclassing a giant and bad class.

Stef

On Jun 27, 2010, at 11:53 AM, Denis Kudriashov wrote:

 I try last Pharo 1.1 rc2 10.06.10.
 
 I found that tool for changing color by user is changed. ColorPickerMorph is 
 removed. Now I can't dynamically change color by mouse and see my changes 
 immediately. Now I must select color in new tool, press ok button. And after 
 that tool close and I must open it again if I dont like my changes. 
 
 It is bad behavior compare with pharo 1.0/squeak. But I really like new color 
 picker morph.
 
 New tool is ColorSelectorDialogWindow. 
 How I can hookup It for tracking color selection?
 Maybe I must add some event triggering in #basicSelectedColor: method.
 But I see many #changed: sends in #basicSelectedColor: method. And maybe I 
 already can implement some dependent class for needed stuff.
 
 What you think?
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Changing color/fillStyle by morph halo menu in 1.1rc2

I do not understand because you can see the selected color in the selected 
color little pane.
Is it not what you need?
Stef]
On Jun 27, 2010, at 11:53 AM, Denis Kudriashov wrote:

 I try last Pharo 1.1 rc2 10.06.10.
 
 I found that tool for changing color by user is changed. ColorPickerMorph is 
 removed. Now I can't dynamically change color by mouse and see my changes 
 immediately. Now I must select color in new tool, press ok button. And after 
 that tool close and I must open it again if I dont like my changes. 
 
 It is bad behavior compare with pharo 1.0/squeak. But I really like new color 
 picker morph.
 
 New tool is ColorSelectorDialogWindow. 
 How I can hookup It for tracking color selection?
 Maybe I must add some event triggering in #basicSelectedColor: method.
 But I see many #changed: sends in #basicSelectedColor: method. And maybe I 
 already can implement some dependent class for needed stuff.
 
 What you think?
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ESUG will sponsor the XMLRPC project!

2010-06-27 Thread Philippe Marschall

On 26.06.2010 19:27, Germán Arduino wrote:
 Hi Folks,
 
 I'm very happy of announce that ESUG will be sponsoring my work to
 develop a XMLRPC client interface, as I comment on my blog:
 http://germanarduino.blogspot.com/2010/06/esug-will-sponsor-xmlrpc-project.html.
 
 I want to thank publicly to Stéphane Ducasse, Alain Plantec, Nuory
 Bouraqadi and ESUG, as they are sponsoring this initiative under the
 support your project program, described in
 http://www.esug.org/Promotion/Project . Thanks you very much ESUG.
 
 Any comment or suggestion to this project is more than welcomed.

WTF?! It's 2010 and you're implementing XMLRPC. Srsly guys? What's next
CORBA?

Cheers
Philippe


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] squeaksource is down (again ...)

2010-06-27 Thread Philippe Marschall

On 24.06.2010 15:10, Torsten Bergmann wrote:
 What could be done is moving to an up to date image/vm but this is a bit
 of work.
 
 Would you be able to at least make the image available somewhere so
 one knows about the loaded packages and applied patches.
 Maybe someone has a minute ...

Nope, I don't have access to the server anymore. You'd have to ask Lukas
or Adrian. There's still the issue with private projects though.

What would probably be an easy fix is to use mod_xsendfile [1] to
deliver the versions. That would take load off the image. It requires
sever access though.

 [1] http://tn123.ath.cx/mod_xsendfile/

Cheers
Philippe


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Changing color/fillStyle by morph halo menu in 1.1rc2

2010-06-27 Thread Denis Kudriashov

I can't see full morph appearance. I just see what color I select.
But It's nothing because I need see my little changes in full morph
appearance.

For example color of button should satisfy color of pane. And when I change
button color I want immediately see full picture of my application view.

I think It is very important for UI design.

2010/6/27 Stéphane Ducasse stephane.duca...@inria.fr

 I do not understand because you can see the selected color in the selected
 color little pane.
 Is it not what you need?
 Stef]
 On Jun 27, 2010, at 11:53 AM, Denis Kudriashov wrote:

  I try last Pharo 1.1 rc2 10.06.10.
 
  I found that tool for changing color by user is changed. ColorPickerMorph
 is removed. Now I can't dynamically change color by mouse and see my changes
 immediately. Now I must select color in new tool, press ok button. And after
 that tool close and I must open it again if I dont like my changes.
 
  It is bad behavior compare with pharo 1.0/squeak. But I really like new
 color picker morph.
 
  New tool is ColorSelectorDialogWindow.
  How I can hookup It for tracking color selection?
  Maybe I must add some event triggering in #basicSelectedColor: method.
  But I see many #changed: sends in #basicSelectedColor: method. And maybe
 I already can implement some dependent class for needed stuff.
 
  What you think?
  ___
  Pharo-project mailing list
  Pharo-project@lists.gforge.inria.fr
  http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] squeaksource is down (again ...)

2010-06-27 Thread Lukas Renggli

 Would you be able to at least make the image available somewhere so
 one knows about the loaded packages and applied patches.
 Maybe someone has a minute ...

 Nope, I don't have access to the server anymore. You'd have to ask Lukas
 or Adrian. There's still the issue with private projects though.

It is running the latest version from http://www.squeaksource.com/ss.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] amount of recheable objects from a root one?

2010-06-27 Thread Mariano Martinez Peck

Hi folks. I need to do something and I am a little lazy to do it. Maybe
someone already did it and can share it with me. I want to take an object X.
That object has references to other objects and I imagine that as a graph.

I need to traverse the graph, and get the final amount of reachable objects
from the object X. I mean, the size of that graph. I need to avoid cycles
and not count objects already counted. Maybe I can reuse part of
SmartRefStream?

Thanks for any tip.

Mariano
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ESUG will sponsor the XMLRPC project!

2010-06-27 Thread Germán Arduino

Hi Philippe:

What is bad with xmlrpc? A lot of sites are using it to expose its data

Cheers.
Germán.

2010/6/27 Philippe Marschall kus...@gmx.net:
 On 26.06.2010 19:27, Germán Arduino wrote:
 Hi Folks,

 I'm very happy of announce that ESUG will be sponsoring my work to
 develop a XMLRPC client interface, as I comment on my blog:
 http://germanarduino.blogspot.com/2010/06/esug-will-sponsor-xmlrpc-project.html.

 I want to thank publicly to Stéphane Ducasse, Alain Plantec, Nuory
 Bouraqadi and ESUG, as they are sponsoring this initiative under the
 support your project program, described in
 http://www.esug.org/Promotion/Project . Thanks you very much ESUG.

 Any comment or suggestion to this project is more than welcomed.

 WTF?! It's 2010 and you're implementing XMLRPC. Srsly guys? What's next
 CORBA?

 Cheers
 Philippe


 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



-- 
=
Germán S. Arduino  gsa @ arsol.net   Twitter: garduino
Arduino Software  Web Hosting   http://www.arduinosoftware.com
PasswordsPro  http://www.passwordspro.com
=

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] amount of recheable objects from a root one?

2010-06-27 Thread Adrian Lienhard

Hi Mariano

Any reason not to use image segments? It even includes a method doSpaceAnalysis 
to count the number of instances per class. In addition you may have take the 
objects in the outpointers collection into account. 

Cheers,
Adrian

On Jun 27, 2010, at 14:41 , Mariano Martinez Peck wrote:

 Hi folks. I need to do something and I am a little lazy to do it. Maybe
 someone already did it and can share it with me. I want to take an object X.
 That object has references to other objects and I imagine that as a graph.
 
 I need to traverse the graph, and get the final amount of reachable objects
 from the object X. I mean, the size of that graph. I need to avoid cycles
 and not count objects already counted. Maybe I can reuse part of
 SmartRefStream?
 
 Thanks for any tip.
 
 Mariano
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] GLORP in Pharo

2010-06-27 Thread Sven Van Caekenberghe

Alberto,

On 27 Jun 2010, at 11:52, Alberto Bacchelli wrote:

 Hi,
 
 What is the current situation of GLORP in Pharo?
 Is there any working porting? Otherwise are there reliable alternatives to it?
 
 Thank you.
 
 Cheers,
 Alberto

I am successfully using Glorp + PostgresV2 in Pharo 1.1 rc2.

I have my own load script at 

http://www.squeaksource.com/ADayAtTheBeach/GlorpPostgreSQLPharoLoader-SvenVanCaekenberghe.3.mcz

HTH,

Sven




___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ESUG will sponsor the XMLRPC project!

2010-06-27 Thread David T. Lewis

On Sun, Jun 27, 2010 at 10:39:46AM -0300, Germ?n Arduino wrote:
 2010/6/27 Philippe Marschall kus...@gmx.net:
  On 26.06.2010 19:27, Germ?n Arduino wrote:
  Hi Folks,
 
  I'm very happy of announce that ESUG will be sponsoring my work to
  develop a XMLRPC client interface, as I comment on my blog:
  http://germanarduino.blogspot.com/2010/06/esug-will-sponsor-xmlrpc-project.html.
 
  I want to thank publicly to St?phane Ducasse, Alain Plantec, Nuory
  Bouraqadi and ESUG, as they are sponsoring this initiative under the
  support your project program, described in
  http://www.esug.org/Promotion/Project . Thanks you very much ESUG.
 
  Any comment or suggestion to this project is more than welcomed.
 
  WTF?! It's 2010 and you're implementing XMLRPC. Srsly guys? What's next
  CORBA?
 
 Hi Philippe:
 
 What is bad with xmlrpc? A lot of sites are using it to expose its data

There is a lot to be said for a simple, well-defined protocol that works
reliably, is easy to understand, and can be readily maintained as a
package for Pharo/Squeak. XMLRPC sounds like a good project to me :)

And thanks to ESUG for sponsoring projects like this.

Dave


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] GLORP in Pharo

2010-06-27 Thread John Toohey

Glorp works in 1.1 and 1.0 of Pharo, with support for Postgres,
Oracle, mySql, DB2 etc. Full information is available at
http://squeakdbx.org/

On Sun, Jun 27, 2010 at 05:52, Alberto Bacchelli
alberto.bacche...@usi.ch wrote:
 Hi,

  What is the current situation of GLORP in Pharo?
 Is there any working porting? Otherwise are there reliable alternatives to it?

 Thank you.

 Cheers,
  Alberto

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




-- 
-JT

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] squeaksource is down (again ...)

2010-06-27 Thread Levente Uzonyi


On Sun, 27 Jun 2010, Philippe Marschall wrote:


On 24.06.2010 15:10, Torsten Bergmann wrote:

What could be done is moving to an up to date image/vm but this is a bit
of work.


Would you be able to at least make the image available somewhere so
one knows about the loaded packages and applied patches.
Maybe someone has a minute ...


Nope, I don't have access to the server anymore. You'd have to ask Lukas
or Adrian. There's still the issue with private projects though.


How about maintaining a copy of the non-private projects and serving them 
with apache? I think most people would be happy with this. The only minor 
issue with this approach is that downloads are not counted, though that 
can be worked around by analyzing the access log or using a rewrite map.



Levente



What would probably be an easy fix is to use mod_xsendfile [1] to
deliver the versions. That would take load off the image. It requires
sever access though.

[1] http://tn123.ath.cx/mod_xsendfile/

Cheers
Philippe


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Xtreme Pharo hacker needed :)

Hi,

I struggle for a functionality I want to add on Autotest. Suppose a class
with two methods A and B, such as A senders of B

ZorkmethodA
   self methodB

And unit tests:

ZorkTesttestSomething
   .
   Zork new methodA
  ...
  self assert: 


If I change methodA, Autotest detects it, search all senders of methodA in
tests and run. As  ZorkTesttestSomething is sender of ZorkmethodA, it
will find and run it.

Now if I change methodB and there's no senders in tests, the previous
heuristic won't work. So I added as last heuristic: if no method found,
search all TestCases that references the changed method class and run.
So here it will find ZorkTest and run all its tests.
The problem is that I don't really know if the method I've changed has been
actually hit by the tests. I just see that tests has been run. I don't
know if my method has been called when running the tests.

So I want to detect this.

One way of doing this seems to use
MethodContextrunSimulated:contextAtEachStep:. I've found this looking at
MessageTally. Is it the best solution ?

So in AutotestfindRunAndShowTestsOf: I try something like this

AutotestfindRunAndShowTestsOf:changedMethod
  | testMethods aTestResult methodHit |
  Finds the test related to changedMethod, run them and tell the view to
update
testMethods := search methodsFor: changedMethod.
 methodHit := false.
thisContext sender
 runSimulated: [aTestResult := runner run: testMethods]
contextAtEachStep: [:current|
 (current method = changedMethod)--- here I detect if changedMethod
has been hit
   ifTrue: [methodHit := true]].
.

but using this debugger opens with SimulationGuardException: triggered by
BlockClosurenewProcess in
MethodContextdoPrimitive:method:receiver:args:

As I don't (yet :) understand all this stuff, I want to know if it's the
right way to do it and what should I check.

Thanks

Laurent Laffont

http://pharocasts.blogspot.com/
http://magaloma.blogspot.com/
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Xtreme Pharo hacker needed :)

2010-06-27 Thread Lukas Renggli

 One way of doing this seems to use
 MethodContextrunSimulated:contextAtEachStep:. I've found this looking at
 MessageTally. Is it the best solution ?
 So in AutotestfindRunAndShowTestsOf: I try something like this
 AutotestfindRunAndShowTestsOf:changedMethod
   | testMethods aTestResult methodHit |
   Finds the test related to changedMethod, run them and tell the view to
 update
 testMethods := search methodsFor: changedMethod.
 methodHit := false.
 thisContext sender
 runSimulated: [aTestResult := runner run: testMethods]
 contextAtEachStep: [:current|
 (current method = changedMethod)    --- here I detect if changedMethod has
 been hit
        ifTrue: [methodHit := true]].
         .
 but using this debugger opens with SimulationGuardException: triggered by
 BlockClosurenewProcess in
 MethodContextdoPrimitive:method:receiver:args:
 As I don't (yet :) understand all this stuff, I want to know if it's the
 right way to do it and what should I check.

This is the stepping mechanism of the debugger. It is dead slow, and
likely to break when you fork processes, mess with the stack, or hit
other kinds of primitives.

I would use method wrappers, they are much easier to use, less error
prone, very efficient, and already integrated with the test runner
(see the in the GUI code: 'test coverage').

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Xtreme Pharo hacker needed :)


Hi Laurent,

Perhaps I am missing something but you only need 2 conditions to detect what 
you are looking for:

1) changed method is a test (and defined in a subclass of TestCase)
2) changed method has a sender that is a test method



-
Benoit St-Jean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)







From: laurent.laff...@gmail.com
Date: Sun, 27 Jun 2010 17:33:53 +0200
To: pharo-project@lists.gforge.inria.fr
Subject: [Pharo-project] Xtreme Pharo hacker needed :)

Hi,
I struggle for a functionality I want to add on Autotest. Suppose a class with 
two methods A and B, such as A senders of B
ZorkmethodA   self methodB


And unit tests:
ZorkTesttestSomething   .   Zork new methodA  ...  self assert: 



If I change methodA, Autotest detects it, search all senders of methodA in 
tests and run. As  ZorkTesttestSomething is sender of ZorkmethodA, it will 
find and run it.
Now if I change methodB and there's no senders in tests, the previous heuristic 
won't work. So I added as last heuristic: if no method found, search all 
TestCases that references the changed method class and run. 

So here it will find ZorkTest and run all its tests. The problem is that I 
don't really know if the method I've changed has been actually hit by the 
tests. I just see that tests has been run. I don't know if my method has been 
called when running the tests. 


So I want to detect this.
One way of doing this seems to use 
MethodContextrunSimulated:contextAtEachStep:. I've found this looking at 
MessageTally. Is it the best solution ?


So in AutotestfindRunAndShowTestsOf: I try something like this
AutotestfindRunAndShowTestsOf:changedMethod  | testMethods aTestResult 
methodHit |

  Finds the test related to changedMethod, run them and tell the view to 
update   testMethods := search methodsFor: changedMethod.

methodHit := false. thisContext sender

runSimulated: [aTestResult := runner run: testMethods]  
contextAtEachStep: [:current|  

(current method = 
changedMethod)--- here I detect if changedMethod has been hit
  ifTrue: [methodHit := true]].

.
but using this debugger opens with SimulationGuardException: triggered by 
BlockClosurenewProcess in MethodContextdoPrimitive:method:receiver:args: 


As I don't (yet :) understand all this stuff, I want to know if it's the right 
way to do it and what should I check.


ThanksLaurent Laffont

http://pharocasts.blogspot.com/
http://magaloma.blogspot.com/
  
_
MSN Dating: Find someone special. Start now.
http://go.microsoft.com/?linkid=9734384___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] amount of recheable objects from a root one?

2010-06-27 Thread Miguel Enrique Cobá Martínez

El dom, 27-06-2010 a las 14:41 +0200, Mariano Martinez Peck escribió:
 Hi folks. I need to do something and I am a little lazy to do it.
 Maybe someone already did it and can share it with me. I want to take
 an object X. That object has references to other objects and I imagine
 that as a graph. 
 
 I need to traverse the graph, and get the final amount of reachable
 objects from the object X. I mean, the size of that graph. I need to
 avoid cycles and not count objects already counted. Maybe I can reuse
 part of SmartRefStream?

What about Magma's Ma object serialization and Ma traverse object
graphs' packages. I think they can  be used independently from Magma to
do what you need.

Cheers

 
 Thanks for any tip.
 
 Mariano
 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- 
Miguel Cobá
http://miguel.leugim.com.mx


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Xtreme Pharo hacker needed :)

On Sun, Jun 27, 2010 at 5:39 PM, Lukas Renggli reng...@gmail.com wrote:

  One way of doing this seems to use
  MethodContextrunSimulated:contextAtEachStep:. I've found this looking
 at
  MessageTally. Is it the best solution ?
  So in AutotestfindRunAndShowTestsOf: I try something like this
  AutotestfindRunAndShowTestsOf:changedMethod
| testMethods aTestResult methodHit |
Finds the test related to changedMethod, run them and tell the view to
  update
  testMethods := search methodsFor: changedMethod.
  methodHit := false.
  thisContext sender
  runSimulated: [aTestResult := runner run: testMethods]
  contextAtEachStep: [:current|
  (current method = changedMethod)--- here I detect if changedMethod
 has
  been hit
 ifTrue: [methodHit := true]].
  .
  but using this debugger opens with SimulationGuardException: triggered
 by
  BlockClosurenewProcess in
  MethodContextdoPrimitive:method:receiver:args:
  As I don't (yet :) understand all this stuff, I want to know if it's the
  right way to do it and what should I check.

 This is the stepping mechanism of the debugger. It is dead slow, and
 likely to break when you fork processes, mess with the stack, or hit
 other kinds of primitives.

 I would use method wrappers, they are much easier to use, less error
 prone, very efficient, and already integrated with the test runner
 (see the in the GUI code: 'test coverage').


Thank you Lukas ! I will have a look.

Laurent



 Lukas

 --
 Lukas Renggli
 www.lukas-renggli.ch

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ESUG will sponsor the XMLRPC project!

2010-06-27 Thread Philippe Marschall

On 27.06.2010 15:39, Germán Arduino wrote:
 Hi Philippe:
 
 What is bad with xmlrpc? A lot of sites are using it to expose its data

Like whom?

Cheers
Philippe


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] [update 1.2] #12018

2010-06-27 Thread stephane ducasse

12018
-

-  Issue 2593:  SystemNavigation#allSendersOf: returns inexisting references

- Issue 2480:   make and:and:and:and: and and:and: deprecated

Stef

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Xtreme Pharo hacker needed :)

2010-06-27 Thread Alexandre Bergel

 The problem is that I don't really know if the method I've changed has been 
 actually hit by the tests. I just see that tests has been run. I don't know 
 if my method has been called when running the tests. 
 
 So I want to detect this.
 
 One way of doing this seems to use 
 MethodContextrunSimulated:contextAtEachStep:. I've found this looking at 
 MessageTally. Is it the best solution ?

If you know exactly which compiled method you are interested in, I would wrap 
it using a plain object that answers to #run:with:in:
This is a feature supported which is supported for quite some time by the VM.
Info on http://www.iam.unibe.ch/~scg/Archive/Papers/Bergel06bRDLPrototyping.pdf 
, Section 2.2

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






___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Xtreme Pharo hacker needed :)

On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel alexan...@bergel.euwrote:

  The problem is that I don't really know if the method I've changed has
 been actually hit by the tests. I just see that tests has been run. I
 don't know if my method has been called when running the tests.
 
  So I want to detect this.
 
  One way of doing this seems to use
 MethodContextrunSimulated:contextAtEachStep:. I've found this looking at
 MessageTally. Is it the best solution ?

 If you know exactly which compiled method you are interested in, I would
 wrap it using a plain object that answers to #run:with:in:
 This is a feature supported which is supported for quite some time by the
 VM.
 Info on
 http://www.iam.unibe.ch/~scg/Archive/Papers/Bergel06bRDLPrototyping.pdfhttp://www.iam.unibe.ch/%7Escg/Archive/Papers/Bergel06bRDLPrototyping.pdf,
  Section 2.2


Thank you, it's cool to learn so sexy stuff :) Should be in Pharo book.

Laurent



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






 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Xtreme Pharo hacker needed :)

2010/6/27 Benoit St-Jean bstj...@hotmail.ca

  Hi Laurent,

 Perhaps I am missing something but you only need 2 conditions to detect
 what you are looking for:

 1) changed method is a test (and defined in a subclass of TestCase)
 2) changed method has a sender that is a test method


First Autotest versions have these two heuristics. Then I feel the need to
add:
- change method is a setUp or tearDown - run all tests of TestCase
- and now when there's no senders of changed method in a TestCase (a private
method for example) - try to find tests of the changed method class  (I
think it can be better but I have no other solution yet)

Indeed, using Autotest I feel the need to be sure that the method I've
changed has been called. I would like to see a warning if it's not the case.

Cheers

Laurent






 -
 Benoit St-Jean
 A standpoint is an intellectual horizon of radius zero.
 (Albert Einstein)




 --
 From: laurent.laff...@gmail.com
 Date: Sun, 27 Jun 2010 17:33:53 +0200
 To: pharo-project@lists.gforge.inria.fr
 Subject: [Pharo-project] Xtreme Pharo hacker needed :)


 Hi,

 I struggle for a functionality I want to add on Autotest. Suppose a class
 with two methods A and B, such as A senders of B

 ZorkmethodA
self methodB

 And unit tests:

 ZorkTesttestSomething
.
Zork new methodA
   ...
   self assert: 


 If I change methodA, Autotest detects it, search all senders of methodA in
 tests and run. As  ZorkTesttestSomething is sender of ZorkmethodA, it
 will find and run it.

 Now if I change methodB and there's no senders in tests, the previous
 heuristic won't work. So I added as last heuristic: if no method found,
 search all TestCases that references the changed method class and run.
 So here it will find ZorkTest and run all its tests.
 The problem is that I don't really know if the method I've changed has been
 actually hit by the tests. I just see that tests has been run. I don't
 know if my method has been called when running the tests.

 So I want to detect this.

 One way of doing this seems to use
 MethodContextrunSimulated:contextAtEachStep:. I've found this looking at
 MessageTally. Is it the best solution ?

 So in AutotestfindRunAndShowTestsOf: I try something like this

 AutotestfindRunAndShowTestsOf:changedMethod
   | testMethods aTestResult methodHit |
   Finds the test related to changedMethod, run them and tell the view to
 update
 testMethods := search methodsFor: changedMethod.
  methodHit := false.
 thisContext sender
  runSimulated: [aTestResult := runner run: testMethods]
 contextAtEachStep: [:current|
  (current method = changedMethod)--- here I detect if changedMethod
 has been hit
ifTrue: [methodHit := true]].
 .

 but using this debugger opens with SimulationGuardException: triggered by
 BlockClosurenewProcess in
 MethodContextdoPrimitive:method:receiver:args:

 As I don't (yet :) understand all this stuff, I want to know if it's the
 right way to do it and what should I check.

 Thanks

 Laurent Laffont

 http://pharocasts.blogspot.com/
 http://magaloma.blogspot.com/

 --
 Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now!
 http://go.microsoft.com/?linkid=9734379

 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Xtreme Pharo hacker needed :)

2010-06-27 Thread Henrik Sperre Johansen


 On 27.06.2010 20:20, laurent laffont wrote:


On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel alexan...@bergel.eu 
mailto:alexan...@bergel.eu wrote:


 The problem is that I don't really know if the method I've
changed has been actually hit by the tests. I just see that
tests has been run. I don't know if my method has been called when
running the tests.

 So I want to detect this.

 One way of doing this seems to use
MethodContextrunSimulated:contextAtEachStep:. I've found this
looking at MessageTally. Is it the best solution ?

If you know exactly which compiled method you are interested in, I
would wrap it using a plain object that answers to #run:with:in:
This is a feature supported which is supported for quite some time
by the VM.
Info on
http://www.iam.unibe.ch/~scg/Archive/Papers/Bergel06bRDLPrototyping.pdf
http://www.iam.unibe.ch/%7Escg/Archive/Papers/Bergel06bRDLPrototyping.pdf
, Section 2.2


Thank you, it's cool to learn so sexy stuff :) Should be in Pharo book.

Laurent

Note: The Cog VM crashes on TestObjectsAsMethods.

Cheers,
Henry
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] [update 1.2] #12019

12019
-

- Issue 156: Pointer tracing tools do not consistently find pointers. Thanks 
andy, johan and matthew.

Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Xtreme Pharo hacker needed :)

2010/6/27 Henrik Sperre Johansen henrik.s.johan...@veloxit.no

On 27.06.2010 20:20, laurent laffont wrote:

On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel alexan...@bergel.euwrote:

The problem is that I don't really know if the method I've changed has
been actually hit by the tests. I just see that tests has been run. I
don't know if my method has been called when running the tests.

So I want to detect this.

One way of doing this seems to use
MethodContextrunSimulated:contextAtEachStep:. I've found this looking at
MessageTally. Is it the best solution ?

If you know exactly which compiled method you are interested in, I would
wrap it using a plain object that answers to #run:with:in:
This is a feature supported which is supported for quite some time by the
VM.
Info on
http://www.iam.unibe.ch/~scg/Archive/Papers/Bergel06bRDLPrototyping.pdfhttp://www.iam.unibe.ch/%7Escg/Archive/Papers/Bergel06bRDLPrototyping.pdf,
Section 2.2

Thank you, it's cool to learn so sexy stuff :) Should be in Pharo book.

Laurent

Note: The Cog VM crashes on TestObjectsAsMethods.

Coding a wrapper the TDD way seems tricky, my image is lost as assert:
failed, so uninstall not done and since all is upside down... :)

Laurent

Cheers,
Henry

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] ESUG will sponsor the XMLRPC project!

2010-06-27 Thread Germán Arduino

As flickr, blogger, wordpress, Joomla sites, Google blog search,
Drupal sites, delicious, zope,  products as SAP, to mention a few that
I have in mind now

I means, not only web sites, also products and I think also that is a
compact protocol that could permit to implement an API to servers /
products easily.

Cheers.
Germán.

2010/6/27 Philippe Marschall kus...@gmx.net:
 On 27.06.2010 15:39, Germán Arduino wrote:
 Hi Philippe:

 What is bad with xmlrpc? A lot of sites are using it to expose its data

 Like whom?

 Cheers
 Philippe


 ___
 Pharo-project mailing list
 Pharo-project@lists.gforge.inria.fr
 http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



-- 
=
Germán S. Arduino  gsa @ arsol.net   Twitter: garduino
Arduino Software  Web Hosting   http://www.arduinosoftware.com
PasswordsPro  http://www.passwordspro.com
=

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Autotest enhancement suggestions


Added removal support for Autotest.

FileOut file included.

-
Benoit St-Jean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein) 
_
MSN Dating: Find someone special. Start now.
http://go.microsoft.com/?linkid=9734384

AutotestListener-installSystemNotifications.st
Description: Binary data
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Changing/Removing Desktop Image in 1.1

2010-06-27 Thread Rob Rothwell

Can anyone remove the default image in 1.1 (Pharo-1.1-11400-rc2dev10.06.1)?
Remove it?

Using the settings browser has no effect for me.

I can't even remove it by adding a halo and deleting it...

Take care,

Rob
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Changing/Removing Desktop Image in 1.1