[Pharo-project] squeaksource is down

[laurent laffont]

Can't wait SmalltalkHub 

Laurent Laffont - @lolgzs 

Pharo Smalltalk Screencasts: http://www.pharocasts.com/
Blog: http://magaloma.blogspot.com/
Developer group: http://cara74.seasidehosting.st

[Pharo-project] Issue 4024 in pharo: 'Transcript clear' does not repaint screen properly

[pharo]

Status: New
Owner: 

New issue 4024 by dougedmu...@gmail.com: 'Transcript clear' does not  
repaint screen properly

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

Pharo image: Pharo | Pharo-core
Pharo core version: Pharo1.3a
Latest update: #13144

Virtual machine used: PHaro4.1.1 on Win32
Class browser used (if applicable): "SystemBrowser default"

Steps to Reproduce
1. Open transcript.
2. Open browser, so it partially covers transcript.
3. Open workspace, so it partially covers browser.
(should now be workspace on top, browser in middle, transcript on bottom).
4. Type 'transcript clear' in workspace

Outer frames of Workspace and Transcript windows are not properly repainted.

Attachments:
repaint_issue.png  64.9 KB

Re: [Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk — Contributors

[laurent laffont]

Done !

Laurent



On Thu, Apr 14, 2011 at 10:07 PM, Diogenes Moreira <
diogenes.more...@gmail.com> wrote:

> i forget the picture [image: photo.jpg]
>
>
> On Thu, Apr 14, 2011 at 5:05 PM, Diogenes Moreira <
> diogenes.more...@gmail.com> wrote:
>
>> Ok.. Well
>>
>> Diógenes Alberto Moreira
>> CTO at Ilon S.A. and CTO at Sociadad Anonima para la Salud S.A. (
>> www.ilon.com.ar)
>> Contributor on DBXTalk (http://squeakdbx.org), and other projects.
>>
>> Smalltalker And Pharo's lover :)
>>
>> Best
>>
>>
>> On Thu, Apr 14, 2011 at 10:46 AM, Mariano Martinez Peck <
>> marianop...@gmail.com> wrote:
>>
>>> if true...then what are you wainting for?
>>>
>>> http://www.pharo-project.org/community/contributors
>>>
>>> Send you data and nice picture :)
>>>
>>> Seriously, it is important for marketing among other things. Imagine you
>>> arrive to a new project...it is good to see that there are several
>>> contributing to it. Probably this page is not the best, but is something
>>> more.
>>>
>>> Mariano
>>>
>>>
>>>
>>> On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont <
>>> laurent.laff...@gmail.com> wrote:
>>>
 Added !

 Laurent.

 On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich wrote:

> Hi Laurent,
>
> I'd like to be added to
> http://www.pharo-project.org/community/contributors . My picture is
> attached. Description text could be "Contributed the default anti-aliased
> fonts and the SimpleMorphic UI framework. Web page at
> www.jvuletich.org".
>
> Thank you.
>
> Cheers,
> Juan Vuletich
>


>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>
>
<>

Re: [Pharo-project] [COTDC] 48 - ClassFactoryForTestCase

[Alexandre Bergel]

-=-=-=-=-=-=-=-=-=
The class ClassFactoryForTestCase is useful when classes needs to be created 
during the execution of the test. This avoid polluting your unit tests with 
dummy and mock classes.
A typical usage of it is:

TestCase subclass: #YourTest
instanceVariableNames: 'classFactory'

YourTest>>setUp
classFactory := ClassFactoryForTestCase new

YourTest>>tearDown 
classFactory deleteClasses.

YourTest>>testIsBehavior
| cls |
cls := classFactory newClass.
self assert: cls isBehavior
-=-=-=-=-=-=-=-=-=

Cheers,
Alexandre

On 14 Apr 2011, at 16:07, laurent laffont wrote:

> Today:  ClassFactoryForTestCase
> 
> Come on guys ! Go Go Go !!
> 
> 
> Comment Of The Day Contest - One Day One Comment
> Rules: 
> #1: Each day a not commented class is elected. Each day the best comment will 
> be integrated with name of the author(s).
> #2: If you cannot comment it, deprecate it.
> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest
> 
> Laurent
> 

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

Re: [Pharo-project] presentation

[Mariano Martinez Peck]

Santiyou forgot to say the most important thing ;)
He is one of the new DBTalk developers for ESUG SummerTalk!!

On Thu, Apr 14, 2011 at 10:27 PM, Stéphane Ducasse <
stephane.duca...@inria.fr> wrote:

> welcome!
> There are plenty of things to do.
> I would love to see more tests, applying smallLint... better quality
> process
> new frameworks...
> Stef
>
>
> >  Hi Pharo friends, I'm Santiago Bragagnolo from Argentina. (Colleague of
> some users of this list from Argentina too)
> >
> >  I'm currently teaching smalltalk in UTN and getting deep in this amazing
> world. So, i want to contribute to pharo comunity, fixing issues, developing
> new features, etc. Ok, how can achive mi goals xD? (too formal? sorry if my
> english is not enough clear or usual :) )
> >
> >
> > Greetings.
> >
> > Santiago.
> >
> >
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Stéphane Ducasse]

ok tx

On Apr 14, 2011, at 8:27 PM, Miguel Cobá wrote:

> El jue, 14-04-2011 a las 20:13 +0200, Stéphane Ducasse escribió:
>> Dale 
>> 
>> so it means that I write what?
>> 
>> [] on: NumericError do: [:ex | ]
>> 
>> how do I access the rangeError?
> 
> [] on: NumericError do: [ :ex | ex reasonCode "This gets you #rangeError
> or any other symbol to detail the exception" ]
> 
> Cheers
> 
> 
> -- 
> Miguel Cobá
> http://twitter.com/MiguelCobaMtz
> http://miguel.leugim.com.mx
> 
> 
> 
> 

Re: [Pharo-project] Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy

[Stéphane Ducasse]

sounds good.
We should sycn with marcus.
Yes having first a cleaning classbuilder is a good step.

Stef

On Apr 14, 2011, at 8:18 PM, Toon Verwaest wrote:

> On 04/14/2011 08:09 PM, Stéphane Ducasse wrote:
>> On Apr 14, 2011, at 4:12 PM, Toon Verwaest wrote:
>> 
>>> Be patient, be patient ;)
>>> 
>>> I'm still very busy at the moment, but it'll get there.
>>> 
>>> We'll probably have discuss if you want to generate slot and layout objects 
>>> in the classbuilder, or if you want to replace the instanceVariables array 
>>> with real layout objects that you keep around. We basically implemented 
>>> everything around the layout objects and keep this data in all classes; but 
>>> you'll have to figure out if you want this in Pharo or not. Decide and let 
>>> me know, I'd say ;)
>> you know the answer (we want slots). After this is more a question of
>>  - is the code robust
>>  - what are the migration plans
>>  - do we schedule that for when
>> 
>> Stef
> Well for robustness reasons I suggest to start the port with only layouts and 
> 1 type of slot object (the standard slot object). This slot object will in 
> the first phase not influence compilation at all. We can also (in the first 
> phase) keep the class format exactly the same as it was before, to not 
> interfere with existing tools and code.
> 
> This makes the layouts only metadata that is used by the class builder and 
> the interface between the compiler and classes. The inspector can easily be 
> rewritten to also use the slot metaobjects.
> 
> If we do it in that format, I can tell you that layouts are stable and so is 
> the migration. I can remove the decompilation/recompilation based on Opal for 
> fast method rewriting for now, if you want to avoid too many dependencies at 
> first and test the whole class builder independent of how methods are 
> updated. This is basically just 1 line of code that needs to be changed so I 
> can easily disable that ...
> 
> If you give me an exact plan and an image into which I can bootstrap my 
> classbuilder, I can do this first step by myself. Someone with more knowledge 
> of the whole ecosystem could then help me to smooth out the problems.
> 
> The only thing that isn't working yet atm is the class globals (the class 
> variables), but that isn't really hard; it just needs to be done :)
> I really didn't care about that part, which is why it isn't there yet.
> 
> Obviously my suggestion means that you won't have slots yet in the beginning, 
> but I think that's the safest bet for now. The classbuilder works and doesn't 
> introduce new concepts yet. It just cleans up existing code.
> 
> cheers,
> Toon
> 

Re: [Pharo-project] presentation

[Stéphane Ducasse]

welcome!
There are plenty of things to do.
I would love to see more tests, applying smallLint... better quality process
new frameworks...
Stef


>  Hi Pharo friends, I'm Santiago Bragagnolo from Argentina. (Colleague of some 
> users of this list from Argentina too)
> 
>  I'm currently teaching smalltalk in UTN and getting deep in this amazing 
> world. So, i want to contribute to pharo comunity, fixing issues, developing 
> new features, etc. Ok, how can achive mi goals xD? (too formal? sorry if my 
> english is not enough clear or usual :) ) 
> 
> 
> Greetings.
> 
> Santiago. 
> 
> 

Re: [Pharo-project] Magma

[Stéphane Ducasse]

> 
>> FYI: Chris Muller plans to update Magma for Pharo 1.2
>> 
>> http://lists.squeakfoundation.org/pipermail/magma/2011-April/001756.html
>> 
>> We now get more package maintainers to see value in supporting Pharo
>> and I think this is a good thing
> 
> If you read that entire message, you'll see that he doesn't intend to
> support Pharo beyond 1.2 without either A) compensation or B)
> developers from Pharo to do the support.

Ok then no magma after 1.2 if people do not help. 
This is also ok for me. I do not use magma. May be there is a bigger market in 
Squeak.
Who knows.

Stef

Re: [Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk — Contributors

[laurent laffont]

On Thu, Apr 14, 2011 at 10:05 PM, Diogenes Moreira <
diogenes.more...@gmail.com> wrote:

> Ok.. Well
>
> Diógenes Alberto Moreira
> CTO at Ilon S.A. and CTO at Sociadad Anonima para la Salud S.A. (
> www.ilon.com.ar)
> Contributor on DBXTalk (http://squeakdbx.org), and other projects.
>
> Smalltalker And Pharo's lover :)
>
>
No photo, no entry ;)

Laurent



> Best
>
>
> On Thu, Apr 14, 2011 at 10:46 AM, Mariano Martinez Peck <
> marianop...@gmail.com> wrote:
>
>> if true...then what are you wainting for?
>>
>> http://www.pharo-project.org/community/contributors
>>
>> Send you data and nice picture :)
>>
>> Seriously, it is important for marketing among other things. Imagine you
>> arrive to a new project...it is good to see that there are several
>> contributing to it. Probably this page is not the best, but is something
>> more.
>>
>> Mariano
>>
>>
>>
>> On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont <
>> laurent.laff...@gmail.com> wrote:
>>
>>> Added !
>>>
>>> Laurent.
>>>
>>> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich wrote:
>>>
 Hi Laurent,

 I'd like to be added to
 http://www.pharo-project.org/community/contributors . My picture is
 attached. Description text could be "Contributed the default anti-aliased
 fonts and the SimpleMorphic UI framework. Web page at www.jvuletich.org
 ".

 Thank you.

 Cheers,
 Juan Vuletich

>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>

[Pharo-project] [COTDC] 48 - ClassFactoryForTestCase

[laurent laffont]

 Today:  ClassFactoryForTestCase

Come on guys ! Go Go Go !!


Comment Of The Day Contest - One Day One Comment
Rules:
#1: Each day a not commented class is elected. Each day the best comment
will be integrated with name of the author(s).
#2: If you cannot comment it, deprecate it.
Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest

Laurent

