Compatibility packages folder? (was Re: isXXX methods? (was Re: 4 additions to core?))

> Could we remove SqueakCompatability from the Core-Packages.pck.st?  That way
> we can ensure that our core packages follow the Cuis philosophy.
>
>
>> On May 14, 2015, at 9:07 AM, Juan Vuletich <[hidden email]> wrote:
>>
>> On 5/14/2015 5:52 AM, H. Hirzel wrote:
>>> Thank you for the clarification, Juan.
>>>
>>> I am aiming at semi-automated porting, i.e. to come up with a recipe
>>> of activities to do the port https://github.com/hhzl/Cuis-NeoCSV.
>>>
>>> I want to redo it, as Sven has posted a new version last week end.
>>>
>>> Replacing
>>>
>>>      isCharacter
>>>
>>> with
>>>
>>>     is: Character
>>>
>>> is fine.
>>
>> But in Cuis it would be '$a class == Character' or '$a isKindOf:
>> Character'. A reasonable alternative is to simply add #isCharacter to
>> SqueakCompatibility.pck.st.
>>
>>> Then I'd like to apply the same recipe to his NeoJSON package.
>>>
>>> cheers
>>> Hannes
>>
>> Cheers,
>> Juan Vuletich
>>
>>> On 5/14/15, Juan Vuletich<[hidden email]>  wrote:
>>>> Hi Hannes,
>>>>
>>>> On 5/13/2015 4:54 PM, H. Hirzel wrote:
>>>>> I do not fully get you Juan.
>>>>>
>>>>> Could you provide a bit more context about what you want to do with
>>>>> the
>>>>>
>>>>>        isXXX
>>>>>
>>>>> methods?
>>>>>
>>>>> HH
>>>> I just think that Object has too many methods, and has a lot of methods
>>>> that are not the business of Object at all. A clear example is
>>>> #isMethodProperties. Does Object really need to know or care about
>>>> MethodProperties?
>>>>
>>>> For the particular case of isXXX methods, in many cases they can be
>>>> replaced by a single #is: method that in Object just answers false. See
>>>> implementors in Cuis for its use.
>>>>
>>>> There are many isXXX methods still in Cuis. #isHeap is an example.
>>>>
>>>> HTH.
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>>> On 5/13/15, Juan Vuletich<[hidden email]>   wrote:
>>>>>> There's always more cleanup to be done!
>>>>>>
>>>>>> #isHeap is easy to remove. But #isArray might be a bit riskier. These
>>>>>> isXXX methods that simply answer a constant are extremely fast, and
>>>>>> never cause context switch. I guess this is important for #isFloat,
>>>>>> #isInteger, #isFraction, although the default that answers false
>>>>>> could
>>>>>> be defined in Number, and not Object... And I'm not really sure for
>>>>>> #isArray.
>>>>>>
>>>>>> As usual, if you feel like digging into this, contributions are
>>>>>> welcome.
>>>>>>
>>>>>> Cheers,
>>>>>> Juan Vuletich
>>>>>>
>>>>>> On 5/12/2015 12:18 PM, David Graham wrote:
>>>>>>> I agree with this. :)  A while back I noticed that some collections
>>>>>>> have isXXX (like isArray and isHeap), while others don't.  Is this
>>>>>>> just a matter of cleanup or is there some logic I'm missing?
>>>>>>>
>>>>>>> On 5/10/2015 1:31 PM, Juan Vuletich wrote:
>>>>>>>> - Character>>   isCharacter
>>>>>>>> I guess we'd also need to add it to Object for this to make sense.
>>>>>>>> But we all agree that calling isXXX methods is not nice style,
>>>>>>>> right?
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Cuis mailing list
>>>>>>> [hidden email]
>>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>> _______________________________________________
>>>>> Cuis mailing list
>>>>> [hidden email]
>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>>
>>>>
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

