Xtreams's FileDirectory dependence

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Xtreams's FileDirectory dependence

Frank Shearar-3
Xtreams depends on FileDirectory in at least three places, all in the
Xtreams-Terminals package. (Three messages on FileUrl, #appending,
#reading, #writing; two tests in XTFileReadingWritingTest >> #setUp
and #tearDown)

Pharo 2.0 has no FileDirectory. So it seems like the easiest (not
necessarily simple, nor right) thing to is to break that out into
Xtreams-Terminals-Squeak and Xtreams-Terminals-Pharo packages, and
similarly for the tests.

After that, we'd need to adjust the ConfigurationOfXtreams. I think I
forgot to fulfil a promise to submit an updated version of this that
loaded FFI correctly (sorry!).

Thoughts? Do any Pharo folk load Xtreams?

frank

Reply | Threaded
Open this post in threaded view
|

Re: Xtreams's FileDirectory dependence

Camillo Bruni-3
FileSystemLegacy is your friend:

http://smalltalkhub.com/#!/~PharoExtras/FileSystemLegacy


On 2013-04-17, at 16:57, Frank Shearar <[hidden email]> wrote:

> Xtreams depends on FileDirectory in at least three places, all in the
> Xtreams-Terminals package. (Three messages on FileUrl, #appending,
> #reading, #writing; two tests in XTFileReadingWritingTest >> #setUp
> and #tearDown)
>
> Pharo 2.0 has no FileDirectory. So it seems like the easiest (not
> necessarily simple, nor right) thing to is to break that out into
> Xtreams-Terminals-Squeak and Xtreams-Terminals-Pharo packages, and
> similarly for the tests.
>
> After that, we'd need to adjust the ConfigurationOfXtreams. I think I
> forgot to fulfil a promise to submit an updated version of this that
> loaded FFI correctly (sorry!).
>
> Thoughts? Do any Pharo folk load Xtreams?
>
> frank
>


Reply | Threaded
Open this post in threaded view
|

Re: Xtreams's FileDirectory dependence

Sven Van Caekenberghe-2

On 17 Apr 2013, at 17:09, Camillo Bruni <[hidden email]> wrote:

> FileSystemLegacy is your friend:
>
> http://smalltalkhub.com/#!/~PharoExtras/FileSystemLegacy

Yes, that is one possibility.

But we want a clean loading Xtreams using FileSystem directly, do we not ?

> On 2013-04-17, at 16:57, Frank Shearar <[hidden email]> wrote:
>
>> Xtreams depends on FileDirectory in at least three places, all in the
>> Xtreams-Terminals package. (Three messages on FileUrl, #appending,
>> #reading, #writing; two tests in XTFileReadingWritingTest >> #setUp
>> and #tearDown)
>>
>> Pharo 2.0 has no FileDirectory. So it seems like the easiest (not
>> necessarily simple, nor right) thing to is to break that out into
>> Xtreams-Terminals-Squeak and Xtreams-Terminals-Pharo packages, and
>> similarly for the tests.
>>
>> After that, we'd need to adjust the ConfigurationOfXtreams. I think I
>> forgot to fulfil a promise to submit an updated version of this that
>> loaded FFI correctly (sorry!).
>>
>> Thoughts? Do any Pharo folk load Xtreams?
>>
>> frank
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Xtreams's FileDirectory dependence

Camillo Bruni-3

On 2013-04-17, at 17:12, Sven Van Caekenberghe <[hidden email]> wrote:

>
> On 17 Apr 2013, at 17:09, Camillo Bruni <[hidden email]> wrote:
>
>> FileSystemLegacy is your friend:
>>
>> http://smalltalkhub.com/#!/~PharoExtras/FileSystemLegacy
>
> Yes, that is one possibility.
>
> But we want a clean loading Xtreams using FileSystem directly, do we not ?


yes definitely ;).
 but for loading it the first time, this is easier.

Reply | Threaded
Open this post in threaded view
|

Re: Xtreams's FileDirectory dependence

Nicolas Cellier
+1 for using a brand new and much cleaner FileSystem
But you must let some time to lazy developpers, so FIleSystemLegacy should be used in some ConfigurationOf in the interim.


2013/4/17 Camillo Bruni <[hidden email]>

On 2013-04-17, at 17:12, Sven Van Caekenberghe <[hidden email]> wrote:

>
> On 17 Apr 2013, at 17:09, Camillo Bruni <[hidden email]> wrote:
>
>> FileSystemLegacy is your friend:
>>
>> http://smalltalkhub.com/#!/~PharoExtras/FileSystemLegacy
>
> Yes, that is one possibility.
>
> But we want a clean loading Xtreams using FileSystem directly, do we not ?


yes definitely ;).
 but for loading it the first time, this is easier.


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Xtreams's FileDirectory dependence

Stéphane Ducasse
In reply to this post by Frank Shearar-3
We are really interested by Xtreams for replacing Pharo Streams.
Now we should evaluate again Xtreams.
So any action that make them easier to load is welcome.
On Apr 17, 2013, at 4:57 PM, Frank Shearar <[hidden email]> wrote:

> Xtreams depends on FileDirectory in at least three places, all in the
> Xtreams-Terminals package. (Three messages on FileUrl, #appending,
> #reading, #writing; two tests in XTFileReadingWritingTest >> #setUp
> and #tearDown)
>
> Pharo 2.0 has no FileDirectory. So it seems like the easiest (not
> necessarily simple, nor right) thing to is to break that out into
> Xtreams-Terminals-Squeak and Xtreams-Terminals-Pharo packages, and
> similarly for the tests.
>
> After that, we'd need to adjust the ConfigurationOfXtreams. I think I
> forgot to fulfil a promise to submit an updated version of this that
> loaded FFI correctly (sorry!).
>
> Thoughts? Do any Pharo folk load Xtreams?
>
> frank
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Xtreams's FileDirectory dependence

Frank Shearar-3
In reply to this post by Frank Shearar-3
On 17 April 2013 20:14, Colin Putney <[hidden email]> wrote:

> On 2013-04-17, at 7:57 AM, Frank Shearar <[hidden email]> wrote:
>
>> Xtreams depends on FileDirectory in at least three places, all in the
>> Xtreams-Terminals package. (Three messages on FileUrl, #appending,
>> #reading, #writing; two tests in XTFileReadingWritingTest >> #setUp
>> and #tearDown)
>>
>> Pharo 2.0 has no FileDirectory. So it seems like the easiest (not
>> necessarily simple, nor right) thing to is to break that out into
>> Xtreams-Terminals-Squeak and Xtreams-Terminals-Pharo packages, and
>> similarly for the tests.
>
> The usual convention would be Xtreams-Squeak-Terminals and
> Xtreams-Pharo-Terminals.
>
> But actually, I'd kind of like to see separate packages for
> FileDirectory terminals and FileSystem terminals. The FS terminals
> would be useful in Squeak as well.

That's a good idea. It's also less divisive while being more precise to boot.

frank

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Xtreams's FileDirectory dependence

Sean P. DeNigris
Administrator
In reply to this post by Stéphane Ducasse
Stéphane Ducasse wrote
We are really interested by Xtreams for replacing Pharo Streams.
Now we should evaluate again Xtreams.
IIRC at ESUG the version on squeaksource is not up to date with the VW version, which is why we were working on handling namespace/prefix mapping in filetree/cypress...
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Xtreams's FileDirectory dependence

Frank Shearar-3
On 18 April 2013 01:42, Sean P. DeNigris <[hidden email]> wrote:
> Stéphane Ducasse wrote
>> We are really interested by Xtreams for replacing Pharo Streams.
>> Now we should evaluate again Xtreams.
>
> IIRC at ESUG the version on squeaksource is not up to date with the VW
> version, which is why we were working on handling namespace/prefix mapping
> in filetree/cypress...

How up to date is https://github.com/mkobetic/Xtreams/ ? That's surely
not the "canonical" repository, which would be in the Cincom Smalltalk
Public Repository. I think? Anyway, assuming it's up to date, one
promising approach to using Martin Kobetic's repository directly is:
* have a way of importing chunk format stuff from a GitHub repository
(see Squeak's inbox for my
doesn't-support-filetree-yet-but-can-do-chunk-format InstallerGitHub
(and I plan to submit a Gofer patch to do the same))
* load into an Environment (Squeak 4.5 can do this, modulo its alpha state).

It might even be possible to import into an Environment with the
prefix-adding import and then fileout/monticelloise the resulting
things as a prefix-using, non-Environments-requiring blob ready for
everyone to use.

frank

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Xtreams's FileDirectory dependence

Jan Vrany
On 18/04/13 11:42, Frank Shearar wrote:

> On 18 April 2013 01:42, Sean P. DeNigris <[hidden email]> wrote:
>> Stéphane Ducasse wrote
>>> We are really interested by Xtreams for replacing Pharo Streams.
>>> Now we should evaluate again Xtreams.
>>
>> IIRC at ESUG the version on squeaksource is not up to date with the VW
>> version, which is why we were working on handling namespace/prefix mapping
>> in filetree/cypress...
>
> How up to date is https://github.com/mkobetic/Xtreams/ ?

Better ask Martin :-)

I know he's now playing now with Xtreams
& Cypress to see how it can be used to maintain cross-dialect
projects. So you may need an up-to-date implementation of Cypress
reader/writer.

Jan

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Xtreams's FileDirectory dependence

Frank Shearar-3
In reply to this post by Frank Shearar-3
On 18 April 2013 10:42, Frank Shearar <[hidden email]> wrote:

> On 18 April 2013 01:42, Sean P. DeNigris <[hidden email]> wrote:
>> Stéphane Ducasse wrote
>>> We are really interested by Xtreams for replacing Pharo Streams.
>>> Now we should evaluate again Xtreams.
>>
>> IIRC at ESUG the version on squeaksource is not up to date with the VW
>> version, which is why we were working on handling namespace/prefix mapping
>> in filetree/cypress...
>
> How up to date is https://github.com/mkobetic/Xtreams/ ?

Given that there's 'From Smalltalk/X, Version:6.2.1 on 30-01-2012 at
10:57:56 PM' in files (like
https://github.com/mkobetic/Xtreams/blob/master/stx_goodies_xtreams_core.st),
it might be possible that this is the Smalltalk/X port's repository.

frank

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Xtreams's FileDirectory dependence

mkobetic
In reply to this post by Frank Shearar-3
As Jan mentioned, in https://github.com/mkobetic/Xtreams I'm primarily just experimenting with Cypress. However the master branch there is misleading, it contains a very early port of Xtreams to ST/X (there's a much more up to date version in Jan's ST/X project @ https://swing.fit.cvut.cz/jenkins/job/xtreams_reports/).

However if you look at some of the other branches in the github project you can find a fairly up to date, Cypress formatted dump from VW as well as the results of Sean's ESUG effort to add namespace-prefix mapping to Filetree (branch pharo_experiment). My ultimate goal is to test Dale's idea to maintain a cross-dialect project as parallel branches in git. However we still need to iron out various dialect differences in terms of what they emit as Cypress formatted output. BTW, does anyone know if git/github can handle absence of a master branch? I'd be inclined to just delete the master from the repository if that works well.

I've been planning to ping Sean about his Filetree fixes for a while, but I need to find the time to be able to actually act on it :-). The prefix-namespace mapping is crucial to make the parallel branch approach at all feasible. There's also the Environment effort on Squeak side which may obviate the prefix mapping need, but it seems to be still in fairly early stages.

So far it was mostly Nicolas' manual effort that brought VW updates over the Squeak/Pharo side. I think it was a while since the last time he's done that, so the VW port is probably ahead somewhat. But Xtreams development isn't that active anymore. Most of our Xtreams related efforts are about using them for various things, so any changes are mostly fixes or small improvements driven by that use. So in some sense a manual update could be a feasible approach at this point. But I would really like to turn the project into a more collaborative effort, where updates can flow reasonably in any direction.

While I'm on the topic, I'm considering some API changes and am not sure how to go about discussing it. I don't want to cross post discussions to a number of mailing lists, so I think I'm inclined to just cross-post an invitation to anyone interested to subscribe to the Issues on the project site (https://code.google.com/p/xtreams/) and have those discussions there. Any thoughts on that?

"Frank Shearar"<[hidden email]> wrote:

> How up to date is https://github.com/mkobetic/Xtreams/ ? That's surely
> not the "canonical" repository, which would be in the Cincom Smalltalk
> Public Repository. I think? Anyway, assuming it's up to date, one
> promising approach to using Martin Kobetic's repository directly is:
> * have a way of importing chunk format stuff from a GitHub repository
> (see Squeak's inbox for my
> doesn't-support-filetree-yet-but-can-do-chunk-format InstallerGitHub
> (and I plan to submit a Gofer patch to do the same))
> * load into an Environment (Squeak 4.5 can do this, modulo its alpha state).
>
> It might even be possible to import into an Environment with the
> prefix-adding import and then fileout/monticelloise the resulting
> things as a prefix-using, non-Environments-requiring blob ready for
> everyone to use.
>
> frank
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Xtreams's FileDirectory dependence

Frank Shearar-3
On 18 April 2013 15:14,  <[hidden email]> wrote:
> As Jan mentioned, in https://github.com/mkobetic/Xtreams I'm primarily just experimenting with Cypress. However the master branch there is misleading, it contains a very early port of Xtreams to ST/X (there's a much more up to date version in Jan's ST/X project @ https://swing.fit.cvut.cz/jenkins/job/xtreams_reports/).
>
> However if you look at some of the other branches in the github project you can find a fairly up to date, Cypress formatted dump from VW as well as the results of Sean's ESUG effort to add namespace-prefix mapping to Filetree (branch pharo_experiment). My ultimate goal is to test Dale's idea to maintain a cross-dialect project as parallel branches in git. However we still need to iron out various dialect differences in terms of what they emit as Cypress formatted output. BTW, does anyone know if git/github can handle absence of a master branch? I'd be inclined to just delete the master from the repository if that works well.

Github's fine with this. You have to choose a new default branch, and
then you can freely git push origin :master. You can also recreate a
new master, and reset default to it if desired.

> I've been planning to ping Sean about his Filetree fixes for a while, but I need to find the time to be able to actually act on it :-). The prefix-namespace mapping is crucial to make the parallel branch approach at all feasible. There's also the Environment effort on Squeak side which may obviate the prefix mapping need, but it seems to be still in fairly early stages.

Environments definitely needs more beating on it. We have flushed out
a number of bugs, but in particular we need folks to just use it, and
try out importing, nesting, and the like

> So far it was mostly Nicolas' manual effort that brought VW updates over the Squeak/Pharo side. I think it was a while since the last time he's done that, so the VW port is probably ahead somewhat. But Xtreams development isn't that active anymore. Most of our Xtreams related efforts are about using them for various things, so any changes are mostly fixes or small improvements driven by that use. So in some sense a manual update could be a feasible approach at this point. But I would really like to turn the project into a more collaborative effort, where updates can flow reasonably in any direction.

Agreed. In particular I'd like to push my #interleave: implementation
upstream! I don't know how far out of sync things are, but certainly I
don't feel any pain when using Xtreams.

> While I'm on the topic, I'm considering some API changes and am not sure how to go about discussing it. I don't want to cross post discussions to a number of mailing lists, so I think I'm inclined to just cross-post an invitation to anyone interested to subscribe to the Issues on the project site (https://code.google.com/p/xtreams/) and have those discussions there. Any thoughts on that?

That's probably the best approach: people interested in Xtreams ought
to talk about Xtreams on the Xtreams list!

frank

> "Frank Shearar"<[hidden email]> wrote:
>> How up to date is https://github.com/mkobetic/Xtreams/ ? That's surely
>> not the "canonical" repository, which would be in the Cincom Smalltalk
>> Public Repository. I think? Anyway, assuming it's up to date, one
>> promising approach to using Martin Kobetic's repository directly is:
>> * have a way of importing chunk format stuff from a GitHub repository
>> (see Squeak's inbox for my
>> doesn't-support-filetree-yet-but-can-do-chunk-format InstallerGitHub
>> (and I plan to submit a Gofer patch to do the same))
>> * load into an Environment (Squeak 4.5 can do this, modulo its alpha state).
>>
>> It might even be possible to import into an Environment with the
>> prefix-adding import and then fileout/monticelloise the resulting
>> things as a prefix-using, non-Environments-requiring blob ready for
>> everyone to use.
>>
>> frank
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Xtreams's FileDirectory dependence

mkobetic
In reply to this post by Frank Shearar-3
"Colin Putney"<[hidden email]> wrote:

> > While I'm on the topic, I'm considering some API changes and am not sure
> > how to go about discussing it. I don't want to cross post discussions to a
> > number of mailing lists, so I think I'm inclined to just cross-post an
> > invitation to anyone interested to subscribe to the Issues on the project
> > site (https://code.google.com/p/xtreams/) and have those discussions
> > there. Any thoughts on that?
> >
> > That's probably the best approach: people interested in Xtreams ought
> > to talk about Xtreams on the Xtreams list!
>
>
> We may need a list eventually, but it would be kind of interesting to try
> Martin's Issues approach. I guess we'd all subscribe to the Atom feed and
> then "post" by opening or commenting on issues?

It looks like anyone should be able to subscribe with arbitrary email address on the Issues section. Alternatively I could add people as project members if that helps. I'd like to use the Issues because that way any discussions are clearly associated and archived with the project.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Xtreams's FileDirectory dependence

Dale Henrichs
In reply to this post by mkobetic
Martin,

github pretty much requires a "master" branch, but it doesn't have to be named "master" ... For FileTree where I use the branch per platform approach, the master branch is where I stash the cherry-picked common code ... then all of the platform branches can merge at their leisure ... If you look at the network graph for FileTree[1] you can see the pattern.

Dale

[1] https://github.com/dalehenrich/filetree/network

----- Original Message -----
| From: [hidden email]
| To: "Frank Shearar" <[hidden email]>
| Cc: "The general-purpose Squeak developers list" <[hidden email]>, "Pharo Development"
| <[hidden email]>
| Sent: Thursday, April 18, 2013 7:14:34 AM
| Subject: Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence
|
| As Jan mentioned, in https://github.com/mkobetic/Xtreams I'm primarily just
| experimenting with Cypress. However the master branch there is misleading,
| it contains a very early port of Xtreams to ST/X (there's a much more up to
| date version in Jan's ST/X project @
| https://swing.fit.cvut.cz/jenkins/job/xtreams_reports/).
|
| However if you look at some of the other branches in the github project you
| can find a fairly up to date, Cypress formatted dump from VW as well as the
| results of Sean's ESUG effort to add namespace-prefix mapping to Filetree
| (branch pharo_experiment). My ultimate goal is to test Dale's idea to
| maintain a cross-dialect project as parallel branches in git. However we
| still need to iron out various dialect differences in terms of what they
| emit as Cypress formatted output. BTW, does anyone know if git/github can
| handle absence of a master branch? I'd be inclined to just delete the master
| from the repository if that works well.
|
| I've been planning to ping Sean about his Filetree fixes for a while, but I
| need to find the time to be able to actually act on it :-). The
| prefix-namespace mapping is crucial to make the parallel branch approach at
| all feasible. There's also the Environment effort on Squeak side which may
| obviate the prefix mapping need, but it seems to be still in fairly early
| stages.
|
| So far it was mostly Nicolas' manual effort that brought VW updates over the
| Squeak/Pharo side. I think it was a while since the last time he's done
| that, so the VW port is probably ahead somewhat. But Xtreams development
| isn't that active anymore. Most of our Xtreams related efforts are about
| using them for various things, so any changes are mostly fixes or small
| improvements driven by that use. So in some sense a manual update could be a
| feasible approach at this point. But I would really like to turn the project
| into a more collaborative effort, where updates can flow reasonably in any
| direction.
|
| While I'm on the topic, I'm considering some API changes and am not sure how
| to go about discussing it. I don't want to cross post discussions to a
| number of mailing lists, so I think I'm inclined to just cross-post an
| invitation to anyone interested to subscribe to the Issues on the project
| site (https://code.google.com/p/xtreams/) and have those discussions there.
| Any thoughts on that?
|
| "Frank Shearar"<[hidden email]> wrote:
| > How up to date is https://github.com/mkobetic/Xtreams/ ? That's surely
| > not the "canonical" repository, which would be in the Cincom Smalltalk
| > Public Repository. I think? Anyway, assuming it's up to date, one
| > promising approach to using Martin Kobetic's repository directly is:
| > * have a way of importing chunk format stuff from a GitHub repository
| > (see Squeak's inbox for my
| > doesn't-support-filetree-yet-but-can-do-chunk-format InstallerGitHub
| > (and I plan to submit a Gofer patch to do the same))
| > * load into an Environment (Squeak 4.5 can do this, modulo its alpha
| > state).
| >
| > It might even be possible to import into an Environment with the
| > prefix-adding import and then fileout/monticelloise the resulting
| > things as a prefix-using, non-Environments-requiring blob ready for
| > everyone to use.
| >
| > frank
| >
|
|
|

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Xtreams's FileDirectory dependence

Frank Shearar-3
In reply to this post by mkobetic
I've added https://code.google.com/p/xtreams/issues/detail?id=2, so
interested people please reply there.

Thanks!

On 18 April 2013 18:35, Nicolas Cellier
<[hidden email]> wrote:

> Hi Martin,
> I recently ported some of the VW fixes to Squeak, but with a fully manual
> mode:
> - open a VW image and track the diffs
> - try to understand the motivation of changes, the implementation and
> analyze which change apply or not (no UninterpretedBytes in Squeak for
> example, ...)
> - update VW image
> - copy/paste the code in Squeak, manually correct a XT prefix here and there
>
> Since not all features can be ported (differences in sockets/pipes etc...)
> this process is fragile and somehow open to randomness, but that's what you
> can get from a human ;)
>
> Ideally, we should proceed with test driven updates, first update/merge the
> tests, then the implementation, but since a test can span several packages,
> that's not always easy to deal with and following the history of commits is
> not that easy in VW...
> Maybe a well structured feature branch/bugfix branch policy coupled with bug
> reports and using git support might indeed help sifting.
> Anyway, I'm still a few months back in change history, so that leave some
> place for experimentation
>
>
> 2013/4/18 <[hidden email]>
>
>> As Jan mentioned, in https://github.com/mkobetic/Xtreams I'm primarily
>> just experimenting with Cypress. However the master branch there is
>> misleading, it contains a very early port of Xtreams to ST/X (there's a much
>> more up to date version in Jan's ST/X project @
>> https://swing.fit.cvut.cz/jenkins/job/xtreams_reports/).
>>
>> However if you look at some of the other branches in the github project
>> you can find a fairly up to date, Cypress formatted dump from VW as well as
>> the results of Sean's ESUG effort to add namespace-prefix mapping to
>> Filetree (branch pharo_experiment). My ultimate goal is to test Dale's idea
>> to maintain a cross-dialect project as parallel branches in git. However we
>> still need to iron out various dialect differences in terms of what they
>> emit as Cypress formatted output. BTW, does anyone know if git/github can
>> handle absence of a master branch? I'd be inclined to just delete the master
>> from the repository if that works well.
>>
>> I've been planning to ping Sean about his Filetree fixes for a while, but
>> I need to find the time to be able to actually act on it :-). The
>> prefix-namespace mapping is crucial to make the parallel branch approach at
>> all feasible. There's also the Environment effort on Squeak side which may
>> obviate the prefix mapping need, but it seems to be still in fairly early
>> stages.
>>
>> So far it was mostly Nicolas' manual effort that brought VW updates over
>> the Squeak/Pharo side. I think it was a while since the last time he's done
>> that, so the VW port is probably ahead somewhat. But Xtreams development
>> isn't that active anymore. Most of our Xtreams related efforts are about
>> using them for various things, so any changes are mostly fixes or small
>> improvements driven by that use. So in some sense a manual update could be a
>> feasible approach at this point. But I would really like to turn the project
>> into a more collaborative effort, where updates can flow reasonably in any
>> direction.
>>
>> While I'm on the topic, I'm considering some API changes and am not sure
>> how to go about discussing it. I don't want to cross post discussions to a
>> number of mailing lists, so I think I'm inclined to just cross-post an
>> invitation to anyone interested to subscribe to the Issues on the project
>> site (https://code.google.com/p/xtreams/) and have those discussions there.
>> Any thoughts on that?
>>
>> "Frank Shearar"<[hidden email]> wrote:
>> > How up to date is https://github.com/mkobetic/Xtreams/ ? That's surely
>> > not the "canonical" repository, which would be in the Cincom Smalltalk
>> > Public Repository. I think? Anyway, assuming it's up to date, one
>> > promising approach to using Martin Kobetic's repository directly is:
>> > * have a way of importing chunk format stuff from a GitHub repository
>> > (see Squeak's inbox for my
>> > doesn't-support-filetree-yet-but-can-do-chunk-format InstallerGitHub
>> > (and I plan to submit a Gofer patch to do the same))
>> > * load into an Environment (Squeak 4.5 can do this, modulo its alpha
>> > state).
>> >
>> > It might even be possible to import into an Environment with the
>> > prefix-adding import and then fileout/monticelloise the resulting
>> > things as a prefix-using, non-Environments-requiring blob ready for
>> > everyone to use.
>> >
>> > frank
>> >
>>
>>
>
>
>
>