Re: [Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk — Contributors

[Diogenes Moreira]

i forget the picture [image: photo.jpg]

On Thu, Apr 14, 2011 at 5:05 PM, Diogenes Moreira <
diogenes.more...@gmail.com> wrote:

> Ok.. Well
>
> Diógenes Alberto Moreira
> CTO at Ilon S.A. and CTO at Sociadad Anonima para la Salud S.A. (
> www.ilon.com.ar)
> Contributor on DBXTalk (http://squeakdbx.org), and other projects.
>
> Smalltalker And Pharo's lover :)
>
> Best
>
>
> On Thu, Apr 14, 2011 at 10:46 AM, Mariano Martinez Peck <
> marianop...@gmail.com> wrote:
>
>> if true...then what are you wainting for?
>>
>> http://www.pharo-project.org/community/contributors
>>
>> Send you data and nice picture :)
>>
>> Seriously, it is important for marketing among other things. Imagine you
>> arrive to a new project...it is good to see that there are several
>> contributing to it. Probably this page is not the best, but is something
>> more.
>>
>> Mariano
>>
>>
>>
>> On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont <
>> laurent.laff...@gmail.com> wrote:
>>
>>> Added !
>>>
>>> Laurent.
>>>
>>> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich wrote:
>>>
 Hi Laurent,

 I'd like to be added to
 http://www.pharo-project.org/community/contributors . My picture is
 attached. Description text could be "Contributed the default anti-aliased
 fonts and the SimpleMorphic UI framework. Web page at www.jvuletich.org
 ".

 Thank you.

 Cheers,
 Juan Vuletich

>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>
<><>

Re: [Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk — Contributors

[Diogenes Moreira]

Ok.. Well

Diógenes Alberto Moreira
CTO at Ilon S.A. and CTO at Sociadad Anonima para la Salud S.A. (
www.ilon.com.ar)
Contributor on DBXTalk (http://squeakdbx.org), and other projects.

Smalltalker And Pharo's lover :)

Best

On Thu, Apr 14, 2011 at 10:46 AM, Mariano Martinez Peck <
marianop...@gmail.com> wrote:

> if true...then what are you wainting for?
>
> http://www.pharo-project.org/community/contributors
>
> Send you data and nice picture :)
>
> Seriously, it is important for marketing among other things. Imagine you
> arrive to a new project...it is good to see that there are several
> contributing to it. Probably this page is not the best, but is something
> more.
>
> Mariano
>
>
>
> On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont <
> laurent.laff...@gmail.com> wrote:
>
>> Added !
>>
>> Laurent.
>>
>> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich wrote:
>>
>>> Hi Laurent,
>>>
>>> I'd like to be added to
>>> http://www.pharo-project.org/community/contributors . My picture is
>>> attached. Description text could be "Contributed the default anti-aliased
>>> fonts and the SimpleMorphic UI framework. Web page at www.jvuletich.org
>>> ".
>>>
>>> Thank you.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Dale Henrichs]

Cesar,

Good point.

Exception handling code even when using simple class-based exceptions
and exception sets does indeed devolve into CaseOf constructs. Using 
classes, the following code is still common:


   [
   (RangeError new) signal: 'access out of bounds'
   ]
 on: Error
 do: [:ex |
   (ex isKindOf: RangeError)
 ifTrue: [ "do your thang" ]
 ifFalse: [ ex pass ]].

and using ExceptionSets doesn't lead to anything better. At GemStone we 
_have_ added an extention that looks something like the following to get 
away from explicit CaseOf code:


   [
   (NumericError new)
 reason: #rangeError;
 signal: 'access out of bounds'
   ]
 onExceptions: NaNError, RangeError
 do:
   {
 [:naNError | "do something with NANError"].
 [:rangeError | "o something with RangeError"].
   }.

but it's just a different form of CaseOf...I don't think the use of 
reasonCodes is the cause...


To get around this, I guess you'd have to start extending various 
Exception classes with "handler-specific" methods that would allow you 
to double dispatch your way out of the CaseOf construct...


Dale

n 04/14/2011 12:38 PM, csra...@bol.com.br wrote:

Not willing to rattle cages, reading this particular set of postings
I wonder if its my sole feeling or this kind of code 'leads to'
naturally to a screaming need for a CaseOf construct?

In the snippet below submitted by Dale if we have some other
[expected] numeric errors (a.k.a. 'reasons') you would end up with a
very hairy entanglement of ifTrue:[]ifFalse:[], wouldn't you?

my 0.01999.

-- Cesar Rabak


Em 14/04/2011 15:52, Dale Henrichs<  dhenr...@vmware.com>  escreveu:
Stef,

For rangeError the code would look like this:

[ (NumericError new) reason: #rangeError; signal: 'access out of
bounds' ] on: NumericError do: [:ex | ex reasonCode == #rangeError
ifTrue: [ "do your thang" ] ifFalse: [ ex pass ]].

Dale

On 04/14/2011 11:13 AM, Stéphane Ducasse wrote:

Dale

so it means that I write what?

[] on: NumericError do: [:ex | ]

how do I access the rangeError?






Using Sven's hierachy as a starting point and taking some cues
from the GemStone exception hierarchy, I would suggest the
following (names atarting with # are reasonCodes in the namespace
of the parent exception class, instead of a unique class):

Exception (messageText reasonCode) Abort Error NumericError
#floatingPointException #rangeError #naNError ZeroDivide
(dividend) FileStreamException (fileName)
#fileDoesNotExistException #fileExistsException (fileClass)
#cannotDeleteFileException #fileWriteError #fileReadError **
#fileClosedException ** #cannotAccessFileException **
#readonlyFileException ** MessageNotUnderstood (message,
receiver) #nonBooleanReceiver (object) OutOfMemory<   handlers?>
ControlInterrupt Halt AssertionFailure BreakPoint CompileError
SyntaxError ** !exists! (input, position) #numberFormatException
** #headlessError ** TimedOut ** (object, operation, timeout)
VerificationException IllegalOperation ** (operation, object)
#sizeMismatch (objects) #subclassResponsibility ** (message,
receiver) #notYetImplemented ** (message, receiver)
#cannotInstanciate ** (class) #readOnlyObject ** (object)
OutOfFreeSpace ** #invalidArgument ** (message, receiver,
argument) #notIndexable ** (object) #noKeyedAccess ** (object)
#nonIntegerIndex ** (receiver, index) #subscriptOutOfBounds **
(receiver, index, from, to) NotFoundException ** (receiver,
object) #keyNotFound ** #valueNotFound ** #elementNotFound **
StreamException (stream) #positionError ** (index, from, to)
EndOfStream ** #beginOfStream **

Notification Admonition LowMemory **

Re: [Pharo-project] [COTDC] 47 - TAssertable

[laurent laffont]

On Wed, Apr 13, 2011 at 9:53 PM, Mariano Martinez Peck <
marianop...@gmail.com> wrote:

>
>
> On Wed, Apr 13, 2011 at 9:28 PM, laurent laffont <
> laurent.laff...@gmail.com> wrote:
>
>> On Tue, Apr 12, 2011 at 10:14 PM, laurent laffont <
>> laurent.laff...@gmail.com> wrote:
>>
>>>  Today:  TAssertable
>>>
>>
>> Is it used ? Could not find any reference.
>>
>>
> I think it is not used yet. I think it is a Trait so that we can make
> things assertable and not need to subclass from TestCase for example. I may
> expect that TestCase uses such Trait instead of implementing all those
> methods,  but it is not the case. Even more, TAssertable users size -> 0.
>
> So...seems a work half done. Adrian Kuhn introduce it. Check
>
> http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=1294837&query=TAssertable
>
>
OK I put your answer as comment.

Laurent.





> Cheers
>
> Mariano
>
>
>>
>> Laurent.
>>
>>
>>
>>
>>>
>>> Comment Of The Day Contest - One Day One Comment
>>> Rules:
>>> #1: Each day a not commented class is elected. Each day the best comment
>>> will be integrated with name of the author(s).
>>> #2: If you cannot comment it, deprecate it.
>>> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest
>>>
>>> Laurent
>>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>

Re: [Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk — Contributors

[laurent laffont]

Done

Laurent.

On Thu, Apr 14, 2011 at 3:56 PM, Esteban Lorenzano wrote:

> Oh, well...
>
> Esteban Lorenzano
> Owner of Smallworks (http://smallworks.com.ar)
> Author of Mars (http://smallworks.com.ar/en/community/Mars)
> Contributor on several projects, like DBXTalk (http://squeakdbx.org), etc.
> We use Pharo for everything we do :)
>
> And here is my picture:
>
>
>
> El 14/04/2011, a las 10:46a.m., Mariano Martinez Peck escribió:
>
> if true...then what are you wainting for?
>
> http://www.pharo-project.org/community/contributors
>
> Send you data and nice picture :)
>
> Seriously, it is important for marketing among other things. Imagine you
> arrive to a new project...it is good to see that there are several
> contributing to it. Probably this page is not the best, but is something
> more.
>
> Mariano
>
>
>
> On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont <
> laurent.laff...@gmail.com> wrote:
>
>> Added !
>>
>> Laurent.
>>
>> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich wrote:
>>
>>> Hi Laurent,
>>>
>>> I'd like to be added to
>>> http://www.pharo-project.org/community/contributors . My picture is
>>> attached. Description text could be "Contributed the default anti-aliased
>>> fonts and the SimpleMorphic UI framework. Web page at www.jvuletich.org
>>> ".
>>>
>>> Thank you.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>
<>

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Dale Henrichs]

On 04/14/2011 12:04 PM, Henrik Sperre Johansen wrote:

On 14.04.2011 20:52, Dale Henrichs wrote:

Stef,

For rangeError the code would look like this:

   [
   (NumericError new)
 reason: #rangeError;
 signal: 'access out of bounds'
   ]
 on: NumericError
 do: [:ex |
   ex reasonCode == #rangeError
 ifTrue: [ "do your thang" ]
 ifFalse: [ ex pass ]].

Dale


Why not use #tag, which is already ANSI?

Cheers,
Henry



At GemStone we decided not to use tag (we had several cats to skin), but 
tag could certainly be used...


Dale

Re: [Pharo-project] presentation

[laurent laffont]

On Thu, Apr 14, 2011 at 9:16 PM, Santiago Bragagnolo <
santiagobragagn...@gmail.com> wrote:

>
>  Hi Pharo friends, I'm Santiago Bragagnolo from Argentina. (Colleague of
> some users of this list from Argentina too)
>
>  I'm currently teaching smalltalk in UTN and getting deep in this amazing
> world. So, i want to contribute to pharo comunity, fixing issues, developing
> new features, etc. Ok, how can achive mi goals xD? (too formal? sorry if my
> english is not enough clear or usual :) )
>

Hi Santiago,

to fix issues see:
http://www.pharocasts.com/2010/03/how-to-contribute-to-pharo.html

Blogs and documentation are always nice ;)

Laurent.



> Greetings.
>
> Santiago.
>
>
>

Re: [Pharo-project] presentation

[Alexandre Bergel]

Hi Santiago!

Welcome!
Here some links where to start:
http://code.google.com/p/pharo/issues/list
http://www.pharo-project.org/community/issue-tracking

Cheers,
Alexandre


On 14 Apr 2011, at 15:16, Santiago Bragagnolo wrote:

> 
>  Hi Pharo friends, I'm Santiago Bragagnolo from Argentina. (Colleague of some 
> users of this list from Argentina too)
> 
>  I'm currently teaching smalltalk in UTN and getting deep in this amazing 
> world. So, i want to contribute to pharo comunity, fixing issues, developing 
> new features, etc. Ok, how can achive mi goals xD? (too formal? sorry if my 
> english is not enough clear or usual :) ) 
> 
> 
> Greetings.
> 
> Santiago. 
> 
> 

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

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[csrabak]

Not willing to rattle cages, reading this particular set of postings I wonder 
if its my sole feeling or this kind of code 'leads to' naturally to a screaming 
need for a CaseOf construct?

In the snippet below submitted by Dale if we have some other [expected] numeric 
errors (a.k.a. 'reasons') you would end up with a very hairy entanglement of 
ifTrue:[]ifFalse:[], wouldn't you?

my 0.01999.

--
Cesar Rabak


Em 14/04/2011 15:52, Dale Henrichs < dhenr...@vmware.com > escreveu:
Stef,

For rangeError the code would look like this:

 [
 (NumericError new)
 reason: #rangeError;
 signal: 'access out of bounds'
 ]
 on: NumericError
 do: [:ex |
 ex reasonCode == #rangeError
 ifTrue: [ "do your thang" ]
 ifFalse: [ ex pass ]].

Dale

On 04/14/2011 11:13 AM, Stéphane Ducasse wrote:
> Dale
>
> so it means that I write what?
>
> [] on: NumericError do: [:ex | ]
>
> how do I access the rangeError?
>
>
>>>
>>
>> Using Sven's hierachy as a starting point and taking some cues from the 
>> GemStone exception hierarchy, I would suggest the following (names atarting 
>> with # are reasonCodes in the namespace of the parent exception class, 
>> instead of a unique class):
>>
>> Exception (messageText reasonCode)
>>   Abort
>>   Error
>> NumericError
>>   #floatingPointException
>>   #rangeError
>>   #naNError
>>   ZeroDivide (dividend)  
>> FileStreamException (fileName)
>>   #fileDoesNotExistException
>>   #fileExistsException (fileClass)
>>   #cannotDeleteFileException
>>   #fileWriteError
>>   #fileReadError **
>>   #fileClosedException **
>>   #cannotAccessFileException **
>>   #readonlyFileException **
>> MessageNotUnderstood (message, receiver)
>> #nonBooleanReceiver (object)
>> OutOfMemory<  handlers?>
>> ControlInterrupt
>>   Halt
>> AssertionFailure
>>   BreakPoint
>> CompileError
>>   SyntaxError ** !exists! (input, position)
>> #numberFormatException **
>> #headlessError **
>> TimedOut ** (object, operation, timeout)
>> VerificationException
>> IllegalOperation ** (operation, object)
>> #sizeMismatch (objects)
>> #subclassResponsibility ** (message, receiver)
>> #notYetImplemented ** (message, receiver)
>> #cannotInstanciate ** (class)
>> #readOnlyObject ** (object)
>> OutOfFreeSpace **
>> #invalidArgument ** (message, receiver, argument)
>> #notIndexable ** (object)
>> #noKeyedAccess ** (object)
>> #nonIntegerIndex ** (receiver, index)
>> #subscriptOutOfBounds ** (receiver, index, from, to)
>> NotFoundException ** (receiver, object)
>>   #keyNotFound **
>>   #valueNotFound **
>>   #elementNotFound **
>> StreamException (stream)
>>   #positionError ** (index, from, to)
>>   EndOfStream **
>>   #beginOfStream **
>>
>>   Notification
>> Admonition
>>   LowMemory **
>>
>
>

Re: [Pharo-project] Magma

[Elliot Finley]

On Thu, Apr 14, 2011 at 1:51 AM, Torsten Bergmann  wrote:
> FYI: Chris Muller plans to update Magma for Pharo 1.2
>
> http://lists.squeakfoundation.org/pipermail/magma/2011-April/001756.html
>
> We now get more package maintainers to see value in supporting Pharo
> and I think this is a good thing

If you read that entire message, you'll see that he doesn't intend to
support Pharo beyond 1.2 without either A) compensation or B)
developers from Pharo to do the support.

[Pharo-project] Issue 4023 in pharo: 'Transcript clear' prints 'Transcript' after clearing prior text

[pharo]

Status: New
Owner: 

New issue 4023 by dougedmu...@gmail.com: 'Transcript clear'  
prints 'Transcript' after clearing prior text

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

Pharo image: Pharo | Pharo-core
Pharo core version: Pharo1.3a
Latest update: #13144

Virtual machine used: PHaro4.1.1 on Win32
Class browser used (if applicable): "SystemBrowser default"

Steps to reproduce:
1. Open a transcript
2. Open a workspace. Send some text to transcript, i.e.,
   Transcript show: 'hello'; cr.