> Yes, a folder
>
>     Packages_compatibility
>
> as a sibling to
>
>     Packages
>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>
> would be fine. There might be several compatibility packages.
>
> On 5/14/15, David Graham<[hidden email]>  wrote:
>> Could we remove SqueakCompatability from the Core-Packages.pck.st?  That way
>> we can ensure that our core packages follow the Cuis philosophy.
>>
>>
>>> On May 14, 2015, at 9:07 AM, Juan Vuletich<[hidden email]>  wrote:
>>>
>>> On 5/14/2015 5:52 AM, H. Hirzel wrote:
>>>> Thank you for the clarification, Juan.
>>>>
>>>> I am aiming at semi-automated porting, i.e. to come up with a recipe
>>>> of activities to do the port https://github.com/hhzl/Cuis-NeoCSV.
>>>>
>>>> I want to redo it, as Sven has posted a new version last week end.
>>>>
>>>> Replacing
>>>>
>>>>       isCharacter
>>>>
>>>> with
>>>>
>>>>      is: Character
>>>>
>>>> is fine.
>>> But in Cuis it would be '$a class == Character' or '$a isKindOf:
>>> Character'. A reasonable alternative is to simply add #isCharacter to
>>> SqueakCompatibility.pck.st.
>>>
>>>> Then I'd like to apply the same recipe to his NeoJSON package.
>>>>
>>>> cheers
>>>> Hannes
>>> Cheers,
>>> Juan Vuletich
>>>
>>>> On 5/14/15, Juan Vuletich<[hidden email]>   wrote:
>>>>> Hi Hannes,
>>>>>
>>>>> On 5/13/2015 4:54 PM, H. Hirzel wrote:
>>>>>> I do not fully get you Juan.
>>>>>>
>>>>>> Could you provide a bit more context about what you want to do with
>>>>>> the
>>>>>>
>>>>>>         isXXX
>>>>>>
>>>>>> methods?
>>>>>>
>>>>>> HH
>>>>> I just think that Object has too many methods, and has a lot of methods
>>>>> that are not the business of Object at all. A clear example is
>>>>> #isMethodProperties. Does Object really need to know or care about
>>>>> MethodProperties?
>>>>>
>>>>> For the particular case of isXXX methods, in many cases they can be
>>>>> replaced by a single #is: method that in Object just answers false. See
>>>>> implementors in Cuis for its use.
>>>>>
>>>>> There are many isXXX methods still in Cuis. #isHeap is an example.
>>>>>
>>>>> HTH.
>>>>>
>>>>> Cheers,
>>>>> Juan Vuletich
>>>>>
>>>>>> On 5/13/15, Juan Vuletich<[hidden email]>    wrote:
>>>>>>> There's always more cleanup to be done!
>>>>>>>
>>>>>>> #isHeap is easy to remove. But #isArray might be a bit riskier. These
>>>>>>> isXXX methods that simply answer a constant are extremely fast, and
>>>>>>> never cause context switch. I guess this is important for #isFloat,
>>>>>>> #isInteger, #isFraction, although the default that answers false
>>>>>>> could
>>>>>>> be defined in Number, and not Object... And I'm not really sure for
>>>>>>> #isArray.
>>>>>>>
>>>>>>> As usual, if you feel like digging into this, contributions are
>>>>>>> welcome.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Juan Vuletich
>>>>>>>
>>>>>>> On 5/12/2015 12:18 PM, David Graham wrote:
>>>>>>>> I agree with this. :)  A while back I noticed that some collections
>>>>>>>> have isXXX (like isArray and isHeap), while others don't.  Is this
>>>>>>>> just a matter of cleanup or is there some logic I'm missing?
>>>>>>>>
>>>>>>>> On 5/10/2015 1:31 PM, Juan Vuletich wrote:
>>>>>>>>> - Character>>    isCharacter
>>>>>>>>> I guess we'd also need to add it to Object for this to make sense.
>>>>>>>>> But we all agree that calling isXXX methods is not nice style,
>>>>>>>>> right?
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Cuis mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>>> _______________________________________________
>>>>>> Cuis mailing list
>>>>>> [hidden email]
>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>>>
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> [hidden email]
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

