1. nix config next steps
So now that we have some code to play with, we need to keep the process
moving. The next step is to start documenting the changes, including
in the standard euphoria documentation, but also we need to write a
man page.
Is there anyone interested in starting the man page? I'd say that we probably
want to make a single page to cover exu/ecu/backendu/bind/shroud.*
Then we need to start working on packaging. There are two main package
formats that are probably worth targeting. I run a Debian based system,
so I'm mostly interested in building a .deb package, but I'm guessing we
have some RPM users around here, as well.
I've started looking over the Debian policy manual, and some docs about
creating .deb packages. It's certainly not a trivial task to do it
correctly (meaning in a sufficient state that it might be included in
the Debian distribution) which I think everyone would agree should be
a goal of this project.
Any feedback/assistance is encouraged and appreciated.
Matt
* Are names like backendu, bind and shroud too generic? Assuming that the
ultimate goal is to get accepted into Linux distributions, do these conflict
with anything already out there? Should we change them? If so, to what?
2. Re: nix config next steps
Matt Lewis wrote:
>
>
> So now that we have some code to play with, we need to keep the process
> moving. The next step is to start documenting the changes, including
> in the standard euphoria documentation, but also we need to write a
> man page.
>
> Is there anyone interested in starting the man page? I'd say that we probably
> want to make a single page to cover exu/ecu/backendu/bind/shroud.*
Hi Matt,
I wanted to see what sort of response you got here first before chipping in. I
don't want you to think that I am abandoning you, but as for me, at this stage
I would find it difficult to make a major contribution. However, keep the lines
of communication open, and who knows, in a few months.
This is a very worthwhile project, so keep at it, I will kepp testing the
releases
and giving feedback in this respect.
>
> Then we need to start working on packaging. There are two main package
> formats that are probably worth targeting. I run a Debian based system,
> so I'm mostly interested in building a .deb package, but I'm guessing we
> have some RPM users around here, as well.
>
Yes, me for one - this may be an area I _could_ _possibly_ help in, if
you are not in too much of a rush. May I suggest you get a working install
script working before going for a full deb / rpm package? This may be easier to
test than full blown packages.
> I've started looking over the Debian policy manual, and some docs about
> creating .deb packages. It's certainly not a trivial task to do it
> correctly (meaning in a sufficient state that it might be included in
> the Debian distribution) which I think everyone would agree should be
> a goal of this project.
Absolutely, ultimately.
>
> Any feedback/assistance is encouraged and appreciated.
>
> Matt
>
> * Are names like backendu, bind and shroud too generic? Assuming that the
> ultimate goal is to get accepted into Linux distributions, do these conflict
> with anything already out there? Should we change them? If so, to what?
No, they should be kept the same. Why - because thats what we're used too,
Chris
3. Re: nix config next steps
Matt Lewis wrote:
>
> Is there anyone interested in starting the man page? I'd say that we
> probably want to make a single page to cover exu/ecu/backendu/bind/shroud.*
Would there be any problem with using the Euphoria documentation as is?
For example:
man exu would get the Euphoria Reference Manual.
man ecu would get the Euphoria to C Translator Manual.
> * Are names like backendu, bind and shroud too generic? Assuming that the
> ultimate goal is to get accepted into Linux distributions, do these conflict
> with anything already out there? Should we change them? If so, to what?
If you don't change the names now, then after some years there will be more
resistance to changing the names. Easier now.
4. Re: nix config next steps
Matt Lewis wrote:
>
>
> * Are names like backendu, bind and shroud too generic? Assuming that the
> ultimate goal is to get accepted into Linux distributions, do these conflict
> with anything already out there? Should we change them? If so, to what?
I think that names like "bind" might lead to confusion.
BIND = Berkeley Internet Name Domain
Please see http://en.wikipedia.org/wiki/BIND
JG
5. Re: nix config next steps
Julio C. Galaret Viera wrote:
>
> Matt Lewis wrote:
> >
> >
> > * Are names like backendu, bind and shroud too generic? Assuming that the
> > ultimate goal is to get accepted into Linux distributions, do these conflict
> > with anything already out there? Should we change them? If so, to what?
>
> I think that names like "bind" might lead to confusion.
>
> BIND = Berkeley Internet Name Domain
>
> Please see <a
> href="http://en.wikipedia.org/wiki/BIND">http://en.wikipedia.org/wiki/BIND</a>
>
> JG
Oh yeah! Go ahead change em!
Chris
6. Re: nix config next steps
Jerry Story wrote:
>
> Matt Lewis wrote:
> >
> > Is there anyone interested in starting the man page? I'd say that we
> > probably want to make a single page to cover exu/ecu/backendu/bind/shroud.*
>
> Would there be any problem with using the Euphoria documentation as is?
> For example:
> man exu would get the Euphoria Reference Manual.
> man ecu would get the Euphoria to C Translator Manual.
man files have to be in nroff format. I'm figuring that we'd explain what
each executable does, give the summary of command line options, and tell
the user where the other documentation is.
There are ways to install the html files into an integrated help system,
which we could do. Try 'dhelp' on a debian system (assuming you have
dhelp installed). We might want to create an index page to help navigate
to all the different documents that we have (reference manual, library,
etc.).
>
> > * Are names like backendu, bind and shroud too generic? Assuming that the
> > ultimate goal is to get accepted into Linux distributions, do these conflict
> > with anything already out there? Should we change them? If so, to what?
>
> If you don't change the names now, then after some years there will be more
> resistance to changing the names. Easier now.
I agree. I'm thinking that we can maybe extend the naming theme we already
have with exu, ecu, exw, etc.
Matt
7. Re: nix config next steps
Julio C. Galaret Viera wrote:
>
> Matt Lewis wrote:
> >
> >
> > * Are names like backendu, bind and shroud too generic? Assuming that the
> > ultimate goal is to get accepted into Linux distributions, do these conflict
> > with anything already out there? Should we change them? If so, to what?
>
> I think that names like "bind" might lead to confusion.
>
> BIND = Berkeley Internet Name Domain
>
> Please see tp://en.wikipedia.org/wiki/BIND
Yes, this was the thought that first sparked me to ask this question.
Matt
8. Re: nix config next steps
Julio C. Galaret Viera wrote:
>
> Matt Lewis wrote:
> >
> >
> > * Are names like backendu, bind and shroud too generic? Assuming that the
> > ultimate goal is to get accepted into Linux distributions, do these conflict
> > with anything already out there? Should we change them? If so, to what?
>
> I think that names like "bind" might lead to confusion.
>
> BIND = Berkeley Internet Name Domain
>
> Please see <a
> href="http://en.wikipedia.org/wiki/BIND">http://en.wikipedia.org/wiki/BIND</a>
>
> JG
Why not bindeu, shroudeu and backendeu?
They don't sound too unfamiliar and are less likely to clash with anything else.
CChris
9. Re: nix config next steps
CChris wrote:
>
> Julio C. Galaret Viera wrote:
> >
> > Matt Lewis wrote:
> > >
> > >
> > > * Are names like backendu, bind and shroud too generic? Assuming that
> > > the
> > > ultimate goal is to get accepted into Linux distributions, do these
> > > conflict
> > > with anything already out there? Should we change them? If so, to what?
> >
> > I think that names like "bind" might lead to confusion.
> >
> > BIND = Berkeley Internet Name Domain
> >
> > Please see <a
> > href="http://en.wikipedia.org/wiki/BIND">http://en.wikipedia.org/wiki/BIND</a>
> >
> > JG
>
> Why not bindeu, shroudeu and backendeu?
> They don't sound too unfamiliar and are less likely to clash with anything
> else.
>
It would make more sense to call them:
bind.eu, shroud.eu and backend.eu
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
10. Re: nix config next steps
Bernie Ryan wrote:
>
> CChris wrote:
> >
> >
> > Why not bindeu, shroudeu and backendeu?
> > They don't sound too unfamiliar and are less likely to clash with anything
> > else.
> >
>
> It would make more sense to call them:
>
> bind.eu, shroud.eu and backend.eu
>
One issue with that scheme is that they look like include files, which they
aren't.
I kinda like:
eubind eushroud eubackend
Matt
11. Re: nix config next steps
Matt Lewis wrote:
<snip>
> I kinda like:
>
> eubind eushroud eubackend
votes_for_this_scheme += 1
Regards,
Juergen
--
There are two ways of constructing a software design:
One way is to make it so simple that there are /obviously/ no deficiencies
and the other is to make it so complicated that there are no /obvious/
deficiencies. [C.A.R. Hoare (1987), The Emperor's Old Clothes]
12. Re: nix config next steps
Matt Lewis wrote:
> Bernie Ryan wrote:
> > CChris wrote:
> > >
> > > Why not bindeu, shroudeu and backendeu?
> > > They don't sound too unfamiliar and are less likely to clash with anything
> > > else.
> > >
> >
> > It would make more sense to call them:
> >
> > bind.eu, shroud.eu and backend.eu
> >
>
> One issue with that scheme is that they look like include files, which they
> aren't.
>
> I kinda like:
>
> eubind eushroud eubackend
Sounds good to me.
euphoria/bin/ed also conflicts with the name of
the ancient Unix ed editor.
It will be great if we can get Euphoria accepted
into a popular Linux distribution. Thanks for your efforts!
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
13. Re: nix config next steps
- Posted by ChrisBurch2 <crylex at ?reeuk.co.u?>
Dec 22, 2007
-
Last edited Dec 23, 2007
Juergen Luethje wrote:
>
> Matt Lewis wrote:
>
> <snip>
>
> > I kinda like:
> >
> > eubind eushroud eubackend
>
> votes_for_this_scheme += 1
votes_for_this_scheme += 1
Chris
>
> Regards,
> Juergen
>
> --
> There are two ways of constructing a software design:
> One way is to make it so simple that there are /obviously/ no deficiencies
> and the other is to make it so complicated that there are no /obvious/
> deficiencies. [C.A.R. Hoare (1987), The Emperor's Old Clothes]
