6:31 p.m.
I cannot find the "frontier.pdf" documentation. Does it become available
only when I install the package locally?
Alecos Papadopoulos
PhD Candidate
Athens University of Economics and Business, Greece
School of Economic Sciences
Department of Economics
https://alecospapadopoulos.wordpress.com/
On 23/7/2018 19:00, gretl-users-request(a)lists.wfu.edu wrote:
and ask everybody who has an
interest in this class of models to test the new package and tell me about
the bugs that it contains, so I can hopefully fix it.
6:37 p.m.
New subject: New "frontier" package Gretl-users Digest, Vol 138, Issue 14
On Tue, 24 Jul 2018, Alecos Papadopoulos wrote:
I cannot find the "frontier.pdf" documentation. Does it
become
available only when I install the package locally?
Yes, that's right. It would probably be good to arrange for the PDF
documentation for function packages to be browsable online, but for
now it's strictly embedded in the package.
Allin
8:12 p.m.
New subject: New "frontier" package Gretl-users Digest, Vol 138, Issue 14
Am 24.07.2018 um 20:37 schrieb Allin Cottrell:
On Tue, 24 Jul 2018, Alecos Papadopoulos wrote:
> I cannot find the "frontier.pdf" documentation. Does it become
> available only when I install the package locally?
Yes, that's right. It would probably be good to arrange for the PDF
documentation for function packages to be browsable online, but for
now it's strictly embedded in the package.
There was this idea to link to all the documentation files from this
page:
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS,
but unfortunately I haven't been able to cut through the C-based web
page code yet.
Apart from that, I was thinking that we could use the facilities on the
sourceforge project page to establish some web-based forums just for the
packages (and add-ons, probably). Then we would pin the packages' help
texts in those subforums as well. But that was just a private thought so
far.
cheers,
sven
8:36 p.m.
New subject: New "frontier" package Gretl-users Digest, Vol 138, Issue 14
On Tue, 24 Jul 2018, Sven Schreiber wrote:
Am 24.07.2018 um 20:37 schrieb Allin Cottrell:
> On Tue, 24 Jul 2018, Alecos Papadopoulos wrote:
>
>> I cannot find the "frontier.pdf" documentation. Does it become
available
>> only when I install the package locally?
>
> Yes, that's right. It would probably be good to arrange for the PDF
> documentation for function packages to be browsable online, but for now
> it's strictly embedded in the package.
>
There was this idea to link to all the documentation files from this page:
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS, but
unfortunately I haven't been able to cut through the C-based web page code
yet.
Maybe gretldata.cgi should be converted to python or similar. Since
I live and breathe C that's what I naturally use to write almost
everything but I'm willing to compromise ;-)
One possibly low-cost idea: if you click on one of the gfn links on
the above-mentioned page (SHOW_FUNCS) Firefox (for example) will
show you the XML (gfn files being XML) -- but Firefox says "This XML
file does not appear to have any style information associated with
it. The document tree is shown below." And you get a not-so-pretty
blob with no line-breaks in the Help or hansl code.
Does anyone know of a way to "associate style information" with an
arbitrary XML file sitting on a given web server such that a browser
would, at least, respect line breaks? Or maybe even do effective
pretty-printing?
Allin
9:27 p.m.
New subject: New "frontier" package Gretl-users Digest, Vol 138, Issue 14
On Tue, 24 Jul 2018, Allin Cottrell wrote:
Does anyone know of a way to "associate style information"
with an arbitrary
XML file sitting on a given web server such that a browser would, at least,
respect line breaks? Or maybe even do effective pretty-printing?
OK, kinda lame question. Seems that getting a gfn file to display
nicely in a browser should just be a matter of writing an
appropriate xsl file that translates the elements of the gfn into
suitable HTML, and referencing the xsl file in the gfn (or maybe
just applying it via the web server?).
If anyone wants to have a go at that, please do. But I have some
experience writing xsl and could pick it up at some point if nobody
intervenes.
Allin
4:50 p.m.
New subject: New "frontier" package Gretl-users Digest, Vol 138, Issue 14
Am 24.07.2018 um 23:27 schrieb Allin Cottrell:
OK, kinda lame question. Seems that getting a gfn file to display
nicely in a browser should just be a matter of writing an appropriate
xsl file that translates the elements of the gfn into suitable HTML,
and referencing the xsl file in the gfn (or maybe just applying it via
the web server?).
If anyone wants to have a go at that, please do. But I have some
experience writing xsl and could pick it up at some point if nobody
intervenes.
Good idea. Attached is a first attempt which seems to do the job on a
basic level. I tested with the following processor:
<python>
import lxml.html
from lxml import etree
xslt_doc = etree.parse("stylesheet4gfns.xlst")
xslt_transformer = etree.XSLT(xslt_doc)
source_doc = etree.parse("yahoo_get.gfn")
output_doc = xslt_transformer(source_doc)
print(str(output_doc))
output_doc.write("output-gfn.html")
</python>
The stylesheet is a bit of a hack, because the line breaks of the help
text are preserved by brute force using the <pre> tag in HTML. But I'd
say the result is better than nothing and good enough for now.
cheers,
sven
5:27 p.m.
New subject: stylesheet for function package help (was: New "frontier" ....)
Am 25.07.2018 um 18:50 schrieb Sven Schreiber:
Am 24.07.2018 um 23:27 schrieb Allin Cottrell:
>
>
> If anyone wants to have a go at that, please do. But I have some
> experience writing xsl and could pick it up at some point if nobody
> intervenes.
>
Good idea. Attached is a first attempt which seems to do the job on a
basic level.
...
The stylesheet is a bit of a hack, because the line breaks of the
help
text are preserved by brute force using the <pre> tag in HTML. But I'd
say the result is better than nothing and good enough for now.
Hi Allin,
is this useable for you as a starting point?
cheers,
sven
7:06 p.m.
New subject: stylesheet for function package help (was: New "frontier" ....)
On Fri, 10 Aug 2018, Sven Schreiber wrote:
Am 25.07.2018 um 18:50 schrieb Sven Schreiber:
> Am 24.07.2018 um 23:27 schrieb Allin Cottrell:
>>
>>
>> If anyone wants to have a go at that, please do. But I have some
>> experience writing xsl and could pick it up at some point if nobody
>> intervenes.
>>
> Good idea. Attached is a first attempt which seems to do the job on a basic
> level.
...
> The stylesheet is a bit of a hack, because the line breaks of the help text
> are preserved by brute force using the <pre> tag in HTML. But I'd say the
> result is better than nothing and good enough for now.
>
Hi Allin,
is this useable for you as a starting point?
Sorry, been rather busy with other things, but I'll take a look as
soon as I can. Certainly sounds promising.
Allin
3:39 p.m.
New subject: stylesheet for function package help (was: New "frontier" ....)
On Fri, 10 Aug 2018, Sven Schreiber wrote:
Am 25.07.2018 um 18:50 schrieb Sven Schreiber:
> Am 24.07.2018 um 23:27 schrieb Allin Cottrell:
>>
>>
>> If anyone wants to have a go at that, please do. But I have some
>> experience writing xsl and could pick it up at some point if nobody
>> intervenes.
>>
> Good idea. Attached is a first attempt which seems to do the job on a basic
> level.
...
> The stylesheet is a bit of a hack, because the line breaks of the help text
> are preserved by brute force using the <pre> tag in HTML. But I'd say the
> result is better than nothing and good enough for now.
>
Hi Allin,
is this useable for you as a starting point?
I've now taken a look, and have uploaded a slight variation on your
stylesheet as gfn2html.xsl (also attached).
The easiest way to get this used by browsers is to insert a reference
as the second line of the gfn file:
<?xml-stylesheet type="text/xsl" href="gfn2html.xsl"?>
That's easy enough to do with a little shell script, and I've
processed these three as a sample:
criteria.gfn
corresp.gfn
delayspectral.gfn
E.g.
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/current_fnfiles/delayspectral.gfn
I don't think there's any bad fallout from inserting this line. If
that's confirmed I can go ahead and batch-process all the gfns.
Allin
4:35 p.m.
New subject: stylesheet for function package help
Am 14.08.2018 um 17:39 schrieb Allin Cottrell:
On Fri, 10 Aug 2018, Sven Schreiber wrote:
The easiest way to get this used by browsers is to insert a reference
as the second line of the gfn file:
<?xml-stylesheet type="text/xsl" href="gfn2html.xsl"?>
Ah, clever!
That's easy enough to do with a little shell script, and I've
processed these three as a sample:
criteria.gfn
corresp.gfn
delayspectral.gfn
Seems to work OK.
I don't think there's any bad fallout from inserting this line. If
that's confirmed I can go ahead and batch-process all the gfns.
OK, but there
are two remaining issues:
1. Newly incoming (or updated) packages need to get this extra line as
well. For the future could this somehow be incorporated into the
"gretlcli.exe --makepkg" command (and its equivalent on Linux)?
2. Then there are the zip format packages. With the exception of
'Threshold_Panel' and 'dhurdle' (and anything else?), all of these have
PDF help files. My proposal would be to put those pdf files manually
into a subdirectory
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/current_fnfiles/unzipped/pdf/ -
the package moderators including myself can take care of that I think.
And then add a link to current_fnfiles/unzipped/pdf/<pkgname>.pdf to the
description field of the package listing. This latter step would involve
changing the dynamic web code for SHOW_FUNCS, but not much I guess.
I admit this is not 100% coherent, since for .gfn packages you click on
the Name field in the list, and for .zip packages you click on the
Description. But IMHO it's acceptable and still reasonably intuitive.
The gap would be the zip packages without pdf help. Maybe we could make
a pdf a requirement for zip packages...
thanks,
sven
5:42 p.m.
New subject: stylesheet for function package help
On Tue, 14 Aug 2018, Sven Schreiber wrote:
Am 14.08.2018 um 17:39 schrieb Allin Cottrell:
> On Fri, 10 Aug 2018, Sven Schreiber wrote:
>
> The easiest way to get this used by browsers is to insert a reference as
> the second line of the gfn file:
>
> <?xml-stylesheet type="text/xsl" href="gfn2html.xsl"?>
Ah, clever!
> That's easy enough to do with a little shell script, and I've processed
> these three as a sample:
>
> criteria.gfn
> corresp.gfn
> delayspectral.gfn
Seems to work OK.
> I don't think there's any bad fallout from inserting this line. If that's
> confirmed I can go ahead and batch-process all the gfns.
OK, but there are two remaining issues:
1. Newly incoming (or updated) packages need to get this extra line as well.
For the future could this somehow be incorporated into the "gretlcli.exe
--makepkg" command (and its equivalent on Linux)?
Could be, though I don't think it would be difficult to inject the
line in question when a gfn is uploaded to the server, if it's not
already present in the XML.
2. Then there are the zip format packages. With the exception of
'Threshold_Panel' and 'dhurdle' (and anything else?), all of these have
PDF
help files. My proposal would be to put those pdf files manually into a
subdirectory
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/current_fnfiles/unzipped/pdf/ - the
package moderators including myself can take care of that I think. And then
add a link to current_fnfiles/unzipped/pdf/<pkgname>.pdf to the description
field of the package listing. This latter step would involve changing the
dynamic web code for SHOW_FUNCS, but not much I guess.
Yes, something like that should work. Also I think the "extract the
PDF to such-and-such a place" step could be automated (on upload, or
probably better, on approval).
Allin
6:36 p.m.
New subject: stylesheet for function package help
Change of sub-topic: Does anyone have any clever ideas regarding the
formatting of plain-text help for function packages?
At present we have an unholy mixture of styles -- this is
mercilessly exposed by the experimental web business up-thread but
is also apparent on viewing package help within gretl.
Some authors favor very short lines that look kinda silly relative
to the standard width of printed material in gretl (that is,
somewhere between 70 and 80 characters per line). Other authors
write very long lines that have to be word-wrapped. Word-wrapping is
fine in some cases, but it totally mangles lines that have been
typed with a hanging indent (or worse, two nested hanging indents!).
One possible idea would be to insist on markdown in gfn text help,
though I think markdown itself has problems in the line-length
department. I've been contemplating the idea of a post-processor
which would "fix" the help text for a package when it's uploaded to
the server, but the more examples I look at, the more it seems like
this would be an advanced AI project!
Another possibility would be to require that all packages have PDF
documentation, though that would both raise the bar for package
contribution and spell the end of standalone gfn files.
Any better/different ideas?
Allin
8:27 p.m.
New subject: stylesheet for function package help
There are now some further updates for the action of clicking on a
gfn link at
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS
in a browser (strictly speaking, only tested in Firefox).
* All current gfn packages are now processed so they'll show HTML.
* The content is now a bit fuller (sample scripts are shown).
* The presentation style is (in my opinion) is a little better.
Note: right-click and "Save as" is, or should be, unaffected.
Allin
8:41 p.m.
New subject: stylesheet for function package help
Em 14 de agosto de 2018, Allin escreveu:
Change of sub-topic: Does anyone have any clever ideas regarding the
formatting of plain-text help for function packages?
At present we have an unholy mixture of styles -- this is
mercilessly exposed by the experimental web business up-thread but
is also apparent on viewing package help within gretl.
Some authors favor very short lines that look kinda silly relative
to the standard width of printed material in gretl (that is,
somewhere between 70 and 80 characters per line). Other authors
write very long lines that have to be word-wrapped. Word-wrapping is
fine in some cases, but it totally mangles lines that have been
typed with a hanging indent (or worse, two nested hanging indents!).
One possible idea would be to insist on markdown in gfn text help,
though I think markdown itself has problems in the line-length
department. I've been contemplating the idea of a post-processor
which would "fix" the help text for a package when it's uploaded to
the server, but the more examples I look at, the more it seems like
this would be an advanced AI project!
Another possibility would be to require that all packages have PDF
documentation, though that would both raise the bar for package
contribution and spell the end of standalone gfn files.
Any better/different ideas?
It's not a better/different idea, but I think Markdown is a great way
to write texts. I'm using a lot of it in my R scripts (via RMarkdown)
and I'm very satisfied with the results.
Best,
Henrique Andrade
8:50 p.m.
New subject: stylesheet for function package help
Em 14 de agosto de 2018, Allin escreveu:
There are now some further updates for the action of clicking on a
gfn link at
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS
in a browser (strictly speaking, only tested in Firefox).
Tested here at my Windows 7 PC using Firefox and Chrome. Everything is
working just fine.
* All current gfn packages are now processed so they'll show
HTML.
* The content is now a bit fuller (sample scripts are shown).
* The presentation style is (in my opinion) is a little better.
Note: right-click and "Save as" is, or should be, unaffected.
Just two simple suggestions:
(1) Put all examples inside code blocks (not just the sample script);
(2) I'm not an expert about digital security, but I think it's better
to mask all e-mail addresses inside the function ("at" instead of
"@")
Best,
Henrique Andrade
9:19 p.m.
New subject: stylesheet for function package help
On Tue, 14 Aug 2018, Henrique Andrade wrote:
Em 14 de agosto de 2018, Allin escreveu:
> There are now some further updates for the action of clicking on a
> gfn link at
> http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS
> in a browser (strictly speaking, only tested in Firefox).
Tested here at my Windows 7 PC using Firefox and Chrome. Everything is
working just fine.
> * All current gfn packages are now processed so they'll show HTML.
>
> * The content is now a bit fuller (sample scripts are shown).
>
> * The presentation style is (in my opinion) is a little better.
>
> Note: right-click and "Save as" is, or should be, unaffected.
Just two simple suggestions:
(1) Put all examples inside code blocks (not just the sample script);
I'd happily do that, but the question is: how do we tell (or rather,
how do we get XSL to distinguish) what's an example as opposed to a
regular line of text? The sample script is easy because it's wrapped
in the tags "<sample-script>" and "</sample-script>", but
other code
fragments that may occur in the help text have no such marking.
(2) I'm not an expert about digital security, but I think
it's better
to mask all e-mail addresses inside the function ("at" instead of
"@")
For sure, yes. But the current version of the XSL file converts "@"
to " at " in author emails.
Allin
1:49 a.m.
New subject: stylesheet for function package help
On Tue, 14 Aug 2018, Henrique Andrade wrote:
Em 14 de agosto de 2018, Allin escreveu:
> One possible idea would be to insist on markdown in gfn text help,
> though I think markdown itself has problems in the line-length
> department. I've been contemplating the idea of a post-processor
> which would "fix" the help text for a package when it's uploaded to
> the server, but the more examples I look at, the more it seems like
> this would be an advanced AI project!
>
> Another possibility would be to require that all packages have PDF
> documentation, though that would both raise the bar for package
> contribution and spell the end of standalone gfn files.
>
> Any better/different ideas?
It's not a better/different idea, but I think Markdown is a great way
to write texts. I'm using a lot of it in my R scripts (via RMarkdown)
and I'm very satisfied with the results.
I'm a bit wary of introducing mandatory rules for package writers; pdf
documentation is probably too much.
On the other hand, markdown seems a viable solution. Basically, we could
say that the help text can be a plain text file, but package authors are
encouraged to improve legibility via markdown (which should be rendered
graphically whenever possible).
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
7:44 a.m.
New subject: stylesheet for function package help
Am 15.08.2018 um 03:49 schrieb Riccardo (Jack) Lucchetti:
On Tue, 14 Aug 2018, Henrique Andrade wrote:
> Em 14 de agosto de 2018, Allin escreveu:
>
>> One possible idea would be to insist on markdown in gfn text help,
>> though I think markdown itself has problems in the line-length
>> department.
>
> It's not a better/different idea, but I think Markdown is a great way
> to write texts. I'm using a lot of it in my R scripts (via RMarkdown)
> and I'm very satisfied with the results.
I like the markdown idea -
although I didn't really know what it was it
turns out I have been using parts of it by imitation already in the past.
Let me add to that that the Sourceforge trackers (bugs and feature
requests in our case) also use markdown syntax, and there are guides
available there.
I'm a bit wary of introducing mandatory rules for package
writers; pdf
documentation is probably too much.
On the other hand, markdown seems a viable solution. Basically, we
could say that the help text can be a plain text file, but package
authors are encouraged to improve legibility via markdown (which
should be rendered graphically whenever possible).
I agree. There should be
incentives ("look at that pretty output, now
look at the other ugly one") but an ugly plain text help should still be
allowed.
One area where I think a mandatory rule doesn't hurt is for the zipped
packages: Requiring a pdf help if you want to pack other resources (aux
files) into your package. The majority of zip packages already has that.
So this only affects Artur's threshold panel package and Jack's double
hurdle package. (Anything else?)
cheers,
sven
11:13 a.m.
New subject: stylesheet for function package help
On Wed, 15 Aug 2018, Sven Schreiber wrote:
One area where I think a mandatory rule doesn't hurt is for the
zipped
packages: Requiring a pdf help if you want to pack other resources (aux
files) into your package. The majority of zip packages already has that. So
this only affects Artur's threshold panel package and Jack's double hurdle
package. (Anything else?)
I think I can add a pdf doc to dhurdle pretty easily, only not now. Let's
say a month.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
12:19 p.m.
New subject: stylesheet for function package help
Am 15.08.2018 um 13:13 schrieb Riccardo (Jack) Lucchetti:
On Wed, 15 Aug 2018, Sven Schreiber wrote:
> One area where I think a mandatory rule doesn't hurt is for the
> zipped packages: Requiring a pdf help if you want to pack other
> resources (aux files) into your package. The majority of zip packages
> already has that. So this only affects Artur's threshold panel
> package and Jack's double hurdle package. (Anything else?)
I think I can add a pdf doc to dhurdle pretty easily, only not now.
Let's say a month.
I didn't mean to imply that it has to happen now now
now. In fact the
existing zip packages without a pdf help could just stay in the list,
only that their help then wouldn't be directly displayable on the web page.
_If_ this mandatory-pdf-in-zip rule is adopted, which it isn't just yet...
cheers,
sven
12:36 p.m.
New subject: stylesheet for function package help
On Wed, 15 Aug 2018, Riccardo (Jack) Lucchetti wrote:
I'm a bit wary of introducing mandatory rules for package
writers; pdf
documentation is probably too much.
OK, I agree.
On the other hand, markdown seems a viable solution. Basically, we
could say
that the help text can be a plain text file, but package authors are
encouraged to improve legibility via markdown (which should be rendered
graphically whenever possible).
Thinking about this some more, it's not totally straightforward. There
are tools to convert markdown to HTML OK, but we don't have a means of
displaying HTML inside gretl. The ideal, from the point of view of
flexibility of display, would be to have the help text as XML -- and
therefore subject to any XSL transformation we want -- but I'm not
proposing that, it would be too onerous.
Maybe we could make a little progress by producing some (short, clear)
guidelines on the formatting of plain text function help. For example,
it would help quite a lot if all paragraphs were separated by exactly
two newlines.
Allin
1:03 p.m.
New subject: stylesheet for function package help
Am 15.08.2018 um 14:36 schrieb Allin Cottrell:
Thinking about this some more, it's not totally straightforward.
There
are tools to convert markdown to HTML OK, but we don't have a means of
displaying HTML inside gretl.
I thought the idea of markdown was that you don't necessarily have to
transform it in order to be nicely human-readable? We're probably
thinking about a subset of markdown instead of the whole spec (at least
I was, I guess).
cheers,
sven
1:57 p.m.
New subject: stylesheet for function package help
On Wed, 15 Aug 2018, Sven Schreiber wrote:
Am 15.08.2018 um 14:36 schrieb Allin Cottrell:
> Thinking about this some more, it's not totally straightforward. There are
> tools to convert markdown to HTML OK, but we don't have a means of
> displaying HTML inside gretl.
I thought the idea of markdown was that you don't necessarily have to
transform it in order to be nicely human-readable?
That's the claim, but there's a problem with line lengths. A single
newline in markdown text translates to a "hard" HTML linebreak, <br>.
So authors who want the body of a paragraph to reflow on demand do not
insert such breaks. So, in turn, we get super-long lines in raw
markdown.
Allin
2:15 p.m.
New subject: stylesheet for function package help
Am 15.08.2018 um 15:57 schrieb Allin Cottrell:
On Wed, 15 Aug 2018, Sven Schreiber wrote:
> Am 15.08.2018 um 14:36 schrieb Allin Cottrell:
>
> I thought the idea of markdown was that you don't necessarily have to
> transform it in order to be nicely human-readable?
That's the claim, but there's a problem with line lengths. A single
newline in markdown text translates to a "hard" HTML linebreak, <br>.
So authors who want the body of a paragraph to reflow on demand do not
insert such breaks. So, in turn, we get super-long lines in raw markdown.
Hm, not sure if that's correct. Looking at (the source version) of the
syntax description at
https://daringfireball.net/projects/markdown/syntax.text suggests that
you can have (single) newlines in the source without getting hard <br />
things. (Compare the html result
https://daringfireball.net/projects/markdown/syntax.)
Instead the syntax intro there says: "When you /do/ want to insert a
|<br />| break tag using Markdown, you end a line with two or more
spaces, then type return. ... "a simplistic “every line break is a |<br
/>|” rule wouldn’t work for Markdown"
cheers,
sven
2:51 p.m.
New subject: stylesheet for function package help
On Wed, 15 Aug 2018, Sven Schreiber wrote:
Am 15.08.2018 um 15:57 schrieb Allin Cottrell:
> On Wed, 15 Aug 2018, Sven Schreiber wrote:
>
>> Am 15.08.2018 um 14:36 schrieb Allin Cottrell:
>>
>> I thought the idea of markdown was that you don't necessarily have to
>> transform it in order to be nicely human-readable?
>
> That's the claim, but there's a problem with line lengths. A single newline
> in markdown text translates to a "hard" HTML linebreak, <br>.
> So authors who want the body of a paragraph to reflow on demand do not
> insert such breaks. So, in turn, we get super-long lines in raw markdown.
Hm, not sure if that's correct. Looking at (the source version) of the syntax
description at https://daringfireball.net/projects/markdown/syntax.text
suggests that you can have (single) newlines in the source without getting
hard <br /> things. (Compare the html result
https://daringfireball.net/projects/markdown/syntax.)
Instead the syntax intro there says: "When you /do/ want to insert a |<br />|
break tag using Markdown, you end a line with two or more spaces, then type
return. ... "a simplistic “every line break is a |<br />|” rule wouldn’t work
for Markdown"
OK, interesting. That's not how it works in the markdown test rig at
https://dillinger.io/ . But it seems that's contrary to the spec.
Allin
2:25 p.m.
New subject: stylesheet for function package help
Am 14.08.2018 um 19:42 schrieb Allin Cottrell:
On Tue, 14 Aug 2018, Sven Schreiber wrote:
> 2. Then there are the zip format packages. With the exception of
> 'Threshold_Panel' and 'dhurdle' (and anything else?), all of these
> have PDF help files. My proposal would be to put those pdf files
> manually into a subdirectory
> http://ricardo.ecn.wfu.edu/gretl/cgi-bin/current_fnfiles/unzipped/pdf/
> - the package moderators including myself can take care of that I
> think. And then add a link to
> current_fnfiles/unzipped/pdf/<pkgname>.pdf to the description field
> of the package listing. This latter step would involve changing the
> dynamic web code for SHOW_FUNCS, but not much I guess.
Yes, something like that should work. Also I think the "extract the
PDF to such-and-such a place" step could be automated (on upload, or
probably better, on approval).
I'd like to move forward with the web links to the respective PDF help
files. I'm not against automation (of course), but as I said I wouldn't
mind to extract and collect the pdf files manually. There isn't such a
rapid flow of new packages, so it's not a problem.
Which variant should it be then, and which sub-directory for the pdf files?
thanks,
sven
8:23 p.m.
New subject: stylesheet for function package help
On Sun, 19 Aug 2018, Sven Schreiber wrote:
Am 14.08.2018 um 19:42 schrieb Allin Cottrell:
> On Tue, 14 Aug 2018, Sven Schreiber wrote:
>
>> 2. Then there are the zip format packages. With the exception of
>> 'Threshold_Panel' and 'dhurdle' (and anything else?), all of
these have
>> PDF help files. My proposal would be to put those pdf files manually into
>> a subdirectory
>> http://ricardo.ecn.wfu.edu/gretl/cgi-bin/current_fnfiles/unzipped/pdf/ -
>> the package moderators including myself can take care of that I think. And
>> then add a link to current_fnfiles/unzipped/pdf/<pkgname>.pdf to the
>> description field of the package listing. This latter step would involve
>> changing the dynamic web code for SHOW_FUNCS, but not much I guess.
>
> Yes, something like that should work. Also I think the "extract the PDF to
> such-and-such a place" step could be automated (on upload, or probably
> better, on approval).
>
I'd like to move forward with the web links to the respective PDF help files.
I'm not against automation (of course), but as I said I wouldn't mind to
extract and collect the pdf files manually. There isn't such a rapid flow of
new packages, so it's not a problem.
Which variant should it be then, and which sub-directory for the pdf files?
I've reminded myself what the relevant server-side code looks like.
At present we extract the gfn code from a zip package to a temporary
file (to be deleted after use) in the "unzipped" subdirectory of the
current packages directory:
(a) in order to validate a gfn against the DTD on upload;
(b) in response to a request from the web server to list the current
packages (get the author, description, version, date); and
(c) in response to a request from gretl for "info" on a zip package
(right-click menu in packages "on server" window).
It seems to me we could combine this with the PDF business (and into
the bargain cut out some CPU cycles on the server) if we just
extracted both the gfn and the PDF (if present) to the "unzipped"
directory on upload -- not as temporary files but under their own
names, to sit there for the duration (that is, until the zip package
is replaced or retired).
Obviously if we choose this route there's still a need to do the
extraction for the existing zip packages, but that could easily be
accomplished via a shell script on the server.
Allin
8:29 p.m.
New subject: stylesheet for function package help
On Mon, 20 Aug 2018, Allin Cottrell wrote:
It seems to me we could [do better] if we just extracted both the
gfn and the PDF (if present) to the "unzipped" directory on upload
-- not as temporary files but under their own names, to sit there
for the duration (that is, until the zip package is replaced or
retired).
OK, to be precise I really meant "on approval" of a zip package, not
"on upload".
Allin
12:42 a.m.
New subject: stylesheet for function package help
On Sun, 19 Aug 2018, Sven Schreiber wrote:
I'd like to move forward with the web links to the respective PDF
help files.
I've now modified the server sources as follows:
1) When a zipfile package is approved, its gfn content (and PDF doc,
if present) are unzipped into the "unzipped" directory.
2) The HTML view of the function packages now includes a "[doc]"
link beside the zipfile download link for zip packages that include
PDF documentation.
3) If a zip package is removed from the public download area via the
admin web interface its associated unzipped gfn and PDF are also
deleted.
Allin
6:10 a.m.
New subject: stylesheet for function package help
Am 21.08.2018 um 02:42 schrieb Allin Cottrell:
On Sun, 19 Aug 2018, Sven Schreiber wrote:
> I'd like to move forward with the web links to the respective PDF
> help files.
I've now modified the server sources as follows:
1) When a zipfile package is approved, its gfn content (and PDF doc,
if present) are unzipped into the "unzipped" directory.
2) The HTML view of the function packages now includes a "[doc]" link
beside the zipfile download link for zip packages that include PDF
documentation.
3) If a zip package is removed from the public download area via the
admin web interface its associated unzipped gfn and PDF are also deleted.
A comprehensive and excellent solution, thanks!
(Cosmetically, maybe the style of the [doc] link should be modified to
be rendered with a smaller font size, but that's very minor of course.)
To all users: You may want to check out the new look of
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS
and browse the available help texts and files for the packages.
thanks,
sven
6:13 a.m.
New subject: stylesheet for function package help
Am 21.08.2018 um 08:10 schrieb Sven Schreiber:
Am 21.08.2018 um 02:42 schrieb Allin Cottrell:
> On Sun, 19 Aug 2018, Sven Schreiber wrote:
>
To all users: You may want to check out the new look of
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS
and browse the available help texts and files for the packages.
Wow, this looks great. I really think that this was an important missing
aspect for attracting more people. This is especially the case for
'external' users who had no contact with gretl before but want a first
look at available packages.
Thank you for realizing this!
Artur
2072
days inactive
2100
days old
30 comments
6 participants
participants (6)
-
Alecos Papadopoulos -
Allin Cottrell -
Artur T. -
Henrique Andrade -
Riccardo (Jack) Lucchetti -
Sven Schreiber