> Yes, I like this idea.
>
> What do others think?
>
> Cheers,
> Juan Vuletich
>
> On 5/14/2015 2:45 PM, H. Hirzel wrote:
> > Yes, a folder
> >
> >     Packages_compatibility
> >
> > as a sibling to
> >
> >     Packages
> >
> > https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> >
> > would be fine. There might be several compatibility packages.
> >
> > On 5/14/15, David Graham<[hidden email]>  wrote:
> >> Could we remove SqueakCompatability from the Core-Packages.pck.st?  That way
> >> we can ensure that our core packages follow the Cuis philosophy.
> >>
> >>
> >>> On May 14, 2015, at 9:07 AM, Juan Vuletich<[hidden email]>  wrote:
> >>>
> >>> On 5/14/2015 5:52 AM, H. Hirzel wrote:
> >>>> Thank you for the clarification, Juan.
> >>>>
> >>>> I am aiming at semi-automated porting, i.e. to come up with a recipe
> >>>> of activities to do the port https://github.com/hhzl/Cuis-NeoCSV.
> >>>>
> >>>> I want to redo it, as Sven has posted a new version last week end.
> >>>>
> >>>> Replacing
> >>>>
> >>>>       isCharacter
> >>>>
> >>>> with
> >>>>
> >>>>      is: Character
> >>>>
> >>>> is fine.
> >>> But in Cuis it would be '$a class == Character' or '$a isKindOf:
> >>> Character'. A reasonable alternative is to simply add #isCharacter to
> >>> SqueakCompatibility.pck.st.
> >>>
> >>>> Then I'd like to apply the same recipe to his NeoJSON package.
> >>>>
> >>>> cheers
> >>>> Hannes
> >>> Cheers,
> >>> Juan Vuletich
> >>>
> >>>> On 5/14/15, Juan Vuletich<[hidden email]>   wrote:
> >>>>> Hi Hannes,
> >>>>>
> >>>>> On 5/13/2015 4:54 PM, H. Hirzel wrote:
> >>>>>> I do not fully get you Juan.
> >>>>>>
> >>>>>> Could you provide a bit more context about what you want to do with
> >>>>>> the
> >>>>>>
> >>>>>>         isXXX
> >>>>>>
> >>>>>> methods?
> >>>>>>
> >>>>>> HH
> >>>>> I just think that Object has too many methods, and has a lot of methods
> >>>>> that are not the business of Object at all. A clear example is
> >>>>> #isMethodProperties. Does Object really need to know or care about
> >>>>> MethodProperties?
> >>>>>
> >>>>> For the particular case of isXXX methods, in many cases they can be
> >>>>> replaced by a single #is: method that in Object just answers false. See
> >>>>> implementors in Cuis for its use.
> >>>>>
> >>>>> There are many isXXX methods still in Cuis. #isHeap is an example.
> >>>>>
> >>>>> HTH.
> >>>>>
> >>>>> Cheers,
> >>>>> Juan Vuletich
> >>>>>
> >>>>>> On 5/13/15, Juan Vuletich<[hidden email]>    wrote:
> >>>>>>> There's always more cleanup to be done!
> >>>>>>>
> >>>>>>> #isHeap is easy to remove. But #isArray might be a bit riskier. These
> >>>>>>> isXXX methods that simply answer a constant are extremely fast, and
> >>>>>>> never cause context switch. I guess this is important for #isFloat,
> >>>>>>> #isInteger, #isFraction, although the default that answers false
> >>>>>>> could
> >>>>>>> be defined in Number, and not Object... And I'm not really sure for
> >>>>>>> #isArray.
> >>>>>>>
> >>>>>>> As usual, if you feel like digging into this, contributions are
> >>>>>>> welcome.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Juan Vuletich
> >>>>>>>
> >>>>>>> On 5/12/2015 12:18 PM, David Graham wrote:
> >>>>>>>> I agree with this. :)  A while back I noticed that some collections
> >>>>>>>> have isXXX (like isArray and isHeap), while others don't.  Is this
> >>>>>>>> just a matter of cleanup or is there some logic I'm missing?
> >>>>>>>>
> >>>>>>>> On 5/10/2015 1:31 PM, Juan Vuletich wrote:
> >>>>>>>>> - Character>>    isCharacter
> >>>>>>>>> I guess we'd also need to add it to Object for this to make sense.
> >>>>>>>>> But we all agree that calling isXXX methods is not nice style,
> >>>>>>>>> right?
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Cuis mailing list
> >>>>>>>> [hidden email]
> >>>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>>>>> _______________________________________________
> >>>>>> Cuis mailing list
> >>>>>> [hidden email]
> >>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>>>>>
> >>>
> >>> _______________________________________________
> >>> Cuis mailing list
> >>> [hidden email]
> >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>
> >> _______________________________________________
> >> Cuis mailing list
> >> [hidden email]
> >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>
> > _______________________________________________
> > Cuis mailing list
> > [hidden email]
> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