3. Type 'Transcript clear.' in workspace

Result:
All prior text removed, but now the word "Transcript" appears.

[Pharo-project] presentation

[Santiago Bragagnolo]

 Hi Pharo friends, I'm Santiago Bragagnolo from Argentina. (Colleague of
some users of this list from Argentina too)

 I'm currently teaching smalltalk in UTN and getting deep in this amazing
world. So, i want to contribute to pharo comunity, fixing issues, developing
new features, etc. Ok, how can achive mi goals xD? (too formal? sorry if my
english is not enough clear or usual :) )


Greetings.

Santiago.

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Henrik Sperre Johansen]

On 14.04.2011 20:52, Dale Henrichs wrote:

Stef,

For rangeError the code would look like this:

  [
  (NumericError new)
reason: #rangeError;
signal: 'access out of bounds'
  ]
on: NumericError
do: [:ex |
  ex reasonCode == #rangeError
ifTrue: [ "do your thang" ]
ifFalse: [ ex pass ]].

Dale


Why not use #tag, which is already ANSI?

Cheers,
Henry

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Dale Henrichs]

On 04/14/2011 11:38 AM, Sven Van Caekenberghe wrote:

Dale,

I think I understand some of your points, there based on valid concerns. We 
should end up with a minimal set of exceptions. The current set was not that 
large IMHO. But here and there some simplifications are possible.

Thanks for submitting a concrete alternative hierarchy.

However, it feels as if the reasons between using a class and a selector are a 
bit arbitrary. I can't make sense out of it.

Another thing that hasn't been discussed so far is what data should go in each 
exception.

This has to be done on a blackboard with a couple of people. And it won't be 
finished in one go either, far from it.

I'll print out your hierarchy as well !

Sven


Sven,

The names with leading $# were intended to be reasonCodes and with no 
leading $# a class name ...


When I editted the list I wasn't thinking very hard:), but I made a best 
guess based on what I thought the name entailed (and we had touched on 
some of the same things in our GemStone discussions)...So I wouldn't put 
much weight on the specifics in my suggestions, I think you get the 
general idea ...


the more important information was in my suggested guidelines ... the 
decisions should be driven by the needs of the existing Pharo code base 
both the core and the applications written against the core ...


BTW, I fully support what you are trying to do and building a good 
usable Exception hierarchy is important ... I just wanted to inject a 
suggestion or two for consideration...


Dale

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Dale Henrichs]

Stef,

For rangeError the code would look like this:

  [
  (NumericError new)
reason: #rangeError;
signal: 'access out of bounds'
  ]
on: NumericError
do: [:ex |
  ex reasonCode == #rangeError
ifTrue: [ "do your thang" ]
ifFalse: [ ex pass ]].

Dale

On 04/14/2011 11:13 AM, Stéphane Ducasse wrote:

Dale

so it means that I write what?

[] on: NumericError do: [:ex | ]

how do I access the rangeError?






Using Sven's hierachy as a starting point and taking some cues from the 
GemStone exception hierarchy, I would suggest the following (names atarting 
with # are reasonCodes in the namespace of the parent exception class, instead 
of a unique class):

Exception (messageText reasonCode)
  Abort
  Error
NumericError
  #floatingPointException
  #rangeError
  #naNError
  ZeroDivide (dividend) 
FileStreamException (fileName)
  #fileDoesNotExistException
  #fileExistsException (fileClass)
  #cannotDeleteFileException
  #fileWriteError
  #fileReadError **
  #fileClosedException **
  #cannotAccessFileException **
  #readonlyFileException **
MessageNotUnderstood (message, receiver)
#nonBooleanReceiver (object)
OutOfMemory<  handlers?>
ControlInterrupt
  Halt
AssertionFailure
  BreakPoint
CompileError
  SyntaxError ** !exists! (input, position)
#numberFormatException **
#headlessError **
TimedOut ** (object, operation, timeout)
VerificationException
IllegalOperation ** (operation, object)
#sizeMismatch (objects)
#subclassResponsibility ** (message, receiver)
#notYetImplemented ** (message, receiver)
#cannotInstanciate ** (class)
#readOnlyObject ** (object)
OutOfFreeSpace **
#invalidArgument ** (message, receiver, argument)
#notIndexable ** (object)
#noKeyedAccess ** (object)
#nonIntegerIndex ** (receiver, index)
#subscriptOutOfBounds ** (receiver, index, from, to)
NotFoundException ** (receiver, object)
  #keyNotFound **
  #valueNotFound **
  #elementNotFound **
StreamException (stream)
  #positionError ** (index, from, to)
  EndOfStream **
  #beginOfStream **

  Notification
Admonition
  LowMemory **

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Sven Van Caekenberghe]

Dale,

I think I understand some of your points, there based on valid concerns. We 
should end up with a minimal set of exceptions. The current set was not that 
large IMHO. But here and there some simplifications are possible.

Thanks for submitting a concrete alternative hierarchy.

However, it feels as if the reasons between using a class and a selector are a 
bit arbitrary. I can't make sense out of it.

Another thing that hasn't been discussed so far is what data should go in each 
exception.

This has to be done on a blackboard with a couple of people. And it won't be 
finished in one go either, far from it.

I'll print out your hierarchy as well !

Sven

On 14 Apr 2011, at 18:07, Dale Henrichs wrote:

> Using Sven's hierachy as a starting point and taking some cues from the 
> GemStone exception hierarchy, I would suggest the following (names atarting 
> with # are reasonCodes in the namespace of the parent exception class, 
> instead of a unique class):
> 
> Exception (messageText reasonCode)
>  Abort
>  Error
>NumericError
>  #floatingPointException
>  #rangeError
>  #naNError
>  ZeroDivide (dividend)
>FileStreamException (fileName)
>  #fileDoesNotExistException
>  #fileExistsException (fileClass)
>  #cannotDeleteFileException
>  #fileWriteError
>  #fileReadError **
>  #fileClosedException **
>  #cannotAccessFileException **
>  #readonlyFileException **
>MessageNotUnderstood (message, receiver)
>#nonBooleanReceiver (object)
>OutOfMemory < handlers?>
>ControlInterrupt
>  Halt
>AssertionFailure
>  BreakPoint
>CompileError
>  SyntaxError ** !exists! (input, position)
>#numberFormatException **
>#headlessError **
>TimedOut ** (object, operation, timeout)
>VerificationException
>IllegalOperation ** (operation, object)
>#sizeMismatch (objects)
>#subclassResponsibility ** (message, receiver)
>#notYetImplemented ** (message, receiver)
>#cannotInstanciate ** (class)
>#readOnlyObject ** (object)
>OutOfFreeSpace ** 
>#invalidArgument ** (message, receiver, argument)
>#notIndexable ** (object)
>#noKeyedAccess ** (object)
>#nonIntegerIndex ** (receiver, index)
>#subscriptOutOfBounds ** (receiver, index, from, to)
>NotFoundException ** (receiver, object)
>  #keyNotFound **
>  #valueNotFound **
>  #elementNotFound **
>StreamException (stream)
>  #positionError ** (index, from, to)
>  EndOfStream **
>  #beginOfStream **
> 
>  Notification
>Admonition
>  LowMemory ** 

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Miguel Cobá]

El jue, 14-04-2011 a las 20:13 +0200, Stéphane Ducasse escribió:
> Dale 
> 
> so it means that I write what?
> 
> [] on: NumericError do: [:ex | ]
> 
> how do I access the rangeError?

[] on: NumericError do: [ :ex | ex reasonCode "This gets you #rangeError
or any other symbol to detail the exception" ]

Cheers


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

Re: [Pharo-project] Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy

[Toon Verwaest]

On 04/14/2011 08:09 PM, Stéphane Ducasse wrote:

On Apr 14, 2011, at 4:12 PM, Toon Verwaest wrote:


Be patient, be patient ;)

I'm still very busy at the moment, but it'll get there.

We'll probably have discuss if you want to generate slot and layout objects in 
the classbuilder, or if you want to replace the instanceVariables array with 
real layout objects that you keep around. We basically implemented everything 
around the layout objects and keep this data in all classes; but you'll have to 
figure out if you want this in Pharo or not. Decide and let me know, I'd say ;)

you know the answer (we want slots). After this is more a question of
- is the code robust
- what are the migration plans
- do we schedule that for when

Stef
Well for robustness reasons I suggest to start the port with only 
layouts and 1 type of slot object (the standard slot object). This slot 
object will in the first phase not influence compilation at all. We can 
also (in the first phase) keep the class format exactly the same as it 
was before, to not interfere with existing tools and code.


This makes the layouts only metadata that is used by the class builder 
and the interface between the compiler and classes. The inspector can 
easily be rewritten to also use the slot metaobjects.


If we do it in that format, I can tell you that layouts are stable and 
so is the migration. I can remove the decompilation/recompilation based 
on Opal for fast method rewriting for now, if you want to avoid too many 
dependencies at first and test the whole class builder independent of 
how methods are updated. This is basically just 1 line of code that 
needs to be changed so I can easily disable that ...


If you give me an exact plan and an image into which I can bootstrap my 
classbuilder, I can do this first step by myself. Someone with more 
knowledge of the whole ecosystem could then help me to smooth out the 
problems.


The only thing that isn't working yet atm is the class globals (the 
class variables), but that isn't really hard; it just needs to be done :)

I really didn't care about that part, which is why it isn't there yet.

Obviously my suggestion means that you won't have slots yet in the 
beginning, but I think that's the safest bet for now. The classbuilder 
works and doesn't introduce new concepts yet. It just cleans up existing 
code.


cheers,
Toon

Re: [Pharo-project] About float: new chapter looking for reader and contributors

[Stéphane Ducasse]

On Apr 14, 2011, at 11:31 AM, Nicolas Cellier wrote:

> I created a git account last night but must install latex on my mac.

you can also just write and I will latex it. There is no problem.

> I don't have your rythm :)

:)
But you are doing a lot of things too.
Sometimes I have the impression that I could be more focused and it would be 
better
but the system does not give me this chance.
Stef

Re: [Pharo-project] isHealthy

[Stéphane Ducasse]

Ok in fact I should have check do: first and I will change thses users of do: 
to replace with doValues: 
because I was following a wrong road because of it.

Stef



>>> 
>>> dict array == nil
>>> should not happen, but
>>> (dict array at: someindex ) == nil
>>> is quite normal.
>> I do not know I have a do: loop and some elements are nil and break the loop.
>> 
>> Stef
> 
> do: iterates the values in the Dictionary, and yes, it's perfectly valid to 
> have a pair someKey -> nil in the dictionary.
> Why you have it (ie who put it there), and if it should be valid in your 
> case, you'd have to figure out :)
> 
> Cheers,
> Henry
> 

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Stéphane Ducasse]

Dale 

so it means that I write what?

[] on: NumericError do: [:ex | ]

how do I access the rangeError?


>> 
> 
> Using Sven's hierachy as a starting point and taking some cues from the 
> GemStone exception hierarchy, I would suggest the following (names atarting 
> with # are reasonCodes in the namespace of the parent exception class, 
> instead of a unique class):
> 
> Exception (messageText reasonCode)
>  Abort
>  Error
>NumericError
>  #floatingPointException
>  #rangeError
>  #naNError
>  ZeroDivide (dividend)
>FileStreamException (fileName)
>  #fileDoesNotExistException
>  #fileExistsException (fileClass)
>  #cannotDeleteFileException
>  #fileWriteError
>  #fileReadError **
>  #fileClosedException **
>  #cannotAccessFileException **
>  #readonlyFileException **
>MessageNotUnderstood (message, receiver)
>#nonBooleanReceiver (object)
>OutOfMemory < handlers?>
>ControlInterrupt
>  Halt
>AssertionFailure
>  BreakPoint
>CompileError
>  SyntaxError ** !exists! (input, position)
>#numberFormatException **
>#headlessError **
>TimedOut ** (object, operation, timeout)
>VerificationException
>IllegalOperation ** (operation, object)
>#sizeMismatch (objects)
>#subclassResponsibility ** (message, receiver)
>#notYetImplemented ** (message, receiver)
>#cannotInstanciate ** (class)
>#readOnlyObject ** (object)
>OutOfFreeSpace ** 
>#invalidArgument ** (message, receiver, argument)
>#notIndexable ** (object)
>#noKeyedAccess ** (object)
>#nonIntegerIndex ** (receiver, index)
>#subscriptOutOfBounds ** (receiver, index, from, to)
>NotFoundException ** (receiver, object)
>  #keyNotFound **
>  #valueNotFound **
>  #elementNotFound **
>StreamException (stream)
>  #positionError ** (index, from, to)
>  EndOfStream **
>  #beginOfStream **
> 
>  Notification
>Admonition
>  LowMemory ** 
> 

Re: [Pharo-project] Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy

[Stéphane Ducasse]

On Apr 14, 2011, at 4:12 PM, Toon Verwaest wrote:

> Be patient, be patient ;)
> 
> I'm still very busy at the moment, but it'll get there.
> 
> We'll probably have discuss if you want to generate slot and layout objects 
> in the classbuilder, or if you want to replace the instanceVariables array 
> with real layout objects that you keep around. We basically implemented 
> everything around the layout objects and keep this data in all classes; but 
> you'll have to figure out if you want this in Pharo or not. Decide and let me 
> know, I'd say ;)

you know the answer (we want slots). After this is more a question of
- is the code robust
- what are the migration plans
- do we schedule that for when

Stef

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Hernan Wilkinson]

On Thu, Apr 14, 2011 at 1:38 PM, Alexandre Bergel
wrote:

> > I think you said it right here: "having classes for all _relevant_
> concepts actually pays off"...
>
> I do not quite agree on this. Responsibility should be the driver, not the
> concepts.
>

