On Wed, Dec 24, 2008 at 5:52 AM, mabshoff <mabsh...@googlemail.com> wrote:
>
>
>
> On Dec 24, 12:53 am, "Georg S. Weber" <georgswe...@googlemail.com>
> wrote:
>> Hi Michael,
>
> Hi Georg,
>
>> the wording "... was just not documented ...", "... documentation
>> problem ...", has been used so often now in this thread, that it just
>> moved up in my priority list (for this Example C Library theme) to the
>> lone very top position. So I'll not do an "exampleclib-1.1.0.spkg" or
>> so, before having dumped a decent amount of what I learned up to now
>> into the Wiki and the Sage Programming Guide.
>
> I am looking forward to reading it :)
>
>> It is tricky to write up things in such a way, that in order to create
>> a "pure C Library" spkg from scratch, one then only needs to copy-and-
>> paste the bits and pieces from the documentation. And from my
>> experience teaching students, a "Musterlösung" ("sample solution" in
>> english) is always very much appreciated.
>
> Sure, but creating spkgs is not a daily occurrence, but instead of
> adding some examples why not create a script that just creates the
> spkg layout? I.e. with some trivial changes the following creates a "C
> library" spkg:
>
> ./sage -create-clib-spkg foo
>
> should run something like following. Obviously we need to echo a dummy
> SPKG.txt, spkg-install and spkg-check instead of just touching the
> file. This seems much easier to me :)
+1. This is a very good idea.
>
> [start]
> mabsh...@sage:/scratch/release-cycle/sage-3.2.3.alpha0$ mkdir foo
> mabsh...@sage:/scratch/release-cycle/sage-3.2.3.alpha0$ cd foo/
> mabsh...@sage:/scratch/release-cycle/sage-3.2.3.alpha0/foo$ hg init
> mabsh...@sage:/scratch/release-cycle/sage-3.2.3.alpha0/foo$ mkdir src
> mabsh...@sage:/scratch/release-cycle/sage-3.2.3.alpha0/foo$ echo "src"
>> .hgignore
> mabsh...@sage:/scratch/release-cycle/sage-3.2.3.alpha0/foo$ touch
> SPKG.txt
> mabsh...@sage:/scratch/release-cycle/sage-3.2.3.alpha0/foo$ touch spkg-
> install
> mabsh...@sage:/scratch/release-cycle/sage-3.2.3.alpha0/foo$ touch spkg-
> check
> mabsh...@sage:/scratch/release-cycle/sage-3.2.3.alpha0/foo$ hg
> add .hgignore SPKG.txt spkg-install spkg-check
> mabsh...@sage:/scratch/release-cycle/sage-3.2.3.alpha0/foo$ hg commit -
> u mabshoff -m "Initial version of $FOO.spkg"
> mabsh...@sage:/scratch/release-cycle/sage-3.2.3.alpha0/foo$ cd ..
> mabsh...@sage:/scratch/release-cycle/sage-3.2.3.alpha0$ ./sage -pkg
> foo
> Creating Sage package foo
> foo/SPKG.txt
>
> Created package foo.spkg
>
> NAME: foo
> VERSION: foo
> SIZE: 4.0K
> HG REPO: Good
> SPKG.txt: Good
>
> Please test this package using
>
> sage -f foo.spkg
>
> immediately. Also, note that you can use
>
> sage -pkg_nc foo
>
> to make an uncompressed version of the package (useful if the
> package is full of compressed data).
> [end]
>
> The same can be done for a pure Python spkg without much trouble. This
> solution seems to be much better to me than to provide examples. In
> the end the documentation should still be improved :)
+1
Yes, it's always much way better to make a command to do something
rather than have good but long documentation and examples explaining
how to do something that should just be a command!
There was once a time when "sage -sdist" was a sequence of commands I
knew in my head. Obviously that doesn't scale well, and it is much
better for it to simply be a single command. Likewise with making
new packages.
-- William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
