Xtreams , Ometa and related

> People:
>
> I working in my SqueakRosCore fork and think if Xtreams should be on it or
> not.
>
> Google surfing brings me
>
> http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/156355
>
> So, four years later I wish feedback about this.
>
> Cool working examples if you know of any.
>
> Opinions:
>
> SqueakSource have two projects about Xtreams, which one I should have ?
>

>
>
> On 5/16/15, 7:24 AM, "Phil (list)" <[hidden email]> wrote:
>
> > While both packages are very nice, I probably wouldn't want them in a
> > core image as I tend to prefer the minimalist approach to images.  They
> > would be great optional packages to have though.  (I understand you're
> > talking about SqueakROS and not Cuis, but just wanted to offer my
> > opinion since you were asking what people thought.)
>
> Thanks for your valuable feedback.
>
> Minimalist approach is one of my goals and was here for learn of Juan and
> all people here.
>
> So, not in the image but easily load and work.
>

>
>
> On 5/16/15, 7:24 AM, "Phil (list)"<[hidden email]>  wrote:
>
>> While both packages are very nice, I probably wouldn't want them in a
>> core image as I tend to prefer the minimalist approach to images.  They
>> would be great optional packages to have though.  (I understand you're
>> talking about SqueakROS and not Cuis, but just wanted to offer my
>> opinion since you were asking what people thought.)
> Thanks for your valuable feedback.
>
> Minimalist approach is one of my goals and was here for learn of Juan and
> all people here.
>
> So, not in the image but easily load and work.
>
> I asking for Xtreams as have a chance to meet Martin Kobetic when he was
> here in Argentina and presented his work.
>
> Seems wonderful at the time and revisiting
> https://code.google.com/p/xtreams/ still is.
>
> Could have sense a Cuis version ?
>
> Edgar

> On May 16, 2015, at 1:41 AM, "Edgar J. De Cleene" <[hidden email]> wrote:
>
> People:
>
> I working in my SqueakRosCore fork and think if Xtreams should be on it or
> not.
>
> Google surfing brings me
>
> http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/156355
>
> So, four years later I wish feedback about this.
>
> Cool working examples if you know of any.
>
> Opinions:
>
> SqueakSource have two projects about Xtreams, which one I should have ?
>
> Ometa  pay same day the work for having it into the .image ?
>
>
> Edgar
> @morplenauta en twitter
>
>
>
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

> On May 17, 2015, at 2:59 AM, "Edgar J. De Cleene" <[hidden email]> wrote:
>
>
>
>
>> On 5/16/15, 5:40 PM, "Casey Ransberger" <[hidden email]> wrote:
>>
>> However: if you get OMeta working cleanly in Cuis, I will personally wash your
>> feet with my mohawk. I mean someone else will have to cover the air fair, but
>> I will -- shit you not -- wash your feet with my freaking mohawk.
>>
>> There isn't a single thing I'm more interested in.
>
> Hello again Casey.
>
> So you say OMeta could pay the work...
>
> Could ellaborate some use cases?
>
> If I could put OMeta in Cuis hope you could come to Argentina to some future
> FAST Smalltalks event.
>
> And we exchange a couple of beers :=)
>
>
>
> Edgar
> @morplenauta en twitter
>
>
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

> People:
>
> I working in my SqueakRosCore fork and think if Xtreams should be on it or
> not.
>
> Google surfing brings me
>
> http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/156355
>
> So, four years later I wish feedback about this.
>
> Cool working examples if you know of any.
>
> Opinions:
>
> SqueakSource have two projects about Xtreams, which one I should have ?
>
> Ometa  pay same day the work for having it into the .image ?
>

> Your info is very useful.
> The experiment until now is I can load OMeta in Squeak 4.6 from
> SqueakSource.
> In my fork wich is Cuis 3,2 can’t load and several tricks for having
> the classes ordered before OMeta uses each failed.
> So if you have the original .st of Alessandro , wish have it for try.
> In Cuis as cloned from Github the preload package loads fine and the
> examples works as in Squeak 4.6.
> I send mail here with link to .jpg picture.
> But post load fails.
>

