Re: Periodic Table of the Operators
Thanks for all the comments. I started this thing as a goof, but I can already see that it will serve dual purposes. Presenting information in such a form can lead people to further insights and questions. Deborah Pickett's comments in this thread are an example. (For some real inspiring examples, see Edward Tufte's Visual Explanations.) To answer some comments: What's periodic about it? and We hope it will be periodically updated. :) I am preparing a second edition incorporating the corrections. While I don't anticipate updating the chart this frequently in general, I would like it to be mostly accurate at the start. Thereafter I'd be happy to update it when Michael Lazzaro publishes the next version of the operator list. (Perhaps he can give me a heads up and we'll strive for a simultaneous release!) I'd like to have this on a big poster, once it's up to date. Perhaps you can set up a Cafepress store for this? I will just as soon as the second edition is complete. a few other words like 'termplars' don't make much sense to me. The group names are, admittedly, flights of fancy. Not all of them make sense, some are deliberate jokes, and many just sound funny to me. Declars seems to be a term in use 'round these parts. Some of the items in Michael's list were named terms. The Templars were crusading monks in the Middle Ages. And so I arrived at Termplars. Then Bazaars just came naturally. You weren't expecting any logic to this, were you? - Mark Mark Lentczner http://www.ozonehouse.com/mark/ [EMAIL PROTECTED]
Predicting Operators
Uri Guttman wrote: are you going to predict any new operators based on missing boxes as mendeleev did? :) Funny you should ask! It is clear that there is a missing list concatenate operator, and that its spelling should be ~~. Alas, that is already taken by smart match. On the other hand, perhaps comma fills this role - though I couldn't find my way through the discussion on comma to know where it now stands. I was going to predict a quasi-operator for an alternate form of qw/.../, but seems I just missed the thread where «...» was introduced for that purpose. It will be corrected in the next version of the chart. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ [EMAIL PROTECTED]
[perl #29917] bug on yy_init
# New Ticket Created by Midnight # Please include the string: [perl #29917] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29917 Under windows (I didn't try on unix), yy_init is not reinitialised after yyparse call. It is not possible to compile parrot assembler two times in the same process because the static variable yy_init in imclexer.c is set to 0 after the first parsing.
[perl #29924] [PATCH] Data::Escape-String quoting problem.
# New Ticket Created by Will Coleda # Please include the string: [perl #29924] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29924 Escaping quotes doesn't seem to work: bash-2.05a$ cat quoting.imc .sub main @MAIN load_bytecode library/Data/Escape.imc .local string foo .local pmc escape escape = find_global Data::Escape;, String print NONE: foo = \ foo = escape(foo) print foo print \n print \: foo = \ foo = escape(foo,\) print foo print \n print ': foo = \ foo = escape(foo,\') print foo print \n end .end bash-2.05a$ ./parrot quoting.imc NONE: :\ ':\' None of which generate the escaped double quote I expected. The following patch: bash-2.05a$ cvs diff library/Data/Escape.imc Index: library/Data/Escape.imc === RCS file: /cvs/public/parrot/library/Data/Escape.imc,v retrieving revision 1.3 diff -u -r1.3 Escape.imc --- library/Data/Escape.imc 17 May 2004 13:41:48 - 1.3 +++ library/Data/Escape.imc 28 May 2004 04:05:28 - @@ -99,7 +99,7 @@ # ne char, '', n34 if c != 34 goto n34 -set tmp, '\\' +set tmp, \\\ branch DONE n34: Changes the output to the slightly more expected: bash-2.05a$ ./parrot quoting.imc NONE: :\ ':\'
Re: JIT problem on Cygwin revisited
--- Leopold Toetsch [EMAIL PROTECTED] wrote: I think next step would need to review Cygwin math lib sources and trace into the library. Nasty. Parrot isn't using GMP right? I am not sure where to go look for the math lib sources other than the math header /usr/include/math.h ??? Is your Cygwin uptodate? I have a complete install that I update daily. Beyond the binary packages provided by Cygwin I build from source if the Cygwin team is delayed in providing a critical/security patch. So yes. Anyone else seeing this errors on Cygwin? It seems that I am the only one doing any work (beyond verifying it builds) in the Cygwin environment. Jens mentioned a possible alignment problem in #parrot when I asked why bogus inserted between the two sets would make the problem magically go away but noop would not. FWIW - here is the output of myconfig versus the perl -V for 5.8.4 that I built myself. leo Cheers Joshua Gatcomb a.k.a. Limbic~Region __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ $ more myconfig Summary of my parrot 0.1.0 configuration: configdate='Fri May 28 07:26:33 2004' Platform: osname=64int, archname=cygwin-64int jitcapable=1, jitarchname=i386-64int, jitosname=64INT, jitcpuarch=i386 execcapable=0 perl=perl Compiler: cc='gcc', ccflags='', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lcrypt -licuuc -licudt' Dynamic Linking: so='.so', ld_shared='-shared', ld_shared_flags='' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=4 byteorder=1234, nv=double, numvalsize=8, doublesize=8 Summary of my perl5 (revision 5 version 8 subversion 4) configuration: Platform: osname=cygwin, osvers=1.5.9(0.11242), archname=cygwin-64int uname='cygwin_nt-5.1 k032zk-0220 1.5.9(0.11242) 2004-03-18 23:05 i686 unknown unknown cygwin ' config_args='-de -Duse64bitint -Dprefix=/usr' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing', optimize='-O2', cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing' ccversion='', gccversion='3.3.1 (cygming special)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='ld2', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /usr/lib /lib libs=-lgdbm -ldb -lcrypt -lgdbm_compat perllibs=-lcrypt -lgdbm_compat libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_64_BIT_INT USE_LARGE_FILES Built under cygwin Compiled at Apr 23 2004 08:21:39 %ENV: PERL5_CPANPLUS_CONFIG=/cygdrive/c/Perl/.cpanplus/Config.pm CYGWIN= @INC: /usr/lib/perl5/5.8.4/cygwin-64int /usr/lib/perl5/5.8.4 /usr/lib/perl5/site_perl/5.8.4/cygwin-64int /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/site_perl .
Q: IO layers
1) Async vs sync Currently the ParrotIOLayerAPI [1] has distinct entries for Open, Read, Write with _Async appended. These are of course all unimplemented. Dan's draft [2] has additionally async variants of seek and tell [3]. I'm thinking of a separate IO layer (above the default OS layer(s)) that implements Read, Write, ... as async oerations. The passed function arguments (or a flag) can indicate, if actually an async or a sync IO operation should be done. Further: for miniparrot we need a fallback of the async IO ops, so that an async IO emulation layer can be pushed above the stdio layer that emulates the async IO API. 2) Send vs Write, Recv vs Read The socket read and write functions are currently also special entries in the API vtable. Using these distinct entries from opcodes would need that the compiler has knowledge, if a Cprint function goes to a file or to a socket. I think this isn't possible [4]. So, again, I think these socket functions should be implemented in a separate IO layer. The ParrotIO structure has inside Cflags a bit, if the ParrotIO refers to a socket. The layer can pass on the request to the next layer, if it can handle the request because the socket bit doesn't match. It's of course debatable if Open() really fits into a socket layer scheme or if it should be a distinct function entry Socket(). But I can imagine that somehing like: open P0, http://some.cc:80; does the right thing. 3) Fill and GetCount What are these functions slots for? Comments answers welcome, leo [1] basically a vtable of functions per IO layer [2] Subject: First draft, IO event design [3] the AIO docs in info libc indicate that after issueing an aio_read or aio_write, the file position is undefined, because these functions might execute in any order. The async tell or seek seems really to be needed, if one async read depends on the previous async read and the amount of data isn't known yet (e.g. tail -f the_log_file) [4] e.g. perldoc perlipc, the socketpair example
Re: [perl #29917] bug on yy_init
Midnight [EMAIL PROTECTED] wrote: Under windows (I didn't try on unix), yy_init is not reinitialised after yyparse call. It is not possible to compile parrot assembler two times in the same process because the static variable yy_init in imclexer.c is set to 0 after the first parsing. $ grep -w yy_init imcc/*.c imcc/imclexer.c:static int yy_init = 1; \ /* whether we need to initialize */ imcc/imclexer.c:if ( yy_init ) imcc/imclexer.c:yy_init = 0; This is generated code from imcc.l. Setting this variable seems to have no effect at all. And it *is* of course possible to compile multiple source files, e.g. Cload_bytecode is doing that. leo
PIO_read, PIO_reads
I didn't get much comments for my proposal WRT IO changes. So I'll sumarize my next planned steps: * use Parrot_stat_info_intval(..., STAT_FILESIZE) in embed.c:Parrot_readbc() to obtain the PBC file size [1] * convert all IO Read layer functions to return a STRING* [2] * toss PIO_read() interface, PIO_reads() is used * fix the Creadline opcode, which is actually unusable now for reading files containing more then a few lines. The returned string gets malloc(3)ed. PObj_external_FLAG|PObj_sysmem_FLAG is set, so that the memory gets freed during DOD. Comments welcome, leo [1] might break platforms that lack mmap as well as a stat implementation in config/gen/platforms/* [2] same signature as Recv()
Re: Freeze, objects, crash, boom.
William Coleda [EMAIL PROTECTED] wrote: I've been trying to wrap my head around freezing and objects. My current understanding is that: o parrotclass extends delegate o delegate's freeze vtable entry is Parrot_delegate_freeze o Parrot_delegate_freeze should delegate the freeze vtable method to PASM. I think that ParrotClass::freeze() and friends needs special treatment. There should be a default implementation, which does the right thing. But if there is a PASM override, it should call that, or some hooks... The same holds for ParrotObject. However, when parrotclass.pmc is compiled to .c, its vtable method for freeze is NOT Parrot_delegate_freeze, but Parrot_default_freeze. Could be something related to the different function prototypes of freeze. But just implemeting the function should fix that. leo
[perl #29927] [PATCH] Dumper can't dump 'Array'
# New Ticket Created by Will Coleda # Please include the string: [perl #29927] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29927 Dumper is currently unable to dump the 'Array' type that's used by the 'foldup' opcode. This patch seems to fix that. bash-2.05a$ cvs diff library/Data/Dumper/Default.imc Index: library/Data/Dumper/Default.imc === RCS file: /cvs/public/parrot/library/Data/Dumper/Default.imc,v retrieving revision 1.6 diff -u -r1.6 Default.imc --- library/Data/Dumper/Default.imc 30 Apr 2004 16:12:41 - 1.6 +++ library/Data/Dumper/Default.imc 28 May 2004 04:57:48 - @@ -542,6 +542,18 @@ .pcc_end_return .end +=item style.pmcArray( name, array ) + +Dumps an Array. + +=cut + +.sub pmcArray +S0 = pmcPerlArray +callmethod +.end + + =back =head1 AUTHOR
Re: Q: IO layers
At 1:15 PM +0200 5/28/04, Leopold Toetsch wrote: 1) Async vs sync Currently the ParrotIOLayerAPI [1] has distinct entries for Open, Read, Write with _Async appended. These are of course all unimplemented. Dan's draft [2] has additionally async variants of seek and tell [3]. I'm thinking of a separate IO layer (above the default OS layer(s)) that implements Read, Write, ... as async oerations. The passed function arguments (or a flag) can indicate, if actually an async or a sync IO operation should be done. Why don't we wait a bit? I should be done with the second draft of the events/IO spec today, and we can go from there. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Q: IO layers
LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT [3] the AIO docs in info libc indicate that after issueing an LT aio_read or aio_write, the file position is undefined, because these LT functions might execute in any order. The async tell or seek seems LT really to be needed, if one async read depends on the previous async LT read and the amount of data isn't known yet (e.g. tail -f the_log_file) aio calls in solaris all have an offset arg (actually an aiocbstruct member and you pass the aiocb) so there is no separate seek. this is due to the fact that you don't have ordering with aio calls to files so each call must set its own seek position. this of course means that the seek pos afterwards is meaningless since it could be set by another call (as leo points out). so mixing aio and sync calls on a single handle is likely to be very ugly regarding seek positions. this is another reason to drop seek/tell as separate ops and just add a seek offset as an arg to the i/o ops. tell is useless in the aio world. the user code needs to manage its own seek location and pass it into each call. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
[perl #29936] JIT debugging on Cygwin not working
# New Ticket Created by Joshua Gatcomb # Please include the string: [perl #29936] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29936 --- osname= cygwin osvers= 1.5.9(0.11242) arch= cygwin-64int cc= gcc 3.3.1 (cygming special) --- Flags: category=core severity=low ack=no --- JIT debugging on Cygwin often fails though I have been unable to isolate under exactly what circumstances the bug arises. Here is a sample: $ cat foo.pasm set N0, 1.0 sinh N2, N0 end $ parrot -o foo.pbc -d foo.pasm $ gdb parrot (gdb) b runops_jit (gdb) r -d -j foo.pbc (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x00518898 in Parrot_jit_debug_stabs (interpreter=0x100d1d78) at src/jit_debug.c:348 348 fprintf(stabs, .stabn N_SLINE ,0,%d,%d /* %s */\n, line, And yet a much larger code sample t/op/arithmetics_26.pasm works fine --- Summary of my parrot 0.1.0 configuration: configdate='Fri May 28 14:02:02 2004' Platform: osname=64int, archname=cygwin-64int jitcapable=1, jitarchname=i386-64int, jitosname=64INT, jitcpuarch=i386 execcapable=0 perl=perl Compiler: cc='gcc', ccflags='', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lcrypt -licuuc -licudt' Dynamic Linking: so='.so', ld_shared='-shared', ld_shared_flags='' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=4 byteorder=1234, nv=double, numvalsize=8, doublesize=8 --- Environment: HOMELANGLANGUAGELD_LIBRARY_PATH LOGDIRPATHPERL5_CPANPLUS_CONFIGSHELL __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/
Re: Q: IO layers
Dan Sugalski [EMAIL PROTECTED] wrote: Why don't we wait a bit? I should be done with the second draft of the events/IO spec today, and we can go from there. That's alway an option ;) But, if you did read on, there was a bit more to think about. Not directly event/IO related. And: fixing the Creadline opcode isn't related to these either, it's just broken as hell and unusable. I know that's all related, and with integrating events and async IO a lot will change, but some restructuring can be done in parallel. Unicode string handling and IO is a bit less broken now, but the input side is still lacking any support. leo
Re: Q: IO layers
Uri Guttman [EMAIL PROTECTED] wrote: this is another reason to drop seek/tell as separate ops and just add a seek offset as an arg to the i/o ops. tell is useless in the aio world. the user code needs to manage its own seek location and pass it into each call. Well, yes that's true. OTOH we might want to support traditional IO sequence of operations. The aio read and write calls have the file positions as argument, sync read and writes don't have it. It could be useful to support both flavors e.g. for libraries that are called from different HLLs. A (synced) lseek(2) can only return, if all async operations are completed. The real problems jump in, when code is mixing sync/async IO. uri leo
Re: Q: IO layers
LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT Uri Guttman [EMAIL PROTECTED] wrote: this is another reason to drop seek/tell as separate ops and just add a seek offset as an arg to the i/o ops. tell is useless in the aio world. the user code needs to manage its own seek location and pass it into each call. LT Well, yes that's true. OTOH we might want to support traditional IO LT sequence of operations. The aio read and write calls have the file LT positions as argument, sync read and writes don't have it. It could be LT useful to support both flavors e.g. for libraries that are called from LT different HLLs. i am not against having a sync api but as dan said it should be a wrapper around the async stuff. but as we agree (and dan hasn't acked yet) the aio ops need a seek arg and the seek/tell ops should be dropped LT A (synced) lseek(2) can only return, if all async operations are LT completed. The real problems jump in, when code is mixing LT sync/async IO. but a synced lseek with async ops out there is just what you say are real problems. coder emptor when doing that. seek should pretty much be seek as it is now. it has nothing to do with aio and is a non-blocking op in my book. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Q: IO layers
At 4:21 PM -0400 5/28/04, Uri Guttman wrote: LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT Uri Guttman [EMAIL PROTECTED] wrote: this is another reason to drop seek/tell as separate ops and just add a seek offset as an arg to the i/o ops. tell is useless in the aio world. the user code needs to manage its own seek location and pass it into each call. LT Well, yes that's true. OTOH we might want to support traditional IO LT sequence of operations. The aio read and write calls have the file LT positions as argument, sync read and writes don't have it. It could be LT useful to support both flavors e.g. for libraries that are called from LT different HLLs. i am not against having a sync api but as dan said it should be a wrapper around the async stuff. but as we agree (and dan hasn't acked yet) the aio ops need a seek arg and the seek/tell ops should be dropped Actually I don't agree, though I'll have to think about it. At the moment I'm leaning towards filehandles maintaining their own position rather than having user code track it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Q: IO layers
DS == Dan Sugalski [EMAIL PROTECTED] writes: DS At 4:21 PM -0400 5/28/04, Uri Guttman wrote: i am not against having a sync api but as dan said it should be a wrapper around the async stuff. but as we agree (and dan hasn't acked yet) the aio ops need a seek arg and the seek/tell ops should be dropped DS Actually I don't agree, though I'll have to think about it. At the DS moment I'm leaning towards filehandles maintaining their own position DS rather than having user code track it. but that doesn't work for parallel aio ops. a handle seek pointer makes no sense in that env. for sync io ops, keep a seek value in the handle but ignore that for aio ops. and i meant for users who do aio, they have to track the seek locations for each op. if you use sync ops, it should work the way they do now. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Periodic Table of the Operators
Not to beat a dead horse, but I've updated the Periodic table with almost all the changes that people here sent me, as well as reading a few more threads and references. This will be the last update for some time. I'll be uploading a version to cafepress so people can get posters, tee-shirts and mouse pads since so many people have asked for it. Check back on the chart's blog page ( http://www.ozonehouse.com/mark/blog/code/PeriodicTable.html ) in a few days for the details. (I won't post that info here - I don't mean to clog this mailing list with my frivolity.) Lastly, in Apocalypse 3, Larry says: Operator precedence should be as simple as possible. Perl's precedence table currently has 24 levels in it. This might or might not be too many. We could probably reduce it to about 18 levels, if we abandon strict C compatibility of the C-like operators. The chart currently has 29 precedence levels (from left to right in the chart) - which was based on various writings about the operators, inferences drawn from examples (such as 1|2|3 + 4), any my own guesses. I can't wait to see how this gets down to 18! Or even back to Perl 5's 24... - Mark
FW: Periodic Table of the Operators
-Original Message- From: Mark Lentczner [mailto:[EMAIL PROTECTED] Sent: Friday, May 28, 2004 7:18 PM To: [EMAIL PROTECTED] Subject: Re: Periodic Table of the Operators Not to beat a dead horse, but I've updated the Periodic table with almost all the changes that people here sent me, as well as reading a few more threads and references. This will be the last update for some time The zip operator is now the Yen sign (¥). Joe Gottman
[perl #29938] [PATCH] Data::Escape String - backslash
# New Ticket Created by Will Coleda # Please include the string: [perl #29938] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29938 bash-2.05a$ cat escape.imc .sub _main @MAIN load_bytecode library/Data/Escape.imc $P1 = find_global Data::Escape;, String $S0 = print $S0 print \n $S0 = $P1($S0,\) print $S0 print \n end .end bash-2.05a$ ./parrot escape.imc \\ \\ Fixing up library/Data/Escape with: gt40: # ascii codes greater than 40 below if c != 92 goto DONE set tmp, # branch DONE DONE: produces: bash-2.05a$ ./parrot escape.imc \\