> Yes, I like this idea.
>
> What do others think?
>
> Cheers,
> Juan Vuletich
>
> On 5/14/2015 2:45 PM, H. Hirzel wrote:
>> Yes, a folder
>>
>>     Packages_compatibility
>>
>> as a sibling to
>>
>>     Packages
>>
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>>
>> would be fine. There might be several compatibility packages.
>>
>> On 5/14/15, David Graham<[hidden email]>  wrote:
>>> Could we remove SqueakCompatability from the Core-Packages.pck.st?  
>>> That way
>>> we can ensure that our core packages follow the Cuis philosophy.
>>>
>>>
>>>> On May 14, 2015, at 9:07 AM, Juan Vuletich<[hidden email]>  wrote:
>>>>
>>>> On 5/14/2015 5:52 AM, H. Hirzel wrote:
>>>>> Thank you for the clarification, Juan.
>>>>>
>>>>> I am aiming at semi-automated porting, i.e. to come up with a recipe
>>>>> of activities to do the port https://github.com/hhzl/Cuis-NeoCSV.
>>>>>
>>>>> I want to redo it, as Sven has posted a new version last week end.
>>>>>
>>>>> Replacing
>>>>>
>>>>>       isCharacter
>>>>>
>>>>> with
>>>>>
>>>>>      is: Character
>>>>>
>>>>> is fine.
>>>> But in Cuis it would be '$a class == Character' or '$a isKindOf:
>>>> Character'. A reasonable alternative is to simply add #isCharacter to
>>>> SqueakCompatibility.pck.st.
>>>>
>>>>> Then I'd like to apply the same recipe to his NeoJSON package.
>>>>>
>>>>> cheers
>>>>> Hannes
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>>> On 5/14/15, Juan Vuletich<[hidden email]>   wrote:
>>>>>> Hi Hannes,
>>>>>>
>>>>>> On 5/13/2015 4:54 PM, H. Hirzel wrote:
>>>>>>> I do not fully get you Juan.
>>>>>>>
>>>>>>> Could you provide a bit more context about what you want to do with
>>>>>>> the
>>>>>>>
>>>>>>>         isXXX
>>>>>>>
>>>>>>> methods?
>>>>>>>
>>>>>>> HH
>>>>>> I just think that Object has too many methods, and has a lot of
>>>>>> methods
>>>>>> that are not the business of Object at all. A clear example is
>>>>>> #isMethodProperties. Does Object really need to know or care about
>>>>>> MethodProperties?
>>>>>>
>>>>>> For the particular case of isXXX methods, in many cases they can be
>>>>>> replaced by a single #is: method that in Object just answers
>>>>>> false. See
>>>>>> implementors in Cuis for its use.
>>>>>>
>>>>>> There are many isXXX methods still in Cuis. #isHeap is an example.
>>>>>>
>>>>>> HTH.
>>>>>>
>>>>>> Cheers,
>>>>>> Juan Vuletich
>>>>>>
>>>>>>> On 5/13/15, Juan Vuletich<[hidden email]>    wrote:
>>>>>>>> There's always more cleanup to be done!
>>>>>>>>
>>>>>>>> #isHeap is easy to remove. But #isArray might be a bit riskier.
>>>>>>>> These
>>>>>>>> isXXX methods that simply answer a constant are extremely fast,
>>>>>>>> and
>>>>>>>> never cause context switch. I guess this is important for
>>>>>>>> #isFloat,
>>>>>>>> #isInteger, #isFraction, although the default that answers false
>>>>>>>> could
>>>>>>>> be defined in Number, and not Object... And I'm not really sure
>>>>>>>> for
>>>>>>>> #isArray.
>>>>>>>>
>>>>>>>> As usual, if you feel like digging into this, contributions are
>>>>>>>> welcome.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Juan Vuletich
>>>>>>>>
>>>>>>>> On 5/12/2015 12:18 PM, David Graham wrote:
>>>>>>>>> I agree with this. :)  A while back I noticed that some
>>>>>>>>> collections
>>>>>>>>> have isXXX (like isArray and isHeap), while others don't.  Is
>>>>>>>>> this
>>>>>>>>> just a matter of cleanup or is there some logic I'm missing?
>>>>>>>>>
>>>>>>>>> On 5/10/2015 1:31 PM, Juan Vuletich wrote:
>>>>>>>>>> - Character>> isCharacter
>>>>>>>>>> I guess we'd also need to add it to Object for this to make
>>>>>>>>>> sense.
>>>>>>>>>> But we all agree that calling isXXX methods is not nice style,
>>>>>>>>>> right?
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Cuis mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>>>> _______________________________________________
>>>>>>> Cuis mailing list
>>>>>>> [hidden email]
>>>>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>>>>
>>>>
>>>> _______________________________________________
>>>> Cuis mailing list
>>>> [hidden email]
>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> [hidden email]
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