that is a good point

>
> Alexandre
>
>
> > Related to exceptions, my question is:  what are all the different
> concepts you have? for example, not finding a Key or not finding a Value are
> really different concepts? or is it the same (not finding something) that
> depending on the context (finding a value or a key) is what looks like they
> are different? if so, then there is only one concept (i.e. not finding an
> object), if it is a key or a value is accidental, contextual to what you are
> looking for.
> > So, I completely agree when you say "having classes for all relevant
> concepts"... I think we do not agree on what are the relevant concepts when
> we talk about exceptions...
> >
> >
> > Toon
> >
> >
> > On 04/14/2011 01:00 AM, Dale Henrichs wrote:
> > On 04/13/2011 02:58 PM, Toon Verwaest wrote:
> > Is it such a problem if you duplicate a certain exception class? At the
> > moment you'll do the same anyway by not completely writing the exact
> > same symbol.
> >
> > It's a simple matter of namespaces and volume of names ... with a large
> open ended namespace you are more likely to have a number of redundant names
> with slight differences in spelling showing up in different spots in the
> hierarchy...with a logically segmented namespace each segment will have a
> manageable number of names and the risk of duplication is reduced ... end of
> discussion ...
> >
> > 10,000 names vs 30 names ... I can easily recognize duplicates in a list
> of 30 names ... not so easy in 10,000 ... that is all ...
> >
> > to attempt to map every possible error condition onto a class will lead
> you to 10,000 much quicker than using reasonCodes ... that is all ...
> >
> > I don't hate classes, it is a _practical_ matter ... if _you_ would
> rather manage 10,000 names then I will say that it isn't practical ... I'm
> _not_ saying it is _wrong_, just not _practical_.
> >
> >
> > And if the problem is not finding classes anymore, maybe we need a
> > better way of organizing the exception classes away from the standard
> > classes so that they are as non-intrusive as symbols, but convey more
> > information?
> >
> > And now you've hit the nail on the head ... in order to handle the extra
> complexity you need additional tools ... before creating more tools, ask
> your self the simple question: "Do I _need_ the additional complexity?" ...
> if the answer is yes, then create the tool, if the answer is no, then you
> don't need to create a new tool ..
> >
> > Again, this is a _practical_ matter...
> >
> >
> > self error: #keyNotFound
> > does not really give much information; and isn't much more difficult to
> > write than:
> > KeyNotFoundException new in: self; key: key; signal
> >
> > From a practical perspective how many exception handlers will be written
> to handle KeyNotFoundException ... I use at:ifAbsent: when I'm doing a look
> up that I think might fail ... better than writing an exception handler ...
> >
> > If there is a real need to write a handler for KeyNotFoundException, then
> by all means create the class, but until you actually NEED
> KeyNotFoundException, `self error: #keyNotFound` or `NotFoundException
> signal: #keyNotFound` will work just fine...
> >
> > although the second one gives you all the contextual information that
> > the first one misses.
> >
> > _If_ you NEED the additional contextual information. It's just like
> writing a framework that no uses ... there's nothing wrong with the idea or
> the implementation, it's just that the framework didn't solve a problem that
> anyone had...
> >
> > If you are going to create a class, I think the least it should do is
> address an real problem, not an imaginary one.
> >
> > To say that "if one were to handle the KeyNotFoundException, they will
> need the complete context", I prefer to say "Until one needs the complete
> context of the KeyNotFoundException, don't bother creating class"
> >
> >
> > What I mean mostly: what about trying to figure out why you want to
> > avoid decent exception classes and tackling that problem?
> >
> > Depends upon what your definition of a decent exception classes is? My
> argument is simply that it is not _necessary_ to create a unique class for
> every unique error condition ... I think that folks should answer the
> question: "Will anyone every write an exception handler for this exception"
> before creating the class ... if the answer is yes (or better yet, I am
> writing code right now and need that exception) then by all means create the
> class.
> >
> > Maybe we don't want classes but exception objects that can pool data
> > together? Maybe a very silly idea: what about just exception "classes"
> > that have dictionaries to store enough information?
> >
> > Tha

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Dale Henrichs]

On 04/14/2011 05:08 AM, Toon Verwaest wrote:

Right, so you confirm the experience of Dale.

In the case of flagging errors without classes, do you generally just
use a simple symbol, or concatenate strings to convey more details? This
last seems somehow a bad idea... but maybe if it's never caught it's not
so relevant?



Using Sven's hierachy as a starting point and taking some cues from the 
GemStone exception hierarchy, I would suggest the following (names 
atarting with # are reasonCodes in the namespace of the parent exception 
class, instead of a unique class):


Exception (messageText reasonCode)
  Abort
  Error
NumericError
  #floatingPointException
  #rangeError
  #naNError
  ZeroDivide (dividend) 
FileStreamException (fileName)
  #fileDoesNotExistException
  #fileExistsException (fileClass)
  #cannotDeleteFileException
  #fileWriteError
  #fileReadError **
  #fileClosedException **
  #cannotAccessFileException **
  #readonlyFileException **
MessageNotUnderstood (message, receiver)
#nonBooleanReceiver (object)
OutOfMemory < handlers?>
ControlInterrupt
  Halt
AssertionFailure
  BreakPoint
CompileError
  SyntaxError ** !exists! (input, position)
#numberFormatException **
#headlessError **
TimedOut ** (object, operation, timeout)
VerificationException
IllegalOperation ** (operation, object)
#sizeMismatch (objects)
#subclassResponsibility ** (message, receiver)
#notYetImplemented ** (message, receiver)
#cannotInstanciate ** (class)
#readOnlyObject ** (object)
OutOfFreeSpace ** 
#invalidArgument ** (message, receiver, argument)
#notIndexable ** (object)
#noKeyedAccess ** (object)
#nonIntegerIndex ** (receiver, index)
#subscriptOutOfBounds ** (receiver, index, from, to)
NotFoundException ** (receiver, object)
  #keyNotFound **
  #valueNotFound **
  #elementNotFound **
StreamException (stream)
  #positionError ** (index, from, to)
  EndOfStream **
  #beginOfStream **

  Notification
Admonition
  LowMemory ** 

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Miguel Cobá]

El jue, 14-04-2011 a las 08:50 -0700, Dale Henrichs escribió:

> For the Exception framework I think the following guidelines should apply:
> 
>1. Each unique error _should_ be uniquely identified and the current
>   mechanism of providing a string argument to the #error: message is
>   not sufficient.
>2. Specific handlers will not be written for most errors, so it isn't
>   absolutely necessary to create a unique exception class for all
>   errors
>3. If specific handlers exist (doing string parsing now) or there is a
>   reasonable case made that specific handlers are likely to written,
>   then a unique exception class should be created.
>4. reasonCodes (within the namespace of an exception class or
>   subhierarcy) can be used to uniquely identify an error condition,
>   when a unique class isn't called for.
>5. In the fullness of time, if a case is found where a reasonCode
>   should be turned into a unique exception class, then the class
>   should be created.
> 
> These guidelines should help keep the Exception hierarchy as small as is 
> needed, but allow expansion as well.
> 
> Keep in mind that the primary purpose of the Exception is to allow code 
> to be written that automates the handling of the exception. Developers 
> don't need Exceptions to debug/develop applications ... the debugger 
> provides all of the information that a developer needs ...So the 
> exception is there when a developer cannot look at the stack and must 
> write code to report the error to a log, an end user, or take corrective 
> action  for an error report, the exception class and reasonCode is 
> sufficient information for a developer to go back to the code and 
> determine the call site ...
> 

Very well put. I think that those guidelines will permit to evolve the
current Exception framework in Pharo and avoid ending with an
over-engineered and commite-dictated set of seldom used exception
classes.
Thanks Dale
-- 
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx

Re: [Pharo-project] Document on UIBuilder Tool

[Mariano Martinez Peck]

On Wed, Apr 13, 2011 at 8:02 PM, sourav roy  wrote:

> Hi all,
>
>
Hi.



> Can any suggest me some documents on-
> 1.UIBuilder Tool
>

There was a recent thread in the mailing list.
http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=1294836&query=UIBuilder


> 2.UI/Morph Class
> 3.Database Connection Programming using Pharo.
>

DBXTalk: www.squeakdbx.org
For more options, you can see:
http://book.pharo-project.org/book/PharoTools/
and most from here : http://www.seaside.st/documentation/persistence
are not seaside only..

Cheers

mariano


>
> Thanks&Regards,
> Sourav Roy
> Bangalore-India
>
>
>
> Get Yourself a cool, short *@in.com* Email ID 
> now!
>



-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-project] Issue 4018 in pharo: Color class enhancement

[pharo]

Comment #4 on issue 4018 by alexandr...@gmail.com: Color class enhancement
http://code.google.com/p/pharo/issues/detail?id=4018

A new version of ColorEnh.2.cs without the mondrian method category. Thanks  
Torsten for seeing this.


Attachments:
ColorEnh.2.cs  1.6 KB

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Dale Henrichs]

On 04/14/2011 01:33 AM, Toon Verwaest wrote:

Somehow I feel like I offended someone :)


Not at all ... I like to wave my arms, talk passionately and draw all 
over a white board ... all things that are difficult to do in an email:)




I personally don't have experience with 10'000+ classes in a system. I
do understand that's where you are coming from and do appreciate the
insight.

My personal experience has rather been the opposite until now. For
example the Pharo/Squeak classbuilder is 1 single class doing
everything. This is horrible; not just horrible because the code is
completely horrid but it's non-extensible, non-configurable,
non-reusable, contains tons of duplication _just because_ it is all put
into one big ball of mud. By decomposing the classbuilder into 4 to 10
different classes I ended up having very little methods with very little
code, and a very high level of configurability and understandability. I
now actually use this classbuilder to build anonymous classes too,
avoiding the whole problem with forgetting to copy in the format that
everyone seems to have.


Monolithic classes are difficult to maintain and hard to extend ... I am 
whole heartedly in favor of using classes, just take a look at 
Metacello: ~300 classes including a dozen exception classes.


My main message is that it is generally a bad idea to build a framework 
when one isn't needed.


One shouldn't be shy about creating multiple classes to do a job, when 
they are called for.


On the other hand, one shouldn't create a framework of classes until 
such a frame work is called for.


For the Exception framework I think the following guidelines should apply:

  1. Each unique error _should_ be uniquely identified and the current
 mechanism of providing a string argument to the #error: message is
 not sufficient.
  2. Specific handlers will not be written for most errors, so it isn't
 absolutely necessary to create a unique exception class for all
 errors
  3. If specific handlers exist (doing string parsing now) or there is a
 reasonable case made that specific handlers are likely to written,
 then a unique exception class should be created.
  4. reasonCodes (within the namespace of an exception class or
 subhierarcy) can be used to uniquely identify an error condition,
 when a unique class isn't called for.
  5. In the fullness of time, if a case is found where a reasonCode
 should be turned into a unique exception class, then the class
 should be created.

These guidelines should help keep the Exception hierarchy as small as is 
needed, but allow expansion as well.


Keep in mind that the primary purpose of the Exception is to allow code 
to be written that automates the handling of the exception. Developers 
don't need Exceptions to debug/develop applications ... the debugger 
provides all of the information that a developer needs ...So the 
exception is there when a developer cannot look at the stack and must 
write code to report the error to a log, an end user, or take corrective 
action  for an error report, the exception class and reasonCode is 
sufficient information for a developer to go back to the code and 
determine the call site ...




And this experience was showing me that having classes for all
_relevant_ concepts actually pays off in the long run. Since you (and
others) are saying that it doesn't for exceptions; and since I don't
have enough experience there I'll take your advice into account when
writing code ;)


Agreed 100% ... we all have to use judgment when writing our code, so 
having a little more information never hurts (unless you're wacked by a 
waving arm:)...


Dale

Re: [Pharo-project] Issue 3984 in pharo: Announcements announced when a test is runned

[pharo]

Comment #6 on issue 3984 by benjamin...@gmail.com: Announcements announced  
when a test is runned

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

A little fix in addition of the previous one

Attachments:
FixTestCaseAnnouncement.1.cs  974 bytes

Re: [Pharo-project] Issue 3984 in pharo: Announcements announced when a test is runned

[pharo]

Updates:
Status: FixProposed

Comment #5 on issue 3984 by benjamin...@gmail.com: Announcements announced  
when a test is runned

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

A new version of announcements for TestCase

The first one can be forgotten

Attachments:
TestCaseAnnouncements.1.cs  3.6 KB

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Alexandre Bergel]

> I think you said it right here: "having classes for all _relevant_ concepts 
> actually pays off"... 

I do not quite agree on this. Responsibility should be the driver, not the 
concepts.

Alexandre