>
> Edgar
>
>
> --
> Edgar J. De Cleene
> Sent with Sparrow
>
>
> On Tuesday, May 19, 2015 at 6:55 PM, Phil (list) wrote:
>
> > On Sat, 2015-05-16 at 05:41 -0300, Edgar J. De Cleene wrote:
> > > People:
> > >
> > >
> > > I working in my SqueakRosCore fork and think if Xtreams should be
> > > on it or
> > > not.
> > >
> > >
> > > Google surfing brings me
> > >
> > >
> > > http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/156355
> > >
> > >
> > > So, four years later I wish feedback about this.
> > >
> > >
> > > Cool working examples if you know of any.
> > >
> > >
> > > Opinions:
> > >
> > >
> > > SqueakSource have two projects about Xtreams, which one I should
> > > have ?
> > >
> > >
> > > Ometa pay same day the work for having it into the .image ?
> >
> >
> > OK, it's all coming back to me as to why my port of OMeta2 died: I
> > had
> > it working perfectly in Cuis 1.0. I think I also had it working in
> > Cuis
> > 2.0 (I even have a .pck which I *believe* was kinda, sorta had
> > working
> > at one point... but now it can only be read in, it no longer works).
> >
> >
> > IIRC, the issue was that part of OMeta is written in OMeta so you
> > can't
> > just load it in the way you would a regular package. I think
> > original
> > work by Alessandro was a .st file which had a very specific ordering
> > of
> > code to load and ran some code as part of the filein which installed
> > OMeta into the image. The SqueakSource package addressed the loading
> > issues by splitting it in 2: a preload and postload package. I
> > believe
> > the preload package patches the parser so that the postload package
> > can
> > even be parsed by Squeak. Then there is some code that gets called
> > after the postload package has been read in that actually patches
> > OMeta
> > into the Squeak compiler. It's a bit tricky and changes to the
> > Smalltalk parser/compiler since then will require some changes (I
> > believe it broke as a result of the changes for closure support
> > being
> > added ~2012 or so)
> >
> >
> > I'm not sure how far you've gotten with it on your own already... if
> > what I have might be helpful, let me know and I'll see if I can't
> > clean
> > it up a bit and put it up on github.
> >
> >
> > >
> > >
> > > Edgar
> > > @morplenauta en twitter
> >
> >
> > Thanks,
> > Phil
> >
> >
> >
> >
> > _______________________________________________
> > 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 Tue, 2015-05-19 at 19:12 -0300, Edgar J. De Cleene wrote:
>> Your info is very useful.
>> The experiment until now is I can load OMeta in Squeak 4.6 from
>> SqueakSource.
>> In my fork wich is Cuis 3,2 can’t load and several tricks for having
>> the classes ordered before OMeta uses each failed.
>> So if you have the original .st of Alessandro , wish have it for try.
>> In Cuis as cloned from Github the preload package loads fine and the
>> examples works as in Squeak 4.6.
>> I send mail here with link to .jpg picture.
>> But post load fails.
>>
>
> OK, I've almost got it working again except for one tiny thing (that
> breaks everything)... #compilerClass no longer exists.  I've poked
> around and all of the compiler indirection has been removed (i.e.
> Compiler is hard-coded everywhere).  This completely breaks OMeta2 so
> unless Juan would consider bringing this functionality back, it's
> probably not going to work without essentially a rewrite.
>
> ... so that's why I gave up on it :-(
>
>>
>> Edgar
>>
>>
>> --
>> Edgar J. De Cleene
>> Sent with Sparrow
>>
>>
>> On Tuesday, May 19, 2015 at 6:55 PM, Phil (list) wrote:
>>
>> > On Sat, 2015-05-16 at 05:41 -0300, Edgar J. De Cleene wrote:
>> > > People:
>> > >
>> > >
>> > > I working in my SqueakRosCore fork and think if Xtreams should be
>> > > on it or
>> > > not.
>> > >
>> > >
>> > > Google surfing brings me
>> > >
>> > >
>> > > http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/156355
>> > >
>> > >
>> > > So, four years later I wish feedback about this.
>> > >
>> > >
>> > > Cool working examples if you know of any.
>> > >
>> > >
>> > > Opinions:
>> > >
>> > >
>> > > SqueakSource have two projects about Xtreams, which one I should
>> > > have ?
>> > >
>> > >
>> > > Ometa pay same day the work for having it into the .image ?
>> >
>> >
>> > OK, it's all coming back to me as to why my port of OMeta2 died: I
>> > had
>> > it working perfectly in Cuis 1.0. I think I also had it working in
>> > Cuis
>> > 2.0 (I even have a .pck which I *believe* was kinda, sorta had
>> > working
>> > at one point... but now it can only be read in, it no longer works).
>> >
>> >
>> > IIRC, the issue was that part of OMeta is written in OMeta so you
>> > can't
>> > just load it in the way you would a regular package. I think
>> > original
>> > work by Alessandro was a .st file which had a very specific ordering
>> > of
>> > code to load and ran some code as part of the filein which installed
>> > OMeta into the image. The SqueakSource package addressed the loading
>> > issues by splitting it in 2: a preload and postload package. I
>> > believe
>> > the preload package patches the parser so that the postload package
>> > can
>> > even be parsed by Squeak. Then there is some code that gets called
>> > after the postload package has been read in that actually patches
>> > OMeta
>> > into the Squeak compiler. It's a bit tricky and changes to the
>> > Smalltalk parser/compiler since then will require some changes (I
>> > believe it broke as a result of the changes for closure support
>> > being
>> > added ~2012 or so)
>> >
>> >
>> > I'm not sure how far you've gotten with it on your own already... if
>> > what I have might be helpful, let me know and I'll see if I can't
>> > clean
>> > it up a bit and put it up on github.
>> >
>> >
>> > >
>> > >
>> > > Edgar
>> > > @morplenauta en twitter
>> >
>> >
>> > Thanks,
>> > Phil
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > 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 May 19, 2015, at 7:00 PM, "Phil (list)" <[hidden email]> wrote:
>
>> On Tue, 2015-05-19 at 19:12 -0300, Edgar J. De Cleene wrote:
>> Your info is very useful.
>> The experiment until now is I can load OMeta in Squeak 4.6 from
>> SqueakSource.
>> In my fork wich is Cuis 3,2 can’t load and several tricks for having
>> the classes ordered before OMeta uses each failed.
>> So if you have the original .st of Alessandro , wish have it for try.
>> In Cuis as cloned from Github the preload package loads fine and the
>> examples works as in Squeak 4.6.
>> I send mail here with link to .jpg picture.
>> But post load fails.
>
> OK, I've almost got it working again except for one tiny thing (that
> breaks everything)... #compilerClass no longer exists.  I've poked
> around and all of the compiler indirection has been removed (i.e.
> Compiler is hard-coded everywhere).  This completely breaks OMeta2 so
> unless Juan would consider bringing this functionality back, it's
> probably not going to work without essentially a rewrite.
>
> ... so that's why I gave up on it :-(
>
>>
>> Edgar
>>
>>
>> --
>> Edgar J. De Cleene
>> Sent with Sparrow
>>
>>
>>> On Tuesday, May 19, 2015 at 6:55 PM, Phil (list) wrote:
>>>
>>>> On Sat, 2015-05-16 at 05:41 -0300, Edgar J. De Cleene wrote:
>>>> People:
>>>>
>>>>
>>>> I working in my SqueakRosCore fork and think if Xtreams should be
>>>> on it or
>>>> not.
>>>>
>>>>
>>>> Google surfing brings me
>>>>
>>>>
>>>> http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/156355
>>>>
>>>>
>>>> So, four years later I wish feedback about this.
>>>>
>>>>
>>>> Cool working examples if you know of any.
>>>>
>>>>
>>>> Opinions:
>>>>
>>>>
>>>> SqueakSource have two projects about Xtreams, which one I should
>>>> have ?
>>>>
>>>>
>>>> Ometa pay same day the work for having it into the .image ?
>>>
>>>
>>> OK, it's all coming back to me as to why my port of OMeta2 died: I
>>> had
>>> it working perfectly in Cuis 1.0. I think I also had it working in
>>> Cuis
>>> 2.0 (I even have a .pck which I *believe* was kinda, sorta had
>>> working
>>> at one point... but now it can only be read in, it no longer works).
>>>
>>>
>>> IIRC, the issue was that part of OMeta is written in OMeta so you
>>> can't
>>> just load it in the way you would a regular package. I think
>>> original
>>> work by Alessandro was a .st file which had a very specific ordering
>>> of
>>> code to load and ran some code as part of the filein which installed
>>> OMeta into the image. The SqueakSource package addressed the loading
>>> issues by splitting it in 2: a preload and postload package. I
>>> believe
>>> the preload package patches the parser so that the postload package
>>> can
>>> even be parsed by Squeak. Then there is some code that gets called
>>> after the postload package has been read in that actually patches
>>> OMeta
>>> into the Squeak compiler. It's a bit tricky and changes to the
>>> Smalltalk parser/compiler since then will require some changes (I
>>> believe it broke as a result of the changes for closure support
>>> being
>>> added ~2012 or so)
>>>
>>>
>>> I'm not sure how far you've gotten with it on your own already... if
>>> what I have might be helpful, let me know and I'll see if I can't
>>> clean
>>> it up a bit and put it up on github.
>>>
>>>
>>>>
>>>>
>>>> Edgar
>>>> @morplenauta en twitter
>>>
>>>
>>> Thanks,
>>> Phil
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

