Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: utf-8 to ISO in Perl
7 views
Skip to first unread message
Message has been deleted
Luuk
Sep 25, 2011, 3:21:21 PM9/25/11
to
On 25-09-2011 20:43, Jawade wrote:
> Ik zoek een eenvoudig Perlscript om utf-8 om te zetten naar ASCII of
> iso. Ik heb dit gemaakt, maar het werkt niet:
>
> #!C:\Perl\bin\perl.exe -w
> my ($data);
> $data = $ARGV[0];
> use Encode 'from_to';
> from_to($data, "utf-8", "iso-8859-1");
> print $data;
> exit;
>
> Iemand die weet hoe het moet?
>
>
> Met vriendelijke groeten, Jawade.
waarom gebruike je niet gewoon iconv
$ iconv --usage
Usage: iconv [-lcs?V] [-f NAME] [-t NAME] [-o FILE] [--from-code=NAME]
[--to-code=NAME] [--list] [--output=FILE] [--silent]
[--verbose]
[--help] [--usage] [--version] [FILE...]
--
Luuk
> Ik zoek een eenvoudig Perlscript om utf-8 om te zetten naar ASCII of
> iso. Ik heb dit gemaakt, maar het werkt niet:
>
> #!C:\Perl\bin\perl.exe -w
> my ($data);
> $data = $ARGV[0];
> use Encode 'from_to';
> from_to($data, "utf-8", "iso-8859-1");
> print $data;
> exit;
>
> Iemand die weet hoe het moet?
>
>
> Met vriendelijke groeten, Jawade.
waarom gebruike je niet gewoon iconv
$ iconv --usage
Usage: iconv [-lcs?V] [-f NAME] [-t NAME] [-o FILE] [--from-code=NAME]
[--to-code=NAME] [--list] [--output=FILE] [--silent]
[--verbose]
[--help] [--usage] [--version] [FILE...]
--
Luuk
Luuk
Sep 25, 2011, 3:45:47 PM9/25/11
to
On 25-09-2011 20:43, Jawade wrote:
> Ik zoek een eenvoudig Perlscript om utf-8 om te zetten naar ASCII of
> iso. Ik heb dit gemaakt, maar het werkt niet:
>
> #!C:\Perl\bin\perl.exe -w
> my ($data);
> $data = $ARGV[0];
> use Encode 'from_to';
> from_to($data, "utf-8", "iso-8859-1");
> print $data;
> exit;
>
> Iemand die weet hoe het moet?
>
>
> Met vriendelijke groeten, Jawade.
> Ik zoek een eenvoudig Perlscript om utf-8 om te zetten naar ASCII of
> iso. Ik heb dit gemaakt, maar het werkt niet:
>
> #!C:\Perl\bin\perl.exe -w
> my ($data);
> $data = $ARGV[0];
> use Encode 'from_to';
> from_to($data, "utf-8", "iso-8859-1");
> print $data;
> exit;
>
> Iemand die weet hoe het moet?
>
>
> Met vriendelijke groeten, Jawade.
maar als je het in Perl wilt doen staat hie een voorbeeld:
http://perldoc.perl.org/Encode.html
(onder het kopje 'Encoding via PerlIO')
--
Luuk
Message has been deleted
Message has been deleted
Luuk
Sep 25, 2011, 4:09:22 PM9/25/11
to
On 25-09-2011 21:55, Jawade wrote:
> Luuk <Lu...@invalid.lan> schreef op Sun, 25 Sep 2011 21:21:21 +0200 in
> artikel <hib4l8-...@luuk.invalid.lan>:
> Bedankt. Maar... ik geef het op. ik heb het op allerlei mogelijke
> manieren geprobeerd, maar er komt alleen een berg foutmeldingen uit.
> iconv schijnt 'ie al niet te herkennen.
>
http://www.gnu.org/s/libiconv/
--
Luuk
> Luuk <Lu...@invalid.lan> schreef op Sun, 25 Sep 2011 21:21:21 +0200 in
> artikel <hib4l8-...@luuk.invalid.lan>:
> manieren geprobeerd, maar er komt alleen een berg foutmeldingen uit.
> iconv schijnt 'ie al niet te herkennen.
>
http://www.gnu.org/s/libiconv/
--
Luuk
Operator
Sep 25, 2011, 9:21:47 PM9/25/11
to
In article <20110925$204...@jawade.naaidwijk.nl>,
Jawade <Henk_...@hotmail.com> writes:
> Ik zoek een eenvoudig Perlscript om utf-8 om te zetten naar ASCII of
> iso. Ik heb dit gemaakt, maar het werkt niet:
>
> #!C:\Perl\bin\perl.exe -w
> my ($data);
> $data = $ARGV[0];
> use Encode 'from_to';
> from_to($data, "utf-8", "iso-8859-1");
> print $data;
> exit;
>
> Iemand die weet hoe het moet?
Jawade <Henk_...@hotmail.com> writes:
> Ik zoek een eenvoudig Perlscript om utf-8 om te zetten naar ASCII of
> iso. Ik heb dit gemaakt, maar het werkt niet:
>
> #!C:\Perl\bin\perl.exe -w
> my ($data);
> $data = $ARGV[0];
> use Encode 'from_to';
> from_to($data, "utf-8", "iso-8859-1");
> print $data;
> exit;
>
> Iemand die weet hoe het moet?
Je probeert een command line argument in $data te stoppen.
Weet je wel zeker dat windows dat als utf-8 aanlevert?
Als dat zo is zou ik het eerst naar het interne Perl formaat
vertalen met decode.
Vervolgens wil je het naar STDOUT sturen.
Gebruik de default encoding daarvan.
#!C:\Perl\bin\perl.exe -w
use Encode;
print decode_utf8($ARGV[0]);
exit; # niet nodig.
NB: Het is niet mogelijk alle utf-8 naar iso* te vertalen.
Anders om natuurlijk wel.
Als je het als iso-8859-1 naar een file wilt sturen
gebruik dan de methode zoals Luuk aangaf:
my $string = decode_utf8($ARGV[0]);
open my $out, ">:encoding(iso-8859-1)", $outfile or die;
pint $out $string;
Operator
Sep 26, 2011, 8:41:19 AM9/26/11
to
In article <4e7fd3ab$0$2492$e4fe...@news2.news.xs4all.nl>,
> #!C:\Perl\bin\perl.exe -w
> use Encode;
> print decode_utf8($ARGV[0]);
Herstel. Dat moet zijn:
print encode('latin1', decode_utf8($ARGV[0])), "\n";
> NB: Het is niet mogelijk alle utf-8 naar iso* te vertalen.
> Anders om natuurlijk wel.
>
> Als je het als iso-8859-1 naar een file wilt sturen
> gebruik dan de methode zoals Luuk aangaf:
>
> my $string = decode_utf8($ARGV[0]);
> open my $out, ">:encoding(iso-8859-1)", $outfile or die;
> print $out $string;
ro...@dragon.doktercom.nl (Operator) writes:
> In article <20110925$204...@jawade.naaidwijk.nl>,
> Jawade <Henk_...@hotmail.com> writes:
>> Ik zoek een eenvoudig Perlscript om utf-8 om te zetten naar ASCII of
>> iso. Ik heb dit gemaakt, maar het werkt niet:
>>
>> #!C:\Perl\bin\perl.exe -w
>> my ($data);
>> $data = $ARGV[0];
>> use Encode 'from_to';
>> from_to($data, "utf-8", "iso-8859-1");
>> print $data;
>> exit;
>>
>> Iemand die weet hoe het moet?
>
> Je probeert een command line argument in $data te stoppen.
> Weet je wel zeker dat windows dat als utf-8 aanlevert?
> Als dat zo is zou ik het eerst naar het interne Perl formaat
> vertalen met decode.
> Vervolgens wil je het naar STDOUT sturen.
> Gebruik de default encoding daarvan.
Herstel! Er is geen default encoding daarvan.
> In article <20110925$204...@jawade.naaidwijk.nl>,
> Jawade <Henk_...@hotmail.com> writes:
>> Ik zoek een eenvoudig Perlscript om utf-8 om te zetten naar ASCII of
>> iso. Ik heb dit gemaakt, maar het werkt niet:
>>
>> #!C:\Perl\bin\perl.exe -w
>> my ($data);
>> $data = $ARGV[0];
>> use Encode 'from_to';
>> from_to($data, "utf-8", "iso-8859-1");
>> print $data;
>> exit;
>>
>> Iemand die weet hoe het moet?
>
> Je probeert een command line argument in $data te stoppen.
> Weet je wel zeker dat windows dat als utf-8 aanlevert?
> Als dat zo is zou ik het eerst naar het interne Perl formaat
> vertalen met decode.
> Vervolgens wil je het naar STDOUT sturen.
> Gebruik de default encoding daarvan.
> #!C:\Perl\bin\perl.exe -w
> use Encode;
> print decode_utf8($ARGV[0]);
print encode('latin1', decode_utf8($ARGV[0])), "\n";
> NB: Het is niet mogelijk alle utf-8 naar iso* te vertalen.
> Anders om natuurlijk wel.
>
> Als je het als iso-8859-1 naar een file wilt sturen
> gebruik dan de methode zoals Luuk aangaf:
>
> my $string = decode_utf8($ARGV[0]);
> open my $out, ">:encoding(iso-8859-1)", $outfile or die;
Message has been deleted
Message has been deleted
Rob
Sep 26, 2011, 1:48:28 PM9/26/11
to
Jawade <Henk_...@hotmail.com> wrote:
> Jawade <Henk_...@hotmail.com> schreef op Mon, 26 Sep 2011 16:55:58 +0200 in artikel <20110926$165...@Jawade.Naaldwijk.nl>:
>>
>> Bedankt, maar ik heb al vele voorbeelden van internet geprobeerd, en
>> ze geven steeds een foute uitkomst.
>> Ook de jouwe helaas: Ik voer in: l+íl+í (gecodeerde lálá) en krijg:
>> l+?l+?
>>
>> Ik vermoed dat dat door de console komt, daar zit ook nog een
>> vertaalslag tussen.
>>
>> Note: die invoer l+íl+í staat in de console bij de + met naar links
>> omgevallen T tjes. Ik ga verder testen zonder console.
>>
>> Later...
>> Test geslaagd, buiten de console om gaat het wel perfect. Bedankt,
>> ook aan Luuk.
>
> Kan het kloppen dat ik hiermee de meer exotische tekens niet kan
> decoden?
> Jawade <Henk_...@hotmail.com> schreef op Mon, 26 Sep 2011 16:55:58 +0200 in artikel <20110926$165...@Jawade.Naaldwijk.nl>:
>>
>> Bedankt, maar ik heb al vele voorbeelden van internet geprobeerd, en
>> ze geven steeds een foute uitkomst.
>> Ook de jouwe helaas: Ik voer in: l+íl+í (gecodeerde lálá) en krijg:
>> l+?l+?
>>
>> Ik vermoed dat dat door de console komt, daar zit ook nog een
>> vertaalslag tussen.
>>
>> Note: die invoer l+íl+í staat in de console bij de + met naar links
>> omgevallen T tjes. Ik ga verder testen zonder console.
>>
>> Later...
>> Test geslaagd, buiten de console om gaat het wel perfect. Bedankt,
>> ook aan Luuk.
>
> Kan het kloppen dat ik hiermee de meer exotische tekens niet kan
> decoden?
Natuurlijk. Als je exotische tekens zonder gezeur wilt dan moet je
gewoon UTF-8 all the way gebruiken. Dus niks ISO-8859.
Dat is tegenwoordig ook standaard in Windows en Linux dus ik weet niet
wat je loopt te tobben.
Message has been deleted
Wil Taphoorn
Sep 30, 2011, 1:39:33 PM9/30/11
to
On 30-9-2011 18:29, Jawade wrote:
>
> Ik zoek gewoon een scriptje of tooltje die utf-8 omzet in iso. BV
>
> Re: =?UTF-8?B?QmVsZ2nDqw==?= failliet in 2012
Wat je daar laat zien is geen UTF-8, maar een MIME-extension met
base64 coding. Het stukje 'QmVsZ2nDqw==' is base64 gecodeerd en
geeft na decodering de text: België.
--
Wil
>
> Ik zoek gewoon een scriptje of tooltje die utf-8 omzet in iso. BV
>
> Re: =?UTF-8?B?QmVsZ2nDqw==?= failliet in 2012
Wat je daar laat zien is geen UTF-8, maar een MIME-extension met
base64 coding. Het stukje 'QmVsZ2nDqw==' is base64 gecodeerd en
geeft na decodering de text: België.
--
Wil
Wil Taphoorn
Sep 30, 2011, 1:52:06 PM9/30/11
to
--
Wil
Message has been deleted
John Bokma
Sep 30, 2011, 3:34:52 PM9/30/11
to
Jawade <Henk_...@hotmail.com> writes:
> Wil Taphoorn <w...@nogo.wtms.nl> schreef op Fri, 30 Sep 2011 19:52:06 +0200 in artikel <WTMSF2...@wtms.nl>:
> Okee, maar dat verwachtte ik niet met die utf8-header. Ja, ik ben wel
> vaker dubbel gecodeerde tekst tegengekomen. Okee, ga ik mee aan de
> slag, bedankt.
Er zijn diverse Perl modules die dit makkelijker maken (MIME
gerelateerd). Het helpt echt als je a) precies wat je wilt goed
opschrijft en b) je probleem beter opschrijft (dus niet
hijdoetutniemeeehhhh) [0]
En aangezien je met Unicode aan het spelen bent, lees zeker:
http://ahinea.com/en/tech/perl-unicode-struggle.html
En nog wat tips op je eerdere Perl:
#!/usr/bin/perl
use strict;
use warnings
begin je script daarmee, dat scheelt een hoop gezeur.
De use warnings is beter dan de -w switch
gebruik altijd use strict
Windows doet niks met de 1e regel, dus het pad naar Perl hoef je onder
Windows/DOS *niet* naar de exe te zetten, het uitvoeren van het script
gaat nl. via associatie met de pl extensie. [1]
[0] geef: invoer, verwachtte uitkomst, actuele uitkomst, minimale versie
die het probleem toont. Bij de invoer is het meestal nuttig om aan
te geven waar het vandaan komt. Dit zijn echt basisdingen die een
programmeur hoort te weten *en* gebruiken.
[1] switches worden wel over genomen uit de she-bang, maar pad naar perl
wordt genegeerd.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
> Wil Taphoorn <w...@nogo.wtms.nl> schreef op Fri, 30 Sep 2011 19:52:06 +0200 in artikel <WTMSF2...@wtms.nl>:
> vaker dubbel gecodeerde tekst tegengekomen. Okee, ga ik mee aan de
> slag, bedankt.
Er zijn diverse Perl modules die dit makkelijker maken (MIME
gerelateerd). Het helpt echt als je a) precies wat je wilt goed
opschrijft en b) je probleem beter opschrijft (dus niet
hijdoetutniemeeehhhh) [0]
En aangezien je met Unicode aan het spelen bent, lees zeker:
http://ahinea.com/en/tech/perl-unicode-struggle.html
En nog wat tips op je eerdere Perl:
#!/usr/bin/perl
use strict;
use warnings
begin je script daarmee, dat scheelt een hoop gezeur.
De use warnings is beter dan de -w switch
gebruik altijd use strict
Windows doet niks met de 1e regel, dus het pad naar Perl hoef je onder
Windows/DOS *niet* naar de exe te zetten, het uitvoeren van het script
gaat nl. via associatie met de pl extensie. [1]
[0] geef: invoer, verwachtte uitkomst, actuele uitkomst, minimale versie
die het probleem toont. Bij de invoer is het meestal nuttig om aan
te geven waar het vandaan komt. Dit zijn echt basisdingen die een
programmeur hoort te weten *en* gebruiken.
[1] switches worden wel over genomen uit de she-bang, maar pad naar perl
wordt genegeerd.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
Message has been deleted
John Bokma
Sep 30, 2011, 4:00:47 PM9/30/11
to
Jawade <Henk_...@hotmail.com> writes:
> Ja, ik heb het al voor elkaar, was simpel toen ik dat base64 eenmaal
> wist. Ik heb een combiscript gemaakt met een switch voor verschillende
> taken. Weer blijkt mij de kracht van Perl. :-)
De kracht van Perl is CPAN: gebruik 'm goed. Wees nooit bang om nieuwe
modules te leren en/of installeren ;-) Met Perl is het erg vaak zo dat
als iets je meer dan 20 regels kost er een module voor is :-D.
> Ja, ik heb het al voor elkaar, was simpel toen ik dat base64 eenmaal
> wist. Ik heb een combiscript gemaakt met een switch voor verschillende
> taken. Weer blijkt mij de kracht van Perl. :-)
De kracht van Perl is CPAN: gebruik 'm goed. Wees nooit bang om nieuwe
modules te leren en/of installeren ;-) Met Perl is het erg vaak zo dat
als iets je meer dan 20 regels kost er een module voor is :-D.
Huibert Bol
Sep 30, 2011, 5:28:12 PM9/30/11
to
Jawade schreef:
> Ja, ik heb het al voor elkaar, was simpel toen ik dat base64 eenmaal
> wist. Ik heb een combiscript gemaakt met een switch voor verschillende
> taken. Weer blijkt mij de kracht van Perl. :-)
Je begrijpt toch wel dat de codering geen UTF-8 hoeft te zijn of base64,
zo zou België bijvoorbeeld ook als ?utf-8?Q?Belgi=C3=AB?= of
=?iso-8859-1?Q?Belgi=EB?= gecodeerd kunnen worden.
--
Huibert
"Okay... really not something I needed to see." --Raven
> Ja, ik heb het al voor elkaar, was simpel toen ik dat base64 eenmaal
> wist. Ik heb een combiscript gemaakt met een switch voor verschillende
> taken. Weer blijkt mij de kracht van Perl. :-)
zo zou België bijvoorbeeld ook als ?utf-8?Q?Belgi=C3=AB?= of
=?iso-8859-1?Q?Belgi=EB?= gecodeerd kunnen worden.
--
Huibert
"Okay... really not something I needed to see." --Raven
Message has been deleted
robert
Oct 3, 2011, 1:23:01 AM10/3/11
to
Jawade <Henk_...@hotmail.com>:
> Huibert Bol <huibe...@quicknet.nl> schreef op Fri, 30 Sep 2011
> 23:28:12 +0200 in artikel <j65c9c$6dm$1...@dont-email.me>:
De tweede is iso-8859-1 en quoted printable.
> iso8859 is zo te lezen.
Niet als je uitvoerapparaat uitgaat van utf-8, om maar iets te noemen.
--
robert
> Huibert Bol <huibe...@quicknet.nl> schreef op Fri, 30 Sep 2011
> 23:28:12 +0200 in artikel <j65c9c$6dm$1...@dont-email.me>:
>> Jawade schreef:
>>
>> > Ja, ik heb het al voor elkaar, was simpel toen ik dat base64 eenmaal
>> > wist. Ik heb een combiscript gemaakt met een switch voor verschillende
>> > taken. Weer blijkt mij de kracht van Perl. :-)
>>
>> Je begrijpt toch wel dat de codering geen UTF-8 hoeft te zijn of base64,
>> zo zou België bijvoorbeeld ook als ?utf-8?Q?Belgi=C3=AB?= of
>> =?iso-8859-1?Q?Belgi=EB?= gecodeerd kunnen worden.
>
> De 1e is utf8 en quoted printable, en de 2e alleen quoted printable.
>>
>> > Ja, ik heb het al voor elkaar, was simpel toen ik dat base64 eenmaal
>> > wist. Ik heb een combiscript gemaakt met een switch voor verschillende
>> > taken. Weer blijkt mij de kracht van Perl. :-)
>>
>> Je begrijpt toch wel dat de codering geen UTF-8 hoeft te zijn of base64,
>> zo zou België bijvoorbeeld ook als ?utf-8?Q?Belgi=C3=AB?= of
>> =?iso-8859-1?Q?Belgi=EB?= gecodeerd kunnen worden.
>
De tweede is iso-8859-1 en quoted printable.
> iso8859 is zo te lezen.
Niet als je uitvoerapparaat uitgaat van utf-8, om maar iets te noemen.
--
robert
Message has been deleted
John Bokma
Oct 3, 2011, 12:35:52 PM10/3/11
to
Jawade <Henk_...@hotmail.com> writes:
> De 1e is utf8 en quoted printable, en de 2e alleen quoted printable.
> De 1e is utf8 en quoted printable, en de 2e alleen quoted printable.
> iso8859 is zo te lezen.
Als je nu een juiste module van CPAN gebruikt, dan /hoef/ je je daar
helemaal geen zorgen om te maken. Maar goed, dat zou slim
programmeren zijn, en daar hebben we het hier niet over ;-).
robert
Oct 3, 2011, 1:03:25 PM10/3/11
to
Jawade <Henk_...@hotmail.com>:
> ISO-8859-1 is zonder enige ingreep te lezen. Met Windows dan.
Lekker ouderwets :) En maar hopen dat je geen euroteken wilt gebruiken in
Windows, want dat bestaat niet in iso-8859-1.
--
robert
> ISO-8859-1 is zonder enige ingreep te lezen. Met Windows dan.
Lekker ouderwets :) En maar hopen dat je geen euroteken wilt gebruiken in
Windows, want dat bestaat niet in iso-8859-1.
--
robert
Message has been deleted
Message has been deleted
robert
Oct 3, 2011, 1:25:42 PM10/3/11
to
Jawade <Henk_...@hotmail.com>:
> robert <US3N37+{n.c.p}@gmail.com> schreef op Mon, 3 Oct 2011 17:03:25 GMT
> in artikel <slrnj8jqmt...@my.local.lan>:
> Als je 15 gebruikt, moet je maar hopen dat je lezers het euroteken kunnen
> zien.
We leven niet meer in het stenen tijdperk, elke fatsoenlijke software kan
in ieder geval de meest voorkomende karaktersets gewoon tonen.
--
robert
> robert <US3N37+{n.c.p}@gmail.com> schreef op Mon, 3 Oct 2011 17:03:25 GMT
> in artikel <slrnj8jqmt...@my.local.lan>:
> zien.
We leven niet meer in het stenen tijdperk, elke fatsoenlijke software kan
in ieder geval de meest voorkomende karaktersets gewoon tonen.
--
robert
John Bokma
Oct 3, 2011, 1:43:23 PM10/3/11
to
Jawade <Henk_...@hotmail.com> writes:
> John Bokma <jo...@castleamber.com> schreef op Mon, 3 Oct 2011 11:35:52 -0500 in artikel <87y5x28...@castleamber.com>:
Heh, "minimale afmetingen" met Perl...
> Bovendien vind ik het leuk om uit te zoeken.
Wielen uitvinden, bedoel je ;-).
> John Bokma <jo...@castleamber.com> schreef op Mon, 3 Oct 2011 11:35:52 -0500 in artikel <87y5x28...@castleamber.com>:
>> Jawade <Henk_...@hotmail.com> writes:
>>
>> > De 1e is utf8 en quoted printable, en de 2e alleen quoted printable.
>> > iso8859 is zo te lezen.
>>
>> Als je nu een juiste module van CPAN gebruikt, dan /hoef/ je je daar
>> helemaal geen zorgen om te maken. Maar goed, dat zou slim
>> programmeren zijn, en daar hebben we het hier niet over ;-).
>
> Ik heb alles wat ik wilde, met minimale afmetingen.
>>
>> > De 1e is utf8 en quoted printable, en de 2e alleen quoted printable.
>> > iso8859 is zo te lezen.
>>
>> Als je nu een juiste module van CPAN gebruikt, dan /hoef/ je je daar
>> helemaal geen zorgen om te maken. Maar goed, dat zou slim
>> programmeren zijn, en daar hebben we het hier niet over ;-).
>
Heh, "minimale afmetingen" met Perl...
> Bovendien vind ik het leuk om uit te zoeken.
Wielen uitvinden, bedoel je ;-).
Message has been deleted
Message has been deleted
robert
Oct 4, 2011, 11:59:02 AM10/4/11
to
Jawade <Henk_...@hotmail.com>:
> robert <US3N37+{n.c.p}@gmail.com> schreef op Mon, 3 Oct 2011 17:25:42 GMT
> in artikel <slrnj8js0m...@my.local.lan>:
Mensen moeten daar gewoon vanaf blijven, de software moet een zinnige
default kiezen. UTF-8 bijvoorbeeld.
--
robert
> robert <US3N37+{n.c.p}@gmail.com> schreef op Mon, 3 Oct 2011 17:25:42 GMT
> in artikel <slrnj8js0m...@my.local.lan>:
>>
>> We leven niet meer in het stenen tijdperk, elke fatsoenlijke software
>> kan in ieder geval de meest voorkomende karaktersets gewoon tonen.
>
> Maar geen euroteken als de persoon iso-8859-1 heeft ingesteld.
>> We leven niet meer in het stenen tijdperk, elke fatsoenlijke software
>> kan in ieder geval de meest voorkomende karaktersets gewoon tonen.
>
Mensen moeten daar gewoon vanaf blijven, de software moet een zinnige
default kiezen. UTF-8 bijvoorbeeld.
--
robert
John Bokma
Oct 4, 2011, 12:59:42 PM10/4/11
to
Jawade <Henk_...@hotmail.com> writes:
> John Bokma <jo...@castleamber.com> schreef op Mon, 3 Oct 2011 12:43:23 -0500 in artikel <87aa9id...@castleamber.com>:
>
> Leuk toch?
Paar MB installeren, paar MB opstarten, en hoeveel geheugen gebruikt het
nu? (Overigens, weet je zeker dat het $ARGV[1] moet zijn, en niet
$ARGV[0]?)
>> > Bovendien vind ik het leuk om uit te zoeken.
>>
>> Wielen uitvinden, bedoel je ;-).
>
> Jij zou moeten weten dat je in programmeerland vaak genoeg het wiel
> opnieuw uitvindt,
Nu, "je" probeert dat zoveel mogelijk te vermijden. Ik weet dat er
massas mensen zijn die "programmeren" en dat inderdaad doen. Vandaar
dat dingen als "SQL injecties" en "Oh, nee, alle passwords op straat"
bijna dagelijks wel te lezen valt.
> sterker nog, het is vaak makkelijker om het wiel opnieuw uit te
> vinden.
Ja, o, zo makkelijk. Tot iemand anders duidelijk maakt dat er 1001
dingen mee mis zijn. Het is maar goed dat het leven van de meeste
programmeurs niet afhangt van hun knutselwerk, anders zou het een
bedreigde diersoort worden.
> John Bokma <jo...@castleamber.com> schreef op Mon, 3 Oct 2011 12:43:23 -0500 in artikel <87aa9id...@castleamber.com>:
>> Jawade <Henk_...@hotmail.com> writes:
>> > John Bokma <jo...@castleamber.com> schreef op Mon, 3 Oct 2011 11:35:52 -0500 in artikel <87y5x28...@castleamber.com>:
>> >>
>> > John Bokma <jo...@castleamber.com> schreef op Mon, 3 Oct 2011 11:35:52 -0500 in artikel <87y5x28...@castleamber.com>:
>> >>
>> >> Als je nu een juiste module van CPAN gebruikt, dan /hoef/ je je daar
>> >> helemaal geen zorgen om te maken. Maar goed, dat zou slim
>> >> programmeren zijn, en daar hebben we het hier niet over ;-).
>> >
>> > Ik heb alles wat ik wilde, met minimale afmetingen.
>>
>> Heh, "minimale afmetingen" met Perl...
>
> print encode('iso-8859-1', decode_utf8(decode_base64($ARGV[1])));
>> >> helemaal geen zorgen om te maken. Maar goed, dat zou slim
>> >> programmeren zijn, en daar hebben we het hier niet over ;-).
>> >
>> > Ik heb alles wat ik wilde, met minimale afmetingen.
>>
>> Heh, "minimale afmetingen" met Perl...
>
>
> Leuk toch?
Paar MB installeren, paar MB opstarten, en hoeveel geheugen gebruikt het
nu? (Overigens, weet je zeker dat het $ARGV[1] moet zijn, en niet
$ARGV[0]?)
>> > Bovendien vind ik het leuk om uit te zoeken.
>>
>> Wielen uitvinden, bedoel je ;-).
>
> opnieuw uitvindt,
Nu, "je" probeert dat zoveel mogelijk te vermijden. Ik weet dat er
massas mensen zijn die "programmeren" en dat inderdaad doen. Vandaar
dat dingen als "SQL injecties" en "Oh, nee, alle passwords op straat"
bijna dagelijks wel te lezen valt.
> sterker nog, het is vaak makkelijker om het wiel opnieuw uit te
> vinden.
Ja, o, zo makkelijk. Tot iemand anders duidelijk maakt dat er 1001
dingen mee mis zijn. Het is maar goed dat het leven van de meeste
programmeurs niet afhangt van hun knutselwerk, anders zou het een
bedreigde diersoort worden.
Message has been deleted
Message has been deleted
robert
Oct 4, 2011, 2:16:35 PM10/4/11
to
Jawade <Henk_...@hotmail.com>:
> robert <US3N37+{n.c.p}@gmail.com> schreef op Tue, 4 Oct 2011 15:59:02 GMT
> in artikel <slrnj8mba6...@my.local.lan>:
> de lezers je niet kan lezen.
Het deel van de lezers dat UTF-8 niet kan lezen is volgens mij
vergelijkbaar met de hoeveelheid mensen die nog op stoommachines of met
paard en wagen rondrijden. Verwaarloosbaar, dus.
--
robert
> robert <US3N37+{n.c.p}@gmail.com> schreef op Tue, 4 Oct 2011 15:59:02 GMT
> in artikel <slrnj8mba6...@my.local.lan>:
>
>> Mensen moeten daar gewoon vanaf blijven, de software moet een zinnige
>> default kiezen. UTF-8 bijvoorbeeld.
>
> Juist die zou ik nooit kiezen, dan weet je nl zeker dat een deel van
>> Mensen moeten daar gewoon vanaf blijven, de software moet een zinnige
>> default kiezen. UTF-8 bijvoorbeeld.
>
> de lezers je niet kan lezen.
Het deel van de lezers dat UTF-8 niet kan lezen is volgens mij
vergelijkbaar met de hoeveelheid mensen die nog op stoommachines of met
paard en wagen rondrijden. Verwaarloosbaar, dus.
--
robert
John Bokma
Oct 4, 2011, 2:21:31 PM10/4/11
to
Jawade <Henk_...@hotmail.com> writes:
> robert <US3N37+{n.c.p}@gmail.com> schreef op Tue, 4 Oct 2011 15:59:02 GMT in artikel <slrnj8mba6...@my.local.lan>:
> robert <US3N37+{n.c.p}@gmail.com> schreef op Tue, 4 Oct 2011 15:59:02 GMT in artikel <slrnj8mba6...@my.local.lan>:
> Juist die zou ik nooit kiezen, dan weet je nl zeker dat een deel van
> de lezers je niet kan lezen. Utf-8 is mooi, maar alleen als iedereen
> dat kan lezen. Anders is het een onding. Net als quoted-printable.
Als je je daar /echt/ zorgen om maakt, dan gebruik je natuurlijk alleen
7-bits ASCII. En heeeej.... da's stiekem /ook/ utf-8. (En dan heb je
vast nog steeds een deel van je lezers die het niet kan lezen ;-) ).
John Bokma
Oct 4, 2011, 2:22:18 PM10/4/11
to
John Bokma
Oct 4, 2011, 2:26:30 PM10/4/11
to
Jawade <Henk_...@hotmail.com> writes:
> John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 11:59:42
> -0500 in artikel <87ty7o6...@castleamber.com>:
[..]
>> Paar MB installeren, paar MB opstarten, en hoeveel geheugen gebruikt het
>> nu? (Overigens, weet je zeker dat het $ARGV[1] moet zijn, en niet
>> $ARGV[0]?)
>
> Ja.
Het loont nu en dan om als je meer dan 1 argument hebt, om Getopt::Long
te gebruiken. Zit standaard bij Perl (core), dus daar hoef je niet
wakker van te liggen (maar goed...).
>> Ja, o, zo makkelijk. Tot iemand anders duidelijk maakt dat er 1001
>> dingen mee mis zijn. Het is maar goed dat het leven van de meeste
>> programmeurs niet afhangt van hun knutselwerk, anders zou het een
>> bedreigde diersoort worden.
>
> Ach, degenen die denken dat ze goed zijn, dat zijn nog de ergsten.
En niet geheel verbazingwekkend: er is een enorme overlap tussen dat
soort, en die wielherherheruitvinders "want ik kan het beter" ;-).
En als het een veeg uit de pot in mijn richting was: ik /denk/ niet dat
ik goed ben, ik ben goed ;-).
> John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 11:59:42
> -0500 in artikel <87ty7o6...@castleamber.com>:
[..]
>> Paar MB installeren, paar MB opstarten, en hoeveel geheugen gebruikt het
>> nu? (Overigens, weet je zeker dat het $ARGV[1] moet zijn, en niet
>> $ARGV[0]?)
>
Het loont nu en dan om als je meer dan 1 argument hebt, om Getopt::Long
te gebruiken. Zit standaard bij Perl (core), dus daar hoef je niet
wakker van te liggen (maar goed...).
>> Ja, o, zo makkelijk. Tot iemand anders duidelijk maakt dat er 1001
>> dingen mee mis zijn. Het is maar goed dat het leven van de meeste
>> programmeurs niet afhangt van hun knutselwerk, anders zou het een
>> bedreigde diersoort worden.
>
En niet geheel verbazingwekkend: er is een enorme overlap tussen dat
soort, en die wielherherheruitvinders "want ik kan het beter" ;-).
En als het een veeg uit de pot in mijn richting was: ik /denk/ niet dat
ik goed ben, ik ben goed ;-).
Message has been deleted
Message has been deleted
John Bokma
Oct 4, 2011, 3:39:48 PM10/4/11
to
Jawade <Henk_...@hotmail.com> writes:
> John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 13:26:30 -0500 in artikel <877h4ki...@castleamber.com>:
>> Jawade <Henk_...@hotmail.com> writes:
[programmeurs]
>> > Ach, degenen die denken dat ze goed zijn, dat zijn nog de ergsten.
>>
>> En niet geheel verbazingwekkend: er is een enorme overlap tussen dat
>> soort, en die wielherherheruitvinders "want ik kan het beter" ;-).
>
> Dat is niet de reden, de reden is vaak onwetendheid,
Er is niet een reden, maar meer. En ja, onwetendheid is inderdaad ook
waarom er heel veel code herherherschreven wordt.
> en verder is het ook regelmatig beter om het wiel uit te vinden.
Ikzelf ben van mening dat het zelden tot nooit het geval is. Oh, het
wiel /lijkt/ beter, maar dat komt omdat men 1001 zaken over het hoofd
heeft gezien. En nadat die allemaal correct geimplementeerd zijn is er
weinig verschil tussen het reeds bestaande wiel, en het wiel wat door
tig ontwikkelrondjes heen gegaan is.
Daarnaast zie ik ook vaak: ik kan het beter dan al die 100 half-af
oplossingen. En dan zijn er 101 half-af oplossingen...
Kortom, ik gebruik het liefst zo veel mogelijk Perl modules. En als ik
denk: dat kan beter, en ik heb de tijd, dan probeer ik contact op te
nemen met de auteur. Een bijkomend voordeel van die Perl modules is dat
ze meestal enige vorm van documenatie hebben *en* gestest zijn door meer
mensen dan ikke.
> De ene taal is hier goed in, de andere daar goed in. Dat hou je
> toch. Ik probeer van alles het beste te nemen.
Tuurlijk. Ik schrijf liever geen complexe GUI applicatie in Perl (ben
daarvoor C++ aan het herleren). Maar het gebruik van libraries is in de
meeste talen een slim iets. Een bekende uitspraak is dat /het/ sterke
punt van Perl CPAN is. En ik denk dat daar veel voor te zeggen valt.
>> En als het een veeg uit de pot in mijn richting was: ik /denk/ niet dat
>> ik goed ben, ik ben goed ;-).
>
> Ik ben op bepaalde punten goed, maar heb ook mijn zwakke punten.
Tuurlijk, iedereen heeft dat. Ik lees nog steeds artikelen over Perl, en
Perl boeken (Modern Perl ligt hier al een tijdje te piepen ;-) ).
> Ik ben mij dat bewust. Als ik een programma van mezelf van 20 jaar
> geleden onder ogen kom, denk ik: waar gaat dit over... :-)
Heh, ik denk dat veel programmeurs dat nu en dan hebben met een
programma van 2 jaar geleden, tenzij ze daar recent nog aan gewerkt
hebben. Het ligt ook aan hoeveel tijd er in gestoken is, als we de
documentatie even gelijk stellen (als in nagenoeg geen). Als je lang aan
iets gewerkt hebt komt het vaak sneller terug dan als het 2 uurtjes ff
een script in elkaar knallen.
> John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 13:26:30 -0500 in artikel <877h4ki...@castleamber.com>:
>> Jawade <Henk_...@hotmail.com> writes:
[programmeurs]
>> > Ach, degenen die denken dat ze goed zijn, dat zijn nog de ergsten.
>>
>> En niet geheel verbazingwekkend: er is een enorme overlap tussen dat
>> soort, en die wielherherheruitvinders "want ik kan het beter" ;-).
>
Er is niet een reden, maar meer. En ja, onwetendheid is inderdaad ook
waarom er heel veel code herherherschreven wordt.
> en verder is het ook regelmatig beter om het wiel uit te vinden.
Ikzelf ben van mening dat het zelden tot nooit het geval is. Oh, het
wiel /lijkt/ beter, maar dat komt omdat men 1001 zaken over het hoofd
heeft gezien. En nadat die allemaal correct geimplementeerd zijn is er
weinig verschil tussen het reeds bestaande wiel, en het wiel wat door
tig ontwikkelrondjes heen gegaan is.
Daarnaast zie ik ook vaak: ik kan het beter dan al die 100 half-af
oplossingen. En dan zijn er 101 half-af oplossingen...
Kortom, ik gebruik het liefst zo veel mogelijk Perl modules. En als ik
denk: dat kan beter, en ik heb de tijd, dan probeer ik contact op te
nemen met de auteur. Een bijkomend voordeel van die Perl modules is dat
ze meestal enige vorm van documenatie hebben *en* gestest zijn door meer
mensen dan ikke.
> De ene taal is hier goed in, de andere daar goed in. Dat hou je
> toch. Ik probeer van alles het beste te nemen.
Tuurlijk. Ik schrijf liever geen complexe GUI applicatie in Perl (ben
daarvoor C++ aan het herleren). Maar het gebruik van libraries is in de
meeste talen een slim iets. Een bekende uitspraak is dat /het/ sterke
punt van Perl CPAN is. En ik denk dat daar veel voor te zeggen valt.
>> En als het een veeg uit de pot in mijn richting was: ik /denk/ niet dat
>> ik goed ben, ik ben goed ;-).
>
Tuurlijk, iedereen heeft dat. Ik lees nog steeds artikelen over Perl, en
Perl boeken (Modern Perl ligt hier al een tijdje te piepen ;-) ).
> Ik ben mij dat bewust. Als ik een programma van mezelf van 20 jaar
> geleden onder ogen kom, denk ik: waar gaat dit over... :-)
Heh, ik denk dat veel programmeurs dat nu en dan hebben met een
programma van 2 jaar geleden, tenzij ze daar recent nog aan gewerkt
hebben. Het ligt ook aan hoeveel tijd er in gestoken is, als we de
documentatie even gelijk stellen (als in nagenoeg geen). Als je lang aan
iets gewerkt hebt komt het vaak sneller terug dan als het 2 uurtjes ff
een script in elkaar knallen.
robert
Oct 4, 2011, 3:51:47 PM10/4/11
to
Jawade <Henk_...@hotmail.com>:
> Vandaar dat het gebruik van utf-8 nog steeds uit den boze is.
Ik leef niet meer in de jaren 90.
--
robert
> Vandaar dat het gebruik van utf-8 nog steeds uit den boze is.
Ik leef niet meer in de jaren 90.
--
robert
Message has been deleted
John Bokma
Oct 4, 2011, 4:14:22 PM10/4/11
to
Jawade <Henk_...@hotmail.com> writes:
> John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 14:39:48
> -0500 in>> Ikzelf ben van mening dat het zelden tot nooit het geval
> is. Oh, het
[..]
>> wiel /lijkt/ beter, maar dat komt omdat men 1001 zaken over het hoofd
>> heeft gezien. En nadat die allemaal correct geimplementeerd zijn is er
>> weinig verschil tussen het reeds bestaande wiel, en het wiel wat door
>> tig ontwikkelrondjes heen gegaan is.
>
> Neem nou het decoden van quoted-printable. Kost mij 8 regeltjes,
Tja, en op zeker met de juiste Perl module een stuk minder... Bijkomend
voordeel is dat die module getest is door meer mensen dan jijzelf, met
documentatie komt, en als iemand anders aan jouw script verder kan en
wil werken, dat het een stuk makkelijker is als dingen met bestaande, en
wellicht al bekende, modules gedaan is.
> maar ik kan er ook een tooltje voor gebruiken, en dan gaat het nog
> eens langzamer ook.
Jaaaaa.... een hele milliseconde, wellicht. Als je je echt zo druk zit
te maken om de snelheid van het verwerken van een command line argument,
waarom zit je dan in Perl te knoeien?
>> Daarnaast zie ik ook vaak: ik kan het beter dan al die 100 half-af
>> oplossingen. En dan zijn er 101 half-af oplossingen...
>
> Ik maak ze wel af, al kost dat veel testtijd. Maar dat geeft niet.
Ik zie mijzelf liever meehelpen aan het vervolmaken van een bestaande
oplossing, ook omdat die vast door meer mensen gebruikt wordt ;-)
> Ja, ben ik met je eens. Maar Perl is voor mij voor veel toepassingen
> niet geschikt omdat ik, wil ik het distribueren, er een exe van moet
> maken van > 1 MB en dat is niet altijd wenselijk, bv voor een klein
> tooltje. Nu zul jij zeggen: laat je klanten Perl installeren, maar
> dat is niet werkbaar, het zijn meestal geen technici.
Als die > 1 MB en zelf-installeren van Perl niet wenselijk is, zit je in
de verkeerde taal te programmeren, simpel.
>> Tuurlijk. Ik schrijf liever geen complexe GUI applicatie in Perl (ben
>> daarvoor C++ aan het herleren). Maar het gebruik van libraries is in de
>> meeste talen een slim iets. Een bekende uitspraak is dat /het/ sterke
>> punt van Perl CPAN is. En ik denk dat daar veel voor te zeggen valt.
>
> Dat kan, mijn voorkeur voor Perl zijn de krachtige commands.
Zoals?
> Maar ik haal ook weleens een module op van internet.
Gelukkig maar.
> FreeBASIC, mijn favoriet, kent ook C++-style programmeren,
Je bedoelt OO?
> compleet met libraries. Daar ben ik echter niet ver mee,
> ondanks de cursus C++ die ik jaren geleden volgde.
C++ leer je ook niet echt in 1 cursus. Het is een erg complexe taal. Ik
schreef gelook ik al hier ergens dat ik het plan heb om 6+ C++ boeken
door te werken ;-) Met 1 boek per maand is dat een cursus van 6 maanden,
of ergens tussen de 2500 en 3000 pagina's. Ik lig nu al (aardig) achter,
dus wellicht ga ik het niet halen in 6 maanden. Maar goed, de wil is er.
>> documentatie even gelijk stellen (als in nagenoeg geen). Als je lang aan
>> iets gewerkt hebt komt het vaak sneller terug dan als het 2 uurtjes ff
>> een script in elkaar knallen.
>
> Ja, en juist die laatste worden slecht gedocumenteerd. Ik heb vaak
> moeite met sources van anderen, omdat iedereen ook een eigen stijl
> heeft.
> Ik programmeer nog steeds compact,
Je bedoeld dat je druk bezig bent met prematuur optimaliseren. Da's niet
goed bij voortplanten, en niet goed bij programmeren ;-).
Mijn motto is: schrijf het eerst leesbaar. En als het dan te traag gaat:
uitzoeken waar het probleem 'm zit, kijken of er een snellere oplossing
(module) voor is op CPAN (soms is dat inderdaad zo, er zijn modules die
een mix van C en Perl zijn en die een (veel) snellere versie van Pure
Perl modules zijn). Maar erg vaak voldoet de Perl oplossing. Zoals ik al
schreef: als je je druk maakt om die paar milliseconden om een module te
laden, en een method uit te voeren, zit je sowieso al in de verkeerde
taal te werken. En dan heb je vast (nog steeds) niet naar het
geheugengebruik gekeken van Perl...
> John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 14:39:48
> -0500 in>> Ikzelf ben van mening dat het zelden tot nooit het geval
> is. Oh, het
[..]
>> wiel /lijkt/ beter, maar dat komt omdat men 1001 zaken over het hoofd
>> heeft gezien. En nadat die allemaal correct geimplementeerd zijn is er
>> weinig verschil tussen het reeds bestaande wiel, en het wiel wat door
>> tig ontwikkelrondjes heen gegaan is.
>
Tja, en op zeker met de juiste Perl module een stuk minder... Bijkomend
voordeel is dat die module getest is door meer mensen dan jijzelf, met
documentatie komt, en als iemand anders aan jouw script verder kan en
wil werken, dat het een stuk makkelijker is als dingen met bestaande, en
wellicht al bekende, modules gedaan is.
> maar ik kan er ook een tooltje voor gebruiken, en dan gaat het nog
> eens langzamer ook.
Jaaaaa.... een hele milliseconde, wellicht. Als je je echt zo druk zit
te maken om de snelheid van het verwerken van een command line argument,
waarom zit je dan in Perl te knoeien?
>> Daarnaast zie ik ook vaak: ik kan het beter dan al die 100 half-af
>> oplossingen. En dan zijn er 101 half-af oplossingen...
>
Ik zie mijzelf liever meehelpen aan het vervolmaken van een bestaande
oplossing, ook omdat die vast door meer mensen gebruikt wordt ;-)
> Ja, ben ik met je eens. Maar Perl is voor mij voor veel toepassingen
> niet geschikt omdat ik, wil ik het distribueren, er een exe van moet
> maken van > 1 MB en dat is niet altijd wenselijk, bv voor een klein
> tooltje. Nu zul jij zeggen: laat je klanten Perl installeren, maar
> dat is niet werkbaar, het zijn meestal geen technici.
Als die > 1 MB en zelf-installeren van Perl niet wenselijk is, zit je in
de verkeerde taal te programmeren, simpel.
>> Tuurlijk. Ik schrijf liever geen complexe GUI applicatie in Perl (ben
>> daarvoor C++ aan het herleren). Maar het gebruik van libraries is in de
>> meeste talen een slim iets. Een bekende uitspraak is dat /het/ sterke
>> punt van Perl CPAN is. En ik denk dat daar veel voor te zeggen valt.
>
Zoals?
> Maar ik haal ook weleens een module op van internet.
Gelukkig maar.
> FreeBASIC, mijn favoriet, kent ook C++-style programmeren,
Je bedoelt OO?
> compleet met libraries. Daar ben ik echter niet ver mee,
> ondanks de cursus C++ die ik jaren geleden volgde.
C++ leer je ook niet echt in 1 cursus. Het is een erg complexe taal. Ik
schreef gelook ik al hier ergens dat ik het plan heb om 6+ C++ boeken
door te werken ;-) Met 1 boek per maand is dat een cursus van 6 maanden,
of ergens tussen de 2500 en 3000 pagina's. Ik lig nu al (aardig) achter,
dus wellicht ga ik het niet halen in 6 maanden. Maar goed, de wil is er.
>> documentatie even gelijk stellen (als in nagenoeg geen). Als je lang aan
>> iets gewerkt hebt komt het vaak sneller terug dan als het 2 uurtjes ff
>> een script in elkaar knallen.
>
> moeite met sources van anderen, omdat iedereen ook een eigen stijl
> heeft.
> Ik programmeer nog steeds compact,
Je bedoeld dat je druk bezig bent met prematuur optimaliseren. Da's niet
goed bij voortplanten, en niet goed bij programmeren ;-).
Mijn motto is: schrijf het eerst leesbaar. En als het dan te traag gaat:
uitzoeken waar het probleem 'm zit, kijken of er een snellere oplossing
(module) voor is op CPAN (soms is dat inderdaad zo, er zijn modules die
een mix van C en Perl zijn en die een (veel) snellere versie van Pure
Perl modules zijn). Maar erg vaak voldoet de Perl oplossing. Zoals ik al
schreef: als je je druk maakt om die paar milliseconden om een module te
laden, en een method uit te voeren, zit je sowieso al in de verkeerde
taal te werken. En dan heb je vast (nog steeds) niet naar het
geheugengebruik gekeken van Perl...
robert
Oct 4, 2011, 4:28:14 PM10/4/11
to
John Bokma <jo...@castleamber.com>:
8 regeltjes van Jawade sneller zijn.
--
robert
> Jawade <Henk_...@hotmail.com> writes:
>
>> Neem nou het decoden van quoted-printable. Kost mij 8 regeltjes,
>
> Tja, en op zeker met de juiste Perl module een stuk minder... Bijkomend
> voordeel is dat die module getest is door meer mensen dan jijzelf, met
> documentatie komt, en als iemand anders aan jouw script verder kan en wil
> werken, dat het een stuk makkelijker is als dingen met bestaande, en
> wellicht al bekende, modules gedaan is.
>
>> maar ik kan er ook een tooltje voor gebruiken, en dan gaat het nog eens
>> langzamer ook.
>
> Jaaaaa.... een hele milliseconde, wellicht. Als je je echt zo druk zit te
> maken om de snelheid van het verwerken van een command line argument,
> waarom zit je dan in Perl te knoeien?
MIME::QuotedPrint is een XS-module, dus het lijkt me sterk dat die
>
>> Neem nou het decoden van quoted-printable. Kost mij 8 regeltjes,
>
> Tja, en op zeker met de juiste Perl module een stuk minder... Bijkomend
> voordeel is dat die module getest is door meer mensen dan jijzelf, met
> documentatie komt, en als iemand anders aan jouw script verder kan en wil
> werken, dat het een stuk makkelijker is als dingen met bestaande, en
> wellicht al bekende, modules gedaan is.
>
>> maar ik kan er ook een tooltje voor gebruiken, en dan gaat het nog eens
>> langzamer ook.
>
> Jaaaaa.... een hele milliseconde, wellicht. Als je je echt zo druk zit te
> maken om de snelheid van het verwerken van een command line argument,
> waarom zit je dan in Perl te knoeien?
8 regeltjes van Jawade sneller zijn.
--
robert
John Bokma
Oct 4, 2011, 4:58:37 PM10/4/11
to
Voor bonuspunten: kan Jawade's 8 regels alle tests goed doorlopen
(quoted-print.t)?
Message has been deleted
Message has been deleted
John Bokma
Oct 4, 2011, 6:21:44 PM10/4/11
to
Jawade <Henk_...@hotmail.com> writes:
> John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 15:14:22 -0500 in artikel <87ty7oh...@castleamber.com>:
>> Jawade <Henk_...@hotmail.com> writes:
[..]
>> Tja, en op zeker met de juiste Perl module een stuk minder... Bijkomend
>> voordeel is dat die module getest is door meer mensen dan jijzelf, met
>> documentatie komt, en als iemand anders aan jouw script verder kan en
>> wil werken, dat het een stuk makkelijker is als dingen met bestaande, en
>> wellicht al bekende, modules gedaan is.
>
> In dit geval is mijn manier echt beter, zo ingewikkeld is het niet.
Het gaat niet om hoe ingewikkeld het is, maar gewoon wat handiger
is. Zeg nu zelf: schrijf je liever 2 regels of 8 regels.
> En die snelheid is hier belangrijk, het zit in een loop.
Wellicht dan toch de reaktie van robert goed doorlezen. En testen. Het
zal niet de eerste keer zijn dat iemand druk zit te optimaliseren met
eigen code en dan niet alleen een traag wiel aan het uitvinden is, maar een
veel beter wiel mist.
>> > maar ik kan er ook een tooltje voor gebruiken, en dan gaat het nog
>> > eens langzamer ook.
>>
>> Jaaaaa.... een hele milliseconde, wellicht. Als je je echt zo druk zit
>> te maken om de snelheid van het verwerken van een command line argument,
>> waarom zit je dan in Perl te knoeien?
>
> ja, Perl blijft knoeien,
Knoeien heeft hier betrekking op de werkzaamheden, niet op de taal,
uiteraard ;-).
>> Ik zie mijzelf liever meehelpen aan het vervolmaken van een bestaande
>> oplossing, ook omdat die vast door meer mensen gebruikt wordt ;-)
>
> Als ik het vermoeden heb dat ik een verbetering heb, doe ik dat ook,
> maar mijn kennis van Perl is matig.
Niks mis mee, dat was die van mij ook niet eens zo lang geleden. Maar in
principe gaat op voor elke taal: als iemand er al (veel) tijd in
gestoken heeft, kijk eerst of dat niet beter werkt. En als dat (na
testen) niet zo blijkt te zijn, kijk a) of je het beter kan en b) of je
jouw methode als verbetering op die library kan aanbieden. Als dat
laatste ja is, heb je als extra voordeel dat anderen dat stuk code ook
testen.
>> Als die > 1 MB en zelf-installeren van Perl niet wenselijk is, zit je in
>> de verkeerde taal te programmeren, simpel.
>
> Het gaat dan om tooltjes van enkele 10-tallen kB, en dan vind ik het
> krom om er een module van > 1 MB bij te doen.
Kom, kom, CGI.pm is niet 1 MB :-D. Maar, eh, jij vind het niet krom om
bij die 10-tallen kB een complete Perl installatie te stoppen (5MB of
zo?).
> Maar het kan natuurlijk
> wel. Ik zou een perl2exe programma willen hebben die louter en alleen
> de functionaliteit meegeeft die in de source gebruikt wordt. Dan zou
> een module als mijn base64>utf8>iso misschien maar een paar honderd kB
> zijn. Dat zou mooi zijn.
Helaas kan dat niet in het algemeen omdat je dan het halting-probleem
zou oplossen (of: een probleem dat soortgelijk is). Jouw magische
compiler kan namelijk niet altijd zien of een bepaalde functionaliteit
ooit gebruikt wordt in jouw source.
>> > Dat kan, mijn voorkeur voor Perl zijn de krachtige commands.
>>
>> Zoals?
>
> Die vertalingen van base64, utf8, en de NNTP en POP3 sets.
> Hoewel ik er niet altijd alles van begrijp, is het zeer
> beheersbaar voor me, door de geringe afmetingen.
Dat zijn geen "Perl commands" maar bibliotheken, en de meeste
programmeertalen hebben die. Jouw script kan wellicht net zo makkelijk
in Python of zelfs C geschreven worden.
>> > FreeBASIC, mijn favoriet, kent ook C++-style programmeren,
>>
>> Je bedoelt OO?
>
> Als het goed is wel. Er bestaan verschillende ontwikkelomgevingen voor,
> maar ik heb daar geen ervaring mee.
OO is geen ontwikkelomgeving, maar een manier van programeren.
>> > compleet met libraries. Daar ben ik echter niet ver mee,
>> > ondanks de cursus C++ die ik jaren geleden volgde.
>>
>> C++ leer je ook niet echt in 1 cursus. Het is een erg complexe taal. Ik
>> schreef gelook ik al hier ergens dat ik het plan heb om 6+ C++ boeken
>> door te werken ;-) Met 1 boek per maand is dat een cursus van 6 maanden,
>> of ergens tussen de 2500 en 3000 pagina's. Ik lig nu al (aardig) achter,
>> dus wellicht ga ik het niet halen in 6 maanden. Maar goed, de wil is er.
>
> Ik ben er ook en flink aantal maanden mee bezig geweest, maar vond
> de IDE toch niet zo logisch.
Daar zit je toch niet aan vast (IDE)?
> Maar dat wende wel. De basis ken ik nog wel,
Bij het doorwerken van "Efficient C++" had ik dat gevoel ook, maar toch
zijn er 1001 gotcha's.
>> > Ik programmeer nog steeds compact,
>>
>> Je bedoeld dat je druk bezig bent met prematuur optimaliseren. Da's niet
>> goed bij voortplanten, en niet goed bij programmeren ;-).
>
> Het is niet storend, maar verraadt de afkomst. Zoals weinig witregels.
Ah, je bedoelt met compact dat je weing witregels gebruikt. Hopelijk
niet omdat je Perl programma dan net een µs of 2 sneller werkt? Met
premature optimaliseren bedoel ik: wakker liggen van of een bepaald stuk
code al snel genoeg is zonder testen. Zeker met een taal als Perl kan
dat funest zijn, helemaal omdat hetzelfde stuk code op een recentere
versie sneller of langzamer kan draaien. Kijk, als je met assembly bezig
bent, en je kent alle instructies van voor tot achter, dan kan ik mij
voorstellen dat je vaak, zonder er veel over na te denken, dingen doet
omdat je /weet/ dat die efficienter zijn. Maar bij Perl zou je je daar
pas echt druk over moeten maken als een gekozen oplossing niet voldoende
snel genoeg werkt. En nu is het mooie van modules dat voor diverse
modules waar snelheid een rol speelt (parsen, coderen/decoderen, enz.)
er nu en dan modules zijn die deels in C geschreven zijn. En soms zijn
die 1:1 compatible (en soms kijkt een wrapper module welke oplossingen
beschikbaar zijn, en valt terug naar een "Pure Perl" module als er geen
XS variant is, b.v.).
>> Mijn motto is: schrijf het eerst leesbaar. En als het dan te traag gaat:
>> uitzoeken waar het probleem 'm zit, kijken of er een snellere oplossing
>> (module) voor is op CPAN (soms is dat inderdaad zo, er zijn modules die
>> een mix van C en Perl zijn en die een (veel) snellere versie van Pure
>> Perl modules zijn). Maar erg vaak voldoet de Perl oplossing. Zoals ik al
>> schreef: als je je druk maakt om die paar milliseconden om een module te
>> laden, en een method uit te voeren, zit je sowieso al in de verkeerde
>> taal te werken. En dan heb je vast (nog steeds) niet naar het
>> geheugengebruik gekeken van Perl...
>
> Ik schrijf in de source weleens op wat ik wil, zeg maar een soort
> flowchard, en vertaal het dan. Dat doe ik ook in assembly.
Niks mis mee. Ik schrijf soms ook eerst in comments wat de code doet. En
dan de echte code er onder (als een reply op Usenet, zeg maar ;-) ).
> Ik compileer Perl meestal, en waar snelheid essentieel is,
Met compileren bedoel je hier dat perl (executable) + script + modules
in 1 exe ingepakt worden. Ik kan mij niet voorstellen dat het sneller
is. Sterker, met PAR had ik het idee dat het iets trager is met
opstarten.
Als snelheid /echt/ essentieel is kan je beter op CPAN shoppen.
> doe ik het anders. Mijn ervaring is dat Perl best snel is, maar
> sommige commands niet. Zoals base64->utf-8.
Da's geen command, natuurlijk. En wellicht advies van robert opvolgen,
kijk eens naar MIME::QuotedPrint; Perl wrapper rond C code, sneller dan
"compileren" (inpakken tot een exe), of zelf wielen maken.
Als je je code post (die 8 regels) kunnen we eens vergelijken. Zou mij
niets verbazen als MIME::QuotedPrint 20x sneller is.
> John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 15:14:22 -0500 in artikel <87ty7oh...@castleamber.com>:
>> Jawade <Henk_...@hotmail.com> writes:
[..]
>> Tja, en op zeker met de juiste Perl module een stuk minder... Bijkomend
>> voordeel is dat die module getest is door meer mensen dan jijzelf, met
>> documentatie komt, en als iemand anders aan jouw script verder kan en
>> wil werken, dat het een stuk makkelijker is als dingen met bestaande, en
>> wellicht al bekende, modules gedaan is.
>
Het gaat niet om hoe ingewikkeld het is, maar gewoon wat handiger
is. Zeg nu zelf: schrijf je liever 2 regels of 8 regels.
> En die snelheid is hier belangrijk, het zit in een loop.
Wellicht dan toch de reaktie van robert goed doorlezen. En testen. Het
zal niet de eerste keer zijn dat iemand druk zit te optimaliseren met
eigen code en dan niet alleen een traag wiel aan het uitvinden is, maar een
veel beter wiel mist.
>> > maar ik kan er ook een tooltje voor gebruiken, en dan gaat het nog
>> > eens langzamer ook.
>>
>> Jaaaaa.... een hele milliseconde, wellicht. Als je je echt zo druk zit
>> te maken om de snelheid van het verwerken van een command line argument,
>> waarom zit je dan in Perl te knoeien?
>
Knoeien heeft hier betrekking op de werkzaamheden, niet op de taal,
uiteraard ;-).
>> Ik zie mijzelf liever meehelpen aan het vervolmaken van een bestaande
>> oplossing, ook omdat die vast door meer mensen gebruikt wordt ;-)
>
> maar mijn kennis van Perl is matig.
Niks mis mee, dat was die van mij ook niet eens zo lang geleden. Maar in
principe gaat op voor elke taal: als iemand er al (veel) tijd in
gestoken heeft, kijk eerst of dat niet beter werkt. En als dat (na
testen) niet zo blijkt te zijn, kijk a) of je het beter kan en b) of je
jouw methode als verbetering op die library kan aanbieden. Als dat
laatste ja is, heb je als extra voordeel dat anderen dat stuk code ook
testen.
>> Als die > 1 MB en zelf-installeren van Perl niet wenselijk is, zit je in
>> de verkeerde taal te programmeren, simpel.
>
> krom om er een module van > 1 MB bij te doen.
Kom, kom, CGI.pm is niet 1 MB :-D. Maar, eh, jij vind het niet krom om
bij die 10-tallen kB een complete Perl installatie te stoppen (5MB of
zo?).
> Maar het kan natuurlijk
> wel. Ik zou een perl2exe programma willen hebben die louter en alleen
> de functionaliteit meegeeft die in de source gebruikt wordt. Dan zou
> een module als mijn base64>utf8>iso misschien maar een paar honderd kB
> zijn. Dat zou mooi zijn.
Helaas kan dat niet in het algemeen omdat je dan het halting-probleem
zou oplossen (of: een probleem dat soortgelijk is). Jouw magische
compiler kan namelijk niet altijd zien of een bepaalde functionaliteit
ooit gebruikt wordt in jouw source.
>> > Dat kan, mijn voorkeur voor Perl zijn de krachtige commands.
>>
>> Zoals?
>
> Hoewel ik er niet altijd alles van begrijp, is het zeer
> beheersbaar voor me, door de geringe afmetingen.
Dat zijn geen "Perl commands" maar bibliotheken, en de meeste
programmeertalen hebben die. Jouw script kan wellicht net zo makkelijk
in Python of zelfs C geschreven worden.
>> > FreeBASIC, mijn favoriet, kent ook C++-style programmeren,
>>
>> Je bedoelt OO?
>
> maar ik heb daar geen ervaring mee.
OO is geen ontwikkelomgeving, maar een manier van programeren.
>> > compleet met libraries. Daar ben ik echter niet ver mee,
>> > ondanks de cursus C++ die ik jaren geleden volgde.
>>
>> C++ leer je ook niet echt in 1 cursus. Het is een erg complexe taal. Ik
>> schreef gelook ik al hier ergens dat ik het plan heb om 6+ C++ boeken
>> door te werken ;-) Met 1 boek per maand is dat een cursus van 6 maanden,
>> of ergens tussen de 2500 en 3000 pagina's. Ik lig nu al (aardig) achter,
>> dus wellicht ga ik het niet halen in 6 maanden. Maar goed, de wil is er.
>
> de IDE toch niet zo logisch.
Daar zit je toch niet aan vast (IDE)?
> Maar dat wende wel. De basis ken ik nog wel,
Bij het doorwerken van "Efficient C++" had ik dat gevoel ook, maar toch
zijn er 1001 gotcha's.
>> > Ik programmeer nog steeds compact,
>>
>> Je bedoeld dat je druk bezig bent met prematuur optimaliseren. Da's niet
>> goed bij voortplanten, en niet goed bij programmeren ;-).
>
Ah, je bedoelt met compact dat je weing witregels gebruikt. Hopelijk
niet omdat je Perl programma dan net een µs of 2 sneller werkt? Met
premature optimaliseren bedoel ik: wakker liggen van of een bepaald stuk
code al snel genoeg is zonder testen. Zeker met een taal als Perl kan
dat funest zijn, helemaal omdat hetzelfde stuk code op een recentere
versie sneller of langzamer kan draaien. Kijk, als je met assembly bezig
bent, en je kent alle instructies van voor tot achter, dan kan ik mij
voorstellen dat je vaak, zonder er veel over na te denken, dingen doet
omdat je /weet/ dat die efficienter zijn. Maar bij Perl zou je je daar
pas echt druk over moeten maken als een gekozen oplossing niet voldoende
snel genoeg werkt. En nu is het mooie van modules dat voor diverse
modules waar snelheid een rol speelt (parsen, coderen/decoderen, enz.)
er nu en dan modules zijn die deels in C geschreven zijn. En soms zijn
die 1:1 compatible (en soms kijkt een wrapper module welke oplossingen
beschikbaar zijn, en valt terug naar een "Pure Perl" module als er geen
XS variant is, b.v.).
>> Mijn motto is: schrijf het eerst leesbaar. En als het dan te traag gaat:
>> uitzoeken waar het probleem 'm zit, kijken of er een snellere oplossing
>> (module) voor is op CPAN (soms is dat inderdaad zo, er zijn modules die
>> een mix van C en Perl zijn en die een (veel) snellere versie van Pure
>> Perl modules zijn). Maar erg vaak voldoet de Perl oplossing. Zoals ik al
>> schreef: als je je druk maakt om die paar milliseconden om een module te
>> laden, en een method uit te voeren, zit je sowieso al in de verkeerde
>> taal te werken. En dan heb je vast (nog steeds) niet naar het
>> geheugengebruik gekeken van Perl...
>
> flowchard, en vertaal het dan. Dat doe ik ook in assembly.
Niks mis mee. Ik schrijf soms ook eerst in comments wat de code doet. En
dan de echte code er onder (als een reply op Usenet, zeg maar ;-) ).
> Ik compileer Perl meestal, en waar snelheid essentieel is,
Met compileren bedoel je hier dat perl (executable) + script + modules
in 1 exe ingepakt worden. Ik kan mij niet voorstellen dat het sneller
is. Sterker, met PAR had ik het idee dat het iets trager is met
opstarten.
Als snelheid /echt/ essentieel is kan je beter op CPAN shoppen.
> doe ik het anders. Mijn ervaring is dat Perl best snel is, maar
> sommige commands niet. Zoals base64->utf-8.
Da's geen command, natuurlijk. En wellicht advies van robert opvolgen,
kijk eens naar MIME::QuotedPrint; Perl wrapper rond C code, sneller dan
"compileren" (inpakken tot een exe), of zelf wielen maken.
Als je je code post (die 8 regels) kunnen we eens vergelijken. Zou mij
niets verbazen als MIME::QuotedPrint 20x sneller is.
John Bokma
Oct 4, 2011, 6:23:25 PM10/4/11
to
Jawade <Henk_...@hotmail.com> writes:
> robert <US3N37+{n.c.p}@gmail.com> schreef op Tue, 4 Oct 2011 20:28:14 GMT in artikel <slrnj8mr2u...@my.local.lan>:
> Vergis je niet in FB,
Jij vergist je, we hebben het hier nog steeds over Perl.
> die wordt gecompileerd naar pure machinecode.
Net als die XS module, grotendeels.
> Bovendien kost het aanroepen en doorgeven ook tijd.
Goh, en hoeveel aanroepen en doorgaves doe je in die 8 regels Perl?
Meten is weten, kom op met die code ;-)
> robert <US3N37+{n.c.p}@gmail.com> schreef op Tue, 4 Oct 2011 20:28:14 GMT in artikel <slrnj8mr2u...@my.local.lan>:
Jij vergist je, we hebben het hier nog steeds over Perl.
> die wordt gecompileerd naar pure machinecode.
Net als die XS module, grotendeels.
> Bovendien kost het aanroepen en doorgeven ook tijd.
Goh, en hoeveel aanroepen en doorgaves doe je in die 8 regels Perl?
Meten is weten, kom op met die code ;-)
robert
Oct 5, 2011, 1:33:57 AM10/5/11
to
Jawade <Henk_...@hotmail.com>:
Oh, ik dacht dat het over Perl ging?
> die wordt gecompileerd naar pure machinecode.
Dat zegt op zich niet zoveel, ook in 'pure machinecode' kan je trage code
schrijven.
> Bovendien kost het aanroepen en doorgeven ook tijd.
Ik denk dat dat verwaarloosbaar is.
--
robert
> robert <US3N37+{n.c.p}@gmail.com> schreef op Tue, 4 Oct 2011 20:28:14 GMT
> in artikel <slrnj8mr2u...@my.local.lan>:
>>
> in artikel <slrnj8mr2u...@my.local.lan>:
>>
>> MIME::QuotedPrint is een XS-module, dus het lijkt me sterk dat die
>> 8 regeltjes van Jawade sneller zijn.
>
> Vergis je niet in FB...
>> 8 regeltjes van Jawade sneller zijn.
>
Oh, ik dacht dat het over Perl ging?
> die wordt gecompileerd naar pure machinecode.
schrijven.
> Bovendien kost het aanroepen en doorgeven ook tijd.
--
robert
Message has been deleted
Message has been deleted
Message has been deleted
John Bokma
Oct 5, 2011, 1:24:07 PM10/5/11
to
Jawade <Henk_...@hotmail.com> writes:
> John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 17:21:44 -0500 in artikel <87d3ecg...@castleamber.com>:
>> Jawade <Henk_...@hotmail.com> writes:
[..]
>> Het gaat niet om hoe ingewikkeld het is, maar gewoon wat handiger
>> is. Zeg nu zelf: schrijf je liever 2 regels of 8 regels.
>
> Als ik voor die 2e regel weer vanalles op moet starten en compileren,
> schrijf ik er veel liever 8.
En jij bent programmeur? Hoe doe je dat als er een kleine bug in je code
zit? Want dan moet je ook vanalles op starten en compileren. Sterker,
wat moet je starten? Je editor? Die staat toch de hele dag open? En
compileren? Dat is of 1 commando (make, ant, o.i.d.), en dat kan je
vanuit je editor doen met 1 druk op de knop (save, compile, run).
>> Wellicht dan toch de reaktie van robert goed doorlezen. En testen. Het
>> zal niet de eerste keer zijn dat iemand druk zit te optimaliseren met
>> eigen code en dan niet alleen een traag wiel aan het uitvinden is, maar een
>> veel beter wiel mist.
>
> Ik ben ervan overtuigd van niet. De QP>ISO laat me geen snelheidsverschil
> merken.
Heh, ik geloof er niks van dat je MIME::QuotedPrint hebt getest. En
verder, je "merkt" niet, je test.
>> Knoeien heeft hier betrekking op de werkzaamheden, niet op de taal,
>> uiteraard ;-).
>
> Ik vind het ook wel leuk knoeien, louter op feeling krijg ik toch
> wel veel voor elkaar. Al jaren trouwens.
Ik denk dat we daarin verschillen ;-). Ik voel mij nooit prettig als ik
"op feeling" programmeer. Of een boekenkast in elkaar zet. Aan de ene
kant lijkt het dat ik daardoor avontuur mis. Maar da's ook niet waar: ik
ga regelmatig wandelen "off-the-beaten-track". Natuurlijk doe ik dat
niet slechts op feeling (dat zou niet snugger zijn), maar het is ook
niet zo dat ik dat rigide plan.
>> gestoken heeft, kijk eerst of dat niet beter werkt. En als dat (na
>> testen) niet zo blijkt te zijn, kijk a) of je het beter kan en b) of je
>> jouw methode als verbetering op die library kan aanbieden. Als dat
>> laatste ja is, heb je als extra voordeel dat anderen dat stuk code ook
>> testen.
>
> Ik denk dat wat ik maak, niet de moeite is.
Ik kan daar niet over oordelen. Maar ik weet dat dingen die ik "niet de
moeite" vind, voor anderen handig zijn. Sterker, ik zou vaker dingen op
mijn site moeten zetten. Maar ja, tijd, he?
>> Kom, kom, CGI.pm is niet 1 MB :-D. Maar, eh, jij vind het niet krom om
>> bij die 10-tallen kB een complete Perl installatie te stoppen (5MB of
>> zo?).
>
> Ja, dat bedoelde ik. Net zoals je vroeger bij een klein VM-progje
> een loeierd van een runtime moest leveren. Dat vind ik niks.
Wat ik bedoel: jij programmeert nu in Perl, en wil niet een module
installeren omdat het dan te groot wordt. Een module van een paar
*kilo*byte.
>> > Die vertalingen van base64, utf8, en de NNTP en POP3 sets.
>> > Hoewel ik er niet altijd alles van begrijp, is het zeer
>> > beheersbaar voor me, door de geringe afmetingen.
>>
>> Dat zijn geen "Perl commands" maar bibliotheken, en de meeste
>> programmeertalen hebben die. Jouw script kan wellicht net zo makkelijk
>> in Python of zelfs C geschreven worden.
>
> Misschien wel, maar niet zo makkelijk.
In Python: vast niet ingewikkelder. In C: kost misschien ietjes meer
moeite, maar dan heb je ook gelijk iets dat heel compact is ;-). Dat het
"niet zo makkelijk" is, heeft wellicht meer te maken met die andere
talen niet of nauwelijks beheersen.
Maar goed, je hebt voor Perl gekozen, en dan vind ik dat je je
belachelijk druk maakt over het vermeende (!) snelheidsverlies van het
gebruiken van aanroepen van 3rd party code en de toename van een paar KB
op het geheel van een aantal MB...
>> OO is geen ontwikkelomgeving, maar een manier van programeren.
>
> Kom nou, jij weet net zo goed als ik dat je OO eigenlijk alleen
> maar zinnig kunt gebruiken in een visual IDE
Hoe kom je daar nu bij? Of beter: kan je uitleggen waarom je dat denkt?
>> Daar zit je toch niet aan vast (IDE)?
>
> Van Visual C++? Nooit geweten dat er meer zijn.
Ah!
>> Bij het doorwerken van "Efficient C++" had ik dat gevoel ook, maar toch
>> zijn er 1001 gotcha's.
>
> Zal best. Een taal beheers je nooit helemaal. Tegenwoordig.
Ik denk niet dat dat pas "tegenwoordig" is ;-). Ook omdat je aan een
taal alleen niks hebt.
[ "compact" programmeren"
> Die witregels zijn 1 ding. Ook de code moet zo compact mogelijk.
Waarom?
> Perl is niet mijn hoofd-ding, als FB die kunstjes ook kende, had
> ik het er niet eens bij gehaald. Base64 decoderen kan met FB ook
> in een paar regels, maar utf8 is er ook onderdeel van, en die is
> niet even te decoderen met FB.
Tuurlijk wel, alleen weet jij dat niet ;-). utf-8 is gewoon bytes
(octets) met een bepaalde afspraak. En als jij utf-8 naar Latin-1 (IIRC)
wilt omzetten dan zit je met de 7 bits tekens al gebakken, want die zijn
hetzelfde. Hoef je alleen maar een mapping te maken voor 128..255, /en/
een afspraak met jezelf te maken wat te doen met tekens die niet af te
beelden zijn op Latin-1.
>> Als snelheid /echt/ essentieel is kan je beter op CPAN shoppen.
>
> Maar ja, dat lost het compileerdeel niet op. Waarom is er trouwens
> geen echte compiler voor Perl?
Voorbeeld: omdat je in Perl dynamisch een Perl programma kan maken (in
een scalar bijvoorbeeld), en dat uitvoeren middels eval. Dus je hebt het
hele Perl circus nodig om dat te ondersteunen. Daarnaast zitten er in
Perl een massa toeters en bellen. Om een simpel Perl script te
compileren moet die ondersteuning voor toeters en bellen ook mee
(garbage collector, om maar iets te noemen). Kortom, wat jij bedoelt met
"echte compiler": kleine executables (paar KB), geen runtime installeren
kan niet met Perl. Uiteraard kan je /wel/ zoiets maken voor een subset
voor Perl. Voor Python is er bijvoorbeeld Shed Skin (Python -> C++).
>> Als je je code post (die 8 regels) kunnen we eens vergelijken. Zou mij
>> niets verbazen als MIME::QuotedPrint 20x sneller is.
>
> Heb jij een FB-compiler dan?
Die heb ik niet nodig om jouw UTF-8 to ISO Perl programma te testen.
> 1.De ascii-waarde van de hulpregel
Wat is de ascii-waarde van een regel? Sterker, ik denk dat je met
"ASCII-waarde" een octet (byte) bedoelt, met een decimale waarde tussen
0 en 255?
> Als de ascii-waarde 61 is, haal de asciiwaarde van de volgende 2
> plaatsen samen in de regel op, en verhoog de index met 2, en als de
> gevonden asciiwaarde 160 is,
Kijk, dat kan al niet. ASCII is 7 bits, dus dat kan nooit 160 worden ;-).
> Moet toch makkelijk te coden zijn...
Zeker, als ik snap wat je probeerd te doen. Kan je dat in 1 zin
opschrijven? En voorbeeld invoer en uitvoer zou zomaar kunnen helpen.
> John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 17:21:44 -0500 in artikel <87d3ecg...@castleamber.com>:
>> Jawade <Henk_...@hotmail.com> writes:
[..]
>> Het gaat niet om hoe ingewikkeld het is, maar gewoon wat handiger
>> is. Zeg nu zelf: schrijf je liever 2 regels of 8 regels.
>
> schrijf ik er veel liever 8.
En jij bent programmeur? Hoe doe je dat als er een kleine bug in je code
zit? Want dan moet je ook vanalles op starten en compileren. Sterker,
wat moet je starten? Je editor? Die staat toch de hele dag open? En
compileren? Dat is of 1 commando (make, ant, o.i.d.), en dat kan je
vanuit je editor doen met 1 druk op de knop (save, compile, run).
>> Wellicht dan toch de reaktie van robert goed doorlezen. En testen. Het
>> zal niet de eerste keer zijn dat iemand druk zit te optimaliseren met
>> eigen code en dan niet alleen een traag wiel aan het uitvinden is, maar een
>> veel beter wiel mist.
>
> merken.
Heh, ik geloof er niks van dat je MIME::QuotedPrint hebt getest. En
verder, je "merkt" niet, je test.
>> Knoeien heeft hier betrekking op de werkzaamheden, niet op de taal,
>> uiteraard ;-).
>
> wel veel voor elkaar. Al jaren trouwens.
Ik denk dat we daarin verschillen ;-). Ik voel mij nooit prettig als ik
"op feeling" programmeer. Of een boekenkast in elkaar zet. Aan de ene
kant lijkt het dat ik daardoor avontuur mis. Maar da's ook niet waar: ik
ga regelmatig wandelen "off-the-beaten-track". Natuurlijk doe ik dat
niet slechts op feeling (dat zou niet snugger zijn), maar het is ook
niet zo dat ik dat rigide plan.
>> gestoken heeft, kijk eerst of dat niet beter werkt. En als dat (na
>> testen) niet zo blijkt te zijn, kijk a) of je het beter kan en b) of je
>> jouw methode als verbetering op die library kan aanbieden. Als dat
>> laatste ja is, heb je als extra voordeel dat anderen dat stuk code ook
>> testen.
>
Ik kan daar niet over oordelen. Maar ik weet dat dingen die ik "niet de
moeite" vind, voor anderen handig zijn. Sterker, ik zou vaker dingen op
mijn site moeten zetten. Maar ja, tijd, he?
>> Kom, kom, CGI.pm is niet 1 MB :-D. Maar, eh, jij vind het niet krom om
>> bij die 10-tallen kB een complete Perl installatie te stoppen (5MB of
>> zo?).
>
> een loeierd van een runtime moest leveren. Dat vind ik niks.
Wat ik bedoel: jij programmeert nu in Perl, en wil niet een module
installeren omdat het dan te groot wordt. Een module van een paar
*kilo*byte.
>> > Die vertalingen van base64, utf8, en de NNTP en POP3 sets.
>> > Hoewel ik er niet altijd alles van begrijp, is het zeer
>> > beheersbaar voor me, door de geringe afmetingen.
>>
>> Dat zijn geen "Perl commands" maar bibliotheken, en de meeste
>> programmeertalen hebben die. Jouw script kan wellicht net zo makkelijk
>> in Python of zelfs C geschreven worden.
>
In Python: vast niet ingewikkelder. In C: kost misschien ietjes meer
moeite, maar dan heb je ook gelijk iets dat heel compact is ;-). Dat het
"niet zo makkelijk" is, heeft wellicht meer te maken met die andere
talen niet of nauwelijks beheersen.
Maar goed, je hebt voor Perl gekozen, en dan vind ik dat je je
belachelijk druk maakt over het vermeende (!) snelheidsverlies van het
gebruiken van aanroepen van 3rd party code en de toename van een paar KB
op het geheel van een aantal MB...
>> OO is geen ontwikkelomgeving, maar een manier van programeren.
>
> maar zinnig kunt gebruiken in een visual IDE
Hoe kom je daar nu bij? Of beter: kan je uitleggen waarom je dat denkt?
>> Daar zit je toch niet aan vast (IDE)?
>
Ah!
>> Bij het doorwerken van "Efficient C++" had ik dat gevoel ook, maar toch
>> zijn er 1001 gotcha's.
>
Ik denk niet dat dat pas "tegenwoordig" is ;-). Ook omdat je aan een
taal alleen niks hebt.
[ "compact" programmeren"
> Die witregels zijn 1 ding. Ook de code moet zo compact mogelijk.
Waarom?
> Perl is niet mijn hoofd-ding, als FB die kunstjes ook kende, had
> ik het er niet eens bij gehaald. Base64 decoderen kan met FB ook
> in een paar regels, maar utf8 is er ook onderdeel van, en die is
> niet even te decoderen met FB.
Tuurlijk wel, alleen weet jij dat niet ;-). utf-8 is gewoon bytes
(octets) met een bepaalde afspraak. En als jij utf-8 naar Latin-1 (IIRC)
wilt omzetten dan zit je met de 7 bits tekens al gebakken, want die zijn
hetzelfde. Hoef je alleen maar een mapping te maken voor 128..255, /en/
een afspraak met jezelf te maken wat te doen met tekens die niet af te
beelden zijn op Latin-1.
>> Als snelheid /echt/ essentieel is kan je beter op CPAN shoppen.
>
> geen echte compiler voor Perl?
Voorbeeld: omdat je in Perl dynamisch een Perl programma kan maken (in
een scalar bijvoorbeeld), en dat uitvoeren middels eval. Dus je hebt het
hele Perl circus nodig om dat te ondersteunen. Daarnaast zitten er in
Perl een massa toeters en bellen. Om een simpel Perl script te
compileren moet die ondersteuning voor toeters en bellen ook mee
(garbage collector, om maar iets te noemen). Kortom, wat jij bedoelt met
"echte compiler": kleine executables (paar KB), geen runtime installeren
kan niet met Perl. Uiteraard kan je /wel/ zoiets maken voor een subset
voor Perl. Voor Python is er bijvoorbeeld Shed Skin (Python -> C++).
>> Als je je code post (die 8 regels) kunnen we eens vergelijken. Zou mij
>> niets verbazen als MIME::QuotedPrint 20x sneller is.
>
Die heb ik niet nodig om jouw UTF-8 to ISO Perl programma te testen.
> 1.De ascii-waarde van de hulpregel
Wat is de ascii-waarde van een regel? Sterker, ik denk dat je met
"ASCII-waarde" een octet (byte) bedoelt, met een decimale waarde tussen
0 en 255?
> Als de ascii-waarde 61 is, haal de asciiwaarde van de volgende 2
> plaatsen samen in de regel op, en verhoog de index met 2, en als de
> gevonden asciiwaarde 160 is,
Kijk, dat kan al niet. ASCII is 7 bits, dus dat kan nooit 160 worden ;-).
> Moet toch makkelijk te coden zijn...
Zeker, als ik snap wat je probeerd te doen. Kan je dat in 1 zin
opschrijven? En voorbeeld invoer en uitvoer zou zomaar kunnen helpen.
John Bokma
Oct 5, 2011, 1:25:47 PM10/5/11
to
Jawade <Henk_...@hotmail.com> writes:
> John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 17:23:25 -0500 in artikel <878vp0g...@castleamber.com>:
[..]
>> Goh, en hoeveel aanroepen en doorgaves doe je in die 8 regels Perl?
>
> Hij zit in een loop, tot aan het einde van een bericht.
Lijkt mij niet verkeerd om dat decoderen dan in een gecompileerd stuk C
code te laten plaatsvinden ;-). Sterker, waarom decodeer je het hele
bericht (email?) niet in 1x middels een (1) aanroep?
> John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 17:23:25 -0500 in artikel <878vp0g...@castleamber.com>:
[..]
>> Goh, en hoeveel aanroepen en doorgaves doe je in die 8 regels Perl?
>
Lijkt mij niet verkeerd om dat decoderen dan in een gecompileerd stuk C
code te laten plaatsvinden ;-). Sterker, waarom decodeer je het hele
bericht (email?) niet in 1x middels een (1) aanroep?
Message has been deleted
Operator
Oct 6, 2011, 1:54:27 PM10/6/11
to
In article <20111006$195...@jawade.naaldwijk.nl>,
Jawade <Henk_...@hotmail.com> writes:
[...]
> en ik denk dat dat juist vertragend werkt.
Niet denken.
Meten is Weten.
Jawade <Henk_...@hotmail.com> writes:
[...]
> en ik denk dat dat juist vertragend werkt.
Niet denken.
Meten is Weten.
John Bokma
Oct 6, 2011, 2:09:27 PM10/6/11
to
Jawade <Henk_...@hotmail.com> writes:
> John Bokma <jo...@castleamber.com> schreef op Wed, 5 Oct 2011 12:25:47 -0500 in artikel <87r52ri...@castleamber.com>:
> heb, en ik denk dat dat juist vertragend werkt.
Ja, hoor, dat zal reuze vertragend werken. Heb je al eens gekeken
hoeveel geheugen Perl zelf vreet?
Bovendien, als je je druk maakt om geheugengebruik, maak je een buffer
met een specifieke afmeting, en bewerk je het bericht in
stukken. Maar... ik heb het idee dat je je weer nodeloos druk maakt om
dingen die er niet toe doen (in dit geval) en dingen die er wel toe doen
onder het tapijt aan het vegen bent ;-).
Maar goed, post je huidige Perl programma, en dan kijken we hoe het
simpeler & sneller kan ;-)
> John Bokma <jo...@castleamber.com> schreef op Wed, 5 Oct 2011 12:25:47 -0500 in artikel <87r52ri...@castleamber.com>:
>> Jawade <Henk_...@hotmail.com> writes:
>>
>> > John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 17:23:25 -0500 in artikel <878vp0g...@castleamber.com>:
>>
>> [..]
>>
>> >> Goh, en hoeveel aanroepen en doorgaves doe je in die 8 regels Perl?
>> >
>> > Hij zit in een loop, tot aan het einde van een bericht.
>>
>> Lijkt mij niet verkeerd om dat decoderen dan in een gecompileerd stuk C
>> code te laten plaatsvinden ;-). Sterker, waarom decodeer je het hele
>> bericht (email?) niet in 1x middels een (1) aanroep?
>
> Nou, dan kan het voorkomen dat ik een lelijk groot buffertje nodig
>>
>> > John Bokma <jo...@castleamber.com> schreef op Tue, 4 Oct 2011 17:23:25 -0500 in artikel <878vp0g...@castleamber.com>:
>>
>> [..]
>>
>> >> Goh, en hoeveel aanroepen en doorgaves doe je in die 8 regels Perl?
>> >
>> > Hij zit in een loop, tot aan het einde van een bericht.
>>
>> Lijkt mij niet verkeerd om dat decoderen dan in een gecompileerd stuk C
>> code te laten plaatsvinden ;-). Sterker, waarom decodeer je het hele
>> bericht (email?) niet in 1x middels een (1) aanroep?
>
> heb, en ik denk dat dat juist vertragend werkt.
Ja, hoor, dat zal reuze vertragend werken. Heb je al eens gekeken
hoeveel geheugen Perl zelf vreet?
Bovendien, als je je druk maakt om geheugengebruik, maak je een buffer
met een specifieke afmeting, en bewerk je het bericht in
stukken. Maar... ik heb het idee dat je je weer nodeloos druk maakt om
dingen die er niet toe doen (in dit geval) en dingen die er wel toe doen
onder het tapijt aan het vegen bent ;-).
Maar goed, post je huidige Perl programma, en dan kijken we hoe het
simpeler & sneller kan ;-)
Message has been deleted
robert
Oct 6, 2011, 2:46:17 PM10/6/11
to
Jawade <Henk_...@hotmail.com>:
> base64 omzetten in Perl is erg traag.
Laat dan toch eens die Perl-code zien, want als het traag gaat dan is er
iets mis: MIME::Base64 is vrijwel pure C-code namelijk, en nog behoorlijk
geoptimaliseerde code ook.
Even een testje: een file van 83MB encoderen gaat in 1.324 seconden (=
63MB/s), decoderen van de uitvoer (die ongeveer 112MB groot is) gaat
vrijwel even snel: 1.429 seconden (= 79MB/s).
Ik gebruik deze code:
-knip-
#!/usr/bin/perl
use strict;
use warnings;
use MIME::Base64;
undef $/;
my $func = ($0 =~ /encode$/) ? \&encode_base64 : \&decode_base64;
print &$func(<>), "\n";
-knip-
>> Wat is de ascii-waarde van een regel? Sterker, ik denk dat je met
>> "ASCII-waarde" een octet (byte) bedoelt, met een decimale waarde tussen
>> 0 en 255?
>
> Heet in veel talen asc(n).
Ik denk dat je in de war bent met chr() en z'n tegenhanger ord().
>> Kijk, dat kan al niet. ASCII is 7 bits, dus dat kan nooit 160 worden
>> ;-).
>
> Ben jij nou programmeur? Nooit van asc(128) of asc(255) gehoord?
Ik ben benieuwd over welke programmeertaal je het hebt, want de ASCII
karakterset telt maar tot 128.
--
robert
> base64 omzetten in Perl is erg traag.
Laat dan toch eens die Perl-code zien, want als het traag gaat dan is er
iets mis: MIME::Base64 is vrijwel pure C-code namelijk, en nog behoorlijk
geoptimaliseerde code ook.
Even een testje: een file van 83MB encoderen gaat in 1.324 seconden (=
63MB/s), decoderen van de uitvoer (die ongeveer 112MB groot is) gaat
vrijwel even snel: 1.429 seconden (= 79MB/s).
Ik gebruik deze code:
-knip-
#!/usr/bin/perl
use strict;
use warnings;
use MIME::Base64;
undef $/;
my $func = ($0 =~ /encode$/) ? \&encode_base64 : \&decode_base64;
print &$func(<>), "\n";
-knip-
>> Wat is de ascii-waarde van een regel? Sterker, ik denk dat je met
>> "ASCII-waarde" een octet (byte) bedoelt, met een decimale waarde tussen
>> 0 en 255?
>
Ik denk dat je in de war bent met chr() en z'n tegenhanger ord().
>> Kijk, dat kan al niet. ASCII is 7 bits, dus dat kan nooit 160 worden
>> ;-).
>
Ik ben benieuwd over welke programmeertaal je het hebt, want de ASCII
karakterset telt maar tot 128.
--
robert
John Bokma
Oct 6, 2011, 3:30:09 PM10/6/11
to
Jawade <Henk_...@hotmail.com> writes:
> John Bokma <jo...@castleamber.com> schreef op Wed, 5 Oct 2011 12:24:07 -0500 in artikel <87vcs3i...@castleamber.com>:
>> Jawade <Henk_...@hotmail.com> writes:
[..]
>> En jij bent programmeur? Hoe doe je dat als er een kleine bug in je code
>> zit? Want dan moet je ook vanalles op starten en compileren. Sterker,
>> wat moet je starten? Je editor? Die staat toch de hele dag open? En
>> compileren? Dat is of 1 commando (make, ant, o.i.d.), en dat kan je
>> vanuit je editor doen met 1 druk op de knop (save, compile, run).
>
> Ik maak zelden fouten, soms een syntaxfout. Nee, liever due 8 regels,
> is beter voor de snelheid ook, heb ik al lang gemerkt. base64 werkt
> vanuit Perl ook traag, terwijl het mij in FB -even spieken - 13 regels
> kost. Dus die ga ik ook in FB gebruiken.
Tja, je roept maar wat, en zonder code zelf te kunnen zien is daar niks
van te zeggen. En als "FB" een exe maakt zou het mij verder niet
verbazen dat dat sneller is omdat je lijkt te vergeten dat perl starten
ook tijd kost. Maar het hele: x regels is sneller dan een call naar een
library van 1 regel is dom geleuter als dat een gevoelskwestie is,
zonder enige vorm van testen.
>> Heh, ik geloof er niks van dat je MIME::QuotedPrint hebt getest. En
>> verder, je "merkt" niet, je test.
>
> Nee, ik heb die niet getest,
Goh...
> maar ben er erg zeker van dat het in FB
> sneller is,
Ja, als FB een exe aanmaakt zal dat vast zo zijn, zie boven.
> het is maar een klein stukje code. In een bestaande loop
> maar 1 regel. Te weten:
Onzichtbare code, leuk.
[ programmeren ]
> Nee, op feeling programmeren is niet de manier, maar de enkele keer
> dat ik in Perl werk, probeer ik weleens wat op de gok, omdat ik anders
> een zoektocht moet organiseren. En regelmatig met positief resultaat.
Ik begrijp dat nooit: mensen die liever 1 uur aankloten (gokken), dan 10
minuten zich inlezen. Zeker niet omdat inlezen makkelijker te herinneren
is dan: oja, ik heb toen een uur zitten kloten, maar wat werkte ook alweer.
>> Wat ik bedoel: jij programmeert nu in Perl, en wil niet een module
>> installeren omdat het dan te groot wordt. Een module van een paar
>> *kilo*byte.
>
> Het voornaamste bij wat ik maak, is dat een leek het ook kan gebruiken,
> zonder allerlei omwegen. Dat doe ik zelfs voor mijn usenetclient, en
> die geef ik niet eens uit.
Dat staat los van: je gebruikt Perl, en vind een module installeren te
veel moeite. Als je verwacht dat een ander Perl installeert mag je ook
wel verwachten dat een module geinstalleerd wordt. Zeker met ActivePerl
is dat allemaal een fluitje van een cent (en evt. nog in een GUI ook).
>> Maar goed, je hebt voor Perl gekozen, en dan vind ik dat je je
>> belachelijk druk maakt over het vermeende (!) snelheidsverlies van het
>> gebruiken van aanroepen van 3rd party code en de toename van een paar KB
>> op het geheel van een aantal MB...
>
>> > Kom nou, jij weet net zo goed als ik dat je OO eigenlijk alleen
>> > maar zinnig kunt gebruiken in een visual IDE
>>
>> Hoe kom je daar nu bij? Of beter: kan je uitleggen waarom je dat denkt?
>
> Een paar knoppen maken is in Visual Basic/C++ een fluitje van een
> cent, maar in een 'gewone' editor wel wat meer werk.
OO heeft niks met knoppen te maken. En verder, het hangt er vanaf wat je
doet: sommige vensters zijn makkelijker met het handje te coderen dan
met de muis van alles lopen slepen en kopieeren. En dan zijn er ook
programma's waar je je UI in kan tekenen, terwijl je programmeert in,
bijvoorbeeld, Emacs (zie b.v. Qt Designer, been there, done that).
[ taal beheersen ]
> Van de 6502 kende ik alle 151 instructies. Van de BASIC op die
> machine kende ik ook alles.
Instructies kennen is niet hetzelfde als een taal beheersen. Het
woordenboek uit je hoofd leren maakt je niet een goede schrijver. Ook
van Python kan je zo alle "instructies" leren. Maar dat maakt je zeker
geen goede Python programmeur, per se.
[code compact]
>> Waarom?
>
> Tja, dat is die 'ziekte' he. Maar ik ben mijn leven al aan 't beteren,
> soms gebruik ik 2 of 3 keer hetzelfde stuk code met kleine verschillen,
> zonder dat weer eenmalig in een sub te stoppen.
Het ligt aan hoe lang dat stuk code is, of dat een probleem is. Kleine
verschillen kan je soms opvangen met een extra parameter, of gebruik een
hogere-orde functie, en geef er een mee die de verschillen afhandelt.
>> > Perl is niet mijn hoofd-ding, als FB die kunstjes ook kende, had
>> > ik het er niet eens bij gehaald. Base64 decoderen kan met FB ook
>> > in een paar regels, maar utf8 is er ook onderdeel van, en die is
>> > niet even te decoderen met FB.
>>
>> Tuurlijk wel, alleen weet jij dat niet ;-). utf-8 is gewoon bytes
>> (octets) met een bepaalde afspraak. En als jij utf-8 naar Latin-1 (IIRC)
>> wilt omzetten dan zit je met de 7 bits tekens al gebakken, want die zijn
>> hetzelfde. Hoef je alleen maar een mapping te maken voor 128..255, /en/
>> een afspraak met jezelf te maken wat te doen met tekens die niet af te
>> beelden zijn op Latin-1.
>
> Wordt veel te groot, er zij er duizenden.
Maar die zijn allemaal niet af te beelden op Latin-1, dus daar kan je
niks mee. Dus moet je afspreken wat je er mee gaat doen; bijvoorbeeld:
ik geef een ? weer als ik er niks mee kan. Kortom: als het 7-bits is,
dan kan je het 1:1 overnemen. Als het "hoger" is, dan moet je beslissen:
kan ik deze afbeelden in Latin 1: als ja, dan doe je dat, als nee, dan
druk je (bijvoorbeeld) een vraagteken af. Die 2e doe je met een
look-up-table, en daar zitten max 128 tekens in. Eitje, toch?
>> Voorbeeld: omdat je in Perl dynamisch een Perl programma kan maken (in
>> een scalar bijvoorbeeld), en dat uitvoeren middels eval. Dus je hebt het
>> hele Perl circus nodig om dat te ondersteunen. Daarnaast zitten er in
>> Perl een massa toeters en bellen. Om een simpel Perl script te
>> compileren moet die ondersteuning voor toeters en bellen ook mee
>> (garbage collector, om maar iets te noemen). Kortom, wat jij bedoelt met
>> "echte compiler": kleine executables (paar KB), geen runtime installeren
>> kan niet met Perl. Uiteraard kan je /wel/ zoiets maken voor een subset
>> voor Perl. Voor Python is er bijvoorbeeld Shed Skin (Python -> C++).
>
> Het had mooi geweest, juist omdat ik in mijn meeste scriptjes maar
> een zeer beperkt aantal instructies gebruik.
Python leren, en Shed Skin gebruiken, dan ;-) Verder is het niet zozeer
dat jij slechts een subset gebruikt van Perl, maar dat je ook het juiste
subset gebruikt *en* hints moet geven. Dingen als:
my $x = "17";
$x *= 3;
$x .= ' euro';
zorgen ervoor dat er een hele bak extra gecompileerde code in je exe mee
moet komen.
>> > 1.De ascii-waarde van de hulpregel
>>
>> Wat is de ascii-waarde van een regel? Sterker, ik denk dat je met
>> "ASCII-waarde" een octet (byte) bedoelt, met een decimale waarde tussen
>> 0 en 255?
>
definitie/ 7 bits. Dat iemand een functie die een octet oplevert asc
noemt, maakt dat niet minder waar.
>> Kijk, dat kan al niet. ASCII is 7 bits, dus dat kan nooit 160 worden ;-).
>
>> Zeker, als ik snap wat je probeerd te doen. Kan je dat in 1 zin
>> opschrijven? En voorbeeld invoer en uitvoer zou zomaar kunnen helpen.
>
> Ik zou het aan de hand van dit stukje zo kunnen coden.
Dat mag ik hopen, omdat /jij/ die "specificatie" op geschreven hebt.
> De invoer is een regel 'regel', de uitvoer ook. Ik heb hem overigens
> teruggebracht naar 5 regels.
Allemaal heel mooi, maar het is mij nog steeds niet duidelijk wat de
ASCII code (of de asc) van 1 regel is...
> John Bokma <jo...@castleamber.com> schreef op Wed, 5 Oct 2011 12:24:07 -0500 in artikel <87vcs3i...@castleamber.com>:
>> Jawade <Henk_...@hotmail.com> writes:
[..]
>> En jij bent programmeur? Hoe doe je dat als er een kleine bug in je code
>> zit? Want dan moet je ook vanalles op starten en compileren. Sterker,
>> wat moet je starten? Je editor? Die staat toch de hele dag open? En
>> compileren? Dat is of 1 commando (make, ant, o.i.d.), en dat kan je
>> vanuit je editor doen met 1 druk op de knop (save, compile, run).
>
> is beter voor de snelheid ook, heb ik al lang gemerkt. base64 werkt
> vanuit Perl ook traag, terwijl het mij in FB -even spieken - 13 regels
> kost. Dus die ga ik ook in FB gebruiken.
Tja, je roept maar wat, en zonder code zelf te kunnen zien is daar niks
van te zeggen. En als "FB" een exe maakt zou het mij verder niet
verbazen dat dat sneller is omdat je lijkt te vergeten dat perl starten
ook tijd kost. Maar het hele: x regels is sneller dan een call naar een
library van 1 regel is dom geleuter als dat een gevoelskwestie is,
zonder enige vorm van testen.
>> Heh, ik geloof er niks van dat je MIME::QuotedPrint hebt getest. En
>> verder, je "merkt" niet, je test.
>
Goh...
> maar ben er erg zeker van dat het in FB
> sneller is,
Ja, als FB een exe aanmaakt zal dat vast zo zijn, zie boven.
> het is maar een klein stukje code. In een bestaande loop
> maar 1 regel. Te weten:
Onzichtbare code, leuk.
[ programmeren ]
> Nee, op feeling programmeren is niet de manier, maar de enkele keer
> dat ik in Perl werk, probeer ik weleens wat op de gok, omdat ik anders
> een zoektocht moet organiseren. En regelmatig met positief resultaat.
Ik begrijp dat nooit: mensen die liever 1 uur aankloten (gokken), dan 10
minuten zich inlezen. Zeker niet omdat inlezen makkelijker te herinneren
is dan: oja, ik heb toen een uur zitten kloten, maar wat werkte ook alweer.
>> Wat ik bedoel: jij programmeert nu in Perl, en wil niet een module
>> installeren omdat het dan te groot wordt. Een module van een paar
>> *kilo*byte.
>
> zonder allerlei omwegen. Dat doe ik zelfs voor mijn usenetclient, en
> die geef ik niet eens uit.
Dat staat los van: je gebruikt Perl, en vind een module installeren te
veel moeite. Als je verwacht dat een ander Perl installeert mag je ook
wel verwachten dat een module geinstalleerd wordt. Zeker met ActivePerl
is dat allemaal een fluitje van een cent (en evt. nog in een GUI ook).
>> Maar goed, je hebt voor Perl gekozen, en dan vind ik dat je je
>> belachelijk druk maakt over het vermeende (!) snelheidsverlies van het
>> gebruiken van aanroepen van 3rd party code en de toename van een paar KB
>> op het geheel van een aantal MB...
>
> base64 omzetten in Perl is erg traag.
Zie boven.
>> > Kom nou, jij weet net zo goed als ik dat je OO eigenlijk alleen
>> > maar zinnig kunt gebruiken in een visual IDE
>>
>> Hoe kom je daar nu bij? Of beter: kan je uitleggen waarom je dat denkt?
>
> cent, maar in een 'gewone' editor wel wat meer werk.
OO heeft niks met knoppen te maken. En verder, het hangt er vanaf wat je
doet: sommige vensters zijn makkelijker met het handje te coderen dan
met de muis van alles lopen slepen en kopieeren. En dan zijn er ook
programma's waar je je UI in kan tekenen, terwijl je programmeert in,
bijvoorbeeld, Emacs (zie b.v. Qt Designer, been there, done that).
[ taal beheersen ]
> Van de 6502 kende ik alle 151 instructies. Van de BASIC op die
> machine kende ik ook alles.
Instructies kennen is niet hetzelfde als een taal beheersen. Het
woordenboek uit je hoofd leren maakt je niet een goede schrijver. Ook
van Python kan je zo alle "instructies" leren. Maar dat maakt je zeker
geen goede Python programmeur, per se.
[code compact]
>> Waarom?
>
> Tja, dat is die 'ziekte' he. Maar ik ben mijn leven al aan 't beteren,
> soms gebruik ik 2 of 3 keer hetzelfde stuk code met kleine verschillen,
> zonder dat weer eenmalig in een sub te stoppen.
Het ligt aan hoe lang dat stuk code is, of dat een probleem is. Kleine
verschillen kan je soms opvangen met een extra parameter, of gebruik een
hogere-orde functie, en geef er een mee die de verschillen afhandelt.
>> > Perl is niet mijn hoofd-ding, als FB die kunstjes ook kende, had
>> > ik het er niet eens bij gehaald. Base64 decoderen kan met FB ook
>> > in een paar regels, maar utf8 is er ook onderdeel van, en die is
>> > niet even te decoderen met FB.
>>
>> Tuurlijk wel, alleen weet jij dat niet ;-). utf-8 is gewoon bytes
>> (octets) met een bepaalde afspraak. En als jij utf-8 naar Latin-1 (IIRC)
>> wilt omzetten dan zit je met de 7 bits tekens al gebakken, want die zijn
>> hetzelfde. Hoef je alleen maar een mapping te maken voor 128..255, /en/
>> een afspraak met jezelf te maken wat te doen met tekens die niet af te
>> beelden zijn op Latin-1.
>
Maar die zijn allemaal niet af te beelden op Latin-1, dus daar kan je
niks mee. Dus moet je afspreken wat je er mee gaat doen; bijvoorbeeld:
ik geef een ? weer als ik er niks mee kan. Kortom: als het 7-bits is,
dan kan je het 1:1 overnemen. Als het "hoger" is, dan moet je beslissen:
kan ik deze afbeelden in Latin 1: als ja, dan doe je dat, als nee, dan
druk je (bijvoorbeeld) een vraagteken af. Die 2e doe je met een
look-up-table, en daar zitten max 128 tekens in. Eitje, toch?
>> Voorbeeld: omdat je in Perl dynamisch een Perl programma kan maken (in
>> een scalar bijvoorbeeld), en dat uitvoeren middels eval. Dus je hebt het
>> hele Perl circus nodig om dat te ondersteunen. Daarnaast zitten er in
>> Perl een massa toeters en bellen. Om een simpel Perl script te
>> compileren moet die ondersteuning voor toeters en bellen ook mee
>> (garbage collector, om maar iets te noemen). Kortom, wat jij bedoelt met
>> "echte compiler": kleine executables (paar KB), geen runtime installeren
>> kan niet met Perl. Uiteraard kan je /wel/ zoiets maken voor een subset
>> voor Perl. Voor Python is er bijvoorbeeld Shed Skin (Python -> C++).
>
> een zeer beperkt aantal instructies gebruik.
Python leren, en Shed Skin gebruiken, dan ;-) Verder is het niet zozeer
dat jij slechts een subset gebruikt van Perl, maar dat je ook het juiste
subset gebruikt *en* hints moet geven. Dingen als:
my $x = "17";
$x *= 3;
$x .= ' euro';
zorgen ervoor dat er een hele bak extra gecompileerde code in je exe mee
moet komen.
>> > 1.De ascii-waarde van de hulpregel
>>
>> Wat is de ascii-waarde van een regel? Sterker, ik denk dat je met
>> "ASCII-waarde" een octet (byte) bedoelt, met een decimale waarde tussen
>> 0 en 255?
>
> Heet in veel talen asc(n).
Ja, in Apache heet een referrer ook een 'referer' [sic]. ASCII is /per
definitie/ 7 bits. Dat iemand een functie die een octet oplevert asc
noemt, maakt dat niet minder waar.
>> Kijk, dat kan al niet. ASCII is 7 bits, dus dat kan nooit 160 worden ;-).
>
> Ben jij nou programmeur? Nooit van asc(128) of asc(255) gehoord?
Tuurlijk wel. Maar ik heb ook gehoord dat ASCII /per definitie/ 7 bits i.s
>> Zeker, als ik snap wat je probeerd te doen. Kan je dat in 1 zin
>> opschrijven? En voorbeeld invoer en uitvoer zou zomaar kunnen helpen.
>
Dat mag ik hopen, omdat /jij/ die "specificatie" op geschreven hebt.
> De invoer is een regel 'regel', de uitvoer ook. Ik heb hem overigens
> teruggebracht naar 5 regels.
Allemaal heel mooi, maar het is mij nog steeds niet duidelijk wat de
ASCII code (of de asc) van 1 regel is...
John Bokma
Oct 6, 2011, 3:39:36 PM10/6/11
to
> Jawade <Henk_...@hotmail.com>:
>> base64 omzetten in Perl is erg traag.
>
> Laat dan toch eens die Perl-code zien, want als het traag gaat dan is er
> iets mis: MIME::Base64 is vrijwel pure C-code namelijk, en nog behoorlijk
> geoptimaliseerde code ook.
Ik gok dat Jawade de opstarttijd van perl er ook bij betrekt. En ja, als
>> base64 omzetten in Perl is erg traag.
>
> Laat dan toch eens die Perl-code zien, want als het traag gaat dan is er
> iets mis: MIME::Base64 is vrijwel pure C-code namelijk, en nog behoorlijk
> geoptimaliseerde code ook.
je dan een string van 10 tekens wilt decoderen, dan zal dat decoderen
vast verzuipen in de opstarttijd van perl zelf.
>> Heet in veel talen asc(n).
>
> Ik denk dat je in de war bent met chr() en z'n tegenhanger ord().
inderdaad een ASC functie, voorbeeld:
http://msdn.microsoft.com/en-us/library/xfw01fx4%28v=vs.85%29.aspx
"Returns the *ANSI* character code corresponding to the first letter in a
string." (nadruk door mij).
Dat ding is gewoon ooit foutief ASC genoemd. Net zoals we het bij Apache
webserver (& co) over de 'referer'[sic] hebben, omdat Phillip
Hallam-Baker het zo opschreef.
Operator
Oct 6, 2011, 3:43:13 PM10/6/11
to
In article <87k48hz...@castleamber.com>,
John Bokma <jo...@castleamber.com> writes:
> Jawade <Henk_...@hotmail.com> writes:
[...]
John Bokma <jo...@castleamber.com> writes:
> Jawade <Henk_...@hotmail.com> writes:
[...]
>> maar 1 regel. Te weten:
>
> Onzichtbare code, leuk.
https://metacpan.org/module/Acme::Bleach
>
> Onzichtbare code, leuk.
Message has been deleted
robert
Oct 6, 2011, 3:53:00 PM10/6/11
to
robert
Oct 6, 2011, 3:58:50 PM10/6/11
to
John Bokma <jo...@castleamber.com>:
van z'n code te zien, dus moet ik maar van PICNIC uitgaan.
>>> Heet in veel talen asc(n).
>>
>> Ik denk dat je in de war bent met chr() en z'n tegenhanger ord().
>
> In een aantal BASIC dialecten (en wellicht daarbuiten ook), is er
> inderdaad een ASC functie...
Die 'in veel talen' is eigenlijk 'in BASIC' :)
--
robert
> US3N37+{n.c.p}@gmail.com (robert) writes:
>
>> Jawade <Henk_...@hotmail.com>:
>>> base64 omzetten in Perl is erg traag.
>>
>> Laat dan toch eens die Perl-code zien, want als het traag gaat dan is er
>> iets mis: MIME::Base64 is vrijwel pure C-code namelijk, en nog
>> behoorlijk geoptimaliseerde code ook.
>
> Ik gok dat Jawade de opstarttijd van perl er ook bij betrekt. En ja, als
> je dan een string van 10 tekens wilt decoderen, dan zal dat decoderen
> vast verzuipen in de opstarttijd van perl zelf.
In dat geval wil ik dat ook wel geloven ja. Maar vooralsnog krijgen we niks
>
>> Jawade <Henk_...@hotmail.com>:
>>> base64 omzetten in Perl is erg traag.
>>
>> Laat dan toch eens die Perl-code zien, want als het traag gaat dan is er
>> iets mis: MIME::Base64 is vrijwel pure C-code namelijk, en nog
>> behoorlijk geoptimaliseerde code ook.
>
> Ik gok dat Jawade de opstarttijd van perl er ook bij betrekt. En ja, als
> je dan een string van 10 tekens wilt decoderen, dan zal dat decoderen
> vast verzuipen in de opstarttijd van perl zelf.
van z'n code te zien, dus moet ik maar van PICNIC uitgaan.
>>> Heet in veel talen asc(n).
>>
>> Ik denk dat je in de war bent met chr() en z'n tegenhanger ord().
>
> In een aantal BASIC dialecten (en wellicht daarbuiten ook), is er
Die 'in veel talen' is eigenlijk 'in BASIC' :)
--
robert
robert
Oct 6, 2011, 4:00:54 PM10/6/11
to
Operator <ro...@dragon.doktercom.nl>:
> https://metacpan.org/module/Acme::Bleach
Trouwens, dit is ook een briljante module:
https://metacpan.org/module/Acme::EyeDrops
--
robert
> https://metacpan.org/module/Acme::Bleach
Trouwens, dit is ook een briljante module:
https://metacpan.org/module/Acme::EyeDrops
--
robert
John Bokma
Oct 6, 2011, 4:01:11 PM10/6/11
to
Jawade <Henk_...@hotmail.com> writes:
> John Bokma <jo...@castleamber.com> schreef op Thu, 6 Oct 2011 14:30:09 -0500 in artikel <87k48hz...@castleamber.com>:
> gezien.
Henk, ik ben mij daar niet van bewust. En het helpt als je precies
aangeeft waar ik "stom" aan het "lullen" bent. Verder denk ik dat je je
meer aangevallen voelt dan dat ik stom aan het lullen bent. Dat
aanvallen komt voornamelijk omdat je:
* beweringen niet onderbouwt
* overduidelijk onjuiste beweringen doet
* dingen doet waarvan ik vind dat een programmeur ze niet hoort te
doen [1]
[megaknip]
[1] maar ik soms in bepaalde gevallen mij ook schuldig aan maak ;-)
> John Bokma <jo...@castleamber.com> schreef op Thu, 6 Oct 2011 14:30:09 -0500 in artikel <87k48hz...@castleamber.com>:
>> Jawade <Henk_...@hotmail.com> writes:
>>
>> > John Bokma <jo...@castleamber.com> schreef op Wed, 5 Oct 2011 12:24:07 -0500 in artikel <87vcs3i...@castleamber.com>:
>> >> Jawade <Henk_...@hotmail.com> writes:
>>
>> [..]
>
> Sorry John, je verzandt weer in stom lullen, ik heb het weer even
>>
>> > John Bokma <jo...@castleamber.com> schreef op Wed, 5 Oct 2011 12:24:07 -0500 in artikel <87vcs3i...@castleamber.com>:
>> >> Jawade <Henk_...@hotmail.com> writes:
>>
>> [..]
>
> gezien.
Henk, ik ben mij daar niet van bewust. En het helpt als je precies
aangeeft waar ik "stom" aan het "lullen" bent. Verder denk ik dat je je
meer aangevallen voelt dan dat ik stom aan het lullen bent. Dat
aanvallen komt voornamelijk omdat je:
* beweringen niet onderbouwt
* overduidelijk onjuiste beweringen doet
* dingen doet waarvan ik vind dat een programmeur ze niet hoort te
doen [1]
[megaknip]
[1] maar ik soms in bepaalde gevallen mij ook schuldig aan maak ;-)
John Bokma
Oct 6, 2011, 4:07:38 PM10/6/11
to
Verder ben ik van mening dat hoe leesbaar code is erg van de programmeur
afhangt. Ik heb ooit een stuk PASCAL omgezet naar Perl (in opdracht), en
er was een ellelange functie die na goed bestuderen te vervangen was
door een paar regels Perl (het deed een bubble sort, en na sorteren werd
het resultaat in omgekeerde volgorde geplaatst, in +/- 120 regels PASCAL
of zo).
Operator
Oct 6, 2011, 4:19:20 PM10/6/11
to
In article <slrnj8s27m...@my.local.lan>,
Tevens voorzien van meer documentatie en handleidingen
dan welk basic programma dan ook.
0 new messages