> Related to exceptions, my question is:  what are all the different concepts 
> you have? for example, not finding a Key or not finding a Value are really 
> different concepts? or is it the same (not finding something) that depending 
> on the context (finding a value or a key) is what looks like they are 
> different? if so, then there is only one concept (i.e. not finding an 
> object), if it is a key or a value is accidental, contextual to what you are 
> looking for.
> So, I completely agree when you say "having classes for all relevant 
> concepts"... I think we do not agree on what are the relevant concepts when 
> we talk about exceptions...
>  
> 
> Toon
> 
> 
> On 04/14/2011 01:00 AM, Dale Henrichs wrote:
> On 04/13/2011 02:58 PM, Toon Verwaest wrote:
> Is it such a problem if you duplicate a certain exception class? At the
> moment you'll do the same anyway by not completely writing the exact
> same symbol.
> 
> It's a simple matter of namespaces and volume of names ... with a large open 
> ended namespace you are more likely to have a number of redundant names with 
> slight differences in spelling showing up in different spots in the 
> hierarchy...with a logically segmented namespace each segment will have a 
> manageable number of names and the risk of duplication is reduced ... end of 
> discussion ...
> 
> 10,000 names vs 30 names ... I can easily recognize duplicates in a list of 
> 30 names ... not so easy in 10,000 ... that is all ...
> 
> to attempt to map every possible error condition onto a class will lead you 
> to 10,000 much quicker than using reasonCodes ... that is all ...
> 
> I don't hate classes, it is a _practical_ matter ... if _you_ would rather 
> manage 10,000 names then I will say that it isn't practical ... I'm _not_ 
> saying it is _wrong_, just not _practical_.
> 
> 
> And if the problem is not finding classes anymore, maybe we need a
> better way of organizing the exception classes away from the standard
> classes so that they are as non-intrusive as symbols, but convey more
> information?
> 
> And now you've hit the nail on the head ... in order to handle the extra 
> complexity you need additional tools ... before creating more tools, ask your 
> self the simple question: "Do I _need_ the additional complexity?" ... if the 
> answer is yes, then create the tool, if the answer is no, then you don't need 
> to create a new tool ..
> 
> Again, this is a _practical_ matter...
> 
> 
> self error: #keyNotFound
> does not really give much information; and isn't much more difficult to
> write than:
> KeyNotFoundException new in: self; key: key; signal
> 
> From a practical perspective how many exception handlers will be written to 
> handle KeyNotFoundException ... I use at:ifAbsent: when I'm doing a look up 
> that I think might fail ... better than writing an exception handler ...
> 
> If there is a real need to write a handler for KeyNotFoundException, then by 
> all means create the class, but until you actually NEED KeyNotFoundException, 
> `self error: #keyNotFound` or `NotFoundException signal: #keyNotFound` will 
> work just fine...
> 
> although the second one gives you all the contextual information that
> the first one misses.
> 
> _If_ you NEED the additional contextual information. It's just like writing a 
> framework that no uses ... there's nothing wrong with the idea or the 
> implementation, it's just that the framework didn't solve a problem that 
> anyone had...
> 
> If you are going to create a class, I think the least it should do is address 
> an real problem, not an imaginary one.
> 
> To say that "if one were to handle the KeyNotFoundException, they will need 
> the complete context", I prefer to say "Until one needs the complete context 
> of the KeyNotFoundException, don't bother creating class"
> 
> 
> What I mean mostly: what about trying to figure out why you want to
> avoid decent exception classes and tackling that problem?
> 
> Depends upon what your definition of a decent exception classes is? My 
> argument is simply that it is not _necessary_ to create a unique class for 
> every unique error condition ... I think that folks should answer the 
> question: "Will anyone every write an exception handler for this exception" 
> before creating the class ... if the answer is yes (or better yet, I am 
> writing code right now and need that exception) then by all means create the 
> class.
> 
> Maybe we don't want classes but exception objects that can pool data
> together? Maybe a very silly idea: what about just exception "classes"
> that have dictionaries to store enough information?
> 
> That would be another way of doing things ... although using exception 
> classes and reasonCodes is pretty close to all that is needed...
> 
> I agree w

Re: [Pharo-project] Issue 4016 in pharo: Monticello Announcements

[pharo]

Comment #2 on issue 4016 by benjamin...@gmail.com: Monticello Announcements
http://code.google.com/p/pharo/issues/detail?id=4016

What do you mean by context ?


A new cs with a new announcer, you can take only this one and ignore the  
first one


Attachments:
MonticelloAnnouncements2.1.cs  3.3 KB

Re: [Pharo-project] [Pharo-users] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk — Contributors

[Adrian Lienhard]

I think the most important thing is to make all pictures the same width and 
height. Then I wouldn't do a table, but rather add filters. For instance, this 
would allow the visitor to filter for people by country and possibly other 
properties (like university, industry, ...). Another improvement would be to 
print the names as a heading (they are just normal text now).

If somebody likes to help with this, pls contact me.

Adrian

On Apr 14, 2011, at 16:42 , laurent laffont wrote:

> On Thu, Apr 14, 2011 at 4:29 PM, Mariano Martinez Peck <
> marianop...@gmail.com> wrote:
> 
>> 
>> 
>> On Thu, Apr 14, 2011 at 4:26 PM, Serge Stinckwich <
>> serge.stinckw...@gmail.com> wrote:
>> 
>>> I think it's a great idea to have a picture and short description.
>>> Maybe we could have something more uniform with the same size for each
>>> picture ?
>>> 
>> 
>> Yes sure, and maybe put a kind of table were each of us is a row, and all
>> data is one column and the picture is another one. So they are aligned.
>> 
> 
> We should just adapt the CSS. I don't know how to modify it in CMSBox.
> 
> Laurent
> 
> 
> 
>> But first the first :)  Get the contributors and then we take care about
>> the make up ehehe
>> 
>> Laurent may be able to take care about the makeup ?
>> 
> 
>> Cheers
>> 
>> Mariano
>> 
>> 
>>> Regards,
>>> 
>>> On Thu, Apr 14, 2011 at 8:46 PM, Mariano Martinez Peck
>>>  wrote:
 if true...then what are you wainting for?
 
 http://www.pharo-project.org/community/contributors
 
 Send you data and nice picture :)
 
 Seriously, it is important for marketing among other things. Imagine you
 arrive to a new project...it is good to see that there are several
 contributing to it. Probably this page is not the best, but is something
 more.
 
 Mariano
 
 
 
 On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont <
>>> laurent.laff...@gmail.com>
 wrote:
> 
> Added !
> Laurent.
> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich 
>>> wrote:
>> 
>> Hi Laurent,
>> 
>> I'd like to be added to
>> http://www.pharo-project.org/community/contributors . My picture is
>> attached. Description text could be "Contributed the default
>>> anti-aliased
>> fonts and the SimpleMorphic UI framework. Web page at
>>> www.jvuletich.org".
>> 
>> Thank you.
>> 
>> Cheers,
>> Juan Vuletich
> 
 
 
 
 --
 Mariano
 http://marianopeck.wordpress.com
 
 
>>> 
>>> 
>>> 
>>> --
>>> Serge Stinckwich
>>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
>>> Every DSL ends up being Smalltalk
>>> http://doesnotunderstand.org/
>>> 
>> 
>> 
>> 
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>> 
>> 

Re: [Pharo-project] Meanwhile, at another vm

[Michael Haupt]

Hi,

On 14 April 2011 16:40, Norbert Hartl  wrote:
>> But we're probably rather off-topic by now. ;-)
>
> No, the subject is "Meanwhile, at another vm". Quite flexible and welcoming 
> to all sorts of discussions :)

all right then. Here we go. :-D

Best,

Michael

Re: [Pharo-project] [Pharo-users] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk — Contributors

[laurent laffont]

On Thu, Apr 14, 2011 at 4:29 PM, Mariano Martinez Peck <
marianop...@gmail.com> wrote:

>
>
> On Thu, Apr 14, 2011 at 4:26 PM, Serge Stinckwich <
> serge.stinckw...@gmail.com> wrote:
>
>> I think it's a great idea to have a picture and short description.
>> Maybe we could have something more uniform with the same size for each
>> picture ?
>>
>
> Yes sure, and maybe put a kind of table were each of us is a row, and all
> data is one column and the picture is another one. So they are aligned.
>

We should just adapt the CSS. I don't know how to modify it in CMSBox.

Laurent



> But first the first :)  Get the contributors and then we take care about
> the make up ehehe
>
> Laurent may be able to take care about the makeup ?
>

> Cheers
>
> Mariano
>
>
>> Regards,
>>
>> On Thu, Apr 14, 2011 at 8:46 PM, Mariano Martinez Peck
>>  wrote:
>> > if true...then what are you wainting for?
>> >
>> > http://www.pharo-project.org/community/contributors
>> >
>> > Send you data and nice picture :)
>> >
>> > Seriously, it is important for marketing among other things. Imagine you
>> > arrive to a new project...it is good to see that there are several
>> > contributing to it. Probably this page is not the best, but is something
>> > more.
>> >
>> > Mariano
>> >
>> >
>> >
>> > On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont <
>> laurent.laff...@gmail.com>
>> > wrote:
>> >>
>> >> Added !
>> >> Laurent.
>> >> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich 
>> wrote:
>> >>>
>> >>> Hi Laurent,
>> >>>
>> >>> I'd like to be added to
>> >>> http://www.pharo-project.org/community/contributors . My picture is
>> >>> attached. Description text could be "Contributed the default
>> anti-aliased
>> >>> fonts and the SimpleMorphic UI framework. Web page at
>> www.jvuletich.org".
>> >>>
>> >>> Thank you.
>> >>>
>> >>> Cheers,
>> >>> Juan Vuletich
>> >>
>> >
>> >
>> >
>> > --
>> > Mariano
>> > http://marianopeck.wordpress.com
>> >
>> >
>>
>>
>>
>> --
>> Serge Stinckwich
>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
>> Every DSL ends up being Smalltalk
>> http://doesnotunderstand.org/
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>

Re: [Pharo-project] Meanwhile, at another vm

[Norbert Hartl]

Am 14.04.2011 um 16:29 schrieb Michael Haupt:

> But we're probably rather off-topic by now. ;-)

No, the subject is "Meanwhile, at another vm". Quite flexible and welcoming to 
all sorts of discussions :)

Norbert

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Hernan Wilkinson]

On Thu, Apr 14, 2011 at 5:33 AM, Toon Verwaest wrote:

> Somehow I feel like I offended someone :)
>
> I personally don't have experience with 10'000+ classes in a system. I do
> understand that's where you are coming from and do appreciate the insight.
>
> My personal experience has rather been the opposite until now. For example
> the Pharo/Squeak classbuilder is 1 single class doing everything. This is
> horrible; not just horrible because the code is completely horrid but it's
> non-extensible, non-configurable, non-reusable, contains tons of duplication
> _just because_ it is all put into one big ball of mud. By decomposing the
> classbuilder into 4 to 10 different classes I ended up having very little
> methods with very little code, and a very high level of configurability and
> understandability. I now actually use this classbuilder to build anonymous
> classes too, avoiding the whole problem with forgetting to copy in the
> format that everyone seems to have.
>
> And this experience was showing me that having classes for all _relevant_
> concepts actually pays off in the long run. Since you (and others) are
> saying that it doesn't for exceptions; and since I don't have enough
> experience there I'll take your advice into account when writing code ;)
>

I think you said it right here: "having classes for all _relevant_ concepts
actually pays off"...
Related to exceptions, my question is:  what are all the different concepts
you have? for example, not finding a Key or not finding a Value are really
different concepts? or is it the same (not finding something) that depending
on the context (finding a value or a key) is what looks like they are
different? if so, then there is only one concept (i.e. not finding an
object), if it is a key or a value is accidental, contextual to what you are
looking for.
So, I completely agree when you say "having classes for all relevant
concepts"... I think we do not agree on what are the relevant concepts when
we talk about exceptions...


>
> Toon
>
>
> On 04/14/2011 01:00 AM, Dale Henrichs wrote:
>
>> On 04/13/2011 02:58 PM, Toon Verwaest wrote:
>>
>>> Is it such a problem if you duplicate a certain exception class? At the
>>> moment you'll do the same anyway by not completely writing the exact
>>> same symbol.
>>>
>>
>> It's a simple matter of namespaces and volume of names ... with a large
>> open ended namespace you are more likely to have a number of redundant names
>> with slight differences in spelling showing up in different spots in the
>> hierarchy...with a logically segmented namespace each segment will have a
>> manageable number of names and the risk of duplication is reduced ... end of
>> discussion ...
>>
>> 10,000 names vs 30 names ... I can easily recognize duplicates in a list
>> of 30 names ... not so easy in 10,000 ... that is all ...
>>
>> to attempt to map every possible error condition onto a class will lead
>> you to 10,000 much quicker than using reasonCodes ... that is all ...
>>
>> I don't hate classes, it is a _practical_ matter ... if _you_ would rather
>> manage 10,000 names then I will say that it isn't practical ... I'm _not_
>> saying it is _wrong_, just not _practical_.
>>
>>
>>> And if the problem is not finding classes anymore, maybe we need a
>>> better way of organizing the exception classes away from the standard
>>> classes so that they are as non-intrusive as symbols, but convey more
>>> information?
>>>
>>
>> And now you've hit the nail on the head ... in order to handle the extra
>> complexity you need additional tools ... before creating more tools, ask
>> your self the simple question: "Do I _need_ the additional complexity?" ...
>> if the answer is yes, then create the tool, if the answer is no, then you
>> don't need to create a new tool ..
>>
>> Again, this is a _practical_ matter...
>>
>>
>>> self error: #keyNotFound
>>> does not really give much information; and isn't much more difficult to
>>> write than:
>>> KeyNotFoundException new in: self; key: key; signal
>>>
>>
>> From a practical perspective how many exception handlers will be written
>> to handle KeyNotFoundException ... I use at:ifAbsent: when I'm doing a look
>> up that I think might fail ... better than writing an exception handler ...
>>
>> If there is a real need to write a handler for KeyNotFoundException, then
>> by all means create the class, but until you actually NEED
>> KeyNotFoundException, `self error: #keyNotFound` or `NotFoundException
>> signal: #keyNotFound` will work just fine...
>>
>>>
>>> although the second one gives you all the contextual information that
>>> the first one misses.
>>>
>>
>> _If_ you NEED the additional contextual information. It's just like
>> writing a framework that no uses ... there's nothing wrong with the idea or
>> the implementation, it's just that the framework didn't solve a problem that
>> anyone had...
>>
>> If you are going to create a class, I think the least it should do is
>> address an real problem, not 

Re: [Pharo-project] Issue 4022 in pharo: Symbol readFrom:

[pharo]

Updates:
Labels: Importance-High

Comment #1 on issue 4022 by benjamin...@gmail.com: Symbol readFrom:
http://code.google.com/p/pharo/issues/detail?id=4022