> --C
>
> P.S.
>
> Word on the superhighway is there's a new version of OMeta coming, but I don't know that it will be based on Squeak (the most recent was built atop Javascript.) More news when I know for sure and have blessing to share with the group.
>
> > On May 19, 2015, at 7:00 PM, "Phil (list)" <[hidden email]> wrote:
> >
> >> On Tue, 2015-05-19 at 19:12 -0300, Edgar J. De Cleene wrote:
> >> Your info is very useful.
> >> The experiment until now is I can load OMeta in Squeak 4.6 from
> >> SqueakSource.
> >> In my fork wich is Cuis 3,2 can’t load and several tricks for having
> >> the classes ordered before OMeta uses each failed.
> >> So if you have the original .st of Alessandro , wish have it for try.
> >> In Cuis as cloned from Github the preload package loads fine and the
> >> examples works as in Squeak 4.6.
> >> I send mail here with link to .jpg picture.
> >> But post load fails.
> >
> > OK, I've almost got it working again except for one tiny thing (that
> > breaks everything)... #compilerClass no longer exists.  I've poked
> > around and all of the compiler indirection has been removed (i.e.
> > Compiler is hard-coded everywhere).  This completely breaks OMeta2 so
> > unless Juan would consider bringing this functionality back, it's
> > probably not going to work without essentially a rewrite.
> >
> > ... so that's why I gave up on it :-(
> >
> >>
> >> Edgar
> >>
> >>
> >> --
> >> Edgar J. De Cleene
> >> Sent with Sparrow
> >>
> >>
> >>> On Tuesday, May 19, 2015 at 6:55 PM, Phil (list) wrote:
> >>>
> >>>> On Sat, 2015-05-16 at 05:41 -0300, Edgar J. De Cleene wrote:
> >>>> People:
> >>>>
> >>>>
> >>>> I working in my SqueakRosCore fork and think if Xtreams should be
> >>>> on it or
> >>>> not.
> >>>>
> >>>>
> >>>> Google surfing brings me
> >>>>
> >>>>
> >>>> http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/156355
> >>>>
> >>>>
> >>>> So, four years later I wish feedback about this.
> >>>>
> >>>>
> >>>> Cool working examples if you know of any.
> >>>>
> >>>>
> >>>> Opinions:
> >>>>
> >>>>
> >>>> SqueakSource have two projects about Xtreams, which one I should
> >>>> have ?
> >>>>
> >>>>
> >>>> Ometa pay same day the work for having it into the .image ?
> >>>
> >>>
> >>> OK, it's all coming back to me as to why my port of OMeta2 died: I
> >>> had
> >>> it working perfectly in Cuis 1.0. I think I also had it working in
> >>> Cuis
> >>> 2.0 (I even have a .pck which I *believe* was kinda, sorta had
> >>> working
> >>> at one point... but now it can only be read in, it no longer works).
> >>>
> >>>
> >>> IIRC, the issue was that part of OMeta is written in OMeta so you
> >>> can't
> >>> just load it in the way you would a regular package. I think
> >>> original
> >>> work by Alessandro was a .st file which had a very specific ordering
> >>> of
> >>> code to load and ran some code as part of the filein which installed
> >>> OMeta into the image. The SqueakSource package addressed the loading
> >>> issues by splitting it in 2: a preload and postload package. I
> >>> believe
> >>> the preload package patches the parser so that the postload package
> >>> can
> >>> even be parsed by Squeak. Then there is some code that gets called
> >>> after the postload package has been read in that actually patches
> >>> OMeta
> >>> into the Squeak compiler. It's a bit tricky and changes to the
> >>> Smalltalk parser/compiler since then will require some changes (I
> >>> believe it broke as a result of the changes for closure support
> >>> being
> >>> added ~2012 or so)
> >>>
> >>>
> >>> I'm not sure how far you've gotten with it on your own already... if
> >>> what I have might be helpful, let me know and I'll see if I can't
> >>> clean
> >>> it up a bit and put it up on github.
> >>>
> >>>
> >>>>
> >>>>
> >>>> Edgar
> >>>> @morplenauta en twitter
> >>>
> >>>
> >>> Thanks,
> >>> Phil
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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 May 19, 2015, at 11:36 PM, "Phil (list)" <[hidden email]> wrote:
>
>> On Tue, 2015-05-19 at 22:12 -0700, Casey Ransberger wrote:
>> Hi Phil.
>>
>> Any particular reason compiler indirection can't go into one of our Squeak compat packs?
>
> I'll let someone else volunteer for that headache. (see below)
>
>> Got myself injured, and will be a week or three before I can sit at a computer for an extended period of time, but I could have a look at it if there isn't some reason we can't get it into compat. I surfed all the way through Cuis looking at every single reference to Color once. Seems like doing the same wouldn't be so hard looking for refs to Compiler and fixing them as I went.
>
> Sorry to hear that and hope you get well soon.  Now would be a good time
> for a tablet if you don't already have one...
>
>> I guess the question is, can a pck modify core classes?
>
> It could, but not terribly efficiently.  We're not talking about missing
> methods, we're talking about needing to alter existing rather critical
> ones.  A package can override those methods (from a quick glance it
> looked to be well over a dozen) but it's an ongoing maintenance headache
> as you would have to merge the needed code with what's already there.
> This was the reason that #compilerClass existed: to provide an easy way
> to swap out the compiler at whatever level is desired without having to
> change numerous other methods and keeping those changes in sync with
> upstream changes over time.
>
>> --C
>>
>> P.S.
>>
>> Word on the superhighway is there's a new version of OMeta coming, but I don't know that it will be based on Squeak (the most recent was built atop Javascript.) More news when I know for sure and have blessing to share with the group.
>>
>>>> On May 19, 2015, at 7:00 PM, "Phil (list)" <[hidden email]> wrote:
>>>>
>>>> On Tue, 2015-05-19 at 19:12 -0300, Edgar J. De Cleene wrote:
>>>> Your info is very useful.
>>>> The experiment until now is I can load OMeta in Squeak 4.6 from
>>>> SqueakSource.
>>>> In my fork wich is Cuis 3,2 can’t load and several tricks for having
>>>> the classes ordered before OMeta uses each failed.
>>>> So if you have the original .st of Alessandro , wish have it for try.
>>>> In Cuis as cloned from Github the preload package loads fine and the
>>>> examples works as in Squeak 4.6.
>>>> I send mail here with link to .jpg picture.
>>>> But post load fails.
>>>
>>> OK, I've almost got it working again except for one tiny thing (that
>>> breaks everything)... #compilerClass no longer exists.  I've poked
>>> around and all of the compiler indirection has been removed (i.e.
>>> Compiler is hard-coded everywhere).  This completely breaks OMeta2 so
>>> unless Juan would consider bringing this functionality back, it's
>>> probably not going to work without essentially a rewrite.
>>>
>>> ... so that's why I gave up on it :-(
>>>
>>>>
>>>> Edgar
>>>>
>>>>
>>>> --
>>>> Edgar J. De Cleene
>>>> Sent with Sparrow
>>>>
>>>>
>>>>>> On Tuesday, May 19, 2015 at 6:55 PM, Phil (list) wrote:
>>>>>>
>>>>>> On Sat, 2015-05-16 at 05:41 -0300, Edgar J. De Cleene wrote:
>>>>>> People:
>>>>>>
>>>>>>
>>>>>> I working in my SqueakRosCore fork and think if Xtreams should be
>>>>>> on it or
>>>>>> not.
>>>>>>
>>>>>>
>>>>>> Google surfing brings me
>>>>>>
>>>>>>
>>>>>> http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/156355
>>>>>>
>>>>>>
>>>>>> So, four years later I wish feedback about this.
>>>>>>
>>>>>>
>>>>>> Cool working examples if you know of any.
>>>>>>
>>>>>>
>>>>>> Opinions:
>>>>>>
>>>>>>
>>>>>> SqueakSource have two projects about Xtreams, which one I should
>>>>>> have ?
>>>>>>
>>>>>>
>>>>>> Ometa pay same day the work for having it into the .image ?
>>>>>
>>>>>
>>>>> OK, it's all coming back to me as to why my port of OMeta2 died: I
>>>>> had
>>>>> it working perfectly in Cuis 1.0. I think I also had it working in
>>>>> Cuis
>>>>> 2.0 (I even have a .pck which I *believe* was kinda, sorta had
>>>>> working
>>>>> at one point... but now it can only be read in, it no longer works).
>>>>>
>>>>>
>>>>> IIRC, the issue was that part of OMeta is written in OMeta so you
>>>>> can't
>>>>> just load it in the way you would a regular package. I think
>>>>> original
>>>>> work by Alessandro was a .st file which had a very specific ordering
>>>>> of
>>>>> code to load and ran some code as part of the filein which installed
>>>>> OMeta into the image. The SqueakSource package addressed the loading
>>>>> issues by splitting it in 2: a preload and postload package. I
>>>>> believe
>>>>> the preload package patches the parser so that the postload package
>>>>> can
>>>>> even be parsed by Squeak. Then there is some code that gets called
>>>>> after the postload package has been read in that actually patches
>>>>> OMeta
>>>>> into the Squeak compiler. It's a bit tricky and changes to the
>>>>> Smalltalk parser/compiler since then will require some changes (I
>>>>> believe it broke as a result of the changes for closure support
>>>>> being
>>>>> added ~2012 or so)
>>>>>
>>>>>
>>>>> I'm not sure how far you've gotten with it on your own already... if
>>>>> what I have might be helpful, let me know and I'll see if I can't
>>>>> clean
>>>>> it up a bit and put it up on github.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Edgar
>>>>>> @morplenauta en twitter
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Phil
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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

