A port of Pharo: Redline Smalltalk ...

>
> jarober says:
>
>>The reason these "Smalltalk for .NET" and "Smalltalk for the JVM"
>>projects never seem to come off is simple - Smalltalk isn't just flat
>>text in an editor.  Smalltalk is the entire interactive environment.
>>It would be fairly simple to get a syntax parser, but it wouldn't be
>>Smalltalk.  It would be Ruby or Python with Smalltalk syntax.
>>Somewhat useful perhaps, but not really Smalltalk.
>
> :(
>
> Hopefully it would have sufficient knowledge to be able to do something
> thus.
>
> Sorry, but I believe that it is the way that had to take commercial
> Smalltalk. It surprises to me that Cincom and company do not see it.
>
> Regards.
> --
> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> No, it's not. I would be far more valuable to have modularized images
> though: Just like Next/Apples Nibs or Bundle-mechanism. These
> image-modules would be edited from a development-image-bundle. They
> could be used to form stand-alone applications already clean of the
> development code or libraries that contain only a diff to the base
> classes, these library-images could then be combined to form more
> complex images. They could also contain their own namespace… and they
> would replace the non-modelling packaging mechanism, but I digress… ^^
>
> | packageWorkedOn |
> packageWorkedOn := Browser newPackageNamed: 'Calculator'.
> packageWorkedOn importPackage: 'Seaside'.
> "Create code in the Browser…"
> packageWorkedOn saveAsMonticello.
> packageWordedOn saveAsPackage.
> packageWorkedOn saveAsApplication.
>
> or something like that … ^^
>
> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <[hidden email]> wrote:
>>
>> jarober says:
>>
>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM"
>>> projects never seem to come off is simple - Smalltalk isn't just flat
>>> text in an editor.  Smalltalk is the entire interactive environment.
>>> It would be fairly simple to get a syntax parser, but it wouldn't be
>>> Smalltalk.  It would be Ruby or Python with Smalltalk syntax.
>>> Somewhat useful perhaps, but not really Smalltalk.
>>
>> :(
>>
>> Hopefully it would have sufficient knowledge to be able to do something
>> thus.
>>
>> Sorry, but I believe that it is the way that had to take commercial
>> Smalltalk. It surprises to me that Cincom and company do not see it.
>>
>> Regards.
>> --
>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Yes this is the vision we have.
> Now if people would help for simple things in pharo we would have more time for such issues.
> We got several people doing PhD on modules and related. We studied namespace and other kind of
> points so we have an idea of what could be a solution but it should be implemented
> tested.....
>
> Stef
>
>
> On Apr 6, 2010, at 1:14 AM, Richard Durr wrote:
>
>> No, it's not. I would be far more valuable to have modularized images
>> though: Just like Next/Apples Nibs or Bundle-mechanism. These
>> image-modules would be edited from a development-image-bundle. They
>> could be used to form stand-alone applications already clean of the
>> development code or libraries that contain only a diff to the base
>> classes, these library-images could then be combined to form more
>> complex images. They could also contain their own namespace… and they
>> would replace the non-modelling packaging mechanism, but I digress… ^^
>>
>> | packageWorkedOn |
>> packageWorkedOn := Browser newPackageNamed: 'Calculator'.
>> packageWorkedOn importPackage: 'Seaside'.
>> "Create code in the Browser…"
>> packageWorkedOn saveAsMonticello.
>> packageWordedOn saveAsPackage.
>> packageWorkedOn saveAsApplication.
>>
>> or something like that … ^^
>>
>> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <[hidden email]> wrote:
>>>
>>> jarober says:
>>>
>>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM"
>>>> projects never seem to come off is simple - Smalltalk isn't just flat
>>>> text in an editor.  Smalltalk is the entire interactive environment.
>>>> It would be fairly simple to get a syntax parser, but it wouldn't be
>>>> Smalltalk.  It would be Ruby or Python with Smalltalk syntax.
>>>> Somewhat useful perhaps, but not really Smalltalk.
>>>
>>> :(
>>>
>>> Hopefully it would have sufficient knowledge to be able to do something
>>> thus.
>>>
>>> Sorry, but I believe that it is the way that had to take commercial
>>> Smalltalk. It surprises to me that Cincom and company do not see it.
>>>
>>> Regards.
>>> --
>>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.html
>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> On Tue, Apr 6, 2010 at 10:50 AM, Stéphane Ducasse
> <[hidden email]> wrote:
>> Yes this is the vision we have.
>> Now if people would help for simple things in pharo we would have more time for such issues.
>> We got several people doing PhD on modules and related. We studied namespace and other kind of
>> points so we have an idea of what could be a solution but it should be implemented
>> tested.....
>>
>> Stef
>>
>>
>> On Apr 6, 2010, at 1:14 AM, Richard Durr wrote:
>>
>>> No, it's not. I would be far more valuable to have modularized images
>>> though: Just like Next/Apples Nibs or Bundle-mechanism. These
>>> image-modules would be edited from a development-image-bundle. They
>>> could be used to form stand-alone applications already clean of the
>>> development code or libraries that contain only a diff to the base
>>> classes, these library-images could then be combined to form more
>>> complex images. They could also contain their own namespace… and they
>>> would replace the non-modelling packaging mechanism, but I digress… ^^
>>>
>>> | packageWorkedOn |
>>> packageWorkedOn := Browser newPackageNamed: 'Calculator'.
>>> packageWorkedOn importPackage: 'Seaside'.
>>> "Create code in the Browser…"
>>> packageWorkedOn saveAsMonticello.
>>> packageWordedOn saveAsPackage.
>>> packageWorkedOn saveAsApplication.
>>>
>>> or something like that … ^^
>>>
>>> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <[hidden email]> wrote:
>>>>
>>>> jarober says:
>>>>
>>>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM"
>>>>> projects never seem to come off is simple - Smalltalk isn't just flat
>>>>> text in an editor.  Smalltalk is the entire interactive environment.
>>>>> It would be fairly simple to get a syntax parser, but it wouldn't be
>>>>> Smalltalk.  It would be Ruby or Python with Smalltalk syntax.
>>>>> Somewhat useful perhaps, but not really Smalltalk.
>>>>
>>>> :(
>>>>
>>>> Hopefully it would have sufficient knowledge to be able to do something
>>>> thus.
>>>>
>>>> Sorry, but I believe that it is the way that had to take commercial
>>>> Smalltalk. It surprises to me that Cincom and company do not see it.
>>>>
>>>> Regards.
>>>> --
>>>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.html
>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Hi richard
>
> some changes are changes coming from squeak and in such a case there is the squeak change
> It does not mean that we can integrate the change as it is.
> Thanks for looking at fixes and bug entries
>
> Stef
>
> On Apr 10, 2010, at 7:52 PM, Richard Durr wrote:
>
>> I am still trying to grok how this issue-fixing works. For example, in
>> "Difficulty:Easy" there are some issues which consist mostly of
>> ChangeSets of something. O_o
>
> O_o
>
> Nice :)
>
>
>>
>> On Tue, Apr 6, 2010 at 10:50 AM, Stéphane Ducasse
>> <[hidden email]> wrote:
>>> Yes this is the vision we have.
>>> Now if people would help for simple things in pharo we would have more time for such issues.
>>> We got several people doing PhD on modules and related. We studied namespace and other kind of
>>> points so we have an idea of what could be a solution but it should be implemented
>>> tested.....
>>>
>>> Stef
>>>
>>>
>>> On Apr 6, 2010, at 1:14 AM, Richard Durr wrote:
>>>
>>>> No, it's not. I would be far more valuable to have modularized images
>>>> though: Just like Next/Apples Nibs or Bundle-mechanism. These
>>>> image-modules would be edited from a development-image-bundle. They
>>>> could be used to form stand-alone applications already clean of the
>>>> development code or libraries that contain only a diff to the base
>>>> classes, these library-images could then be combined to form more
>>>> complex images. They could also contain their own namespace… and they
>>>> would replace the non-modelling packaging mechanism, but I digress… ^^
>>>>
>>>> | packageWorkedOn |
>>>> packageWorkedOn := Browser newPackageNamed: 'Calculator'.
>>>> packageWorkedOn importPackage: 'Seaside'.
>>>> "Create code in the Browser…"
>>>> packageWorkedOn saveAsMonticello.
>>>> packageWordedOn saveAsPackage.
>>>> packageWorkedOn saveAsApplication.
>>>>
>>>> or something like that … ^^
>>>>
>>>> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <[hidden email]> wrote:
>>>>>
>>>>> jarober says:
>>>>>
>>>>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM"
>>>>>> projects never seem to come off is simple - Smalltalk isn't just flat
>>>>>> text in an editor.  Smalltalk is the entire interactive environment.
>>>>>> It would be fairly simple to get a syntax parser, but it wouldn't be
>>>>>> Smalltalk.  It would be Ruby or Python with Smalltalk syntax.
>>>>>> Somewhat useful perhaps, but not really Smalltalk.
>>>>>
>>>>> :(
>>>>>
>>>>> Hopefully it would have sufficient knowledge to be able to do something
>>>>> thus.
>>>>>
>>>>> Sorry, but I believe that it is the way that had to take commercial
>>>>> Smalltalk. It surprises to me that Cincom and company do not see it.
>>>>>
>>>>> Regards.
>>>>> --
>>>>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.html
>>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> I'd like to contribute, but I am not good enough for the difficult
> ones to come to pleasing solutions, and I somehow don't feel the other
> ones accessable for me :/
>
> On Sat, Apr 10, 2010 at 9:21 PM, Stéphane Ducasse
> <[hidden email]> wrote:
>> Hi richard
>>
>> some changes are changes coming from squeak and in such a case there is the squeak change
>> It does not mean that we can integrate the change as it is.
>> Thanks for looking at fixes and bug entries
>>
>> Stef
>>
>> On Apr 10, 2010, at 7:52 PM, Richard Durr wrote:
>>
>>> I am still trying to grok how this issue-fixing works. For example, in
>>> "Difficulty:Easy" there are some issues which consist mostly of
>>> ChangeSets of something. O_o
>>
>> O_o
>>
>> Nice :)
>>
>>
>>>
>>> On Tue, Apr 6, 2010 at 10:50 AM, Stéphane Ducasse
>>> <[hidden email]> wrote:
>>>> Yes this is the vision we have.
>>>> Now if people would help for simple things in pharo we would have more time for such issues.
>>>> We got several people doing PhD on modules and related. We studied namespace and other kind of
>>>> points so we have an idea of what could be a solution but it should be implemented
>>>> tested.....
>>>>
>>>> Stef
>>>>
>>>>
>>>> On Apr 6, 2010, at 1:14 AM, Richard Durr wrote:
>>>>
>>>>> No, it's not. I would be far more valuable to have modularized images
>>>>> though: Just like Next/Apples Nibs or Bundle-mechanism. These
>>>>> image-modules would be edited from a development-image-bundle. They
>>>>> could be used to form stand-alone applications already clean of the
>>>>> development code or libraries that contain only a diff to the base
>>>>> classes, these library-images could then be combined to form more
>>>>> complex images. They could also contain their own namespace… and they
>>>>> would replace the non-modelling packaging mechanism, but I digress… ^^
>>>>>
>>>>> | packageWorkedOn |
>>>>> packageWorkedOn := Browser newPackageNamed: 'Calculator'.
>>>>> packageWorkedOn importPackage: 'Seaside'.
>>>>> "Create code in the Browser…"
>>>>> packageWorkedOn saveAsMonticello.
>>>>> packageWordedOn saveAsPackage.
>>>>> packageWorkedOn saveAsApplication.
>>>>>
>>>>> or something like that … ^^
>>>>>
>>>>> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <[hidden email]> wrote:
>>>>>>
>>>>>> jarober says:
>>>>>>
>>>>>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM"
>>>>>>> projects never seem to come off is simple - Smalltalk isn't just flat
>>>>>>> text in an editor.  Smalltalk is the entire interactive environment.
>>>>>>> It would be fairly simple to get a syntax parser, but it wouldn't be
>>>>>>> Smalltalk.  It would be Ruby or Python with Smalltalk syntax.
>>>>>>> Somewhat useful perhaps, but not really Smalltalk.
>>>>>>
>>>>>> :(
>>>>>>
>>>>>> Hopefully it would have sufficient knowledge to be able to do something
>>>>>> thus.
>>>>>>
>>>>>> Sorry, but I believe that it is the way that had to take commercial
>>>>>> Smalltalk. It surprises to me that Cincom and company do not see it.
>>>>>>
>>>>>> Regards.
>>>>>> --
>>>>>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.html
>>>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>> [hidden email]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> I'd like to contribute, but I am not good enough for the difficult
> ones to come to pleasing solutions, and I somehow don't feel the other
> ones accessable for me :/
>
> On Sat, Apr 10, 2010 at 9:21 PM, Stéphane Ducasse
> <[hidden email]> wrote:
>> Hi richard
>>
>> some changes are changes coming from squeak and in such a case there is the squeak change
>> It does not mean that we can integrate the change as it is.
>> Thanks for looking at fixes and bug entries
>>
>> Stef
>>
>> On Apr 10, 2010, at 7:52 PM, Richard Durr wrote:
>>
>>> I am still trying to grok how this issue-fixing works. For example, in
>>> "Difficulty:Easy" there are some issues which consist mostly of
>>> ChangeSets of something. O_o
>>
>> O_o
>>
>> Nice :)
>>
>>
>>>
>>> On Tue, Apr 6, 2010 at 10:50 AM, Stéphane Ducasse
>>> <[hidden email]> wrote:
>>>> Yes this is the vision we have.
>>>> Now if people would help for simple things in pharo we would have more time for such issues.
>>>> We got several people doing PhD on modules and related. We studied namespace and other kind of
>>>> points so we have an idea of what could be a solution but it should be implemented
>>>> tested.....
>>>>
>>>> Stef
>>>>
>>>>
>>>> On Apr 6, 2010, at 1:14 AM, Richard Durr wrote:
>>>>
>>>>> No, it's not. I would be far more valuable to have modularized images
>>>>> though: Just like Next/Apples Nibs or Bundle-mechanism. These
>>>>> image-modules would be edited from a development-image-bundle. They
>>>>> could be used to form stand-alone applications already clean of the
>>>>> development code or libraries that contain only a diff to the base
>>>>> classes, these library-images could then be combined to form more
>>>>> complex images. They could also contain their own namespace… and they
>>>>> would replace the non-modelling packaging mechanism, but I digress… ^^
>>>>>
>>>>> | packageWorkedOn |
>>>>> packageWorkedOn := Browser newPackageNamed: 'Calculator'.
>>>>> packageWorkedOn importPackage: 'Seaside'.
>>>>> "Create code in the Browser…"
>>>>> packageWorkedOn saveAsMonticello.
>>>>> packageWordedOn saveAsPackage.
>>>>> packageWorkedOn saveAsApplication.
>>>>>
>>>>> or something like that … ^^
>>>>>
>>>>> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <[hidden email]> wrote:
>>>>>>
>>>>>> jarober says:
>>>>>>
>>>>>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM"
>>>>>>> projects never seem to come off is simple - Smalltalk isn't just flat
>>>>>>> text in an editor.  Smalltalk is the entire interactive environment.
>>>>>>> It would be fairly simple to get a syntax parser, but it wouldn't be
>>>>>>> Smalltalk.  It would be Ruby or Python with Smalltalk syntax.
>>>>>>> Somewhat useful perhaps, but not really Smalltalk.
>>>>>>
>>>>>> :(
>>>>>>
>>>>>> Hopefully it would have sufficient knowledge to be able to do something
>>>>>> thus.
>>>>>>
>>>>>> Sorry, but I believe that it is the way that had to take commercial
>>>>>> Smalltalk. It surprises to me that Cincom and company do not see it.
>>>>>>
>>>>>> Regards.
>>>>>> --
>>>>>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.html
>>>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>> [hidden email]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Richard
>
> Nicolas checked systematically that add: method returns their argument.
>
>        - Issue 2171:   add consistency in MC, Exception and other
>
> for the tests:
>        this a list of possible tests that would be worth to migrate to pharo.
>        - Issue 2238:   tests for FileStream behavior
>        - Issue 1920:   Better PureBehaviorTests
>        - Issue 1934:   some tests for WeakRegistry
>
> Let me know if you need advices.
>
> Stef
>
> On Apr 11, 2010, at 6:16 PM, Richard Durr wrote:
>
>> I'd like to contribute, but I am not good enough for the difficult
>> ones to come to pleasing solutions, and I somehow don't feel the other
>> ones accessable for me :/
>>
>> On Sat, Apr 10, 2010 at 9:21 PM, Stéphane Ducasse
>> <[hidden email]> wrote:
>>> Hi richard
>>>
>>> some changes are changes coming from squeak and in such a case there is the squeak change
>>> It does not mean that we can integrate the change as it is.
>>> Thanks for looking at fixes and bug entries
>>>
>>> Stef
>>>
>>> On Apr 10, 2010, at 7:52 PM, Richard Durr wrote:
>>>
>>>> I am still trying to grok how this issue-fixing works. For example, in
>>>> "Difficulty:Easy" there are some issues which consist mostly of
>>>> ChangeSets of something. O_o
>>>
>>> O_o
>>>
>>> Nice :)
>>>
>>>
>>>>
>>>> On Tue, Apr 6, 2010 at 10:50 AM, Stéphane Ducasse
>>>> <[hidden email]> wrote:
>>>>> Yes this is the vision we have.
>>>>> Now if people would help for simple things in pharo we would have more time for such issues.
>>>>> We got several people doing PhD on modules and related. We studied namespace and other kind of
>>>>> points so we have an idea of what could be a solution but it should be implemented
>>>>> tested.....
>>>>>
>>>>> Stef
>>>>>
>>>>>
>>>>> On Apr 6, 2010, at 1:14 AM, Richard Durr wrote:
>>>>>
>>>>>> No, it's not. I would be far more valuable to have modularized images
>>>>>> though: Just like Next/Apples Nibs or Bundle-mechanism. These
>>>>>> image-modules would be edited from a development-image-bundle. They
>>>>>> could be used to form stand-alone applications already clean of the
>>>>>> development code or libraries that contain only a diff to the base
>>>>>> classes, these library-images could then be combined to form more
>>>>>> complex images. They could also contain their own namespace… and they
>>>>>> would replace the non-modelling packaging mechanism, but I digress… ^^
>>>>>>
>>>>>> | packageWorkedOn |
>>>>>> packageWorkedOn := Browser newPackageNamed: 'Calculator'.
>>>>>> packageWorkedOn importPackage: 'Seaside'.
>>>>>> "Create code in the Browser…"
>>>>>> packageWorkedOn saveAsMonticello.
>>>>>> packageWordedOn saveAsPackage.
>>>>>> packageWorkedOn saveAsApplication.
>>>>>>
>>>>>> or something like that … ^^
>>>>>>
>>>>>> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <[hidden email]> wrote:
>>>>>>>
>>>>>>> jarober says:
>>>>>>>
>>>>>>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM"
>>>>>>>> projects never seem to come off is simple - Smalltalk isn't just flat
>>>>>>>> text in an editor.  Smalltalk is the entire interactive environment.
>>>>>>>> It would be fairly simple to get a syntax parser, but it wouldn't be
>>>>>>>> Smalltalk.  It would be Ruby or Python with Smalltalk syntax.
>>>>>>>> Somewhat useful perhaps, but not really Smalltalk.
>>>>>>>
>>>>>>> :(
>>>>>>>
>>>>>>> Hopefully it would have sufficient knowledge to be able to do something
>>>>>>> thus.
>>>>>>>
>>>>>>> Sorry, but I believe that it is the way that had to take commercial
>>>>>>> Smalltalk. It surprises to me that Cincom and company do not see it.
>>>>>>>
>>>>>>> Regards.
>>>>>>> --
>>>>>>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.html
>>>>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pharo-project mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>> [hidden email]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> These would be migrated from Squeak to Pharo, right?
>
> On Sun, Apr 11, 2010 at 10:01 PM, Stéphane Ducasse
> <[hidden email]> wrote:
>> Richard
>>
>> Nicolas checked systematically that add: method returns their argument.
>>
>>        - Issue 2171:   add consistency in MC, Exception and other
>>
>> for the tests:
>>        this a list of possible tests that would be worth to migrate to pharo.
>>        - Issue 2238:   tests for FileStream behavior
>>        - Issue 1920:   Better PureBehaviorTests
>>        - Issue 1934:   some tests for WeakRegistry
>>
>> Let me know if you need advices.
>>
>> Stef
>>
>> On Apr 11, 2010, at 6:16 PM, Richard Durr wrote:
>>
>>> I'd like to contribute, but I am not good enough for the difficult
>>> ones to come to pleasing solutions, and I somehow don't feel the other
>>> ones accessable for me :/
>>>
>>> On Sat, Apr 10, 2010 at 9:21 PM, Stéphane Ducasse
>>> <[hidden email]> wrote:
>>>> Hi richard
>>>>
>>>> some changes are changes coming from squeak and in such a case there is the squeak change
>>>> It does not mean that we can integrate the change as it is.
>>>> Thanks for looking at fixes and bug entries
>>>>
>>>> Stef
>>>>
>>>> On Apr 10, 2010, at 7:52 PM, Richard Durr wrote:
>>>>
>>>>> I am still trying to grok how this issue-fixing works. For example, in
>>>>> "Difficulty:Easy" there are some issues which consist mostly of
>>>>> ChangeSets of something. O_o
>>>>
>>>> O_o
>>>>
>>>> Nice :)
>>>>
>>>>
>>>>>
>>>>> On Tue, Apr 6, 2010 at 10:50 AM, Stéphane Ducasse
>>>>> <[hidden email]> wrote:
>>>>>> Yes this is the vision we have.
>>>>>> Now if people would help for simple things in pharo we would have more time for such issues.
>>>>>> We got several people doing PhD on modules and related. We studied namespace and other kind of
>>>>>> points so we have an idea of what could be a solution but it should be implemented
>>>>>> tested.....
>>>>>>
>>>>>> Stef
>>>>>>
>>>>>>
>>>>>> On Apr 6, 2010, at 1:14 AM, Richard Durr wrote:
>>>>>>
>>>>>>> No, it's not. I would be far more valuable to have modularized images
>>>>>>> though: Just like Next/Apples Nibs or Bundle-mechanism. These
>>>>>>> image-modules would be edited from a development-image-bundle. They
>>>>>>> could be used to form stand-alone applications already clean of the
>>>>>>> development code or libraries that contain only a diff to the base
>>>>>>> classes, these library-images could then be combined to form more
>>>>>>> complex images. They could also contain their own namespace… and they
>>>>>>> would replace the non-modelling packaging mechanism, but I digress… ^^
>>>>>>>
>>>>>>> | packageWorkedOn |
>>>>>>> packageWorkedOn := Browser newPackageNamed: 'Calculator'.
>>>>>>> packageWorkedOn importPackage: 'Seaside'.
>>>>>>> "Create code in the Browser…"
>>>>>>> packageWorkedOn saveAsMonticello.
>>>>>>> packageWordedOn saveAsPackage.
>>>>>>> packageWorkedOn saveAsApplication.
>>>>>>>
>>>>>>> or something like that … ^^
>>>>>>>
>>>>>>> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> jarober says:
>>>>>>>>
>>>>>>>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM"
>>>>>>>>> projects never seem to come off is simple - Smalltalk isn't just flat
>>>>>>>>> text in an editor.  Smalltalk is the entire interactive environment.
>>>>>>>>> It would be fairly simple to get a syntax parser, but it wouldn't be
>>>>>>>>> Smalltalk.  It would be Ruby or Python with Smalltalk syntax.
>>>>>>>>> Somewhat useful perhaps, but not really Smalltalk.
>>>>>>>>
>>>>>>>> :(
>>>>>>>>
>>>>>>>> Hopefully it would have sufficient knowledge to be able to do something
>>>>>>>> thus.
>>>>>>>>
>>>>>>>> Sorry, but I believe that it is the way that had to take commercial
>>>>>>>> Smalltalk. It surprises to me that Cincom and company do not see it.
>>>>>>>>
>>>>>>>> Regards.
>>>>>>>> --
>>>>>>>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.html
>>>>>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pharo-project mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pharo-project mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>> [hidden email]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> On Sun, Apr 11, 2010 at 10:01 PM, Stéphane Ducasse
> <[hidden email]> wrote:
>> Richard
>>
>> Nicolas checked systematically that add: method returns their argument.
>>
>>        - Issue 2171:   add consistency in MC, Exception and other
>>
>> for the tests:
>>        this a list of possible tests that would be worth to migrate to pharo.
>>        - Issue 2238:   tests for FileStream behavior
>>        - Issue 1920:   Better PureBehaviorTests
>>        - Issue 1934:   some tests for WeakRegistry
>>
>> Let me know if you need advices.
>>
>> Stef
>>
>> On Apr 11, 2010, at 6:16 PM, Richard Durr wrote:
>>
>>> I'd like to contribute, but I am not good enough for the difficult
>>> ones to come to pleasing solutions, and I somehow don't feel the other
>>> ones accessable for me :/
>>>
>>> On Sat, Apr 10, 2010 at 9:21 PM, Stéphane Ducasse
>>> <[hidden email]> wrote:
>>>> Hi richard
>>>>
>>>> some changes are changes coming from squeak and in such a case there is the squeak change
>>>> It does not mean that we can integrate the change as it is.
>>>> Thanks for looking at fixes and bug entries
>>>>
>>>> Stef
>>>>
>>>> On Apr 10, 2010, at 7:52 PM, Richard Durr wrote:
>>>>
>>>>> I am still trying to grok how this issue-fixing works. For example, in
>>>>> "Difficulty:Easy" there are some issues which consist mostly of
>>>>> ChangeSets of something. O_o
>>>>
>>>> O_o
>>>>
>>>> Nice :)
>>>>
>>>>
>>>>>
>>>>> On Tue, Apr 6, 2010 at 10:50 AM, Stéphane Ducasse
>>>>> <[hidden email]> wrote:
>>>>>> Yes this is the vision we have.
>>>>>> Now if people would help for simple things in pharo we would have more time for such issues.
>>>>>> We got several people doing PhD on modules and related. We studied namespace and other kind of
>>>>>> points so we have an idea of what could be a solution but it should be implemented
>>>>>> tested.....
>>>>>>
>>>>>> Stef
>>>>>>
>>>>>>
>>>>>> On Apr 6, 2010, at 1:14 AM, Richard Durr wrote:
>>>>>>
>>>>>>> No, it's not. I would be far more valuable to have modularized images
>>>>>>> though: Just like Next/Apples Nibs or Bundle-mechanism. These
>>>>>>> image-modules would be edited from a development-image-bundle. They
>>>>>>> could be used to form stand-alone applications already clean of the
>>>>>>> development code or libraries that contain only a diff to the base
>>>>>>> classes, these library-images could then be combined to form more
>>>>>>> complex images. They could also contain their own namespace… and they
>>>>>>> would replace the non-modelling packaging mechanism, but I digress… ^^
>>>>>>>
>>>>>>> | packageWorkedOn |
>>>>>>> packageWorkedOn := Browser newPackageNamed: 'Calculator'.
>>>>>>> packageWorkedOn importPackage: 'Seaside'.
>>>>>>> "Create code in the Browser…"
>>>>>>> packageWorkedOn saveAsMonticello.
>>>>>>> packageWordedOn saveAsPackage.
>>>>>>> packageWorkedOn saveAsApplication.
>>>>>>>
>>>>>>> or something like that … ^^
>>>>>>>
>>>>>>> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> jarober says:
>>>>>>>>
>>>>>>>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM"
>>>>>>>>> projects never seem to come off is simple - Smalltalk isn't just flat
>>>>>>>>> text in an editor.  Smalltalk is the entire interactive environment.
>>>>>>>>> It would be fairly simple to get a syntax parser, but it wouldn't be
>>>>>>>>> Smalltalk.  It would be Ruby or Python with Smalltalk syntax.
>>>>>>>>> Somewhat useful perhaps, but not really Smalltalk.
>>>>>>>>
>>>>>>>> :(
>>>>>>>>
>>>>>>>> Hopefully it would have sufficient knowledge to be able to do something
>>>>>>>> thus.
>>>>>>>>
>>>>>>>> Sorry, but I believe that it is the way that had to take commercial
>>>>>>>> Smalltalk. It surprises to me that Cincom and company do not see it.
>>>>>>>>
>>>>>>>> Regards.
>>>>>>>> --
>>>>>>>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.html
>>>>>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pharo-project mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pharo-project mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>> [hidden email]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project