(No comment was entered for this change.)

Re: [Pharo-project] Meanwhile, at another vm

[Michael Haupt]

Hi Dave,

On 14 April 2011 16:13, Dave Mason  wrote:
> I'n not sure what you mean that hotswap (or rather HotSwap) has been around 
> since 1.4... do you perhaps mean HotSpot - the better jitter?

no, that's around since 1.3 IIRC. :-)

The HotSwap technology (i.e., the possibility to change method
implementations at run-time) was introduced in the Java VM with the
release of Java 1.4.

What I don't understand is how HotSwap is supposed to be related to
#become:. Also, JSR 292 does not change anything about that if I'm not
totally mistaken. It introduces INVOKEDYNAMIC. The details at
http://www.jcp.org/en/jsr/detail?id=292 do not give away anything
related to HotSwap, schema changes or object identity exchange.

But we're probably rather off-topic by now. ;-)

Best,

Michael

Re: [Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk — Contributors

[Mariano Martinez Peck]

On Thu, Apr 14, 2011 at 4:26 PM, Serge Stinckwich <
serge.stinckw...@gmail.com> wrote:

> I think it's a great idea to have a picture and short description.
> Maybe we could have something more uniform with the same size for each
> picture ?
>

Yes sure, and maybe put a kind of table were each of us is a row, and all
data is one column and the picture is another one. So they are aligned.

But first the first :)  Get the contributors and then we take care about the
make up ehehe

Laurent may be able to take care about the makeup ?

Cheers

Mariano


> Regards,
>
> On Thu, Apr 14, 2011 at 8:46 PM, Mariano Martinez Peck
>  wrote:
> > if true...then what are you wainting for?
> >
> > http://www.pharo-project.org/community/contributors
> >
> > Send you data and nice picture :)
> >
> > Seriously, it is important for marketing among other things. Imagine you
> > arrive to a new project...it is good to see that there are several
> > contributing to it. Probably this page is not the best, but is something
> > more.
> >
> > Mariano
> >
> >
> >
> > On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont <
> laurent.laff...@gmail.com>
> > wrote:
> >>
> >> Added !
> >> Laurent.
> >> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich 
> wrote:
> >>>
> >>> Hi Laurent,
> >>>
> >>> I'd like to be added to
> >>> http://www.pharo-project.org/community/contributors . My picture is
> >>> attached. Description text could be "Contributed the default
> anti-aliased
> >>> fonts and the SimpleMorphic UI framework. Web page at
> www.jvuletich.org".
> >>>
> >>> Thank you.
> >>>
> >>> Cheers,
> >>> Juan Vuletich
> >>
> >
> >
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
> >
> >
>
>
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
> Every DSL ends up being Smalltalk
> http://doesnotunderstand.org/
>



-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-project] Meanwhile, at another vm

[Stefan Marr]

Hi:

On 14 Apr 2011, at 16:13, Dave Mason wrote:
> On Apr 14, 2011, at 04:13, Michael Haupt wrote:
> 
>> I'm puzzled; where is #become: mentioned as being implemented in that
>> talk? It's mostly about INVOKEDYNAMIC, which is an entirely different
>> thing. (They mention HotSwap on one slide, but that, as I wrote, has
>> been around since 1.4, and is also not really #become:.)
> 
> I'n not sure what you mean that hotswap (or rather HotSwap) has been around 
> since 1.4... do you perhaps mean HotSpot - the better jitter?
Hotswap, as in changing methods in a class. That is what the JVM supports, and 
that is what Michael is referring to.
That is part of the JVM debuggers and tooling interface. That is part of the 
spec, not just an implementation detail of HotSpot.


> I haven't dug into the fine details, but here is a post from 2006 by Gilad 
> Bracha, sometimes contributor to this list:
> 
>http://blogs.sun.com/gbracha/entry/jsr292_and_hotswapping
> 
> and the update to it is the slides I cited say there is a patch to support 
> hotswap currently as of Sept 2009.
Hotswap for methods was introduced as part of the debugging API, and that was 
part of Java 1.4 with its JavaTM Platform Debugger Architecture...


-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

Re: [Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk — Contributors

[Serge Stinckwich]

I think it's a great idea to have a picture and short description.
Maybe we could have something more uniform with the same size for each picture ?
Regards,

On Thu, Apr 14, 2011 at 8:46 PM, Mariano Martinez Peck
 wrote:
> if true...then what are you wainting for?
>
> http://www.pharo-project.org/community/contributors
>
> Send you data and nice picture :)
>
> Seriously, it is important for marketing among other things. Imagine you
> arrive to a new project...it is good to see that there are several
> contributing to it. Probably this page is not the best, but is something
> more.
>
> Mariano
>
>
>
> On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont 
> wrote:
>>
>> Added !
>> Laurent.
>> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich  wrote:
>>>
>>> Hi Laurent,
>>>
>>> I'd like to be added to
>>> http://www.pharo-project.org/community/contributors . My picture is
>>> attached. Description text could be "Contributed the default anti-aliased
>>> fonts and the SimpleMorphic UI framework. Web page at www.jvuletich.org".
>>>
>>> Thank you.
>>>
>>> Cheers,
>>> Juan Vuletich
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>



-- 
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/

[Pharo-project] Issue 4022 in pharo: Symbol readFrom:

[pharo]

Status: FixProposed
Owner: benjamin...@gmail.com
Labels: Milestone-1.3

New issue 4022 by benjamin...@gmail.com: Symbol readFrom:
http://code.google.com/p/pharo/issues/detail?id=4022

Symbol readFromString: '#''plop-plip''' returns #plop where it should  
return #'plop-plip'


Attachments:
Symbol class.BenjaminVanRyseghem.1.cs  576 bytes

Re: [Pharo-project] Meanwhile, at another vm

[Dave Mason]

On Apr 14, 2011, at 04:13, Michael Haupt wrote:

> I'm puzzled; where is #become: mentioned as being implemented in that
> talk? It's mostly about INVOKEDYNAMIC, which is an entirely different
> thing. (They mention HotSwap on one slide, but that, as I wrote, has
> been around since 1.4, and is also not really #become:.)

I'n not sure what you mean that hotswap (or rather HotSwap) has been around 
since 1.4... do you perhaps mean HotSpot - the better jitter?

I haven't dug into the fine details, but here is a post from 2006 by Gilad 
Bracha, sometimes contributor to this list:

http://blogs.sun.com/gbracha/entry/jsr292_and_hotswapping

and the update to it is the slides I cited say there is a patch to support 
hotswap currently as of Sept 2009.

Perhaps Gilad is listening, and can provide some context.

../Dave

[Pharo-project] Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy

[Toon Verwaest]

Be patient, be patient ;)

I'm still very busy at the moment, but it'll get there.

We'll probably have discuss if you want to generate slot and layout 
objects in the classbuilder, or if you want to replace the 
instanceVariables array with real layout objects that you keep around. 
We basically implemented everything around the layout objects and keep 
this data in all classes; but you'll have to figure out if you want this 
in Pharo or not. Decide and let me know, I'd say ;)


cheers,
Toon

On 04/14/2011 04:07 PM, Stéphane Ducasse wrote:

I want this class builder :)

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Stéphane Ducasse]

I want this class builder :)

On Apr 14, 2011, at 10:33 AM, Toon Verwaest wrote:

> Somehow I feel like I offended someone :)
> 
> I personally don't have experience with 10'000+ classes in a system. I do 
> understand that's where you are coming from and do appreciate the insight.
> 
> My personal experience has rather been the opposite until now. For example 
> the Pharo/Squeak classbuilder is 1 single class doing everything. This is 
> horrible; not just horrible because the code is completely horrid but it's 
> non-extensible, non-configurable, non-reusable, contains tons of duplication 
> _just because_ it is all put into one big ball of mud. By decomposing the 
> classbuilder into 4 to 10 different classes I ended up having very little 
> methods with very little code, and a very high level of configurability and 
> understandability. I now actually use this classbuilder to build anonymous 
> classes too, avoiding the whole problem with forgetting to copy in the format 
> that everyone seems to have.
> 
> And this experience was showing me that having classes for all _relevant_ 
> concepts actually pays off in the long run. Since you (and others) are saying 
> that it doesn't for exceptions; and since I don't have enough experience 
> there I'll take your advice into account when writing code ;)
> 
> Toon
> 
> On 04/14/2011 01:00 AM, Dale Henrichs wrote:
>> On 04/13/2011 02:58 PM, Toon Verwaest wrote:
>>> Is it such a problem if you duplicate a certain exception class? At the
>>> moment you'll do the same anyway by not completely writing the exact
>>> same symbol.
>> 
>> It's a simple matter of namespaces and volume of names ... with a large open 
>> ended namespace you are more likely to have a number of redundant names with 
>> slight differences in spelling showing up in different spots in the 
>> hierarchy...with a logically segmented namespace each segment will have a 
>> manageable number of names and the risk of duplication is reduced ... end of 
>> discussion ...
>> 
>> 10,000 names vs 30 names ... I can easily recognize duplicates in a list of 
>> 30 names ... not so easy in 10,000 ... that is all ...
>> 
>> to attempt to map every possible error condition onto a class will lead you 
>> to 10,000 much quicker than using reasonCodes ... that is all ...
>> 
>> I don't hate classes, it is a _practical_ matter ... if _you_ would rather 
>> manage 10,000 names then I will say that it isn't practical ... I'm _not_ 
>> saying it is _wrong_, just not _practical_.
>> 
>>> 
>>> And if the problem is not finding classes anymore, maybe we need a
>>> better way of organizing the exception classes away from the standard
>>> classes so that they are as non-intrusive as symbols, but convey more
>>> information?
>> 
>> And now you've hit the nail on the head ... in order to handle the extra 
>> complexity you need additional tools ... before creating more tools, ask 
>> your self the simple question: "Do I _need_ the additional complexity?" ... 
>> if the answer is yes, then create the tool, if the answer is no, then you 
>> don't need to create a new tool ..
>> 
>> Again, this is a _practical_ matter...
>> 
>>> 
>>> self error: #keyNotFound
>>> does not really give much information; and isn't much more difficult to
>>> write than:
>>> KeyNotFoundException new in: self; key: key; signal
>> 
>> From a practical perspective how many exception handlers will be written to 
>> handle KeyNotFoundException ... I use at:ifAbsent: when I'm doing a look up 
>> that I think might fail ... better than writing an exception handler ...
>> 
>> If there is a real need to write a handler for KeyNotFoundException, then by 
>> all means create the class, but until you actually NEED 
>> KeyNotFoundException, `self error: #keyNotFound` or `NotFoundException 
>> signal: #keyNotFound` will work just fine...
>>> 
>>> although the second one gives you all the contextual information that
>>> the first one misses.
>> 
>> _If_ you NEED the additional contextual information. It's just like writing 
>> a framework that no uses ... there's nothing wrong with the idea or the 
>> implementation, it's just that the framework didn't solve a problem that 
>> anyone had...
>> 
>> If you are going to create a class, I think the least it should do is 
>> address an real problem, not an imaginary one.
>> 
>> To say that "if one were to handle the KeyNotFoundException, they will need 
>> the complete context", I prefer to say "Until one needs the complete context 
>> of the KeyNotFoundException, don't bother creating class"
>> 
>>> 
>>> What I mean mostly: what about trying to figure out why you want to
>>> avoid decent exception classes and tackling that problem?
>> 
>> Depends upon what your definition of a decent exception classes is? My 
>> argument is simply that it is not _necessary_ to create a unique class for 
>> every unique error condition ... I think that folks should answer the 
>> question: "Will anyone every write an exception handle

Re: [Pharo-project] Issue 4015 in pharo: Fix in SmalltalkEditor

[pharo]

Updates:
Status: FixProposed

Comment #4 on issue 4015 by marcus.d...@gmail.com: Fix in SmalltalkEditor
http://code.google.com/p/pharo/issues/detail?id=4015

ups, not yes

Re: [Pharo-project] Issue 3387 in pharo: Package name should not contain crptic characters

[pharo]

Comment #8 on issue 3387 by marcus.d...@gmail.com: Package name should not  
contain crptic characters

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

Was the license agreement received?

[Pharo-project] [update 1.3] #13151

[Marcus Denker]

13151
-

Issue 4020: Improve cleanUpForRelease and cleanUpForProduction
Issue 4017: CommandLine>>#initialize should not reset registrations
Issue 3999: Add More Explicit Error Classes for Collections
- Deprecate FillInTheBlankMorph


