Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.advocacy > #318621 > unrolled thread
| Started by | owl <owl@rooftop.invalid> |
|---|---|
| First post | 2015-09-02 15:43 +0000 |
| Last post | 2015-09-04 04:55 +0000 |
| Articles | 20 on this page of 168 — 18 participants |
Back to article view | Back to comp.os.linux.advocacy
Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-02 15:43 +0000
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-02 17:45 +0200
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-02 15:52 +0000
Re: Three more weeks of UNIX Steve Carroll <fretwizzer@gmail.com> - 2015-09-02 08:54 -0700
Re: Three more weeks of UNIX dunno <dunno@dunno.dunno> - 2015-09-03 00:12 +0000
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-02 18:00 +0200
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-02 16:07 +0000
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-02 18:40 +0200
Re: Three more weeks of UNIX chrisv <chrisv@nospam.invalid> - 2015-09-02 12:09 -0500
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-02 20:43 +0200
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-02 21:19 +0200
Re: Three more weeks of UNIX ronb <ronbNOSPAM@gmail.com> - 2015-09-02 23:31 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-02 20:36 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-03 09:17 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-03 10:06 -0700
Re: Three more weeks of UNIX "A.M" <.m@nsn.s> - 2015-09-03 08:47 -0400
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-03 13:22 +0000
Re: Three more weeks of UNIX "A.M" <.m@nsn.s> - 2015-09-03 10:10 -0400
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-03 09:31 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-03 16:47 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-03 22:29 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-03 23:48 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-04 01:38 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-04 02:50 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-04 04:34 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-03 23:35 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-04 07:39 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-04 01:00 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 16:59 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 17:15 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-05 10:40 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 18:51 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-05 13:09 -0700
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-05 10:39 -0700
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-05 20:03 +0200
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 18:50 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-05 13:16 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 20:52 +0000
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-05 19:58 +0200
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-05 20:39 +0200
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 19:13 +0000
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-05 21:26 +0200
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 19:43 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 19:50 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 19:55 +0000
Re: Three more weeks of UNIX Steve Carroll <fretwizzer@gmail.com> - 2015-09-05 13:39 -0700
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-05 23:14 +0200
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-05 23:28 +0200
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-06 00:02 +0200
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-06 01:24 +0200
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-06 02:12 +0200
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-06 02:33 +0200
Re: Three more weeks of UNIX ronb <ronbNOSPAM@gmail.com> - 2015-09-06 01:03 +0000
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-06 03:24 +0200
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-06 09:45 +0200
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-06 06:40 +0000
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-06 09:58 -0500
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-06 03:40 +0200
Re: Three more weeks of UNIX dunno <dunno@dunno.dunno> - 2015-09-06 03:04 +0000
Re: Three more weeks of UNIX dunno <dunno@dunno.dunno> - 2015-09-06 04:48 +0000
Re: Three more weeks of UNIX dunno <dunno@dunno.dunno> - 2015-09-06 06:46 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-06 06:14 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-06 07:21 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-06 08:12 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-06 10:09 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-06 10:24 -0700
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-06 09:00 -0500
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-06 10:55 -0700
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-06 18:44 -0500
Re: Three more weeks of UNIX ronb <ronbNOSPAM@gmail.com> - 2015-09-06 19:24 +0000
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-06 21:47 +0200
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-06 09:35 -0500
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-06 12:03 +0200
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-06 21:04 +0000
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-06 23:18 +0200
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-06 21:51 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-06 22:37 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-06 23:08 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-06 23:38 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-07 00:10 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-08 09:15 -0700
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-08 09:18 -0700
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-08 10:04 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-09 01:44 +0000
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-09 02:00 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-08 19:05 -0700
Re: Three more weeks of UNIX "A.M" <.m@nsn.s> - 2015-09-09 09:23 -0400
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-09 09:44 -0700
Re: Three more weeks of UNIX "A.M" <.m@nsn.s> - 2015-09-09 12:47 -0400
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-09 10:04 -0700
Re: Three more weeks of UNIX "A.M" <.m@nsn.s> - 2015-09-09 13:15 -0400
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-09 10:28 -0700
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-08 19:00 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-09 02:12 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-08 19:18 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-09 02:30 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-08 19:33 -0700
Re: Three more weeks of UNIX chrisv <chrisv@nospam.invalid> - 2015-09-08 07:42 -0500
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-08 15:30 +0200
Re: Three more weeks of UNIX chrisv <chrisv@nospam.invalid> - 2015-09-08 09:05 -0500
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-08 08:02 -0700
Re: Three more weeks of UNIX "A.M" <.m@nsn.s> - 2015-09-08 12:10 -0400
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-08 09:17 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 22:53 +0000
Re: Three more weeks of UNIX Melzzzzz <mel@zzzzz.com> - 2015-09-06 01:00 +0200
Re: Three more weeks of UNIX vallor <vallor@cultnix.org> - 2015-09-07 00:10 +0000
Re: Three more weeks of UNIX Melzzzzz <melz@zzzzz.com> - 2015-09-07 02:12 +0200
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-06 01:04 +0200
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-05 12:45 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 19:48 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-05 13:20 -0700
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-05 13:38 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 19:10 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-05 12:48 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-05 19:53 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-05 13:26 -0700
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-04 09:28 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-04 04:52 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-03 23:48 -0700
Re: Three more weeks of UNIX dunno <dunno@dunno.dunno> - 2015-09-04 05:13 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-03 23:49 -0700
Re: Three more weeks of UNIX dunno <dunno@dunno.dunno> - 2015-09-04 07:34 +0000
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-04 00:48 -0700
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-05 10:09 +0200
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-06 09:42 +0200
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-06 07:49 +0000
Re: Three more weeks of UNIX ronb <ronbNOSPAM@gmail.com> - 2015-09-06 19:26 +0000
Re: Three more weeks of UNIX chrisv <chrisv@nospam.invalid> - 2015-09-08 07:34 -0500
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-08 08:31 -0700
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-03 09:33 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-03 16:48 +0000
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-05 10:08 +0200
Re: Three more weeks of UNIX Snit <usenet@gallopinginsanity.com> - 2015-09-05 13:36 -0700
Re: Three more weeks of UNIX Steve Carroll <fretwizzer@gmail.com> - 2015-09-03 11:45 -0700
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-05 01:26 -0500
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-05 02:27 -0500
Re: Three more weeks of UNIX ronb <ronbNOSPAM@gmail.com> - 2015-09-02 23:30 +0000
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-05 02:15 -0500
Re: Three more weeks of UNIX ronb <ronbNOSPAM@gmail.com> - 2015-09-05 21:19 +0000
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-07 04:39 -0500
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-05 01:15 -0500
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-05 02:12 -0500
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-05 02:26 -0500
Re: Three more weeks of UNIX ronb <ronbNOSPAM@gmail.com> - 2015-09-05 21:21 +0000
Re: Three more weeks of UNIX Nobody <nobody@invalid.com> - 2015-09-07 04:46 -0500
Re: Three more weeks of UNIX DFS <nospam@dfs.com> - 2015-09-07 10:18 -0400
Re: Three more weeks of UNIX cc <scatnubbs@hotmail.com> - 2015-09-03 04:27 -0700
Re: Three more weeks of UNIX DFS <nospam@dfs.com> - 2015-09-03 09:26 -0400
Re: Three more weeks of UNIX "A.M" <.m@nsn.s> - 2015-09-03 10:37 -0400
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-02 20:40 +0200
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-02 21:17 +0200
Snit Michael Glasser unable to do simple search Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-02 23:02 +0200
Re: Snit Michael Glasser unable to do simple search hifye <hifye@humanoid.net> - 2015-09-02 17:10 -0400
Re: Snit Michael Glasser unable to do simple search Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-03 01:09 +0200
Re: Peter Köhlmann admits he has no clue what he is talking about "A.M" <.m@nsn.s> - 2015-09-02 17:50 -0400
Re: Peter Köhlmann admits he has no clue what he is talking about Nobody <nobody@invalid.com> - 2015-09-05 01:17 -0500
Re: Three more weeks of UNIX JEDIDIAH <jedi@nomad.mishnet> - 2015-09-03 12:02 -0500
Re: Three more weeks of UNIX chrisv <chrisv@nospam.invalid> - 2015-09-03 13:02 -0500
Re: Three more weeks of UNIX JEDIDIAH <jedi@nomad.mishnet> - 2015-09-03 13:16 -0500
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-02 20:42 +0000
Re: Three more weeks of UNIX John Gohde <john.h.gohde@gmail.com> - 2015-09-02 09:08 -0700
Re: Three more weeks of UNIX Peter Köhlmann <peter-koehlmann@t-online.de> - 2015-09-02 20:35 +0200
Re: Three more weeks of UNIX dunno <dunno@dunno.dunno> - 2015-09-03 00:12 +0000
Re: Three more weeks of UNIX dunno <dunno@dunno.dunno> - 2015-09-03 01:07 +0000
Re: Three more weeks of UNIX dunno <dunno@dunno.dunno> - 2015-09-03 01:39 +0000
Re: Three more weeks of UNIX cc <scatnubbs@hotmail.com> - 2015-09-03 04:28 -0700
Re: Three more weeks of UNIX Debbie Ballard <rex.ballard@gmail.com> - 2015-09-03 21:10 -0700
Re: Three more weeks of UNIX owl <owl@rooftop.invalid> - 2015-09-04 04:55 +0000
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Snit <usenet@gallopinginsanity.com> |
|---|---|
| Date | 2015-09-08 08:02 -0700 |
| Message-ID | <D214468B.5AFF2%usenet@gallopinginsanity.com> |
| In reply to | #319612 |
On 9/8/15, 6:30 AM, in article msmnu7$66j$1@news.albasani.net, "Melzzzzz" <mel@zzzzz.com> wrote: > On 9/8/15 2:42 PM, chrisv wrote: >> Melzzzzz wrote: >> >>> Nope, nobody bothered to write this one seems to me. wkhtmltopdf >>> is done and everybody is satisfied ;p >> >> Well, let's face it, there's no way that the 2% of the market that >> uses GNU/Linux is always going to have the most and best applications >> written for it. In fact, it usually will not. >> >> Believe it or not, some filthy Linux-haters have claimed that this >> means that GNU/Linux users have less "freedom" than Windows users! >> > I was not fair to wkhtmltopdf. I looked source code and it seems fine. > Culprit was network speed. Snit has 50mbps I have 8mbps and owl 12mbps I > think. No wonder Snit won ;) > OS X did better not just on speed, which could be from network speed, but also on making output where you can select the text and look up an ingredient. Still, it was a fun - if somewhat overdone - challenge. Also amusing how the Mac was able to handle it so well Peter was convinced, and likely still is, that even with absolute video proof it was somehow faked. The Mac was able to handle the task so well Peter literally could not believe it. -- * OS X / Linux: What is a file? <http://youtu.be/_dMbXGLW9PI> * Mint MATE Trash, Panel, Menu: <http://youtu.be/C0y74FIf7uE> * Mint KDE working with folders: <http://youtu.be/7C9nvniOoE0> * Mint KDE creating files: <http://youtu.be/N7-fZJaJUv8> * Mint KDE help: <http://youtu.be/3ikizUd3sa8> * Mint KDE general navigation: <http://youtu.be/t9y14yZtQuI> * Mint KDE bugs or Easter eggs? <http://youtu.be/CU-whJQvtfA> * Easy on OS X / Hard on Linux: <http://youtu.be/D3BPWANQoIk> * OS / Word Processor Comparison: <http://youtu.be/w6Qcl-w7s5c>
[toc] | [prev] | [next] | [standalone]
| From | "A.M" <.m@nsn.s> |
|---|---|
| Date | 2015-09-08 12:10 -0400 |
| Message-ID | <msn16k$egn$1@dont-email.me> |
| In reply to | #319616 |
On 2015-09-08 11:02 AM, Snit wrote: > On 9/8/15, 6:30 AM, in article msmnu7$66j$1@news.albasani.net, "Melzzzzz" > <mel@zzzzz.com> wrote: > >> On 9/8/15 2:42 PM, chrisv wrote: >>> Melzzzzz wrote: >>> >>>> Nope, nobody bothered to write this one seems to me. wkhtmltopdf >>>> is done and everybody is satisfied ;p >>> >>> Well, let's face it, there's no way that the 2% of the market that >>> uses GNU/Linux is always going to have the most and best applications >>> written for it. In fact, it usually will not. >>> >>> Believe it or not, some filthy Linux-haters have claimed that this >>> means that GNU/Linux users have less "freedom" than Windows users! >>> >> I was not fair to wkhtmltopdf. I looked source code and it seems fine. >> Culprit was network speed. Snit has 50mbps I have 8mbps and owl 12mbps I >> think. No wonder Snit won ;) >> > OS X did better not just on speed, which could be from network speed, but > also on making output where you can select the text and look up an > ingredient. > > Still, it was a fun - if somewhat overdone - challenge. Also amusing how the > Mac was able to handle it so well Peter was convinced, and likely still is, > that even with absolute video proof it was somehow faked. The Mac was able > to handle the task so well Peter literally could not believe it. Peter the Klöwn is not a real human being; he is a robot programmed to deny that anything not based on Linux can be any good. He automatically scours the Internet looking for pro-Windows or pro-OS X statements and automatically says the opposite. He makes sure to finish every one of the posts with an insult to give people the impression that he's a real human being. -- A.M
[toc] | [prev] | [next] | [standalone]
| From | Snit <usenet@gallopinginsanity.com> |
|---|---|
| Date | 2015-09-08 09:17 -0700 |
| Message-ID | <D2145843.5B037%usenet@gallopinginsanity.com> |
| In reply to | #319626 |
On 9/8/15, 9:10 AM, in article msn16k$egn$1@dont-email.me, "A.M" <.m@nsn.s> wrote: > On 2015-09-08 11:02 AM, Snit wrote: >> On 9/8/15, 6:30 AM, in article msmnu7$66j$1@news.albasani.net, "Melzzzzz" >> <mel@zzzzz.com> wrote: >> >>> On 9/8/15 2:42 PM, chrisv wrote: >>>> Melzzzzz wrote: >>>> >>>>> Nope, nobody bothered to write this one seems to me. wkhtmltopdf >>>>> is done and everybody is satisfied ;p >>>> >>>> Well, let's face it, there's no way that the 2% of the market that >>>> uses GNU/Linux is always going to have the most and best applications >>>> written for it. In fact, it usually will not. >>>> >>>> Believe it or not, some filthy Linux-haters have claimed that this >>>> means that GNU/Linux users have less "freedom" than Windows users! >>>> >>> I was not fair to wkhtmltopdf. I looked source code and it seems fine. >>> Culprit was network speed. Snit has 50mbps I have 8mbps and owl 12mbps I >>> think. No wonder Snit won ;) >>> >> OS X did better not just on speed, which could be from network speed, but >> also on making output where you can select the text and look up an >> ingredient. >> >> Still, it was a fun - if somewhat overdone - challenge. Also amusing how the >> Mac was able to handle it so well Peter was convinced, and likely still is, >> that even with absolute video proof it was somehow faked. The Mac was able >> to handle the task so well Peter literally could not believe it. > > Peter the Klöwn is not a real human being; he is a robot programmed to > deny that anything not based on Linux can be any good. He automatically > scours the Internet looking for pro-Windows or pro-OS X statements and > automatically says the opposite. He makes sure to finish every one of > the posts with an insult to give people the impression that he's a real > human being. > Pretty much. -- * OS X / Linux: What is a file? <http://youtu.be/_dMbXGLW9PI> * Mint MATE Trash, Panel, Menu: <http://youtu.be/C0y74FIf7uE> * Mint KDE working with folders: <http://youtu.be/7C9nvniOoE0> * Mint KDE creating files: <http://youtu.be/N7-fZJaJUv8> * Mint KDE help: <http://youtu.be/3ikizUd3sa8> * Mint KDE general navigation: <http://youtu.be/t9y14yZtQuI> * Mint KDE bugs or Easter eggs? <http://youtu.be/CU-whJQvtfA> * Easy on OS X / Hard on Linux: <http://youtu.be/D3BPWANQoIk> * OS / Word Processor Comparison: <http://youtu.be/w6Qcl-w7s5c>
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2015-09-05 22:53 +0000 |
| Message-ID | <sdfmv93.kid@rooftop.invalid> |
| In reply to | #319198 |
Melzzzzz <mel@zzzzz.com> wrote:
> On Sat, 05 Sep 2015 14:19:26 -0700
> Snit <usenet@gallopinginsanity.com> wrote:
>> On 9/5/15, 2:14 PM, in article 20150905231428.4d151511@maxa-pc,
>> "Melzzzzz" <mel@zzzzz.com> wrote:
>>
>> >> That one above pulls from these (I think that's all :):
>> >>
>> >> anon@sandpit:~$ cat dogetrecipes.sh
>> >> #!/bin/sh
>> >> for i in `./getrecipes.sh`; do echo
>> >> "http://allrecipes.com"$i"print/"; done
>> >>
>> >> anon@sandpit:~$ cat getrecipes.sh
>> >> #!/bin/sh
>> >> parallel --no-notice -P 3 -N3 wget -q {1} {2} {3} ::: \
>> >> allrecipes.com -O one.html \
>> >> allrecipes.com/?page=2 -O two.html \
>> >> allrecipes.com/?page=3 -O three.html
>> >>
>> >> cat one.html two.html three.html > recipes.html
>> >>
>> >>
>> >> grep /recipe/ recipes.html |\
>> >> perl -e 'while(<>){ $x=$_;$x=~s/^.*<a href=\"//g;
>> >> $x=~s/\".*//g;print $x;}'|\ uniq
>> >>
>> >>
>> >>
>> >
>> > I have made script just to download files and I might add that it
>> > downloads *far less* then through wkhtmltopdf. I guess that tool
>> > downloads more even you have predownloaded initial files.
>> > I watched network activity and it is at maximum all the time
>> > conversion works, but I didn't try conversion tool on local files.
>> > I guess culprit is that tool downloads something more, question is
>> > what?
>>
>> Do not know - but Owl said he tried it on local files as well.
>>
>> I still do not know why he does not just use a different choice for
>> the download / conversion. That one seems to suck... so use something
>> else.
>>
>>
> Look it is impossible to take 1 second to convert file to pdf
> no matter how inefficient. Tool downloads something from net
> no matter what...
> As I said, download of print pages takes 12 secs no matter how
> inefficient conversion shouldn't took more than additional 12-20 secs .
> It is downloading something *huge*.
Testing shows that it *is* making network connections on those local
files. Hand-crafted local files making no network connections, so it
is not anything evil in wkhtmltopdf itself; it is just following html
on those particular pages. I see some akamai stuff, some windstream
stuff out of Arkansas, some other connection I didn't follow.
It is *still* making unreasonably large PDFs though.and that probably
has something to do with this issue that was present on OS X version:
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/1747
<quote>
wkhtmltopdf 0.12.0-OSX: Massively large PDF file size and non-selectable
text #1747
</quote>
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/1695#issuecomment-42554576
<quote>
We are currently working on OS X builds. The problem you are facing has
most probably nothing to do with images but with fonts. The current 64Bit
builds availabe for OS X are not yet able to embed fonts so they are
rasterizing every single character to a vector outline. That leads to
a massive increase in file size, especially with sites like yours that
have a lot of text. You can try this 32Bit build but please remember
that it is completely unofficial and unsupported yet, and I don't plan
to keep it available there forever. If --lowquality doesn't work with
this build then maybe re-opening this issue is worth considering, but
it's up to @ashkulz to decide.
</quote>
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-09-06 01:00 +0200 |
| Message-ID | <20150906010038.21efc34c@maxa-pc> |
| In reply to | #319202 |
On Sat, 5 Sep 2015 22:53:58 +0000 (UTC)
owl <owl@rooftop.invalid> wrote:
> Melzzzzz <mel@zzzzz.com> wrote:
> > On Sat, 05 Sep 2015 14:19:26 -0700
> > Snit <usenet@gallopinginsanity.com> wrote:
>
> >> On 9/5/15, 2:14 PM, in article 20150905231428.4d151511@maxa-pc,
> >> "Melzzzzz" <mel@zzzzz.com> wrote:
> >>
> >> >> That one above pulls from these (I think that's all :):
> >> >>
> >> >> anon@sandpit:~$ cat dogetrecipes.sh
> >> >> #!/bin/sh
> >> >> for i in `./getrecipes.sh`; do echo
> >> >> "http://allrecipes.com"$i"print/"; done
> >> >>
> >> >> anon@sandpit:~$ cat getrecipes.sh
> >> >> #!/bin/sh
> >> >> parallel --no-notice -P 3 -N3 wget -q {1} {2} {3} ::: \
> >> >> allrecipes.com -O one.html \
> >> >> allrecipes.com/?page=2 -O two.html \
> >> >> allrecipes.com/?page=3 -O three.html
> >> >>
> >> >> cat one.html two.html three.html > recipes.html
> >> >>
> >> >>
> >> >> grep /recipe/ recipes.html |\
> >> >> perl -e 'while(<>){ $x=$_;$x=~s/^.*<a href=\"//g;
> >> >> $x=~s/\".*//g;print $x;}'|\ uniq
> >> >>
> >> >>
> >> >>
> >> >
> >> > I have made script just to download files and I might add that it
> >> > downloads *far less* then through wkhtmltopdf. I guess that tool
> >> > downloads more even you have predownloaded initial files.
> >> > I watched network activity and it is at maximum all the time
> >> > conversion works, but I didn't try conversion tool on local
> >> > files. I guess culprit is that tool downloads something more,
> >> > question is what?
> >>
> >> Do not know - but Owl said he tried it on local files as well.
> >>
> >> I still do not know why he does not just use a different choice for
> >> the download / conversion. That one seems to suck... so use
> >> something else.
> >>
> >>
>
> > Look it is impossible to take 1 second to convert file to pdf
> > no matter how inefficient. Tool downloads something from net
> > no matter what...
> > As I said, download of print pages takes 12 secs no matter how
> > inefficient conversion shouldn't took more than additional 12-20
> > secs . It is downloading something *huge*.
>
> Testing shows that it *is* making network connections on those local
> files. Hand-crafted local files making no network connections, so it
> is not anything evil in wkhtmltopdf itself; it is just following html
> on those particular pages. I see some akamai stuff, some windstream
> stuff out of Arkansas, some other connection I didn't follow.
There is definitely something evil. It takes *much more* data than, say,
wget.
>
> It is *still* making unreasonably large PDFs though.and that probably
> has something to do with this issue that was present on OS X version:
Hard disks have more than 100mb/s write speed these days. Also Linux
has writeback cache which makes writes instant.
Have you checked `user` vs `real` time? It shows low user and high real.
All in all something on that print pages makes wkhtmltopdf downloading
like crazy, while wget do not.
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2015-09-07 00:10 +0000 |
| Message-ID | <55ecd5e0$0$19793$c3e8da3$3a1a2348@news.astraweb.com> |
| In reply to | #319206 |
On Sun, 06 Sep 2015 01:00:38 +0200, Melzzzzz wrote:
> On Sat, 5 Sep 2015 22:53:58 +0000 (UTC)
> owl <owl@rooftop.invalid> wrote:
>
>> Melzzzzz <mel@zzzzz.com> wrote:
>> > On Sat, 05 Sep 2015 14:19:26 -0700 Snit
>> > <usenet@gallopinginsanity.com> wrote:
>>
>> >> On 9/5/15, 2:14 PM, in article 20150905231428.4d151511@maxa-pc,
>> >> "Melzzzzz" <mel@zzzzz.com> wrote:
>> >>
>> >> >> That one above pulls from these (I think that's all :):
>> >> >>
>> >> >> anon@sandpit:~$ cat dogetrecipes.sh #!/bin/sh for i in
>> >> >> `./getrecipes.sh`; do echo "http://allrecipes.com"$i"print/";
>> >> >> done
>> >> >>
>> >> >> anon@sandpit:~$ cat getrecipes.sh #!/bin/sh parallel --no-notice
>> >> >> -P 3 -N3 wget -q {1} {2} {3} ::: \
>> >> >> allrecipes.com -O one.html \
>> >> >> allrecipes.com/?page=2 -O two.html \ allrecipes.com/?page=3 -O
>> >> >> three.html
>> >> >>
>> >> >> cat one.html two.html three.html > recipes.html
>> >> >>
>> >> >>
>> >> >> grep /recipe/ recipes.html |\
>> >> >> perl -e 'while(<>){ $x=$_;$x=~s/^.*<a href=\"//g;
>> >> >> $x=~s/\".*//g;print $x;}'|\ uniq
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> > I have made script just to download files and I might add that it
>> >> > downloads *far less* then through wkhtmltopdf. I guess that tool
>> >> > downloads more even you have predownloaded initial files.
>> >> > I watched network activity and it is at maximum all the time
>> >> > conversion works, but I didn't try conversion tool on local files.
>> >> > I guess culprit is that tool downloads something more, question is
>> >> > what?
>> >>
>> >> Do not know - but Owl said he tried it on local files as well.
>> >>
>> >> I still do not know why he does not just use a different choice for
>> >> the download / conversion. That one seems to suck... so use
>> >> something else.
>> >>
>> >>
>> >>
>> > Look it is impossible to take 1 second to convert file to pdf no
>> > matter how inefficient. Tool downloads something from net no matter
>> > what...
>> > As I said, download of print pages takes 12 secs no matter how
>> > inefficient conversion shouldn't took more than additional 12-20 secs
>> > . It is downloading something *huge*.
>>
>> Testing shows that it *is* making network connections on those local
>> files. Hand-crafted local files making no network connections, so it
>> is not anything evil in wkhtmltopdf itself; it is just following html
>> on those particular pages. I see some akamai stuff, some windstream
>> stuff out of Arkansas, some other connection I didn't follow.
>
> There is definitely something evil. It takes *much more* data than, say,
> wget.
When you guys are using wget to make a local archive, are you passing it
the "--convert-links" parameter? Might help.
(See the man page for more information.)
>
>
>> It is *still* making unreasonably large PDFs though.and that probably
>> has something to do with this issue that was present on OS X version:
> Hard disks have more than 100mb/s write speed these days. Also Linux has
> writeback cache which makes writes instant.
> Have you checked `user` vs `real` time? It shows low user and high real.
> All in all something on that print pages makes wkhtmltopdf downloading
> like crazy, while wget do not.
--
-v
"Yes you can create hotkeys by the dozen if you like...."
Husse Jun 16 2007
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <melz@zzzzz.com> |
|---|---|
| Date | 2015-09-07 02:12 +0200 |
| Message-ID | <20150907021226.65525afd@maxa-pc> |
| In reply to | #319421 |
On 07 Sep 2015 00:10:08 GMT
vallor <vallor@cultnix.org> wrote:
> On Sun, 06 Sep 2015 01:00:38 +0200, Melzzzzz wrote:
>
> > On Sat, 5 Sep 2015 22:53:58 +0000 (UTC)
> > owl <owl@rooftop.invalid> wrote:
> >
> >> Melzzzzz <mel@zzzzz.com> wrote:
> >> > On Sat, 05 Sep 2015 14:19:26 -0700 Snit
> >> > <usenet@gallopinginsanity.com> wrote:
> >>
> >> >> On 9/5/15, 2:14 PM, in article 20150905231428.4d151511@maxa-pc,
> >> >> "Melzzzzz" <mel@zzzzz.com> wrote:
> >> >>
> >> >> >> That one above pulls from these (I think that's all :):
> >> >> >>
> >> >> >> anon@sandpit:~$ cat dogetrecipes.sh #!/bin/sh for i in
> >> >> >> `./getrecipes.sh`; do echo "http://allrecipes.com"$i"print/";
> >> >> >> done
> >> >> >>
> >> >> >> anon@sandpit:~$ cat getrecipes.sh #!/bin/sh parallel
> >> >> >> --no-notice -P 3 -N3 wget -q {1} {2} {3} ::: \
> >> >> >> allrecipes.com -O one.html \
> >> >> >> allrecipes.com/?page=2 -O two.html \ allrecipes.com/?page=3
> >> >> >> -O three.html
> >> >> >>
> >> >> >> cat one.html two.html three.html > recipes.html
> >> >> >>
> >> >> >>
> >> >> >> grep /recipe/ recipes.html |\
> >> >> >> perl -e 'while(<>){ $x=$_;$x=~s/^.*<a href=\"//g;
> >> >> >> $x=~s/\".*//g;print $x;}'|\ uniq
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> > I have made script just to download files and I might add
> >> >> > that it downloads *far less* then through wkhtmltopdf. I
> >> >> > guess that tool downloads more even you have predownloaded
> >> >> > initial files. I watched network activity and it is at
> >> >> > maximum all the time conversion works, but I didn't try
> >> >> > conversion tool on local files. I guess culprit is that tool
> >> >> > downloads something more, question is what?
> >> >>
> >> >> Do not know - but Owl said he tried it on local files as well.
> >> >>
> >> >> I still do not know why he does not just use a different choice
> >> >> for the download / conversion. That one seems to suck... so use
> >> >> something else.
> >> >>
> >> >>
> >> >>
> >> > Look it is impossible to take 1 second to convert file to pdf no
> >> > matter how inefficient. Tool downloads something from net no
> >> > matter what...
> >> > As I said, download of print pages takes 12 secs no matter how
> >> > inefficient conversion shouldn't took more than additional 12-20
> >> > secs . It is downloading something *huge*.
> >>
> >> Testing shows that it *is* making network connections on those
> >> local files. Hand-crafted local files making no network
> >> connections, so it is not anything evil in wkhtmltopdf itself; it
> >> is just following html on those particular pages. I see some
> >> akamai stuff, some windstream stuff out of Arkansas, some other
> >> connection I didn't follow.
> >
> > There is definitely something evil. It takes *much more* data than,
> > say, wget.
>
> When you guys are using wget to make a local archive, are you passing
> it the "--convert-links" parameter? Might help.
Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Peter Köhlmann <peter-koehlmann@t-online.de> |
|---|---|
| Date | 2015-09-06 01:04 +0200 |
| Message-ID | <msfsap$lqu$1@dont-email.me> |
| In reply to | #319202 |
owl wrote:
> Melzzzzz <mel@zzzzz.com> wrote:
>> On Sat, 05 Sep 2015 14:19:26 -0700
>> Snit <usenet@gallopinginsanity.com> wrote:
>
>>> On 9/5/15, 2:14 PM, in article 20150905231428.4d151511@maxa-pc,
>>> "Melzzzzz" <mel@zzzzz.com> wrote:
>>>
>>> >> That one above pulls from these (I think that's all :):
>>> >>
>>> >> anon@sandpit:~$ cat dogetrecipes.sh
>>> >> #!/bin/sh
>>> >> for i in `./getrecipes.sh`; do echo
>>> >> "http://allrecipes.com"$i"print/"; done
>>> >>
>>> >> anon@sandpit:~$ cat getrecipes.sh
>>> >> #!/bin/sh
>>> >> parallel --no-notice -P 3 -N3 wget -q {1} {2} {3} ::: \
>>> >> allrecipes.com -O one.html \
>>> >> allrecipes.com/?page=2 -O two.html \
>>> >> allrecipes.com/?page=3 -O three.html
>>> >>
>>> >> cat one.html two.html three.html > recipes.html
>>> >>
>>> >>
>>> >> grep /recipe/ recipes.html |\
>>> >> perl -e 'while(<>){ $x=$_;$x=~s/^.*<a href=\"//g;
>>> >> $x=~s/\".*//g;print $x;}'|\ uniq
>>> >>
>>> >>
>>> >>
>>> >
>>> > I have made script just to download files and I might add that it
>>> > downloads *far less* then through wkhtmltopdf. I guess that tool
>>> > downloads more even you have predownloaded initial files.
>>> > I watched network activity and it is at maximum all the time
>>> > conversion works, but I didn't try conversion tool on local files.
>>> > I guess culprit is that tool downloads something more, question is
>>> > what?
>>>
>>> Do not know - but Owl said he tried it on local files as well.
>>>
>>> I still do not know why he does not just use a different choice for
>>> the download / conversion. That one seems to suck... so use something
>>> else.
>>>
>>>
>
>> Look it is impossible to take 1 second to convert file to pdf
>> no matter how inefficient. Tool downloads something from net
>> no matter what...
>> As I said, download of print pages takes 12 secs no matter how
>> inefficient conversion shouldn't took more than additional 12-20 secs .
>> It is downloading something *huge*.
>
> Testing shows that it *is* making network connections on those local
> files. Hand-crafted local files making no network connections, so it
> is not anything evil in wkhtmltopdf itself; it is just following html
> on those particular pages. I see some akamai stuff, some windstream
> stuff out of Arkansas, some other connection I didn't follow.
Well, it should do that.
It uses WebKit to render internally the website
To do that it has to follow the links
> It is *still* making unreasonably large PDFs though.and that probably
> has something to do with this issue that was present on OS X version:
Could be.
It could also be because Snit Michael Glasser uses Paparazzi. He can tell it
to use user selectable sizes which are way smaller then the standard sizes.
wkhtml2pdf uses by default A4 paper size
[toc] | [prev] | [next] | [standalone]
| From | Snit <usenet@gallopinginsanity.com> |
|---|---|
| Date | 2015-09-05 12:45 -0700 |
| Message-ID | <D210945C.5A066%usenet@gallopinginsanity.com> |
| In reply to | #319156 |
On 9/5/15, 12:13 PM, in article fasdnmv83.asdi@rooftop.invalid, "owl"
<owl@rooftop.invalid> wrote:
> Melzzzzz <mel@zzzzz.com> wrote:
>> On Sat, 5 Sep 2015 19:58:35 +0200
>> Melzzzzz <mel@zzzzz.com> wrote:
>
>>> On Sat, 5 Sep 2015 16:59:50 +0000 (UTC)
>>> owl <owl@rooftop.invalid> wrote:
>>>
>>>> Snit <usenet@gallopinginsanity.com> wrote:
>>>>> On 9/4/15, 12:39 AM, in article fad.viz0@rooftop.invalid, "owl"
>>>>> <owl@rooftop.invalid> wrote:
>>>>
>>>>> ...
>>>>>>> I am responsible only for my actions, and my actions are honest.
>>>>>>> If you wish to believe my weird "fan" club about my "unquotable
>>>>>>> lies" then so be it.
>>>>>>
>>>>>>> And you have still not shared your script. Why not?
>>>>>>
>>>>>> I may post it tomorrow. I need to try a few things first.
>>>>
>>>>> You are spending a LOT more time on yours than I did mine...
>>>>
>>>> Because there's apparently a bug in wkhtmltopdf. (Huge file sizes).
>>>>
>>>>> but yours will
>>>>> likely also be a lot "cleaner". Mine is a bit of a mess, but as we
>>>>> saw it works well.
>>>>
>>>>> Once you share yours I will make my video public:
>>>>> <https://youtu.be/TH3rKDAAvsc>
>>>>
>>>>> Looking at my script again I could have made it a LOT easier.
>>>>> Might test that tomorrow and then have a MUCH better script. But
>>>>> whatever... it works. :)
>>>>
>>>> The code should work on OS X with the zenity stuff commented out.
>>>> Curious if the wkhtmltopdf bug is still present in the OS X
>>>> version. At the time it was mentioned, the thing apparently
>>>> worked fine for Linux. Now I'm seeing what appears to be
>>>> that same situation that was described for the OS X version,
>>>> but on Linux.
>>>
>>> Have you tried with --lowquality option?
>>>
>>>>
>>>> #!/bin/sh
>>>>
>>>> date=`date`
>>>> #zenity --notification --text="starting... ${date}"
>>>> stime=`date +%s`
>>>>
>>>> if [ ! -e ~/Recipes ];then
>>>> mkdir ~/Recipes
>>>> fi
>>>>
>>>> html="$(parallel --no-notice -P 3 -N 3 wget -q {1} {2} {3} ::: \
>>>> allrecipes.com -O - \
>>>> allrecipes.com/?page=2 -O - \
>>>> allrecipes.com/?page=3 -O -)"
>>>>
>>>> recipelines=$( echo "${html}" |grep /recipe/ \
>>>> |perl -e 'while(<>){ $x=$_;$x=~s/^.*<a href=\"//g;
>>>> $x=~s/\".*//g;print $x;}' \ |uniq)
>>>>
>>>> filenames=$(echo "${recipelines}" |cut -f4 -d'/')
>>>>
>>>> parallel --no-notice -P 8 -N 1 --xapply \
>>>
>>> you should do all at once to hide download latencies....
>>>
>>>> wkhtmltopdf -q -n \
>>>> http://allrecipes.com/{1}/print/ /home/anon/Recipes/{2}.pdf \
>>>> ::: ${recipelines} ::: ${filenames}
>>>
>>> try --lowquality option.
>>>
>
>> My link is saturated with just 4 page downloads and it is not
>> wkhtml2pdf issue rather network speed. I get 1.4 secs per file,
>> but it is not because I do some processing, rather my 8mbit link is
>> saturated...
>
> I initially grabbed all the html files, and then processed after that.
> Still took 1-1.5 seconds to generate the PDFs from local html.
>
Even my slower tool is faster than that... and both produce output where you
can select the text. This is handy if you want to quickly see what an
ingredient is or the like. Heck, if I did this a lot I could set up an
action that worked only in Preview to look up alternate ingredients. I do
that fairly often when using foreign spices I do not have... or mixes of
spices I can make myself.
--
* OS X / Linux: What is a file? <http://youtu.be/_dMbXGLW9PI>
* Mint MATE Trash, Panel, Menu: <http://youtu.be/C0y74FIf7uE>
* Mint KDE working with folders: <http://youtu.be/7C9nvniOoE0>
* Mint KDE creating files: <http://youtu.be/N7-fZJaJUv8>
* Mint KDE help: <http://youtu.be/3ikizUd3sa8>
* Mint KDE general navigation: <http://youtu.be/t9y14yZtQuI>
* Mint KDE bugs or Easter eggs? <http://youtu.be/CU-whJQvtfA>
* Easy on OS X / Hard on Linux: <http://youtu.be/D3BPWANQoIk>
* OS / Word Processor Comparison: <http://youtu.be/w6Qcl-w7s5c>
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2015-09-05 19:48 +0000 |
| Message-ID | <fasdnmv.3jif@rooftop.invalid> |
| In reply to | #319161 |
Snit <usenet@gallopinginsanity.com> wrote:
> On 9/5/15, 12:13 PM, in article fasdnmv83.asdi@rooftop.invalid, "owl"
> <owl@rooftop.invalid> wrote:
>> Melzzzzz <mel@zzzzz.com> wrote:
>>> On Sat, 5 Sep 2015 19:58:35 +0200
>>> Melzzzzz <mel@zzzzz.com> wrote:
>>
>>>> On Sat, 5 Sep 2015 16:59:50 +0000 (UTC)
>>>> owl <owl@rooftop.invalid> wrote:
>>>>
>>>>> Snit <usenet@gallopinginsanity.com> wrote:
>>>>>> On 9/4/15, 12:39 AM, in article fad.viz0@rooftop.invalid, "owl"
>>>>>> <owl@rooftop.invalid> wrote:
>>>>>
>>>>>> ...
>>>>>>>> I am responsible only for my actions, and my actions are honest.
>>>>>>>> If you wish to believe my weird "fan" club about my "unquotable
>>>>>>>> lies" then so be it.
>>>>>>>
>>>>>>>> And you have still not shared your script. Why not?
>>>>>>>
>>>>>>> I may post it tomorrow. I need to try a few things first.
>>>>>
>>>>>> You are spending a LOT more time on yours than I did mine...
>>>>>
>>>>> Because there's apparently a bug in wkhtmltopdf. (Huge file sizes).
>>>>>
>>>>>> but yours will
>>>>>> likely also be a lot "cleaner". Mine is a bit of a mess, but as we
>>>>>> saw it works well.
>>>>>
>>>>>> Once you share yours I will make my video public:
>>>>>> <https://youtu.be/TH3rKDAAvsc>
>>>>>
>>>>>> Looking at my script again I could have made it a LOT easier.
>>>>>> Might test that tomorrow and then have a MUCH better script. But
>>>>>> whatever... it works. :)
>>>>>
>>>>> The code should work on OS X with the zenity stuff commented out.
>>>>> Curious if the wkhtmltopdf bug is still present in the OS X
>>>>> version. At the time it was mentioned, the thing apparently
>>>>> worked fine for Linux. Now I'm seeing what appears to be
>>>>> that same situation that was described for the OS X version,
>>>>> but on Linux.
>>>>
>>>> Have you tried with --lowquality option?
>>>>
>>>>>
>>>>> #!/bin/sh
>>>>>
>>>>> date=`date`
>>>>> #zenity --notification --text="starting... ${date}"
>>>>> stime=`date +%s`
>>>>>
>>>>> if [ ! -e ~/Recipes ];then
>>>>> mkdir ~/Recipes
>>>>> fi
>>>>>
>>>>> html="$(parallel --no-notice -P 3 -N 3 wget -q {1} {2} {3} ::: \
>>>>> allrecipes.com -O - \
>>>>> allrecipes.com/?page=2 -O - \
>>>>> allrecipes.com/?page=3 -O -)"
>>>>>
>>>>> recipelines=$( echo "${html}" |grep /recipe/ \
>>>>> |perl -e 'while(<>){ $x=$_;$x=~s/^.*<a href=\"//g;
>>>>> $x=~s/\".*//g;print $x;}' \ |uniq)
>>>>>
>>>>> filenames=$(echo "${recipelines}" |cut -f4 -d'/')
>>>>>
>>>>> parallel --no-notice -P 8 -N 1 --xapply \
>>>>
>>>> you should do all at once to hide download latencies....
>>>>
>>>>> wkhtmltopdf -q -n \
>>>>> http://allrecipes.com/{1}/print/ /home/anon/Recipes/{2}.pdf \
>>>>> ::: ${recipelines} ::: ${filenames}
>>>>
>>>> try --lowquality option.
>>>>
>>
>>> My link is saturated with just 4 page downloads and it is not
>>> wkhtml2pdf issue rather network speed. I get 1.4 secs per file,
>>> but it is not because I do some processing, rather my 8mbit link is
>>> saturated...
>>
>> I initially grabbed all the html files, and then processed after that.
>> Still took 1-1.5 seconds to generate the PDFs from local html.
>>
> Even my slower tool is faster than that... and both produce output where you
> can select the text. This is handy if you want to quickly see what an
> ingredient is or the like. Heck, if I did this a lot I could set up an
> action that worked only in Preview to look up alternate ingredients. I do
> that fairly often when using foreign spices I do not have... or mixes of
> spices I can make myself.
Your tool has nothing to do with this problem.
[toc] | [prev] | [next] | [standalone]
| From | Snit <usenet@gallopinginsanity.com> |
|---|---|
| Date | 2015-09-05 13:20 -0700 |
| Message-ID | <D2109C83.5A084%usenet@gallopinginsanity.com> |
| In reply to | #319163 |
On 9/5/15, 12:48 PM, in article fasdnmv.3jif@rooftop.invalid, "owl" <owl@rooftop.invalid> wrote: >>>> My link is saturated with just 4 page downloads and it is not >>>> wkhtml2pdf issue rather network speed. I get 1.4 secs per file, >>>> but it is not because I do some processing, rather my 8mbit link is >>>> saturated... >>> >>> I initially grabbed all the html files, and then processed after that. >>> Still took 1-1.5 seconds to generate the PDFs from local html. >>> >> Even my slower tool is faster than that... and both produce output where you >> can select the text. This is handy if you want to quickly see what an >> ingredient is or the like. Heck, if I did this a lot I could set up an >> action that worked only in Preview to look up alternate ingredients. I do >> that fairly often when using foreign spices I do not have... or mixes of >> spices I can make myself. > > Your tool has nothing to do with this problem. What I am noting is that the download / conversion tools I am using produce PDFs that allow me to more easily work with the PDFs. I can edit them (say crossing out text), look up a word, etc. To me this is a pretty big advantage. If I had PDFs that looked much the same but were just images that would also sorta suck. -- * OS X / Linux: What is a file? <http://youtu.be/_dMbXGLW9PI> * Mint MATE Trash, Panel, Menu: <http://youtu.be/C0y74FIf7uE> * Mint KDE working with folders: <http://youtu.be/7C9nvniOoE0> * Mint KDE creating files: <http://youtu.be/N7-fZJaJUv8> * Mint KDE help: <http://youtu.be/3ikizUd3sa8> * Mint KDE general navigation: <http://youtu.be/t9y14yZtQuI> * Mint KDE bugs or Easter eggs? <http://youtu.be/CU-whJQvtfA> * Easy on OS X / Hard on Linux: <http://youtu.be/D3BPWANQoIk> * OS / Word Processor Comparison: <http://youtu.be/w6Qcl-w7s5c>
[toc] | [prev] | [next] | [standalone]
| From | Snit <usenet@gallopinginsanity.com> |
|---|---|
| Date | 2015-09-05 13:38 -0700 |
| Message-ID | <D210A0BD.5A08F%usenet@gallopinginsanity.com> |
| In reply to | #319144 |
On 9/5/15, 11:39 AM, in article 20150905203958.4639ce63@maxa-pc, "Melzzzzz" <mel@zzzzz.com> wrote: >> try --lowquality option. >> > > My link is saturated with just 4 page downloads and it is not > wkhtml2pdf issue rather network speed. I get 1.4 secs per file, > but it is not because I do some processing, rather my 8mbit link is > saturated... Try local files. On both Linux and OS X it seems wkhtml2pdf pretty much sucks. Glad I have two other choices. At least. Choice is good. -- * OS X / Linux: What is a file? <http://youtu.be/_dMbXGLW9PI> * Mint MATE Trash, Panel, Menu: <http://youtu.be/C0y74FIf7uE> * Mint KDE working with folders: <http://youtu.be/7C9nvniOoE0> * Mint KDE creating files: <http://youtu.be/N7-fZJaJUv8> * Mint KDE help: <http://youtu.be/3ikizUd3sa8> * Mint KDE general navigation: <http://youtu.be/t9y14yZtQuI> * Mint KDE bugs or Easter eggs? <http://youtu.be/CU-whJQvtfA> * Easy on OS X / Hard on Linux: <http://youtu.be/D3BPWANQoIk> * OS / Word Processor Comparison: <http://youtu.be/w6Qcl-w7s5c>
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2015-09-05 19:10 +0000 |
| Message-ID | <samnv993a.f@rooftop.invalid> |
| In reply to | #319132 |
Melzzzzz <mel@zzzzz.com> wrote:
> On Sat, 5 Sep 2015 16:59:50 +0000 (UTC)
> owl <owl@rooftop.invalid> wrote:
>> Snit <usenet@gallopinginsanity.com> wrote:
>> > On 9/4/15, 12:39 AM, in article fad.viz0@rooftop.invalid, "owl"
>> > <owl@rooftop.invalid> wrote:
>>
>> > ...
>> >>> I am responsible only for my actions, and my actions are honest.
>> >>> If you wish to believe my weird "fan" club about my "unquotable
>> >>> lies" then so be it.
>> >>
>> >>> And you have still not shared your script. Why not?
>> >>
>> >> I may post it tomorrow. I need to try a few things first.
>>
>> > You are spending a LOT more time on yours than I did mine...
>>
>> Because there's apparently a bug in wkhtmltopdf. (Huge file sizes).
>>
>> > but yours will
>> > likely also be a lot "cleaner". Mine is a bit of a mess, but as we
>> > saw it works well.
>>
>> > Once you share yours I will make my video public:
>> > <https://youtu.be/TH3rKDAAvsc>
>>
>> > Looking at my script again I could have made it a LOT easier. Might
>> > test that tomorrow and then have a MUCH better script. But
>> > whatever... it works. :)
>>
>> The code should work on OS X with the zenity stuff commented out.
>> Curious if the wkhtmltopdf bug is still present in the OS X
>> version. At the time it was mentioned, the thing apparently
>> worked fine for Linux. Now I'm seeing what appears to be
>> that same situation that was described for the OS X version,
>> but on Linux.
> Have you tried with --lowquality option?
>>
>> #!/bin/sh
>>
>> date=`date`
>> #zenity --notification --text="starting... ${date}"
>> stime=`date +%s`
>>
>> if [ ! -e ~/Recipes ];then
>> mkdir ~/Recipes
>> fi
>>
>> html="$(parallel --no-notice -P 3 -N 3 wget -q {1} {2} {3} ::: \
>> allrecipes.com -O - \
>> allrecipes.com/?page=2 -O - \
>> allrecipes.com/?page=3 -O -)"
>>
>> recipelines=$( echo "${html}" |grep /recipe/ \
>> |perl -e 'while(<>){ $x=$_;$x=~s/^.*<a href=\"//g;
>> $x=~s/\".*//g;print $x;}' \ |uniq)
>>
>> filenames=$(echo "${recipelines}" |cut -f4 -d'/')
>>
>> parallel --no-notice -P 8 -N 1 --xapply \
> you should do all at once to hide download latencies....
Tried it several ways. Downloading all at once, then running wkthtmltopdf
against local files, etc. The big factor is the processing html to pdf,
even parallelized on local files. Since download time was very small,
I thought to pull the html into variables and avoid tmpfile creation.
>> wkhtmltopdf -q -n \
>> http://allrecipes.com/{1}/print/ /home/anon/Recipes/{2}.pdf \
>> ::: ${recipelines} ::: ${filenames}
> try --lowquality option.
Been there done that. Doesn't help. It's how wkhtmltopdf is dealing
with fonts. I posted a link the other day about this same effect
(huge PDF file sizes) using wkhtmltopdf on OS X. I think it's somewhere
in this thread.
[toc] | [prev] | [next] | [standalone]
| From | Snit <usenet@gallopinginsanity.com> |
|---|---|
| Date | 2015-09-05 12:48 -0700 |
| Message-ID | <D2109525.5A068%usenet@gallopinginsanity.com> |
| In reply to | #319154 |
On 9/5/15, 12:10 PM, in article samnv993a.f@rooftop.invalid, "owl"
<owl@rooftop.invalid> wrote:
>> you should do all at once to hide download latencies....
>
> Tried it several ways. Downloading all at once, then running wkthtmltopdf
> against local files, etc. The big factor is the processing html to pdf,
> even parallelized on local files. Since download time was very small,
> I thought to pull the html into variables and avoid tmpfile creation.
>
>>> wkhtmltopdf -q -n \
>>> http://allrecipes.com/{1}/print/ /home/anon/Recipes/{2}.pdf \
>>> ::: ${recipelines} ::: ${filenames}
>
>> try --lowquality option.
>
> Been there done that. Doesn't help. It's how wkhtmltopdf is dealing
> with fonts. I posted a link the other day about this same effect
> (huge PDF file sizes) using wkhtmltopdf on OS X. I think it's somewhere
> in this thread.
Why not try a different tool? I tried a couple different ones... I liked
your ability to turn of JavaScript and my first (and faster) option does not
have that. My second one, which is still faster than yours, does have that
option.
I have run into an issue where my script is now crashing on me. Even went
back to an older copy and it crashes fairly often. I think it is tied to the
Automator Action of "Get Link URLs from Webpages". No idea why that would
crash... and need to test more to see if it is really that.
--
* OS X / Linux: What is a file? <http://youtu.be/_dMbXGLW9PI>
* Mint MATE Trash, Panel, Menu: <http://youtu.be/C0y74FIf7uE>
* Mint KDE working with folders: <http://youtu.be/7C9nvniOoE0>
* Mint KDE creating files: <http://youtu.be/N7-fZJaJUv8>
* Mint KDE help: <http://youtu.be/3ikizUd3sa8>
* Mint KDE general navigation: <http://youtu.be/t9y14yZtQuI>
* Mint KDE bugs or Easter eggs? <http://youtu.be/CU-whJQvtfA>
* Easy on OS X / Hard on Linux: <http://youtu.be/D3BPWANQoIk>
* OS / Word Processor Comparison: <http://youtu.be/w6Qcl-w7s5c>
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2015-09-05 19:53 +0000 |
| Message-ID | <sadfmv8.jivz@rooftop.invalid> |
| In reply to | #319162 |
Snit <usenet@gallopinginsanity.com> wrote:
> On 9/5/15, 12:10 PM, in article samnv993a.f@rooftop.invalid, "owl"
> <owl@rooftop.invalid> wrote:
>>> you should do all at once to hide download latencies....
>>
>> Tried it several ways. Downloading all at once, then running wkthtmltopdf
>> against local files, etc. The big factor is the processing html to pdf,
>> even parallelized on local files. Since download time was very small,
>> I thought to pull the html into variables and avoid tmpfile creation.
>>
>>>> wkhtmltopdf -q -n \
>>>> http://allrecipes.com/{1}/print/ /home/anon/Recipes/{2}.pdf \
>>>> ::: ${recipelines} ::: ${filenames}
>>
>>> try --lowquality option.
>>
>> Been there done that. Doesn't help. It's how wkhtmltopdf is dealing
>> with fonts. I posted a link the other day about this same effect
>> (huge PDF file sizes) using wkhtmltopdf on OS X. I think it's somewhere
>> in this thread.
> Why not try a different tool? I tried a couple different ones... I liked
> your ability to turn of JavaScript and my first (and faster) option does not
> have that. My second one, which is still faster than yours, does have that
> option.
> I have run into an issue where my script is now crashing on me. Even went
> back to an older copy and it crashes fairly often. I think it is tied to the
> Automator Action of "Get Link URLs from Webpages". No idea why that would
> crash... and need to test more to see if it is really that.
It's a Mac, right? 'nuff said.
[toc] | [prev] | [next] | [standalone]
| From | Snit <usenet@gallopinginsanity.com> |
|---|---|
| Date | 2015-09-05 13:26 -0700 |
| Message-ID | <D2109DE8.5A086%usenet@gallopinginsanity.com> |
| In reply to | #319167 |
On 9/5/15, 12:53 PM, in article sadfmv8.jivz@rooftop.invalid, "owl"
<owl@rooftop.invalid> wrote:
> Snit <usenet@gallopinginsanity.com> wrote:
>> On 9/5/15, 12:10 PM, in article samnv993a.f@rooftop.invalid, "owl"
>> <owl@rooftop.invalid> wrote:
>
>>>> you should do all at once to hide download latencies....
>>>
>>> Tried it several ways. Downloading all at once, then running wkthtmltopdf
>>> against local files, etc. The big factor is the processing html to pdf,
>>> even parallelized on local files. Since download time was very small,
>>> I thought to pull the html into variables and avoid tmpfile creation.
>>>
>>>>> wkhtmltopdf -q -n \
>>>>> http://allrecipes.com/{1}/print/ /home/anon/Recipes/{2}.pdf \
>>>>> ::: ${recipelines} ::: ${filenames}
>>>
>>>> try --lowquality option.
>>>
>>> Been there done that. Doesn't help. It's how wkhtmltopdf is dealing
>>> with fonts. I posted a link the other day about this same effect
>>> (huge PDF file sizes) using wkhtmltopdf on OS X. I think it's somewhere
>>> in this thread.
>
>> Why not try a different tool? I tried a couple different ones... I liked
>> your ability to turn of JavaScript and my first (and faster) option does not
>> have that. My second one, which is still faster than yours, does have that
>> option.
>
>> I have run into an issue where my script is now crashing on me. Even went
>> back to an older copy and it crashes fairly often. I think it is tied to the
>> Automator Action of "Get Link URLs from Webpages". No idea why that would
>> crash... and need to test more to see if it is really that.
>
> It's a Mac, right? 'nuff said.
>
:)
I added a 10 second pause after each step to test. Most certainly is the
"Get Links URLs from Webpages" action.
Only does it some times... though seems to be getting worse. And I find no
info on that online. Weird.
I do have an alternate method of grabbing the code and setting it to get the
URLs, but mine is SLOW on that... though if I played with it I am sure I
could speed it up.
--
* OS X / Linux: What is a file? <http://youtu.be/_dMbXGLW9PI>
* Mint MATE Trash, Panel, Menu: <http://youtu.be/C0y74FIf7uE>
* Mint KDE working with folders: <http://youtu.be/7C9nvniOoE0>
* Mint KDE creating files: <http://youtu.be/N7-fZJaJUv8>
* Mint KDE help: <http://youtu.be/3ikizUd3sa8>
* Mint KDE general navigation: <http://youtu.be/t9y14yZtQuI>
* Mint KDE bugs or Easter eggs? <http://youtu.be/CU-whJQvtfA>
* Easy on OS X / Hard on Linux: <http://youtu.be/D3BPWANQoIk>
* OS / Word Processor Comparison: <http://youtu.be/w6Qcl-w7s5c>
[toc] | [prev] | [next] | [standalone]
| From | Snit <usenet@gallopinginsanity.com> |
|---|---|
| Date | 2015-09-04 09:28 -0700 |
| Message-ID | <D20F14B3.59EE6%usenet@gallopinginsanity.com> |
| In reply to | #318915 |
On 9/4/15, 12:39 AM, in article fad.viz0@rooftop.invalid, "owl" <owl@rooftop.invalid> wrote: > Snit <usenet@gallopinginsanity.com> wrote: >> On 9/3/15, 9:34 PM, in article afdsmv8.kdi@rooftop.invalid, "owl" >> <owl@rooftop.invalid> wrote: > >> ... >>>>> The title bar was odd. >>> >>>> It is the standard Safari title bar. And you could see a script was running >>>> and, more importantly (to prove I was doing an actual conversion), that >>>> Paparrazi has a progress bar in the dock. >>> >>> Your reputation is also not my fault. > >> I am responsible only for my actions, and my actions are honest. If you wish >> to believe my weird "fan" club about my "unquotable lies" then so be it. > >> And you have still not shared your script. Why not? > > I may post it tomorrow. I need to try a few things first. OK, updated mine again... my filtering is still slow and absurd, but since it only adds a second to the processing, at most, might never fix it. Instead focused on output: <http://youtu.be/yG4ig_g1wyw> 48 seconds for 59 recipes 0.8 seconds per recipe * Small file sizes * Prettier output (similar to yours... no JavaScript) * Files named with each recipe name * Text fully is real text (though selection is a bit weird) Notice that my other scripts still work on the text: "Word Count" and "Look Up in Urban Dictionary" as well as standard services like the built in dictionary. This could come in handy if you opened a recipe and wanted to know what an ingredient you were not familiar with was or if a description used slang you were not familiar with, etc. Not shown on the video but strike through and highlighting works, as does Markup. As I have noted, ALL these things I talk about work when and where you need them on OS X (for the most part, anyway). -- * OS X / Linux: What is a file? <http://youtu.be/_dMbXGLW9PI> * Mint MATE Trash, Panel, Menu: <http://youtu.be/C0y74FIf7uE> * Mint KDE working with folders: <http://youtu.be/7C9nvniOoE0> * Mint KDE creating files: <http://youtu.be/N7-fZJaJUv8> * Mint KDE help: <http://youtu.be/3ikizUd3sa8> * Mint KDE general navigation: <http://youtu.be/t9y14yZtQuI> * Mint KDE bugs or Easter eggs? <http://youtu.be/CU-whJQvtfA> * Easy on OS X / Hard on Linux: <http://youtu.be/D3BPWANQoIk> * OS / Word Processor Comparison: <http://youtu.be/w6Qcl-w7s5c>
[toc] | [prev] | [next] | [standalone]
| From | owl <owl@rooftop.invalid> |
|---|---|
| Date | 2015-09-04 04:52 +0000 |
| Message-ID | <e0aa.3p@rooftop.invalid> |
| In reply to | #318892 |
Snit <usenet@gallopinginsanity.com> wrote: > On 9/3/15, 8:17 PM, in article D20E5B6D.59E5E%usenet@gallopinginsanity.com, > "Snit" <usenet@gallopinginsanity.com> wrote: >>>> Did you hardcode the URLs? If so that is sorta cheating I think... but wrote >>>> about it elsewhere that I see gray areas here. This is designed in a way >>>> that would work only with that site. >>> >>> For the three site pages, yeah. That's the only way to get them all. >>> Doesn't matter to me if we limit it to just the 20 on page 1. >> >> Oh, if we can hardcode the URLs then this is trivial (and, I think, >> cheating... but it is what I do for this example). Also modified mine to not >> use Pazarrazi but a different tool that allows me to turn off JavaScript (I >> like the way your printouts did not have some of my extra "stuff"). The >> other "tool" us an Automator action called "Download URLs as PDFs". Hmmmm, >> maybe silly I did not use that before. :) >> >> My files are still about the same size. >> >> I then edit the names so they look better (could do this with Paparrazi, >> too). I start roughly on the minute (half a second late, whatever) and get >> all 53 done, including name change, by 49 seconds (so I have gone up to >> about 0.9 seconds per recipe with my different download tool and other >> changes... but just playing around): >> >> <http://youtu.be/MuZM_wANG-k> >> >> On these ones links do not work, but it is real text (can select it and >> zooming in 800x it is still sharp) > Have tested again with Paparrazi: 60 files in 42 seconds. Seems pretty > consistent at about 0.7 seconds a file. > <http://youtu.be/vPaBI4pIl10> > The tool where I can turn JavaScript off seems to take a bit longer for the > conversion... about 0.8 to 0.9 seconds per file. Still a lot faster than > your 3 seconds or so. :) Mine is down to about 1.4 seconds per file now, but I need to find out why the files are so huge. I know that's what's causing the delay. Aside from the size, I can still probably trim the time down a bit just by recombining steps that I separated in order to keep track of all the nested pipes and computed argv[]. When you think about it, mine is taking twice as long to deal with 10 times the amount of data, so mine is actually 5 times faster than yours. :)
[toc] | [prev] | [next] | [standalone]
| From | Snit <usenet@gallopinginsanity.com> |
|---|---|
| Date | 2015-09-03 23:48 -0700 |
| Message-ID | <D20E8CCB.59E7C%usenet@gallopinginsanity.com> |
| In reply to | #318901 |
On 9/3/15, 9:52 PM, in article e0aa.3p@rooftop.invalid, "owl" <owl@rooftop.invalid> wrote: >>> I then edit the names so they look better (could do this with Paparrazi, >>> too). I start roughly on the minute (half a second late, whatever) and get >>> all 53 done, including name change, by 49 seconds (so I have gone up to >>> about 0.9 seconds per recipe with my different download tool and other >>> changes... but just playing around): >>> >>> <http://youtu.be/MuZM_wANG-k> >>> >>> On these ones links do not work, but it is real text (can select it and >>> zooming in 800x it is still sharp) > >> Have tested again with Paparrazi: 60 files in 42 seconds. Seems pretty >> consistent at about 0.7 seconds a file. > >> <http://youtu.be/vPaBI4pIl10> > >> The tool where I can turn JavaScript off seems to take a bit longer for the >> conversion... about 0.8 to 0.9 seconds per file. Still a lot faster than >> your 3 seconds or so. :) > > Mine is down to about 1.4 seconds per file now, but I need to find > out why the files are so huge. I know that's what's causing the delay. > Aside from the size, I can still probably trim the time down a bit > just by recombining steps that I separated in order to keep track > of all the nested pipes and computed argv[]. When you think about > it, mine is taking twice as long to deal with 10 times the amount > of data, so mine is actually 5 times faster than yours. :) Yours takes twice as long and ends up with files twice as big with no known benefits. OK, so we can both do your hand-picked task of downloading all such recipes as PDFs. What about my tasks? * The find a single recipe and both save and email a version where you add notes to it. Nobody spoke of what he would do - pretty much bail on the task and just send a URL and write notes in text. Now I know this can be done on Linux; save, open, edit, email. Just curious to see how you people would generally do it. A couple ways I might: <https://youtu.be/NPM_WldEBs0>. * Make a video, as you have been, but with cursor replacement / resizing (post production), window highlighting, zooming, arbitrary area highlighting. You have talked about this as being outside your area of expertise. Fair enough - but I wonder if anyone else in COLA is able. I doubt it. For me these were done just to show something else: <https://youtu.be/aSNpnYpmKag>. * Getting a WayBackArchive page and getting images of all links, the HTML validation and CSS validation from W3.org, and a link to the archive page, as I did here: <http://tmp.gallopinginsanity.com/sandman/sandman-archive.pdf>. This was easy to do BUT I used a rather pricey tool. Downside of OS X, that tool no longer works well with the current Mac (it crashes on Print or Save to PDF) and I am not willing to pay for an upgrade. I miss it though and might at some point. Would love to see you take a crack at the first and third, even if you cannot do the second. -- * OS X / Linux: What is a file? <http://youtu.be/_dMbXGLW9PI> * Mint MATE Trash, Panel, Menu: <http://youtu.be/C0y74FIf7uE> * Mint KDE working with folders: <http://youtu.be/7C9nvniOoE0> * Mint KDE creating files: <http://youtu.be/N7-fZJaJUv8> * Mint KDE help: <http://youtu.be/3ikizUd3sa8> * Mint KDE general navigation: <http://youtu.be/t9y14yZtQuI> * Mint KDE bugs or Easter eggs? <http://youtu.be/CU-whJQvtfA> * Easy on OS X / Hard on Linux: <http://youtu.be/D3BPWANQoIk> * OS / Word Processor Comparison: <http://youtu.be/w6Qcl-w7s5c>
[toc] | [prev] | [next] | [standalone]
| From | dunno <dunno@dunno.dunno> |
|---|---|
| Date | 2015-09-04 05:13 +0000 |
| Message-ID | <msb9aa$sr6$1@news.mixmin.net> |
| In reply to | #318892 |
owl <owl@rooftop.invalid> wrote: > Snit <usenet@gallopinginsanity.com> wrote: >> On 9/3/15, 6:38 PM, in article fasmnvc93.jdif@rooftop.invalid, "owl" >> <owl@rooftop.invalid> wrote: > >> ... >>>>>> But your first thought was I *had* to be cheating... shows your >>>>>> assumptions. >>>>> >>>>> Not my fault your video look suspicious. >>> >>>> LOL! It shows me doing the task you asked about... run a script to download >>>> the recipes. >>> >>>> You are the one who assumed this was not likely to be true... you assumed >>>> the task could not be done on a Mac or, perhaps, on a Mac by someone who is >>>> not a programmer. >>> >>> I already explained to you the oddities I noticed in your video, as well >>> as the sparse information you displayed. > >> Nothing odd about the video at all. Not a thing. Heck, it is showing me >> directly working on the system. But whatever: you made a mistake and jumped >> to a poor conclusion. To me it is just funny to see the reaction. > > The title bar was odd. I didn't see the video you guys are talking about, but I just checked my MacBook and it seems that OS X do allow right clicks on windows without changing active program (thus, without changing title bar). Never paid attention to it before, because I usually keep my windows full screen. >>>> As I said, not as easy for me as a programmer and if we keep playing this >>>> game we might get to my limits - as it is I have tried briefly to get the >>>> full list of recipes and failed... tried scrolling down and getting the list >>>> of URLs. No dice. >>> >>> Watch the URL bar while you're scrolling. > >> Right, it moves to page 2 and 3. Is it cheating to hard code that? Do you >> keep searching until you add no more links? If we can just hardcode those >> URLs in, or add the added bit to the end of the URL it becomes pretty >> trivial. > > I grab all three. Originally I just got the first twenty on page 1, but > you mentioned that there were more, so I just get them all. > > >> ... >>>>>>> I checked into the conversion utility I use. It has *as an option* >>>>>>> what I assumed would be standard: don't process javascript. I turned >>>>>>> off javascript and got an immediate speed increase. I fiddled with >>>>>>> various options to GNU parallel and now have it processing 58 files in >>>>>>> 102 seconds. (Not sure why it's 58 now instead of 59) >>>>> >>>>>> So still more than a second per file, vs. my 0.8. :) >>>>> >>>>> My PDFs are in the 300-800KB range vs your <100KB files. That probably >>>>> accounts for some of the sluggishness here. (Down to 98 sec now). >>> >>>> Why would yours be so much bigger? >>> >>> Higher quality? Who knows. > >> Yours are actual PDFs with actual text in them, right, not just images. > > anon@sandpit:~/Recipes$ file worlds-best-lasagna.pdf > worlds-best-lasagna.pdf: PDF document, version 1.4 > anon@sandpit:~/Recipes$ cp worlds-best-lasagna.pdf foo > anon@sandpit:~/Recipes$ file foo > foo: PDF document, version 1.4 > anon@sandpit:~/Recipes$ > > >>>> Seems we have another place where the Mac >>>> is "ahead". Are the links in yours active and working? In mine they are, >>>> though I could change that so they would not be. >>> >>> Mine don't have any links after I strip the javascript. It's not that >>> there are dead links -- all the crap from the html version is stripped >>> off. It's nice and clean. >>> >>> http://i.imgur.com/gLtDoVP.png > >> But I assume that is PDF text and not just an image saved in a PDF, right? > > It's possibly just an image on these pages. I tested the utility on > another site and it produced a pdf that had text that is at least > selectable for copy/paste. Links don't work. I'll have to play > with this some more and find out. Images would explain the huge > file size. > >> ... >>>>> While debugging, I had the html files sitting already downloaded and it >>>>> was actually slower for some reason. >>> >>>> Odd. For me I would just need the URLs... having trouble getting all of >>>> them. Did not really put much effort into it, though. Already put too much >>>> time into something that has no real value for me. I did, though, try and >>>> failed. Not denying that. >>> >>> See above. > >> Did you hardcode the URLs? If so that is sorta cheating I think... but wrote >> about it elsewhere that I see gray areas here. This is designed in a way >> that would work only with that site. > > For the three site pages, yeah. That's the only way to get them all. > Doesn't matter to me if we limit it to just the 20 on page 1. > > >> Right now my workflow would take modification to grab multiple URLs, but I >> could do it with saving the things to a file then reading the file. Would >> add a fraction of a second to the processing. -- dunno
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.os.linux.advocacy
csiph-web