Hello Ralph,
Ralph Corderoy ra...@inputplus.co.uk wrote:
|Hi Peter,
|
| http://lists.gnu.org/archive/html/groff/2014-06/bin14bGZPiUPU.bin
| which
|
| The .bin extension issue for attachments in archived email has come up
| before. Does anyone know why lists.gnu.org is doing this and
Hi Steffen,
The closest is
http://www.iana.org/assignments/media-types/application/gzip which
leaves the tar for the user to fathom out if left to MIME types
alone.
[http://svn.apache.org/viewvc/tika/trunk/tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml]
lists the
Hello Ralph,
Ralph Corderoy ra...@inputplus.co.uk wrote:
|Hi Steffen,
|
| The closest is
| http://www.iana.org/assignments/media-types/application/gzip which
| leaves the tar for the user to fathom out if left to MIME types
| alone.
|
|
On Fri, Jun 27, 2014 at 03:43:24PM +0200, Steffen Nurpmeso wrote:
Oh, after fiddling with unsupported linker options etc. to compile
the showcase i got a SIGBUS. You know, as in Bus stop, wet day,
she's there etc. Only the umbrella is still missing.
Ciao,
--steffen
Not clear to me, if
Hello Ulrich,
Ulrich Lauther ulrich.laut...@t-online.de wrote:
|On Fri, Jun 27, 2014 at 03:43:24PM +0200, Steffen Nurpmeso wrote:
| Oh, after fiddling with unsupported linker options etc. to compile
| the showcase i got a SIGBUS. You know, as in Bus stop, wet day,
| she's there etc. Only
Hi Doug,
Ulrich wrote, Please find below ... my attached code.
gnu.org reports not found for the strange-looking URL where the
attachment was supposedly stored:
http://lists.gnu.org/archive/html/groff/attachments/20140623/d3f40bfc/attachment.bin
The email I received from the list had the
On Thu, Jun 26, 2014, Ralph Corderoy wrote:
When I view Ulrich's email at
http://lists.gnu.org/archive/html/groff/2014-06/msg00089.html I see a
distribute.tgz link at the end of it to
http://lists.gnu.org/archive/html/groff/2014-06/bin14bGZPiUPU.bin which
works for me.
The .bin extension
In the meantime I have send the tgz-file directly to Dough, not to the list,
and he was able to read it.
Waiting for comments,
ulrich
Hi Peter,
http://lists.gnu.org/archive/html/groff/2014-06/bin14bGZPiUPU.bin
which
The .bin extension issue for attachments in archived email has come up
before. Does anyone know why lists.gnu.org is doing this and whether
there'd be any point trying to get it fixed?
It's to protect
Ulrich wrote, Please find below ... my attached code.
gnu.org reports not found for the strange-looking URL where the
attachment was supposedly stored:
http://lists.gnu.org/archive/html/groff/attachments/20140623/d3f40bfc/attachment.bin
On Thu, May 08, 2014 at 04:17:16PM -0400, Doug McIlroy wrote:
[...]
I fully agree with the first paragraph. However, as there is essentially no
limit on the amount (or kind) of path-dependent state that may be needed
to calculate each partial solution, I see forking as the easiest way to
On Fri, May 09, 2014 at 01:07:02PM +0200, Ulrich Lauther wrote:
On Fri, May 09, 2014 at 10:48:08AM +0100, Denis M. Wilson wrote:
The method used in TeX is the shortest path in a directed acyclic graph.
This is a well-understood problem. There seems unfortunately to be
nothing useful in the
On Fri, May 09, 2014 at 01:12:14PM +0100, Roger Leigh wrote:
On Fri, May 09, 2014 at 01:07:02PM +0200, Ulrich Lauther wrote:
On Fri, May 09, 2014 at 10:48:08AM +0100, Denis M. Wilson wrote:
The method used in TeX is the shortest path in a directed acyclic graph.
This is a well-understood
On Sun, May 04, 2014 at 02:59:19PM -0400, Doug McIlroy wrote:
I don't see why any forking should be needed.
I am all ears. I'd love to know a better way to cope with events
that are triggered by line breaks, when several different potential
line breaks are in play, as were discussed in my
I don't see why any forking should be needed.
I am all ears. I'd love to know a better way to cope with events
that are triggered by line breaks, when several different potential
line breaks are in play, as were discussed in my posting to which
Peter's referred. Forking is certainly
On Sat, 3 May 2014 14:23:10 -0400
Peter Schaffter pe...@schaffter.ca wrote:
A straightforward way to pull this off would be to actualize the
notional copies of groff by forking. There would be one copy going
forward from each line break. That would evaluate the cost of
breaking at each
On Fri, Apr 25, 2014, Doug McIlroy wrote:
Equations and displayed quotations are not a problem for the line-breaking
algorithm; they'd all be handled in the macro packages, which would have
the duty to delimit the blocks of text that are to be treated unitarily.
But that doesn't mean we're
On Sat, May 03, 2014 at 02:23:10PM -0400, Peter Schaffter wrote:
I suspect I'm a voice crying in the wilderness here, but we need to
consider that a greedy algorithm is almost always faster than a
dynamic programming solution; furthermore, greedy algorithms
sometimes lead to optimal
On Thu, Apr 24, 2014, Ulrich Lauther wrote:
Any time you introduce a break, even within a logical paragraph, the
preceding text needs to be adjusted. I can't see any advantage to
including the text after an in-paragraph insertion in the adjustment
process,
Yes, the preceding text
Keith --
On Wed, Apr 23, 2014, Keith Marshall wrote:
Signalling the end of collected paragraphs can't be done exclusively
within macros because, unlike SGMLs, paragraph macros in groff
generally aren't closed.
Doesn't a paragraph logically conclude at any request which introduces a
20 matches
Mail list logo