--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Re: [Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk — Contributors

[Esteban Lorenzano]

Oh, well...Esteban LorenzanoOwner of Smallworks (http://smallworks.com.ar)Author of Mars (http://smallworks.com.ar/en/community/Mars)Contributor on several projects, like DBXTalk (http://squeakdbx.org), etc.We use Pharo for everything we do :)And here is my picture: El 14/04/2011, a las 10:46a.m., Mariano Martinez Peck escribió:if true...then what are you wainting for?http://www.pharo-project.org/community/contributorsSend you data and nice picture :)
Seriously, it is important for marketing among other things. Imagine you arrive to a new project...it is good to see that there are several contributing to it. Probably this page is not the best, but is something more. 
MarianoOn Wed, Apr 13, 2011 at 8:18 PM, laurent laffont  wrote:
Added !Laurent.On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich  wrote:


Hi Laurent,

I'd like to be added to http://www.pharo-project.org/community/contributors . My picture is attached. Description text could be "Contributed the default anti-aliased fonts and the SimpleMorphic UI framework. Web page at www.jvuletich.org".




Thank you.

Cheers,
Juan Vuletich

-- Marianohttp://marianopeck.wordpress.com

Re: [Pharo-project] Issue 3999 in pharo: Add More Explicit Error Classes for Collections

[pharo]

Updates:
Status: Closed

Comment #2 on issue 3999 by marcus.d...@gmail.com: Add More Explicit Error  
Classes for Collections

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

Collections-Unordered-CamilloBruni.110

seems to remove KeyNotFoundError which is referenced elsewhere. So I did  
not merge that.

Re: [Pharo-project] Issue 4015 in pharo: Fix in SmalltalkEditor

[pharo]

Updates:
Status: Closed

Comment #3 on issue 4015 by marcus.d...@gmail.com: Fix in SmalltalkEditor
http://code.google.com/p/pharo/issues/detail?id=4015

in 13151

Re: [Pharo-project] Issue 4017 in pharo: CommandLine>>#initialize should not reset registrations

[pharo]

Updates:
Status: Closed

Comment #1 on issue 4017 by marcus.d...@gmail.com: CommandLine>>#initialize  
should not reset registrations

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

in 13152

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Hernan Wilkinson]

On Thu, Apr 14, 2011 at 10:37 AM, Camillo Bruni wrote:

>
> On 2011-04-14, at 14:19, Hernan Wilkinson wrote:
>
> >
> >
> > On Thu, Apr 14, 2011 at 9:08 AM, Toon Verwaest 
> wrote:
> > Right, so you confirm the experience of Dale.
> >
> > In the case of flagging errors without classes, do you generally just use
> a simple symbol, or concatenate strings to convey more details? This last
> seems somehow a bad idea... but maybe if it's never caught it's not so
> relevant?
> >
> > I don't understand exactly what you mean... if you are suggesting using
> error codes over exceptions, no, that is not may point. Exceptions are the
> right tool to get rid of the repeated/error prone code you create when using
> error codes, there is not doubt about it.
> > What I'm saying is that from the handling point of view you only need to
> identify the exception to handle, and matching the class of the exception
> with identifying the exception is not the only way (I showed another way in
> a previous mail).
> > Also, categorizing exception types using subclassing does not seem to be
> a good idea either... it is common use now, but that does not mean it is
> good. Sometimes you want to categorize exceptions in a different way that
> your exception class hierarchy forces you, and when that happens it is
> really a pain.
>
> But right now that is possible by concatenating Exceptions, generating
> ExceptionSets, which you could even generate upfront, so complexity-wise it
> is the same as using symbols as identifiers in a generic Exception class.
>

yes of course, but you still have the super-class relationship... anyway,
this is not the main issue


>
> But I agree finding the right balance of how many exception classes to use
> is not easy. However, we are still far from that in Pharo..., even worse,
> since no one uses explicit error classes no one uses them.


As I said, I used them in a system and the conclusion was that you don't
need them... a program can do little when an exception is throw to fix the
problem (but in very small cases)...  they are basically to inform the user
that something went wrong and having a good description is more important
than having a big exception hierarchy.


> And certainly there should be another way to catch errors than just by
> relying on the type / class. Sometimes it would be nice to be able to catch
> errors depending on the place they were thrown,  for instance only handle
> exceptions thrown in my own methods / my package...
>

yes, that is completely true... I would be great to have a mechanism where
you could automatically convert exception while the pass subsystems/layers
bounderies too... that is a great research topic I think

>
> And concerning the IDE, we need a lot of improvements there, the current
> design and functionality in Pharo at least, resembles more a system from the
> 70'ies than a more recent ide.
>



-- 
*Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: hernan.wilkin...@10pines.com
site: http://www.10Pines.com *

[Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk — Contributors

[Mariano Martinez Peck]

if true...then what are you wainting for?

http://www.pharo-project.org/community/contributors

Send you data and nice picture :)

Seriously, it is important for marketing among other things. Imagine you
arrive to a new project...it is good to see that there are several
contributing to it. Probably this page is not the best, but is something
more.

Mariano



On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont
wrote:

> Added !
>
> Laurent.
>
> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich  wrote:
>
>> Hi Laurent,
>>
>> I'd like to be added to
>> http://www.pharo-project.org/community/contributors . My picture is
>> attached. Description text could be "Contributed the default anti-aliased
>> fonts and the SimpleMorphic UI framework. Web page at www.jvuletich.org".
>>
>> Thank you.
>>
>> Cheers,
>> Juan Vuletich
>>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Philippe Marschall]

On 04/11/2011 04:10 PM, Sven Van Caekenberghe wrote:
> Hi All,
> 
> I have this idea that I would like to discuss on the next Pharo sprint and 
> maybe start to implement if there is some consensus on it.
> 
> It has been mentioned many times before on this list that Object>>#error: 
> should be replaced by signalling specific Exceptions in as many cases as 
> possible (or where it makes sense). Even today, there was 
> http://code.google.com/p/pharo/issues/detail?id=3987 !
> 
> I think the core system should set the example here, by defining a number of 
> general purpose exceptions and by using them. Going over #error: senders will 
> be a lot of work but can be done in incremental/Pharo steps.
> 
> So I went over the current hierarchy, scanned quickly through their 
> references and some #error: senders by fundamental classes and looked at some 
> other Smalltalks. I came up with the following very rough draft of an 
> extended hierarchy (** marks new exceptions). In between brackets are the 
> instance variables. Of course, we have to discuss about naming, instance 
> variables and opportunities for reuse and inheritance (could be fun). 
> 
> I am no expert on exceptions and would certainly like to learn more. I am 
> probably overlooking some aspects. We have to keep this Smalltalk like, 
> flexible, dynamic, not start mimicing other languages. 
> 
> Any step in this direction will be an improvement over the current situation. 
> Really using them correctly throughout the system will take some time. 
> Defining the hierarchy could be done rather quickly. Refactoring is always 
> possible later on.
> 
> Exception (messageText)
>   Abort
>   Error
> ArithemticError
>   ZeroDivide (dividend)   
>   FloatingPointException
>   RangeError ** (from, to)
>   NaNError **
> FileStreamException (fileName)
>   FileDoesNotExistException (readOnly)
>   FileExistsException (fileClass)
>   CannotDeleteFileException
>   FileWriteError
>   FileReadError **
>   FileClosedException **
>   CannotAccessFileException **
>   ReadonlyFileException **
> MessageNotUnderstood (message, receiver)
> NonBooleanReceiver (object)
> OutOfMemory
> Halt
>   AssertionFailure
>   BreakPoint
> SyntaxError ** !exists! (input, position)
>   NumberFormatException **
> HeadlessError **
> TimedOut ** (object, operation, timeout)
> VerificationException
> IllegalOperation ** (operation, object)
> SizeMismatch (objects)
> LowMemory ** (percentageFree)
> SubclassResponsibility ** (message, receiver)
> NotYetImplemented ** (message, receiver)
> CannotInstanciate ** (class)
> ReadOnlyObject ** (object)
> OutOfFreeSpace ** (object, size)
> InvalidArgument ** (message, receiver, argument)
> NotIndexable ** (object)
> NoKeyedAccess ** (object)
> NonIntegerIndex ** (receiver, index)
> SubscriptOutOfBounds ** (receiver, index, from, to)
> NotFoundException ** (receiver, object)
>   KeyNotFound **
>   ValueNotFound **
>   ElementNotFound **
> StreamException (stream)
>   PositionError ** (index, from, to) 
>   EndOfStream **
>   BeginOfStream ** 
> 
> All feedback is welcome.

PrimitiveFailed for #primitiveFailed would be nice as well.

Cheers
Philippe

Re: [Pharo-project] Issue 4017 in pharo: CommandLine>>#initialize should not reset registrations

[pharo]

Comment #2 on issue 4017 by marcus.d...@gmail.com: CommandLine>>#initialize  
should not reset registrations

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

in 13152

Re: [Pharo-project] Issue 4020 in pharo: Improve cleanUpForRelease and cleanUpForProduction

[pharo]

Updates:
Status: Closed

Comment #2 on issue 4020 by marcus.d...@gmail.com: Improve  
cleanUpForRelease and cleanUpForProduction

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

in 13151

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Camillo Bruni]

On 2011-04-14, at 14:19, Hernan Wilkinson wrote:

> 
> 
> On Thu, Apr 14, 2011 at 9:08 AM, Toon Verwaest  
> wrote:
> Right, so you confirm the experience of Dale.
> 
> In the case of flagging errors without classes, do you generally just use a 
> simple symbol, or concatenate strings to convey more details? This last seems 
> somehow a bad idea... but maybe if it's never caught it's not so relevant?
> 
> I don't understand exactly what you mean... if you are suggesting using error 
> codes over exceptions, no, that is not may point. Exceptions are the right 
> tool to get rid of the repeated/error prone code you create when using error 
> codes, there is not doubt about it.
> What I'm saying is that from the handling point of view you only need to 
> identify the exception to handle, and matching the class of the exception 
> with identifying the exception is not the only way (I showed another way in a 
> previous mail).
> Also, categorizing exception types using subclassing does not seem to be a 
> good idea either... it is common use now, but that does not mean it is good. 
> Sometimes you want to categorize exceptions in a different way that your 
> exception class hierarchy forces you, and when that happens it is really a 
> pain.

But right now that is possible by concatenating Exceptions, generating 
ExceptionSets, which you could even generate upfront, so complexity-wise it is 
the same as using symbols as identifiers in a generic Exception class.

But I agree finding the right balance of how many exception classes to use is 
not easy. However, we are still far from that in Pharo..., even worse, since no 
one uses explicit error classes no one uses them. And certainly there should be 
another way to catch errors than just by relying on the type / class. Sometimes 
it would be nice to be able to catch errors depending on the place they were 
thrown,  for instance only handle exceptions thrown in my own methods / my 
package...

And concerning the IDE, we need a lot of improvements there, the current design 
and functionality in Pharo at least, resembles more a system from the 70'ies 
than a more recent ide.

Re: [Pharo-project] Issue 3148 in pharo: Proposal: adding 261 named colors

[pharo]

Updates:
Status: Duplicate
Mergedinto: 4018

Comment #3 on issue 3148 by marcus.d...@gmail.com: Proposal: adding 261  
named colors

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

(No comment was entered for this change.)

Re: [Pharo-project] Issue 4018 in pharo: Color class enhancement

[pharo]

Comment #3 on issue 4018 by marcus.d...@gmail.com: Color class enhancement
http://code.google.com/p/pharo/issues/detail?id=4018

Issue 3148 has been merged into this issue.

Re: [Pharo-project] Issue 4018 in pharo: Color class enhancement

[Marcus Denker]

And pleast, please have a look at old tracker entries...

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

On Apr 14, 2011, at 3:11 PM, ph...@googlecode.com wrote:

> 
> Comment #2 on issue 4018 by alexandr...@gmail.com: Color class enhancement
> http://code.google.com/p/pharo/issues/detail?id=4018
> 
> XKCDColors, written by Johan Fabry
> 
> Attachments:
>   XKCDColor.st  12.1 KB
>   XKCDColorTest.st  458 bytes
> 
> 

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Re: [Pharo-project] Issue 4018 in pharo: Color class enhancement

[pharo]

Comment #2 on issue 4018 by alexandr...@gmail.com: Color class enhancement
http://code.google.com/p/pharo/issues/detail?id=4018

XKCDColors, written by Johan Fabry

Attachments:
XKCDColor.st  12.1 KB
XKCDColorTest.st  458 bytes

Re: [Pharo-project] Issue 4018 in pharo: Color class enhancement

[pharo]

Comment #1 on issue 4018 by torsten@astares.de: Color class enhancement
http://code.google.com/p/pharo/issues/detail?id=4018

take care, "*mondrian-core-accessing" is used for method category

Re: [Pharo-project] Issue 3986 in pharo: Bug with Delay during clock rollover

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #4 on issue 3986 by marcus.d...@gmail.com: Bug with Delay during  
clock rollover

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

(No comment was entered for this change.)

Re: [Pharo-project] Issue 4020 in pharo: Improve cleanUpForRelease and cleanUpForProduction

[pharo]

Comment #1 on issue 4020 by marcus.d...@gmail.com: Improve  
cleanUpForRelease and cleanUpForProduction

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

Issue 4021 has been merged into this issue.

Re: [Pharo-project] Issue 4021 in pharo: Improve cleanUpForRelease and cleanUpForProduction

[pharo]

Updates:
Status: Duplicate
Mergedinto: 4020

Comment #1 on issue 4021 by marcus.d...@gmail.com: Improve  
cleanUpForRelease and cleanUpForProduction

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

(No comment was entered for this change.)

[Pharo-project] Issue 4021 in pharo: Improve cleanUpForRelease and cleanUpForProduction

[pharo]

Status: FixProposed
Owner: marcus.d...@gmail.com
Labels: Milestone-1.3

New issue 4021 by marcus.d...@gmail.com: Improve cleanUpForRelease and  
cleanUpForProduction

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

cleanUpForRelease:
 - call BitBlt cleanUp

Production:

- unload Helystem fixed
- unload Deprecated12 and Deprecated13
- unload SimpleMorphic



Attachments:
betterCleanUpMethods.1.cs  4.5 KB

[Pharo-project] Issue 4020 in pharo: Improve cleanUpForRelease and cleanUpForProduction

[pharo]

Status: FixProposed
Owner: marcus.d...@gmail.com
Labels: Milestone-1.3

New issue 4020 by marcus.d...@gmail.com: Improve cleanUpForRelease and  
cleanUpForProduction

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

cleanUpForRelease:
 - call BitBlt cleanUp

Production:

- unload Helystem fixed
- unload Deprecated12 and Deprecated13
- unload SimpleMorphic



Attachments:
betterCleanUpMethods.1.cs  4.5 KB

[Pharo-project] Issue 4019 in pharo: It should be possible to call CodeLoader>>initialize multiple times

[pharo]

Status: Accepted
Owner: marcus.d...@gmail.com
Labels: Milestone-1.3

