Re: Chr Ord, v0.4
Simon Cozens [EMAIL PROTECTED] writes: On Thu, Oct 25, 2001 at 09:47:01AM -0400, James Mastros wrote: This is version 0.4 of my chr and ord patch for parrot. Included is a patch, a test file, and an example. That one looks good. You know, if it had documentation, I'd commit it. :) I would just like to say that Mr Simon Cozens is a very bad man. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Revamping the build system
[EMAIL PROTECTED] (Paolo Molaro) writes: [...] I'm going to bite and say the words (and get the flames). autoconf automake libtool FWIW: I have the impression that they're not very happy with those in the apache httpd project. (But I am blissfully ignorant about the details). - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Revamping the build system
[EMAIL PROTECTED] (Simon Cozens) writes:
On Tue, Oct 23, 2001 at 09:05:33AM -0400, Andy Dougherty wrote:
While imperfect and Unix-centric, we can (and should!) learn a lot
from auto{conf,make} and metaconfig.
*nod*. I just had a look around, and most of the other languages are
using autoconf. But then, most of the other languages don't run on
upwards of 70 platforms. :(
I wonder how serious we need to be about keeping that goal.
I think we need to be serious about making it possibly. The freaks
with the weirdo platforms will make it work.
- ask
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Languages in the core source tree?
[EMAIL PROTECTED] (Dan Sugalski) writes: At 07:15 AM 10/22/2001 -0700, Wizard wrote: 1) Do we put them all in the parrot CVS tree I think it would be good for the languages to be in tree, but I would like to have it under a different mechanism for cvs checkout. In other words, the default cvs checkout of parrot does NOT check out the languages tree, but a separate checkout is required for the languages. I'll ask Ask and see what we can do for that. one way to do that would be to make a parrot-languages module and put them in there. Then we can have a 'parrot-full' module that will checkout parrot/ and parrot-languages into parrot/languages/ It can probably be done in two billion other ways, of which some might fit better. But it's 6.20am and my brain's associative search system is only processing about 0.14 ideas per minute. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Languages in the core source tree?
[EMAIL PROTECTED] (Michael G Schwern) writes: [...] However, the author(s) of each individual interpreter should be responsible for their own language. Basically, a mini-pumpinking. oh, just to make it clear: Our CVS setup supports just giving someone access to certain directories within a cvs module. -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Schedule of things to come
[EMAIL PROTECTED] (Dan Sugalski) writes: [...] If the 0.02/0.03/0.04 versions of parrot leak, it's not that big a deal since it's not like we've got a long-running persistent interpreter like mod_parrot or anything... ;-) I think Robert and I are planning to get mod_parrot to work as soon as parrot has some kind of I/O. :-) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: String rationale
In message [EMAIL PROTECTED] Tom Hughes [EMAIL PROTECTED] wrote: Other than that it looked quite good and I'll probably start looking at bending the existing code into the new model over the weekend. Attached is my first pass at this - it's not fully ready yet but is something for people to cast an eye over before I spend lots of time going down the wrong path ;-) The encoding_lookup() and chartype_lookup() routines will obviously need to load the relevant libraries on the fly when we have support for that. The packfile stuff is just a hack to make it work for now. Presumably we will have to modify the byte code format to record the string types as names or something so we can look them up properly? String comparison is not language sensitive here - as before it just compares based on character values. Other than that I think it's aiming in the right direction and it does pass all the tests... Please correct me if I'm wrong. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ # This is a patch for parrot to update it to parrot-ns # # To apply this patch: # STEP 1: Chdir to the source directory. # STEP 2: Run the 'applypatch' program with this patch file as input. # # If you do not have 'applypatch', it is part of the 'makepatch' package # that you can fetch from the Comprehensive Perl Archive Network: # http://www.perl.com/CPAN/authors/Johan_Vromans/makepatch-x.y.tar.gz # In the above URL, 'x' should be 2 or higher. # # To apply this patch without the use of 'applypatch': # STEP 1: Chdir to the source directory. # If you have a decent Bourne-type shell: # STEP 2: Run the shell with this file as input. # If you don't have such a shell, you may need to manually create/delete # the files/directories as shown below. # STEP 3: Run the 'patch' program with this file as input. # # These are the commands needed to create/delete files/directories: # mkdir 'chartypes' chmod 0755 'chartypes' mkdir 'encodings' chmod 0755 'encodings' rm -f 'transcode.c' rm -f 'strutf8.c' rm -f 'strutf32.c' rm -f 'strutf16.c' rm -f 'strnative.c' rm -f 'include/parrot/transcode.h' rm -f 'include/parrot/strutf8.h' rm -f 'include/parrot/strutf32.h' rm -f 'include/parrot/strutf16.h' rm -f 'include/parrot/strnative.h' touch 'chartype.c' chmod 0644 'chartype.c' touch 'chartypes/unicode.c' chmod 0644 'chartypes/unicode.c' touch 'chartypes/usascii.c' chmod 0644 'chartypes/usascii.c' touch 'encoding.c' chmod 0644 'encoding.c' touch 'encodings/singlebyte.c' chmod 0644 'encodings/singlebyte.c' touch 'encodings/utf16.c' chmod 0644 'encodings/utf16.c' touch 'encodings/utf32.c' chmod 0644 'encodings/utf32.c' touch 'encodings/utf8.c' chmod 0644 'encodings/utf8.c' touch 'include/parrot/chartype.h' chmod 0644 'include/parrot/chartype.h' touch 'include/parrot/encoding.h' chmod 0644 'include/parrot/encoding.h' # # This command terminates the shell and need not be executed manually. exit # End of Preamble Patch data follows diff -c 'parrot/MANIFEST' 'parrot-ns/MANIFEST' Index: ./MANIFEST *** ./MANIFEST Wed Oct 24 22:16:51 2001 --- ./MANIFEST Sat Oct 27 14:59:43 2001 *** *** 1,5 --- 1,8 assemble.pl ChangeLog + chartype.c + chartypes/unicode.c + chartypes/usascii.c classes/genclass.pl classes/intclass.c config_h.in *** *** 14,19 --- 17,27 docs/parrotbyte.pod docs/strings.pod docs/vtables.pod + encoding.c + encodings/singlebyte.c + encodings/utf8.c + encodings/utf16.c + encodings/utf32.c examples/assembly/bsr.pasm examples/assembly/call.pasm examples/assembly/euclid.pasm *** *** 29,34 --- 37,44 global_setup.c hints/mswin32.pl hints/vms.pl + include/parrot/chartype.h + include/parrot/encoding.h include/parrot/events.h include/parrot/exceptions.h include/parrot/global_setup.h *** *** 45,55 include/parrot/runops_cores.h include/parrot/stacks.h include/parrot/string.h - include/parrot/strnative.h - include/parrot/strutf16.h - include/parrot/strutf32.h - include/parrot/strutf8.h - include/parrot/transcode.h include/parrot/trace.h include/parrot/unicode.h interpreter.c --- 55,60 *** *** 107,116 runops_cores.c stacks.c string.c - strnative.c - strutf16.c - strutf32.c - strutf8.c test_c.in test_main.c Test/More.pm --- 112,117 *** *** 128,134 t/op/time.t t/op/trans.t trace.c - transcode.c Types_pm.in vtable_h.pl vtable.tbl --- 129,134 diff -c 'parrot/Makefile.in' 'parrot-ns/Makefile.in' Index: ./Makefile.in *** ./Makefile.in Wed Oct 24 19:23:47 2001 --- ./Makefile.in Sat Oct 27 15:02:45 2001 *** *** 11,19 $(INC)/pmc.h $(INC)/resources.h O_FILES = global_setup$(O) interpreter$(O) parrot$(O) register$(O) \ ! core_ops$(O) memory$(O) packfile$(O) stacks$(O) string$(O) strnative$(O) \ ! strutf8$(O) strutf16$(O) strutf32$(O) transcode$(O) runops_cores$(O) \ ! trace$(O) vtable_ops$(O)
Re: String rationale
In message [EMAIL PROTECTED] Tom Hughes [EMAIL PROTECTED] wrote: Attached is my first pass at this - it's not fully ready yet but is something for people to cast an eye over before I spend lots of time going down the wrong path ;-) Before anybody else spots, let me just add what I forget to mention in my original post, which is that transcoding isn't implemented yet as I'm still thinking about the best way to do it. There is a hook in place ready for it though. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: Schedule of things to come
At 06:27 AM 10/27/2001 -0700, Ask Bjoern Hansen wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: [...] If the 0.02/0.03/0.04 versions of parrot leak, it's not that big a deal since it's not like we've got a long-running persistent interpreter like mod_parrot or anything... ;-) I think Robert and I are planning to get mod_parrot to work as soon as parrot has some kind of I/O. :-) Darned soon now. So I know for the first-stage rollout, does Apache's module system support Apache managing filehandles and modules calling apache's I/O routines, or does it just do weird magic with I/O on normal filehandles? Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String rationale
At 04:23 PM 10/27/2001 +0100, Tom Hughes wrote: In message [EMAIL PROTECTED] Tom Hughes [EMAIL PROTECTED] wrote: Other than that it looked quite good and I'll probably start looking at bending the existing code into the new model over the weekend. Attached is my first pass at this - it's not fully ready yet but is something for people to cast an eye over before I spend lots of time going down the wrong path ;-) It looks pretty good on first glance. The packfile stuff is just a hack to make it work for now. Presumably we will have to modify the byte code format to record the string types as names or something so we can look them up properly? Yup. I think tagging the strings with a few type integers and a set of name-type tables in the bytecode are going to be needed for this. String comparison is not language sensitive here - as before it just compares based on character values. I'm still unsure as to how to properly handle locale-aware comparison, which is an interesting problem in and of itself. Luckily we just need to make the facilities for it, and someone else handles the policy. :) Other than that I think it's aiming in the right direction and it does pass all the tests... Please correct me if I'm wrong. Let me mull it over a bit. I think I'm going to commit it, but a second think on it won't hurt. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Schedule of things to come
On 10/27/01 4:22 PM, Dan Sugalski wrote: At 06:27 AM 10/27/2001 -0700, Ask Bjoern Hansen wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: I think Robert and I are planning to get mod_parrot to work as soon as parrot has some kind of I/O. :-) Darned soon now. So I know for the first-stage rollout, does Apache's module system support Apache managing filehandles and modules calling apache's I/O routines, or does it just do weird magic with I/O on normal filehandles? Which apache module system would this be, 1.3 or 2.0? What do the relative schedules (heh? :) of Parrot/Perl 6 and apache 2.0 look like? It'd be nice not to end up with one or the other being out of step (e.g. mod_perl6/parrot for apache 1.3 arriving long after apache 2.0 is the established standard) -John
Re: Schedule of things to come
At 06:09 PM 10/27/2001 -0400, John Siracusa wrote: On 10/27/01 4:22 PM, Dan Sugalski wrote: At 06:27 AM 10/27/2001 -0700, Ask Bjoern Hansen wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: I think Robert and I are planning to get mod_parrot to work as soon as parrot has some kind of I/O. :-) Darned soon now. So I know for the first-stage rollout, does Apache's module system support Apache managing filehandles and modules calling apache's I/O routines, or does it just do weird magic with I/O on normal filehandles? Which apache module system would this be, 1.3 or 2.0? Got me. I'd say ask Ask. :) What do the relative schedules (heh? :) of Parrot/Perl 6 and apache 2.0 look like? It'd be nice not to end up with one or the other being out of step (e.g. mod_perl6/parrot for apache 1.3 arriving long after apache 2.0 is the established standard) I think we're due out in reasonably good alpha/beta shape for the summer. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Schedule of things to come
On 10/27/01 7:08 PM, Dan Sugalski wrote: I think we're due out in reasonably good alpha/beta shape for the summer. Heh, the phrase suitable vague springs to mind... :) (which year is that again? ;) -John
Re: Schedule of things to come
On 10/27/01 10:34 PM, John Siracusa wrote: On 10/27/01 7:08 PM, Dan Sugalski wrote: I think we're due out in reasonably good alpha/beta shape for the summer. Heh, the phrase suitable vague springs to mind... :) s/e v/y v/; # oops :) -John
Re: Schedule of things to come
On Sat, 27 Oct 2001, John Siracusa wrote: On 10/27/01 7:08 PM, Dan Sugalski wrote: I think we're due out in reasonably good alpha/beta shape for the summer. Heh, the phrase suitably vague springs to mind... :) Ah, and you thought it was my *technical* skills that got me this job! (which year is that again? ;) 19102, of course. ;-P Dan
Opcode complaints
Okay, now that I've had some time working with Parrot assembler, I've
developed a list of complaints. ;^)
1. No if(s|sc, i|ic)
We're treating strings as second-class citizens here. Why shouldn't you
be able to do an 'if' on a string? You could interpret it as the
string's length, or the string's length string ne 0.
2. No unless
'unless' is often more useful than 'if'. Observe:
# if(I0) {some stuff} else {other stuff}
if I0, BeginIF
branch ElseIF
BeginIF: some stuff
branch EndIF
ElseIF: other stuff
EndIF:
vs.
unless I0, ElseIF
some stuff
branch EndIF
ElseIF: other stuff
EndIF:
In the first case, the if block uses two branches, and in the second it
only uses one. Maybe I'm just being nitpicky, but I find the second one
a lot cleaner.
3. eq and friends: branching
The greatest oddity I've found so far is the eq operator and its pals.
While I'm sure these'll be great for something like 'if($foo eq $bar)',
they're less than optimal for anything more complicated: 'if($foo eq
$bar $foo eq $baz)', or even the simple '$foobar=$foo eq $bar'. The
best way I've found so far to use eq and friends in a generic way is:
#I0=I1 eq I2
eq I1, I2, YES
set I0, 0
branch END
YES: set I0, 1
END:
That's pretty suboptimal, considering that it could be:
eq I0, I1, I2
and even the if case would just be:
#if(I1 eq I2)
#I0 is the temp register
eq I0, I1, I2
if I0, ...
That's a lot cleaner, isn't it?
4. eq and friends: string variants
One thing that seems to be missing is string and numeric variants on the
comparison ops. While this isn't a problem now, it may be once we get
PMCs.
I can probably write a patch to fix all this, but first we have to
decide if it needs fixing. Some of these are kind of nitpicky, but
they're still things I find annoying. Thoughts?
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take action, Im not going to fire a $2 million missile at a $10
empty tent and hit a camel in the butt.
--Dubya
