octave-dev

[OctDev] license.m

[William P. Y. H. <wil...@gm...>]

I wrote license.m from the documentation of Matlab 7 (but it's not
entirely compatible) and I'm attaching it along with this mail. I
think we can put it in octave-forge ;)

Please discuss and test it :)

--
William Poetra Yoga Hadisoeseno

Re: [OctDev] license.m

[Paul K. <pki...@us...>]

William,

Can you please post functions which implement base matlab
function to bu...@oc....  John expressed an interest
in having more complete coverage in time for the Octave 3.0
release.

If he does not want them or does not act on them in a
reasonable time (e.g., six weeks) then I'm happy to
include them in octave-forge, but I would prefer to
give John first right of refusal (I will need reminding).

The alternative is to build infrastructure so that octave-forge
doesn't shadow any octave functions unless we tell it to
in the build/install scripts.  If anyone wants to tackle
this, keep in mind that we want to support testing before
installation, which means installing all the files we want
to keep into a temporary build directory.  I think
converting each subdirectory to support S=F8ren's packaging
system (extended as necessary) is the best way to go.

- Paul

On Nov 27, 2005, at 2:12 AM, William Poetra Yoga Hadisoeseno wrote:

> I wrote license.m from the documentation of Matlab 7 (but it's not
> entirely compatible) and I'm attaching it along with this mail. I
> think we can put it in octave-forge ;)
>
> Please discuss and test it :)
>
> --
> William Poetra Yoga Hadisoeseno
> <license.m>=

Re: [OctDev] license.m

[William P. Y. H. <wil...@gm...>]

On 11/28/05, Paul Kienzle <pki...@us...> wrote:
> William,
>
> Can you please post functions which implement base matlab
> function to bu...@oc....  John expressed an interest
> in having more complete coverage in time for the Octave 3.0
> release.
>
> If he does not want them or does not act on them in a
> reasonable time (e.g., six weeks) then I'm happy to
> include them in octave-forge, but I would prefer to
> give John first right of refusal (I will need reminding).
>

OK, I've posted them on bu...@oc....

> The alternative is to build infrastructure so that octave-forge
> doesn't shadow any octave functions unless we tell it to
> in the build/install scripts.  If anyone wants to tackle
> this, keep in mind that we want to support testing before
> installation, which means installing all the files we want
> to keep into a temporary build directory.  I think
> converting each subdirectory to support S=F8ren's packaging
> system (extended as necessary) is the best way to go.
>

Yes, I think this is good, because we wouldn't need to worry about old
octave-forge functions shadowing new octave functions. I think a
script can do this, and it can also help us when we want to check for
(and remove) obsolete functions in octave-forge.

I've heard about this packaging system before, but I haven't checked
it out yet. Maybe you can put a temporary "freeze" on the cvs
repository, checkout the latest version, make the changes, empty the
repository, then upload the new files?

--
William Poetra Yoga Hadisoeseno

Re: [OctDev] license.m

[Paul K. <pki...@us...>]

On Nov 28, 2005, at 10:49 AM, William Poetra Yoga Hadisoeseno wrote:

> On 11/28/05, Paul Kienzle <pki...@us...> wrote:
>>
>> The alternative is to build infrastructure so that octave-forge
>> doesn't shadow any octave functions unless we tell it to
>> in the build/install scripts.  If anyone wants to tackle
>> this, keep in mind that we want to support testing before
>> installation, which means installing all the files we want
>> to keep into a temporary build directory.  I think
>> converting each subdirectory to support S=F8ren's packaging
>> system (extended as necessary) is the best way to go.
>>
>
> Yes, I think this is good, because we wouldn't need to worry about old
> octave-forge functions shadowing new octave functions. I think a
> script can do this, and it can also help us when we want to check for
> (and remove) obsolete functions in octave-forge.
>
> I've heard about this packaging system before, but I haven't checked
> it out yet. Maybe you can put a temporary "freeze" on the cvs
> repository, checkout the latest version, make the changes, empty the
> repository, then upload the new files?

No freeze required, just create a branch for for 2.1.x support.

Also, no need to delete and reinsert since it will just be
adding packaging info. I don't want to lose the file change history.

- Paul