New issue 4019 by marcus.d...@gmail.com: It should be possible to call  
CodeLoader>>initialize multiple times

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

It should be possible to call CodeLoader>>initialize multiple times

[Pharo-project] Issue 4018 in pharo: Color class enhancement

[pharo]

Status: Accepted
Owner: alexandr...@gmail.com

New issue 4018 by alexandr...@gmail.com: Color class enhancement
http://code.google.com/p/pharo/issues/detail?id=4018

The proposed .cs add a couple of useful constant values on the class side  
of Color.


Attachments:
ColorEnh.1.cs  1.7 KB

[Pharo-project] Issue 4017 in pharo: CommandLine>>#initialize should not reset registrations

[pharo]

Status: Accepted
Owner: marcus.d...@gmail.com
Labels: Milestone-1.3

New issue 4017 by marcus.d...@gmail.com: CommandLine>>#initialize should  
not reset registrations

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

CommandLine>>#initialize should not reset registrations

Re: [Pharo-project] Issue 3985 in pharo: Create temporary in debugger does not work for new keyword method

[pharo]

Updates:
Status: Closed

Comment #1 on issue 3985 by marcus.d...@gmail.com: Create temporary in  
debugger does not work for new keyword method

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

If it's good in 1.3 than it's fixed.

(If someone wants to backport to 1.2, sunmit a fix... but we will release  
1.3 soon)

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Hernan Wilkinson]

On Thu, Apr 14, 2011 at 9:08 AM, Toon Verwaest wrote:

> Right, so you confirm the experience of Dale.
>
> In the case of flagging errors without classes, do you generally just use a
> simple symbol, or concatenate strings to convey more details? This last
> seems somehow a bad idea... but maybe if it's never caught it's not so
> relevant?
>

I don't understand exactly what you mean... if you are suggesting using
error codes over exceptions, no, that is not may point. Exceptions are the
right tool to get rid of the repeated/error prone code you create when using
error codes, there is not doubt about it.
What I'm saying is that from the handling point of view you only need to
identify the exception to handle, and matching the class of the exception
with identifying the exception is not the only way (I showed another way in
a previous mail).
Also, categorizing exception types using subclassing does not seem to be a
good idea either... it is common use now, but that does not mean it is good.
Sometimes you want to categorize exceptions in a different way that your
exception class hierarchy forces you, and when that happens it is really a
pain.


>
> cheers,
> Toon
>
>
> On 04/14/2011 02:03 PM, Hernan Wilkinson wrote:
>
>> the problem is not related to technical issues (like how much machine
>> memory you save, etc). It is related to knowledge organization...
>> If you have two classes that define exactly the same methods, inst var,
>> etc, why do you have two instead of one? If you answer is "because of the
>> name of the class", remember that names are contextualized to the place
>> where they are used...
>> I mean, this is easy, just take all the places where exceptions are handle
>> in Smalltalk and look what the handlers do with the exceptions. You will see
>> that in almost all cases the exceptions are not used at all, the information
>> they carry with them is not use at all... so, from a theory point of view it
>> looks nice to have a big exception hierarchy but from the practical point of
>> view is not only useless but also more difficult to use.
>> I build a system that had an exception class base on where they were
>> signal and not handled, we end up with around 1100 exceptions... only 3 or 4
>> are handled directly
>>
>
>


-- 
*Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: hernan.wilkin...@10pines.com
site: http://www.10Pines.com *

Re: [Pharo-project] Issue 4015 in pharo: Fix in SmalltalkEditor

[pharo]

Comment #2 on issue 4015 by benjamin...@gmail.com: Fix in SmalltalkEditor
http://code.google.com/p/pharo/issues/detail?id=4015

A new change set, in addition of the previous one

Attachments:
SmalltalkEditor-modelCurrentSelectedClass.st  839 bytes

[Pharo-project] [update 1.3] #13150

[Marcus Denker]

13150
-

Issue 4014: DNU for TestRunner because of #theme
Issue 4011: Finder: self is not bound to class
--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Re: [Pharo-project] Issue 4011 in pharo: Finder: self is not bound to class

[pharo]

Updates:
Status: Closed

Comment #2 on issue 4011 by marcus.d...@gmail.com: Finder: self is not  
bound to class

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

in 13150

Re: [Pharo-project] Issue 4014 in pharo: DNU for TestRunner because of #theme

[pharo]

Updates:
Status: Closed

Comment #2 on issue 4014 by marcus.d...@gmail.com: DNU for TestRunner  
because of #theme

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

in 13150

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Toon Verwaest]

Right, so you confirm the experience of Dale.

In the case of flagging errors without classes, do you generally just 
use a simple symbol, or concatenate strings to convey more details? This 
last seems somehow a bad idea... but maybe if it's never caught it's not 
so relevant?


cheers,
Toon

On 04/14/2011 02:03 PM, Hernan Wilkinson wrote:
the problem is not related to technical issues (like how much machine 
memory you save, etc). It is related to knowledge organization...
If you have two classes that define exactly the same methods, inst 
var, etc, why do you have two instead of one? If you answer is 
"because of the name of the class", remember that names are 
contextualized to the place where they are used...
I mean, this is easy, just take all the places where exceptions are 
handle in Smalltalk and look what the handlers do with the exceptions. 
You will see that in almost all cases the exceptions are not used at 
all, the information they carry with them is not use at all... so, 
from a theory point of view it looks nice to have a big exception 
hierarchy but from the practical point of view is not only useless but 
also more difficult to use.
I build a system that had an exception class base on where they were 
signal and not handled, we end up with around 1100 exceptions... only 
3 or 4 are handled directly

Re: [Pharo-project] Issue 4016 in pharo: Monticello Announcements

[pharo]

Comment #1 on issue 4016 by ryd...@gmail.com: Monticello Announcements
http://code.google.com/p/pharo/issues/detail?id=4016

Some context would be nice...
And MC announcements should _definately_ not be done by the Core System  
Announcer :)

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

[Hernan Wilkinson]

the problem is not related to technical issues (like how much machine memory
you save, etc). It is related to knowledge organization...
If you have two classes that define exactly the same methods, inst var, etc,
why do you have two instead of one? If you answer is "because of the name of
the class", remember that names are contextualized to the place where they
are used...
I mean, this is easy, just take all the places where exceptions are handle
in Smalltalk and look what the handlers do with the exceptions. You will see
that in almost all cases the exceptions are not used at all, the information
they carry with them is not use at all... so, from a theory point of view it
looks nice to have a big exception hierarchy but from the practical point of
view is not only useless but also more difficult to use.
I build a system that had an exception class base on where they were signal
and not handled, we end up with around 1100 exceptions... only 3 or 4 are
handled directly

On Wed, Apr 13, 2011 at 6:01 PM, Toon Verwaest wrote:

> I find the "managing the exception hierarchy" a bit strange... Do you
> really have to manage anything more than just normal classes? Every
> exception is related to a specific part of your code, just like other
> classes. What's wrong with creating hundreds of small classes wherever it's
> necessary? You might save a tiny bit of memory by using error codes or
> symbols, but I don't really see much more of a gain there, while you do gain
> from proper objects.
>
> Being clear and modeling properly generally pays off in the long run. And
> the bit of runtime memory you save isn't really worth your while...
>
> Or am I missing something else? I didn't really follow the whole
> conversation in-depth.
>
> cheers,
> Toon
>
>
> On 04/13/2011 09:54 PM, Dale Henrichs wrote:
>
>> Camillo,
>>
>> Hey, I _am_ old, but not _that_ old:) ... There are a couple of things
>> that were invented in the Stone Age that have survived to today, so old
>> ideas are not immediately bad, because they are old:)
>>
>> It feels like you are creating classes that are not much more than symbols
>> ...
>>
>> I am not one to shy away from using classes when they are called for, but
>> I am just making a practicality point ... we don't have a unique class for
>> each character in the alphabet, but we couldwe could have a unique class
>> for every possible error condition or not ...
>>
>> I think it is simply a practical answer...
>>
>> I do maintain that you _should_ use some sort of test along the lines of:
>> "Will anyone ever need to write a handler for the exception?" in your
>> criteria for deciding when to create a class and when to use something like
>> a "reason code" to disambiguate the signalling site...
>>
>> Dale
>>
>> On 04/13/2011 12:32 PM, Camillo Bruni wrote:
>>
>>> Perfect, I ll be there to bang heads ;).
>>>
>>> So without "Exception" pre- or suffix seems to be nice. However I
>>> don't see the need of using symbols over real classes. This feels
>>> indeed like going to stone age of error handling, thats what you have
>>> polymorphism and ExceptionSets for.
>>>
>>> Anyway, the main idea is to make single exceptions recognizable and
>>> not just use one single, basically meaningless, exception type.
>>>
>>> best regards, Camillo Bruni
>>>
>>>
>>> On 2011-04-13, at 21:22, Sven Van Caekenberghe wrote:
>>>
>>>  Thanks a lot everybody for the reactions, this could become a nice
 discussion next Friday. All points raised are valid, I would like
 simple names and a compact multipurpose hierarchy too.

 On 13 Apr 2011, at 19:39, Dale Henrichs wrote:

  Some thoughts from an old man (started programming before
> exceptions of any kind were available:) ...
>
> In the old days, error numbers had a place in the universe ...
> error numbers of a certain range indicated specific errors and
> the "error handlers" could check for a range or a specific error
> ...
>
> Today I think there is still a place for the notion of "error
> numbers".
>
> In Smalltalk I would use Symbols instead of numbers, but the idea
> would be to use a concrete exception class to identify broad
> categories of error conditions (i.e., FileStreamError) and a
> symbolic "reason code" to indicate the specific error (i.e.,
> #fileDoesNotExist, #fileExists, #cannotDelete, etc.), that way an
> error handler can be written for FileStreamError and then
> specific action take with respect to which "reason code" is
> involved, if such action is needed.
>
> The main advantage of using reasonCodes over using a "class per
> error condition" is that you can reduce the size of the Exception
> hierarchy to a manageable size (GemStone has hundreds of error
> conditions, so we've resorted to using "reason codes" to manage
> the size of the hierarchy).
>
> As Hernan hints, more often than not it is important to be very
> speci

[Pharo-project] Issue 4016 in pharo: Monticello Announcements

[pharo]

Status: FixProposed
Owner: benjamin...@gmail.com
Labels: Nautilus

New issue 4016 by benjamin...@gmail.com: Monticello Announcements
http://code.google.com/p/pharo/issues/detail?id=4016

Add some monticello announcement basically when a package turn dirty and  
when a package turn clean


Attachments:
MonticelloAnnouncements.1.cs  3.2 KB

[Pharo-project] Problem with Monticello when reverting a method

[Hernan Wilkinson]

Hi,
 if I revert a method to a previous version and that version belongs to a
different package, then I create a new version of the package and the I load
that new version on a new image, the old version of the method is still
there... seems like monticello is not handling loading previous versions of
a method of a different package correctly.
 Is that a known issue? does anybody know how to solve it?

 Thanks!
 Hernan.

-- 
*Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: hernan.wilkin...@10pines.com
site: http://www.10Pines.com *

Re: [Pharo-project] Issue 4015 in pharo: Fix in SmalltalkEditor

[pharo]

Comment #1 on issue 4015 by nicolas@gmail.com: Fix in SmalltalkEditor
http://code.google.com/p/pharo/issues/detail?id=4015

I would ban or refactor selectedClassOrMetaClass.
First, it should be Metaclass rather than MetaClass.
Then, it should be selectedClassOrMetaclassOrTraitOrClassTrait given  
current implementation.

And finally, why not just selectedBehavior ?

Maybe both should be selectedBehavior.
Just add it to your dispatch method for a transient time (to avoid  
complaints coming from various OB, O2 & co), then zap the entire workaround.

[Pharo-project] Issue 4015 in pharo: Fix in SmalltalkEditor

[pharo]

Status: FixProposed
Owner: benjamin...@gmail.com
Labels: Nautilus

New issue 4015 by benjamin...@gmail.com: Fix in SmalltalkEditor
http://code.google.com/p/pharo/issues/detail?id=4015

Related to: Issue 3908: Fix for pool variables references

I have introduced a new method to retrieve the model selectedClass.

Because the method name is different in Browser and in  
Nautilus/Finder/RML... I've also introduced a ugly dispatch ...


I think this method name shouldn't be hardcoded, but I haven't any clue how  
to do it other than provided it to the SmalltalkEditor which sucks ...


Attachments:
SmalltalkEditor.BenjaminVanRyseghem.2.cs  3.0 KB

Re: [Pharo-project] Issue 4014 in pharo: DNU for TestRunner because of #theme

[pharo]

Updates:
Status: FixToInclude

Comment #1 on issue 4014 by marcus.d...@gmail.com: DNU for TestRunner  
because of #theme

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

fix attached

Attachments:
FixTestRunnerTheme.1.cs  2.1 KB

Re: [Pharo-project] Issue 3963 in pharo: RPackageOrganizer and announcements

[pharo]

Updates:
Status: Closed

Comment #3 on issue 3963 by benjamin...@gmail.com: RPackageOrganizer and  
announcements

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

Integrated in RPackage

Re: [Pharo-project] Issue 3991 in pharo: use them instead of UITheme current

[pharo]

Updates:
Status: Closed

Comment #4 on issue 3991 by marcus.d...@gmail.com: use them instead of  
UITheme current

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

(No comment was entered for this change.)

Re: [Pharo-project] Issue 4011 in pharo: Finder: self is not bound to class

[pharo]

Updates:
Status: FixProposed

Comment #1 on issue 4011 by benjamin...@gmail.com: Finder: self is not  
bound to class

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

- Better behavior when a method is compiled
- Do it is now linked to the selectedClass

Name: Finder-BenjaminVanRyseghem.44 in PharoInbox.