>
>
> On 5/16/2015 1:19 PM, Phil (list) wrote:
>> On Sat, 2015-05-16 at 10:50 -0500, David Graham wrote:
>>> Sounds fine to me, but I'm wondering if it would be a good time to
>>> create a separate github repo for non-core packages?  It would be nice
>>> to have a central place for packages which are not ready or don't
>>> belong
>>> in core.
>>>
>> We already have an index of non-core packages.  Centralizing into one
>> repo would defeat the whole point of git.
>
> Sorry, for clarification I wasn't trying to suggest that we put every
> package made for Cuis into a single repo, just the commonly used
> ones.  Maybe just move what is now Packages into separate repo ?  In
> all honesty, I don't have a strong opinion here, just brainstorming
> ways to help grow the community and potentially lighten Juan's workload.
>
> What I'd really like is to make all the legacy stuff like OSs, files,
> and git go away. :)

> On 5/16/2015 4:48 PM, David Graham wrote:
>>
>>
>> On 5/16/2015 1:19 PM, Phil (list) wrote:
>>> On Sat, 2015-05-16 at 10:50 -0500, David Graham wrote:
>>>> Sounds fine to me, but I'm wondering if it would be a good time to
>>>> create a separate github repo for non-core packages?  It would be nice
>>>> to have a central place for packages which are not ready or don't
>>>> belong
>>>> in core.
>>>>
>>> We already have an index of non-core packages.  Centralizing into one
>>> repo would defeat the whole point of git.
>>
>> Sorry, for clarification I wasn't trying to suggest that we put every
>> package made for Cuis into a single repo, just the commonly used
>> ones.  Maybe just move what is now Packages into separate repo ?  In
>> all honesty, I don't have a strong opinion here, just brainstorming
>> ways to help grow the community and potentially lighten Juan's workload.
>>
>> What I'd really like is to make all the legacy stuff like OSs, files,
>> and git go away. :)
>
> :)
>
> BTW, I just did a commit, with a new folder CompatibilityPackages.
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

> Juan,
>
> the new CompatibilityPackages has
>
> - SqueakCompatibility
>
> - VMMaker
> - Balloon
>
> in it. For SqueakCompatibility it is obvious that they are there. But
> what about the other comparatively large packages. A README.md file
> would clarify the situation why they are there.

> --Hannes
>
> On 5/16/15, Juan Vuletich<[hidden email]>  wrote:
>> On 5/16/2015 4:48 PM, David Graham wrote:
>>>
>>> On 5/16/2015 1:19 PM, Phil (list) wrote:
>>>> On Sat, 2015-05-16 at 10:50 -0500, David Graham wrote:
>>>>> Sounds fine to me, but I'm wondering if it would be a good time to
>>>>> create a separate github repo for non-core packages?  It would be nice
>>>>> to have a central place for packages which are not ready or don't
>>>>> belong
>>>>> in core.
>>>>>
>>>> We already have an index of non-core packages.  Centralizing into one
>>>> repo would defeat the whole point of git.
>>> Sorry, for clarification I wasn't trying to suggest that we put every
>>> package made for Cuis into a single repo, just the commonly used
>>> ones.  Maybe just move what is now Packages into separate repo ?  In
>>> all honesty, I don't have a strong opinion here, just brainstorming
>>> ways to help grow the community and potentially lighten Juan's workload.
>>>
>>> What I'd really like is to make all the legacy stuff like OSs, files,
>>> and git go away. :)
>> :)
>>
>> BTW, I just did a commit, with a new folder CompatibilityPackages.
>>
>> Cheers,
>> Juan Vuletich
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