> --C
>
> > On May 19, 2015, at 11:36 PM, "Phil (list)" <[hidden email]> wrote:
> >
> >> On Tue, 2015-05-19 at 22:12 -0700, Casey Ransberger wrote:
> >> Hi Phil.
> >>
> >> Any particular reason compiler indirection can't go into one of our Squeak compat packs?
> >
> > I'll let someone else volunteer for that headache. (see below)
> >
> >> Got myself injured, and will be a week or three before I can sit at a computer for an extended period of time, but I could have a look at it if there isn't some reason we can't get it into compat. I surfed all the way through Cuis looking at every single reference to Color once. Seems like doing the same wouldn't be so hard looking for refs to Compiler and fixing them as I went.
> >
> > Sorry to hear that and hope you get well soon.  Now would be a good time
> > for a tablet if you don't already have one...
> >
> >> I guess the question is, can a pck modify core classes?
> >
> > It could, but not terribly efficiently.  We're not talking about missing
> > methods, we're talking about needing to alter existing rather critical
> > ones.  A package can override those methods (from a quick glance it
> > looked to be well over a dozen) but it's an ongoing maintenance headache
> > as you would have to merge the needed code with what's already there.
> > This was the reason that #compilerClass existed: to provide an easy way
> > to swap out the compiler at whatever level is desired without having to
> > change numerous other methods and keeping those changes in sync with
> > upstream changes over time.
> >
> >> --C
> >>
> >> P.S.
> >>
> >> Word on the superhighway is there's a new version of OMeta coming, but I don't know that it will be based on Squeak (the most recent was built atop Javascript.) More news when I know for sure and have blessing to share with the group.
> >>
> >>>> On May 19, 2015, at 7:00 PM, "Phil (list)" <[hidden email]> wrote:
> >>>>
> >>>> On Tue, 2015-05-19 at 19:12 -0300, Edgar J. De Cleene wrote:
> >>>> Your info is very useful.
> >>>> The experiment until now is I can load OMeta in Squeak 4.6 from
> >>>> SqueakSource.
> >>>> In my fork wich is Cuis 3,2 can’t load and several tricks for having
> >>>> the classes ordered before OMeta uses each failed.
> >>>> So if you have the original .st of Alessandro , wish have it for try.
> >>>> In Cuis as cloned from Github the preload package loads fine and the
> >>>> examples works as in Squeak 4.6.
> >>>> I send mail here with link to .jpg picture.
> >>>> But post load fails.
> >>>
> >>> OK, I've almost got it working again except for one tiny thing (that
> >>> breaks everything)... #compilerClass no longer exists.  I've poked
> >>> around and all of the compiler indirection has been removed (i.e.
> >>> Compiler is hard-coded everywhere).  This completely breaks OMeta2 so
> >>> unless Juan would consider bringing this functionality back, it's
> >>> probably not going to work without essentially a rewrite.
> >>>
> >>> ... so that's why I gave up on it :-(
> >>>
> >>>>
> >>>> Edgar
> >>>>
> >>>>
> >>>> --
> >>>> Edgar J. De Cleene
> >>>> Sent with Sparrow
> >>>>
> >>>>
> >>>>>> On Tuesday, May 19, 2015 at 6:55 PM, Phil (list) wrote:
> >>>>>>
> >>>>>> On Sat, 2015-05-16 at 05:41 -0300, Edgar J. De Cleene wrote:
> >>>>>> People:
> >>>>>>
> >>>>>>
> >>>>>> I working in my SqueakRosCore fork and think if Xtreams should be
> >>>>>> on it or
> >>>>>> not.
> >>>>>>
> >>>>>>
> >>>>>> Google surfing brings me
> >>>>>>
> >>>>>>
> >>>>>> http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/156355
> >>>>>>
> >>>>>>
> >>>>>> So, four years later I wish feedback about this.
> >>>>>>
> >>>>>>
> >>>>>> Cool working examples if you know of any.
> >>>>>>
> >>>>>>
> >>>>>> Opinions:
> >>>>>>
> >>>>>>
> >>>>>> SqueakSource have two projects about Xtreams, which one I should
> >>>>>> have ?
> >>>>>>
> >>>>>>
> >>>>>> Ometa pay same day the work for having it into the .image ?
> >>>>>
> >>>>>
> >>>>> OK, it's all coming back to me as to why my port of OMeta2 died: I
> >>>>> had
> >>>>> it working perfectly in Cuis 1.0. I think I also had it working in
> >>>>> Cuis
> >>>>> 2.0 (I even have a .pck which I *believe* was kinda, sorta had
> >>>>> working
> >>>>> at one point... but now it can only be read in, it no longer works).
> >>>>>
> >>>>>
> >>>>> IIRC, the issue was that part of OMeta is written in OMeta so you
> >>>>> can't
> >>>>> just load it in the way you would a regular package. I think
> >>>>> original
> >>>>> work by Alessandro was a .st file which had a very specific ordering
> >>>>> of
> >>>>> code to load and ran some code as part of the filein which installed
> >>>>> OMeta into the image. The SqueakSource package addressed the loading
> >>>>> issues by splitting it in 2: a preload and postload package. I
> >>>>> believe
> >>>>> the preload package patches the parser so that the postload package
> >>>>> can
> >>>>> even be parsed by Squeak. Then there is some code that gets called
> >>>>> after the postload package has been read in that actually patches
> >>>>> OMeta
> >>>>> into the Squeak compiler. It's a bit tricky and changes to the
> >>>>> Smalltalk parser/compiler since then will require some changes (I
> >>>>> believe it broke as a result of the changes for closure support
> >>>>> being
> >>>>> added ~2012 or so)
> >>>>>
> >>>>>
> >>>>> I'm not sure how far you've gotten with it on your own already... if
> >>>>> what I have might be helpful, let me know and I'll see if I can't
> >>>>> clean
> >>>>> it up a bit and put it up on github.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Edgar
> >>>>>> @morplenauta en twitter
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Phil
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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 Tue, 2015-05-19 at 19:12 -0300, Edgar J. De Cleene wrote:
>> Your info is very useful.
>> The experiment until now is I can load OMeta in Squeak 4.6 from
>> SqueakSource.
>> In my fork wich is Cuis 3,2 can’t load and several tricks for having
>> the classes ordered before OMeta uses each failed.
>> So if you have the original .st of Alessandro , wish have it for try.
>> In Cuis as cloned from Github the preload package loads fine and the
>> examples works as in Squeak 4.6.
>> I send mail here with link to .jpg picture.
>> But post load fails.
>>
> OK, I've almost got it working again except for one tiny thing (that
> breaks everything)... #compilerClass no longer exists.  I've poked
> around and all of the compiler indirection has been removed (i.e.
> Compiler is hard-coded everywhere).  This completely breaks OMeta2 so
> unless Juan would consider bringing this functionality back, it's
> probably not going to work without essentially a rewrite.
>
> ... so that's why I gave up on it :-(

