Re: [Esug-list] Few thoughts about Google Summer of Code

M
mkobetic@cincom.com
Fri, Oct 29, 2010 2:40 PM

"Paolo Bonzini"bonzini@gnu.org wrote:

On 10/29/2010 04:15 PM, mkobetic@cincom.com wrote:

Another significant hurdle was that each dialect has it's own fileout
format. CVST allowed using SIF as well for that reason, but that's
foreign to every dialect. Would you be happy to commit your sources
to git in SIF?

I don't think inter-dialect communication is a problem.  Any dialect
should be able to use whatever it prefers, like XML for VW or chunks for
Squeak or its own syntax for GST.  Did CVST actually rely on SIF or did
it just "allow" using it?

No, it had configurable "source codec" for that reason, so you could use native chunks or SIF (when I started, VW 5i wasn't out yet, so no XML). But SIF was critical when we had our our cross-dialect workshop with Steve Wart (Dolphin) and Brian Hogan (VA) at Camp Smalltalk in Colorado Springs. And we did get it going between the three dialects there.

Anyway, yes, for dialect specific project, SIF wouldn't be necessary, but I feel we'd be missing an opportunity here. If you commit your project into something like github in a portable format, the chances of the project taking off in another dialect as well are greatly increased IMO. It may actually help our community to stop diverging so much and promote more collaboration. Look how adopting monticello in Gemstone helped the portability of Seaside between the two dialects. Why raise arbitrary barriers ?

Another point I'd like to emphasize, if we want to attract people from other languages claiming integration with these VCS, it's not enough to merely use them as just a back-end store for our source. We have to step outside of our comfort zone and adopt the development model that comes with it (and it might actually do us good, this new crop of VCS has some neat stuff). We need to learn the tool and use the tool for version-control, not just hide it away and only push it from time to time with a ten foot pole. Otherwise people will see right away that we're just faking the integration. So in VW I wouldn't try to swap git in as a just a different "database back end" behind Store. I think it needs to be full on file based VC integration (ala CVST or whatever) that can run side by side with Store if you wanted.

"Paolo Bonzini"<bonzini@gnu.org> wrote: > On 10/29/2010 04:15 PM, mkobetic@cincom.com wrote: > > Another significant hurdle was that each dialect has it's own fileout > > format. CVST allowed using SIF as well for that reason, but that's > > foreign to every dialect. Would you be happy to commit your sources > > to git in SIF? > > I don't think inter-dialect communication is a problem. Any dialect > should be able to use whatever it prefers, like XML for VW or chunks for > Squeak or its own syntax for GST. Did CVST actually rely on SIF or did > it just "allow" using it? No, it had configurable "source codec" for that reason, so you could use native chunks or SIF (when I started, VW 5i wasn't out yet, so no XML). But SIF was critical when we had our our cross-dialect workshop with Steve Wart (Dolphin) and Brian Hogan (VA) at Camp Smalltalk in Colorado Springs. And we did get it going between the three dialects there. Anyway, yes, for dialect specific project, SIF wouldn't be necessary, but I feel we'd be missing an opportunity here. If you commit your project into something like github in a portable format, the chances of the project taking off in another dialect as well are greatly increased IMO. It may actually help our community to stop diverging so much and promote more collaboration. Look how adopting monticello in Gemstone helped the portability of Seaside between the two dialects. Why raise arbitrary barriers ? Another point I'd like to emphasize, if we want to attract people from other languages claiming integration with these VCS, it's not enough to merely use them as just a back-end store for our source. We have to step outside of our comfort zone and adopt the development model that comes with it (and it might actually do us good, this new crop of VCS has some neat stuff). We need to learn the tool and use the tool for version-control, not just hide it away and only push it from time to time with a ten foot pole. Otherwise people will see right away that we're just faking the integration. So in VW I wouldn't try to swap git in as a just a different "database back end" behind Store. I think it needs to be full on file based VC integration (ala CVST or whatever) that can run side by side with Store if you wanted.
BF
Bert Freudenberg
Fri, Oct 29, 2010 3:34 PM

On 29.10.2010, at 16:40, mkobetic@cincom.com wrote:

Another point I'd like to emphasize, if we want to attract people from other languages claiming integration with these VCS, it's not enough to merely use them as just a back-end store for our source. We have to step outside of our comfort zone and adopt the development model that comes with it (and it might actually do us good, this new crop of VCS has some neat stuff). We need to learn the tool and use the tool for version-control, not just hide it away and only push it from time to time with a ten foot pole. Otherwise people will see right away that we're just faking the integration. So in VW I wouldn't try to swap git in as a just a different "database back end" behind Store. I think it needs to be full on file based VC integration (ala CVST or whatever) that can run side by side with Store if you wanted.

Indeed. It might even be necessary to support out-of-the-image development. That includes ditching chunk format in favor of a syntax someone might actually want to write (like GST).

  • Bert -
On 29.10.2010, at 16:40, mkobetic@cincom.com wrote: > Another point I'd like to emphasize, if we want to attract people from other languages claiming integration with these VCS, it's not enough to merely use them as just a back-end store for our source. We have to step outside of our comfort zone and adopt the development model that comes with it (and it might actually do us good, this new crop of VCS has some neat stuff). We need to learn the tool and use the tool for version-control, not just hide it away and only push it from time to time with a ten foot pole. Otherwise people will see right away that we're just faking the integration. So in VW I wouldn't try to swap git in as a just a different "database back end" behind Store. I think it needs to be full on file based VC integration (ala CVST or whatever) that can run side by side with Store if you wanted. Indeed. It might even be necessary to support out-of-the-image development. That includes ditching chunk format in favor of a syntax someone might actually want to write (like GST). - Bert -
PB
Paolo Bonzini
Fri, Oct 29, 2010 3:40 PM

On 10/29/2010 05:34 PM, Bert Freudenberg wrote:

On 29.10.2010, at 16:40, mkobetic@cincom.com wrote:

Otherwise people will see right away that we're just faking the
integration. So in VW I wouldn't try to swap git in as a just a
different "database back end" behind Store. I think it needs to be
full on file based VC integration (ala CVST or whatever) that can
run side by side with Store if you wanted.

Indeed. It might even be necessary to support out-of-the-image
development.

That can come later.  Chunk format is actually passable if you only have
to do that every once in a while (because you use the IDE).

Ability to work seamlessly with people that use the tools outside
Smalltalk is already a big step forward.  It will often do even if the
integration with the tool is kind of fake.

Paolo

On 10/29/2010 05:34 PM, Bert Freudenberg wrote: > On 29.10.2010, at 16:40, mkobetic@cincom.com wrote: > >> Otherwise people will see right away that we're just faking the >> integration. So in VW I wouldn't try to swap git in as a just a >> different "database back end" behind Store. I think it needs to be >> full on file based VC integration (ala CVST or whatever) that can >> run side by side with Store if you wanted. > > Indeed. It might even be necessary to support out-of-the-image > development. That can come later. Chunk format is actually passable if you only have to do that every once in a while (because you use the IDE). Ability to work seamlessly with people that use the tools outside Smalltalk is already a big step forward. It will often do even if the integration with the tool is kind of fake. Paolo