> Hi Hannes,
>
> On 5/17/2015 8:10 AM, H. Hirzel wrote:
>> Juan,
>>
>> the new CompatibilityPackages has
>>
>> - SqueakCompatibility
>>
>> - VMMaker
>> - Balloon
>>
>> in it. For SqueakCompatibility it is obvious that they are there. But
>> what about the other comparatively large packages. A README.md file
>> would clarify the situation why they are there.
>
> Yes, we'd write some. At least, right now, let me say that that folder
> is for SqueakCompatibility.pck.st, and any other packages that depend on
> it. VMMaker, for instance, is a verbatim copy of current VMMaker for
> Squeak, without a single line of code changed. But this is open for
> discussion.
>
> Thoughts?
>
> Cheers,
> Juan Vuletich
>
>
>> --Hannes
>>
>> On 5/16/15, Juan Vuletich<[hidden email]>  wrote:
>>> On 5/16/2015 4:48 PM, David Graham wrote:
>>>>
>>>> On 5/16/2015 1:19 PM, Phil (list) wrote:
>>>>> On Sat, 2015-05-16 at 10:50 -0500, David Graham wrote:
>>>>>> Sounds fine to me, but I'm wondering if it would be a good time to
>>>>>> create a separate github repo for non-core packages?  It would be
>>>>>> nice
>>>>>> to have a central place for packages which are not ready or don't
>>>>>> belong
>>>>>> in core.
>>>>>>
>>>>> We already have an index of non-core packages.  Centralizing into one
>>>>> repo would defeat the whole point of git.
>>>> Sorry, for clarification I wasn't trying to suggest that we put every
>>>> package made for Cuis into a single repo, just the commonly used
>>>> ones.  Maybe just move what is now Packages into separate repo ?  In
>>>> all honesty, I don't have a strong opinion here, just brainstorming
>>>> ways to help grow the community and potentially lighten Juan's
>>>> workload.
>>>>
>>>> What I'd really like is to make all the legacy stuff like OSs, files,
>>>> and git go away. :)
>>> :)
>>>
>>> BTW, I just did a commit, with a new folder CompatibilityPackages.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> [hidden email]
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
>

> On May 18, 2015, at 5:37 PM, Juan Vuletich <[hidden email]> wrote:
>
> Hi Hannes,
>
>> On 5/17/2015 8:10 AM, H. Hirzel wrote:
>> Juan,
>>
>> the new CompatibilityPackages has
>>
>> - SqueakCompatibility
>>
>> - VMMaker
>> - Balloon
>>
>> in it. For SqueakCompatibility it is obvious that they are there. But
>> what about the other comparatively large packages. A README.md file
>> would clarify the situation why they are there.
>
> Yes, we'd write some. At least, right now, let me say that that folder is for SqueakCompatibility.pck.st, and any other packages that depend on it. VMMaker, for instance, is a verbatim copy of current VMMaker for Squeak, without a single line of code changed. But this is open for discussion.
>
> Thoughts?
>
> Cheers,
> Juan Vuletich
>
>
>> --Hannes
>>
>>> On 5/16/15, Juan Vuletich<[hidden email]>  wrote:
>>>> On 5/16/2015 4:48 PM, David Graham wrote:
>>>>
>>>>> On 5/16/2015 1:19 PM, Phil (list) wrote:
>>>>>> On Sat, 2015-05-16 at 10:50 -0500, David Graham wrote:
>>>>>> Sounds fine to me, but I'm wondering if it would be a good time to
>>>>>> create a separate github repo for non-core packages?  It would be nice
>>>>>> to have a central place for packages which are not ready or don't
>>>>>> belong
>>>>>> in core.
>>>>> We already have an index of non-core packages.  Centralizing into one
>>>>> repo would defeat the whole point of git.
>>>> Sorry, for clarification I wasn't trying to suggest that we put every
>>>> package made for Cuis into a single repo, just the commonly used
>>>> ones.  Maybe just move what is now Packages into separate repo ?  In
>>>> all honesty, I don't have a strong opinion here, just brainstorming
>>>> ways to help grow the community and potentially lighten Juan's workload.
>>>>
>>>> What I'd really like is to make all the legacy stuff like OSs, files,
>>>> and git go away. :)
>>> :)
>>>
>>> BTW, I just did a commit, with a new folder CompatibilityPackages.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> [hidden email]
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org