* Re: Patches...[was: Re: SourceNav release ... ]
[not found] <17B78BDF120BD411B70100500422FC6309E40F@IIS000>
@ 2002-01-09 14:22 ` Ian Roxborough
0 siblings, 0 replies; 3+ messages in thread
From: Ian Roxborough @ 2002-01-09 14:22 UTC (permalink / raw)
To: Bernard Dautrevaux; +Cc: sourcenav
Hi,
This is the version of frink that I hacked to work with
Itcl3.0 code:
http://people.redhat.com/irox/frink/frink-1.2p40-itcl3.tar.gz
I did this work against frink version 1.2 and then version
2.0 came out and I didn't have enough time to move my changes
into the 2.0 version and submit them back.
There is still no requirement to run frink on your code
before submitting a patch. Frink was mainly used for us
to unify the coding style (as SN has had many different
developers using different coding styles in the past).
Ian.
On Wed, 9 Jan 2002 10:14:31 +0100 Bernard Dautrevaux <Dautrevaux@microprocess.com> wrote:
>
> > -----Original Message-----
> > From: Ian Roxborough [mailto:irox@redhat.com]
> > Sent: Tuesday, January 08, 2002 9:27 PM
> > To: Dautrevaux@microprocess.com
> > Cc: sourcenav@redhat.com
> > Subject: Re: Patches...[was: Re: SourceNav release ... ]
> >
> >
> >
> > Hi Bernard,
> >
> > thanks for pointing that out, I've removed the requirement
> > to run frink for the time being and updated the webpage
> > to reflect this.
> >
> > Ian.
> >
>
> Frink looking like a nice tool for this purpose, couldn't the itcl-aware
> version be either contributed to the original frink (if the fact that I
> can't even doanload it through your link is just a temporary situation), or
> proposed as an html download or at least though CVS?
>
> TIA
>
> Bernard
>
> --------------------------------------------
> Bernard Dautrevaux
> Microprocess Ingenierie
> 97 bis, rue de Colombes
> 92400 COURBEVOIE
> FRANCE
> Tel: +33 (0) 1 47 68 80 80
> Fax: +33 (0) 1 47 88 97 85
> e-mail: dautrevaux@microprocess.com
> b.dautrevaux@usa.net
> --------------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: Patches...[was: Re: SourceNav release ... ]
@ 2002-01-08 5:24 Bernard Dautrevaux
0 siblings, 0 replies; 3+ messages in thread
From: Bernard Dautrevaux @ 2002-01-08 5:24 UTC (permalink / raw)
To: 'Ian Roxborough'; +Cc: sourcenav
> -----Original Message-----
> From: Ian Roxborough [mailto:irox@redhat.com]
> Sent: Monday, January 07, 2002 10:27 PM
> To: Ian Roxborough
> Cc: sourcenav@sources.redhat.com
> Subject: Patches...[was: Re: SourceNav release ... ]
>
>
> On Mon, 7 Jan 2002 13:14:12 -0800 Ian Roxborough
> <irox@redhat.com> wrote:
> >
> > Before that I need to write a "how to submit patches" web
> > page so I can reject patches and point people to this page
> > so they can get there patch into shape. Just simple things
> > like having a changelog entry, matching coding style and stuff.
>
> It's here and always was:
> http://sources.redhat.com/sourcenav/contrib.html
>
> It was already there (scroll down to "Submitting Patches").
Fine page; only problem: it says we must format tcl/tk code with frink, as
you've modified it to accept [incr tcl]. It seems perfectly reasonable...
except almost nobody can download this version of frink, as the ftp server
on source.redhat.com is restricted (AFAICR only mirrors are able to get to
source.redhat.com in FTP due to load problems).
So where could we get this "frink" tcl/tk formatter that seems mandatory to
provide patches to the current snapshots/CVS version of SN?
Regards,
Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
b.dautrevaux@usa.net
--------------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: SourceNav release ...
@ 2002-01-06 0:26 Simonovsky, Pavel
2002-01-06 3:48 ` Mo DeJong
0 siblings, 1 reply; 3+ messages in thread
From: Simonovsky, Pavel @ 2002-01-06 0:26 UTC (permalink / raw)
To: sourcenav
So - you mean , that in fact SN is dead , and there is no
any development team behind it? It is very important info - I suggested this
tool to 2-3 teems in our company ... I have to warn them - that it dose no
worth a waste of time... Thanks a lot !!! It is really crucial
information!!!
___________________________________
Simonovsky Pavel
Multiplatform CONTROL-MNew Dimension Software
Software Engineer
Voice: + 972 3 7664648
Fax: + 972 3 6451100
Email: Pavel_Simonovsky@bmc.com
-----Original Message-----
From: khamis2@t-online.de [mailto:khamis2@t-online.de]
Sent: Saturday, January 05, 2002 1:43 AM
To: Roman Levenstein
Cc: sourcenav@sources.redhat.com
Subject: Re: SourceNav release ...
Roman Levenstein wrote:
>Hi,
>
>>because the actual tcl parser is written in a strange
>>
>>licenced interpreter "rex?" and redhat don't have the
>>
>>origin source code and the license to this parser.
>>Also SN tcl parser doesn't support tcl/tk8.x. So if
>>there are enough people interested in this I would
>>
>start
>
>>writing a new parser (using flex) for tcl that
>>
>supports
>
>>tcltk8.x (without xref).
>>
I wasn't exact here, SN tcl parser doesn't support Itcl3.0!
>
>The Rex scanner generator is a part of the Cocktail
>Toolbox, which is also used for other SN parsers such
>as Cobol and Java parsers.
>
Yep!
>
>
>There is a public domain version of it, which can be
>found at:
>http://www.gmd.de/SCAI/lab/adaptor/cocktail.html
>
Good to know
>
>So, there is no problem with a licence.
>
>As for the origin source for the *.rex file, it's also
>not a problem. REX specification is generated from
>*.scan file by cg tool as far as I remember. Anyway,
>there is a description of this process in the docs.
>
>
>BTW, Cocktail is one of the best compiler construction
>toolkits and it's really very powerful and much better
>than yacc/lex. It covers the whole process of compiler
>construction- from lexical and syntax analysis up to
>code generation and register allocation. And, which is
>also very important, the generated parsers and
>scanners are much faster than those generated by
>lex/yacc.
>
Hmm, but who is familar with this toolbox? I'm not familar with the
cocktail toolbox
and actually don't have the time to spend time learning this language.
It's true that the parsers implemented in lex/yacc are not perfekt, but
lex is good enough
to write a parser in the 'free' time, since SN is not developed
officially anymore!
I would appreciate very much, if you do a hack to let tcl parser
understands
the itcl class definition "itcl:class".
khamis
>
>Roman
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Send your FREE holiday greetings online!
>http://greetings.yahoo.com
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: SourceNav release ...
2002-01-06 0:26 SourceNav release Simonovsky, Pavel
@ 2002-01-06 3:48 ` Mo DeJong
2002-01-06 6:36 ` Ralf Corsepius
0 siblings, 1 reply; 3+ messages in thread
From: Mo DeJong @ 2002-01-06 3:48 UTC (permalink / raw)
To: sourcenav
On Sun, 6 Jan 2002 02:25:59 -0600
"Simonovsky, Pavel" <Pavel_Simonovsky@bmc.com> wrote:
> So - you mean , that in fact SN is dead , and there is no
> any development team behind it? It is very important info - I suggested this
> tool to 2-3 teems in our company ... I have to warn them - that it dose no
> worth a waste of time...
Well, that might be a bit too strong. I don't speak for Red Hat, but as a former member of the development team I feel safe in stating that they are no longer allocating resources to SN. Basically, it comes down to $$. If you have paying customers then you can pay the engineers and managers. This might just be my impression, but it seemed that being able to download the code for free gave people the impression that they should not have to chip in for any new development. Also, the dot crunch did not help.
I know for a fact that Ian has been doing some great work on his own time to get the development version that uses Tcl/Tk 8.3 available via CVS. It is quite an improvement over the 5.0 release. That said, what is lacking is time and resources to put out a 5.1 release. What is the solution? I am not sure. I would like to hear ideas from people on this list. I would think the right solution would provide a stable 5.1 release, but also provide a plan for 5.2 and future releases.
cheers
Mo DeJong
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: SourceNav release ...
2002-01-06 3:48 ` Mo DeJong
@ 2002-01-06 6:36 ` Ralf Corsepius
2002-01-07 13:22 ` Ian Roxborough
0 siblings, 1 reply; 3+ messages in thread
From: Ralf Corsepius @ 2002-01-06 6:36 UTC (permalink / raw)
To: Mo DeJong; +Cc: Sourcenav List
Am Son, 2002-01-06 um 04.54 schrieb Mo DeJong:
> On Sun, 6 Jan 2002 02:25:59 -0600
> "Simonovsky, Pavel" <Pavel_Simonovsky@bmc.com> wrote:
>
> > So - you mean , that in fact SN is dead , and there is no
> > any development team behind it? It is very important info - I suggested this
> > tool to 2-3 teems in our company ... I have to warn them - that it dose no
> > worth a waste of time...
>
> Well, that might be a bit too strong. I don't speak for Red Hat, but as a former member of the development team I feel safe in stating that they are no longer allocating resources to SN. Basically, it comes down to $$. If you have paying customers then you can pay the engineers and managers. This might just be my impression, but it seemed that being able to download the code for free gave people the impression that they should not have to chip in for any new development. Also, the dot crunch did not help.
>
> I know for a fact that Ian has been doing some great work on his own
time to get the development version that uses Tcl/Tk 8.3 available via
CVS. It is quite an improvement over the 5.0 release. That said, what is
lacking is time and resources to put out a 5.1 release. What is the
solution? I am not sure. I would like to hear ideas from people on this
list.
OK, here is mine:
IMHO, the basic problem is to render SN into an active project.
As RH apparently is not developing actively anymore, one solution would
be to convert SN into a real OpenSource community project.
AFAIS, there would be 2 approaches to such an attempt:
1.) Apply the existing RH-infrastructure and run it
RH-conducted/assisted.
This would require RH to provide minimal assistance and support (ML,
CVS, ftp etc) + generally OK-ing into such undertaking.
Given the existing SN-related infrastructure at RH, I fail to see why
this should not work. At that lacks are active maintainers (RH or Non-RH
person) willing to accept and apply patches + to guide people though
development.
From my POV, it's only the lack of active maintainers which currently
lets appear SN as "dumped dead code junk".
2.) To lunch a GPL'ed non-RH related project somewhere else, using RH's
SN-code as basis. IMHO, nobody actually would be interested in doing so
and I also doubt it would actually work out.
> I would think the right solution would provide a stable 5.1 release,
> but also provide a plan for 5.2 and future releases.
I fully agree.
But the only way to achieve something of this kind IMHO would be
somebody (the maintainer - who is it? Ian, you?) to show some visible
initiative - Currently, SN appears not only to be dead, but to
unmaintained.
Ralf
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: SourceNav release ...
2002-01-06 6:36 ` Ralf Corsepius
@ 2002-01-07 13:22 ` Ian Roxborough
2002-01-07 13:34 ` Patches...[was: Re: SourceNav release ... ] Ian Roxborough
0 siblings, 1 reply; 3+ messages in thread
From: Ian Roxborough @ 2002-01-07 13:22 UTC (permalink / raw)
To: Ralf Corsepius; +Cc: sourcenav
On 06 Jan 2002 15:35:32 +0100 Ralf Corsepius <corsepiu@faw.uni-ulm.de> wrote:
>
> As RH apparently is not developing actively anymore, one solution would
> be to convert SN into a real OpenSource community project.
>
> AFAIS, there would be 2 approaches to such an attempt:
>
> 1.) Apply the existing RH-infrastructure and run it
> RH-conducted/assisted.
> This would require RH to provide minimal assistance and support (ML,
> CVS, ftp etc) + generally OK-ing into such undertaking.
>
> Given the existing SN-related infrastructure at RH, I fail to see why
> this should not work. At that lacks are active maintainers (RH or Non-RH
> person) willing to accept and apply patches + to guide people though
> development.
Well, this is what is happening. Sorry if it isn't as fast and high
profile as you'd like.
The only downside of this is contributors have to sign a
Copyright assignment so that Red Hat retains the copyright.
Probably the first person who would recieve one is Khamis
(the copyright assignment will only apply to worked checked
in CVS). I should beable to accept small patches (~12 lines?)
without a copyright assignment.
Before that I need to write a "how to submit patches" web
page so I can reject patches and point people to this page
so they can get there patch into shape. Just simple things
like having a changelog entry, matching coding style and stuff.
> From my POV, it's only the lack of active maintainers which currently
> lets appear SN as "dumped dead code junk".
Beats leaving the code to rott away in a tarball somewhere where nobody
can download it.
> 2.) To lunch a GPL'ed non-RH related project somewhere else, using RH's
> SN-code as basis. IMHO, nobody actually would be interested in doing so
> and I also doubt it would actually work out.
sourcenav.sourceforge.net?
If somebody wants to host and maintain another version of SN that is
OK by me, this would avoid copyright assignment and stuff like that.
I would not stop maintaining a copy here, not until atleast the
other version was way better . :-)
> > I would think the right solution would provide a stable 5.1 release,
> > but also provide a plan for 5.2 and future releases.
> I fully agree.
>
> But the only way to achieve something of this kind IMHO would be
> somebody (the maintainer - who is it? Ian, you?) to show some visible
> initiative - Currently, SN appears not only to be dead, but to
> unmaintained.
Well, if I was to "pull my finger out" as they say and make this
happen (i.e. copyrights, patches page, regular approvals etc.), would
you be interested in maintaining a small part of SN? I would like to
divide up the work (Windows port/build, parsers, db, etc.) so it
is more manageable.
Ian.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Patches...[was: Re: SourceNav release ... ]
2002-01-07 13:22 ` Ian Roxborough
@ 2002-01-07 13:34 ` Ian Roxborough
0 siblings, 0 replies; 3+ messages in thread
From: Ian Roxborough @ 2002-01-07 13:34 UTC (permalink / raw)
To: Ian Roxborough; +Cc: sourcenav
On Mon, 7 Jan 2002 13:14:12 -0800 Ian Roxborough <irox@redhat.com> wrote:
>
> Before that I need to write a "how to submit patches" web
> page so I can reject patches and point people to this page
> so they can get there patch into shape. Just simple things
> like having a changelog entry, matching coding style and stuff.
It's here and always was:
http://sources.redhat.com/sourcenav/contrib.html
It was already there (scroll down to "Submitting Patches").
A number of people have submitted small patches without
ChangeLog entries. Please resubmit your patch complete
with a plain text ChangeLog entry (i.e. not part of the diff)
if you wish to have your patch include in the CVS repository.
Thanks,
Ian.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-01-09 19:29 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <17B78BDF120BD411B70100500422FC6309E40F@IIS000>
2002-01-09 14:22 ` Patches...[was: Re: SourceNav release ... ] Ian Roxborough
2002-01-08 5:24 Bernard Dautrevaux
-- strict thread matches above, loose matches on Subject: below --
2002-01-06 0:26 SourceNav release Simonovsky, Pavel
2002-01-06 3:48 ` Mo DeJong
2002-01-06 6:36 ` Ralf Corsepius
2002-01-07 13:22 ` Ian Roxborough
2002-01-07 13:34 ` Patches...[was: Re: SourceNav release ... ] Ian Roxborough
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).