> Hi Folks,
>
> On 5/20/2015 4:37 AM, Phil (list) wrote:
> > On Wed, 2015-05-20 at 00:02 -0700, Casey Ransberger wrote:
> >> Are you arguing for restoring compiler indirection in Cuis?
> >>
> >> That's a trade off either way. But I agree having it in the core of the system would be worthwhile for language researchers.
> >>
> > I'm in favor of it but I may be in the minority on this.  If feels like
> > a trade off of extensibility in favor of minimalism.
>
> Minimalism should be to empower us, not to impair us. Removing this was
> a mistake.
>
> Please try the attached. If it's ok, it will be in the next commit.
>

> Juan,
>
>
>
> On Wed, 2015-05-20 at 13:11 -0300, Juan Vuletich wrote:
>
>> Hi Folks,
>>
>>
>> On 5/20/2015 4:37 AM, Phil (list) wrote:
>>
>>> On Wed, 2015-05-20 at 00:02 -0700, Casey Ransberger wrote:
>>>
>>>> Are you arguing for restoring compiler indirection in Cuis?
>>>>
>>>>
>>>> That's a trade off either way. But I agree having it in the core of
>>>> the system would be worthwhile for language researchers.
>>>>
>>> I'm in favor of it but I may be in the minority on this.  If feels
>>> like a trade off of extensibility in favor of minimalism.
>>
>> Minimalism should be to empower us, not to impair us. Removing this was
>>  a mistake.
>>
>> Please try the attached. If it's ok, it will be in the next commit.
>>
>>
>
> This is fantastic news!  I tried the changesets against 2330 but there
> still appear to be some direct calls left (around 2 dozen... filein failed
> on PositionableStream #fileInAnnouncing:)  I *believe* pretty much every
> reference to Compiler needs to be replaced with compilerClass for class of
> the method being compiled/compiled for (i.e. the caller).
>
>> Cheers,
>> Juan Vuletich
>>
>
> Thanks,
> Phil