on the long term Configure system
(To use Simon's nomenclature) The long term goal of the Parrot build system (of which configuring is the major part) is to bootstrap itself from ground zero, a la Parrot von Münchausen. Ground zero is here defined as a simple C file (possibly augmented by one or more simple C headers) and a C compiler. We should not assume a certain build driver (make). We should not assume a native compilation or execution (think cross-compilation). All the above mean that neither Configure nor autoconf/automake are right. Those assume too much UNIX-like environment. We should not. The bootstrapping may take several rounds as Parrot learns more about its environment. "It's a-a-l-i-i-i-v-e!" What should be be in the very first C file? Something along the lines: - write to a file - compile (collect output) - execute (collect output) (note that execution may not be native) This should be enough to figure out existence and size of various types, structs, and functions, headers, and libraries. You know, the standard Configure/autoconf stuff. At some point Parrot should have enough brain cells to solve directed graph dependency problems (also known as "make"). On keeping your nose portability-clean: I think reading perlport carefully will keep one reasonably scared. As Simon mentioned studying microperl (get Perl 5.7.2) and say "make -f Makefile.micro" is useful: you can get 85% operational Perl even when completely ignoring anything that's not ANSI C. P.S. Maybe the "long term" discussion should take place in perl6-build, to draw fire from the "short term"? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Configurators!
On Tue 11 Sep 2001 01:35, Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote: > Yes, I'm still interested. Don't know how much I'll have time, > though, (even after 5.8.0, that is). But I guess (together with Andy) > we can at least tell horror stories about all the possible ways of how > *not* to do it to scare all the young whippersnappers :-) I'm still available for help in that area - if it is still wanted - I'm OTOH putting my spare tuits in Test-Smoke (perl core smoking) and perl5, so requests will be handled on ad-hoc basis. Now that Jeff is (temporarily) unavailable, I might be the one to /guard/ against HP-UX bloopers ;) Just tell me what to do and count me in. -- H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.6.1, 5.7.1 & 629 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Patch: missing comparison _ics
On Mon, Sep 10, 2001 at 09:24:33PM -0400, Bryan C. Warnock wrote: > This patch (temporarily) fixes the missing _ic on comparison opcodes. Didn't apply cleanly. Can you try again from CVS? Simon
Re: Parrot configure stuff, first stab
On Mon, Sep 10, 2001 at 11:42:01PM -0700, Matthew Cline wrote: > This is a first stab at the configure stuff for Parrot. Damn, I knew I should have got that mail out last night. Sorry, Matthew. Simon
Re: Patch: assembler deferred output
On Mon, Sep 10, 2001 at 09:44:24PM -0400, Bryan C. Warnock wrote: > Following patch defers output of opcode until the end of an error-free run. > Also introduces a primitive '-c' option to allow checking of assembly only > (a la Perl). Sort-of applied. Because I couldn't apply the previous patch, this one required some babysitting. Simon
Re: Muddled Boundaries - Perl 6 vs Parrot
On Mon, Sep 10, 2001 at 11:26:03AM -0700, Benjamin Stuhl wrote: > > It's not a prioirty, but it's so much easier to walk the > > correct path from the start. Since it's all Parrot, it's even easier. > > Hear, hear! I remember the pain in 5.005_5* of turning off > PERL_POLLUTE. I expect that there may still be CPAN modules > that won't build without manually defining it. You are, of course, correct; I back down. However, if you care that much, I'm going to make you prove it by implementing it. :) As Nat identifies, the problem is with deciding what should and shouldn't be exported, especially on platforms which require an explicit "exports" list. For instance, the interpreter ops should never see the light of day; other functions might need to. So sorting out namespaces ought to be unnecessary in many cases. For instance, since interpreter ops should never escape from an object, there should be no need to explicitly rename them - we simply don't export them. (But are there platforms where you *can't* tell the linker or ar to not export certain symbols?) I am in two minds here. I want to have Parrot_... prefices on functions even if they're *not* completely necessary /pour encourager les autres/. However, I don't want to go the way of opening up everything in a public API righht now, because once you've exported a symbol for developers to use, you can never take it away from them again - whereas if nearly everything's private and not exported, you can always open it up later. So on balance, I think I'm not going to do anything about the Great Renaming Issue until someone (myself included) has either come up with a patch and/or a good proposal for what the Parrot API should look like for embedders. And by embedders, don't forget we also mean Perl 6 itself, since Parrot is just an interpreter - it's got to be fed bytecode from *somewhere*... Simon
Configure system
One of the items on the Parrot TODO is to build a Configure system. I don't want to spark up the old metaconfig-versus-autoconf debate again, so I'll clarify what I mean. We have long-term and short-term goals for Parrot's configure system. The long-term goal is not something I want people to worry about right now, but it would be good if people could start thinking about it. Eventually, we want Parrot's configure to work a little like the proposed microperl configure system. That's to say, we build a tiny tiny version of Parrot with default values for various config assumptions; we can ship config.h files that work on standard Unix platforms, Win32, and so on. Then that microparrot runs various precompiled bytecode programs which probe the system finding out more information about the enivronment, and produce a config file which is used to build Parrot proper. But we can't do that right now because we don't have a very easy way of generating those precompiled bytecode programs. So relax. The short-term goal is really really simple and really really neat. You'll notice that the Parrot build process currently depends on the existence of Perl 5 to build certain header files and preprocess the opcode table. So if we know we've got Perl 5 hanging around, we know we've already got a config file which tells us things like how big IVs are, what header files we have around, and so on. Furthermore, we can write a Perl program which uses Config.pm to give us this information in a hash, and hence we can use that to produce a config.h specific to a given machine. So I'd like to see a patch which consists of a program to automatically generate Parrot's config.h from Perl's Config.pm. You could be really clever, and also have it conditionally include some of the header files mentioned in parrot.h depending on whether the i_... values in Config.pm say we have them. (You may need to move the "#include"s of the system header files from parrot.h to config.h) No prizes will be awarded for using Perl's config.h, or C preprocessor abuse. :) Furthermore, I'd like to see a Portability Pumpkin step forward to warn us when we're doing things that don't go down too well on Cray Unicos or QNX 6. Simon
Re: String API
On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote: > Have you guys seen Topaz? I may have heard of it, yes. > The other major suggestion I have is to avoid "void *" > interfaces. I'm using void * to avoid char *. :) > Do we really need a string_make() that takes > the encoding enum? Yes. > Aren't encodings different enough that > we'd want string_make_ascii(), string_make_utf32(), ... No. Look at the code for string_make. If you're already passing *in* a UTF32 buffer, why do we need any special processing for UTF32? > Maybe I've been doing C++ too long, Any C++ is too much C++. > but taking advantage of compiler type checks as much as possible > seems like an excellent goal -- especially since the various > string_* functions are going to be visible in user code. And that'll remove the abstraction I've fought so hard to put in. > The use of an encoding enum seems a little weird, but once > you explain why it will probably make sense. Right now the > only thing it seems good for is the transcoding system -- > everything else is slower and vtables are more cumbersome > because you have to manage a vtable[num_encodings] array. I don't know why I did this. Patches welcome. > I'd make a string's encoding a direct pointer to its' > vtable struct. The transcoding algorithm seems like it > could be implemented using a string iterator on the source > with a character-by-character append to the destination. No, that's a really bad way to do it. We can special-case things like UTF16 to UTF32. > The destination can be pre-extended to the length of the source to > avoid fragmenting memory. Yes, I've thought about that, and that's what max_bytes is for. > How many encoding specific > optimizations are there? Is it worth having a table of > custom transcoders instead of using a generic algorithm? Yes. Simon
Re: Patch: missing comparison _ics
On Mon, Sep 10, 2001 at 09:24:33PM -0400, Bryan C. Warnock wrote: > This patch (temporarily) fixes the missing _ic on comparison opcodes. I'd also like to publically question the wisdom of changing *too much* of the assembly before we have an assembler that's smart enough to grok both styles of code. Simon
RE: Configure system
Simon Cozens:
# One of the items on the Parrot TODO is to build a Configure
# system. I don't want to spark up the old metaconfig-versus-autoconf
# debate again, so I'll clarify what I mean.
...
# You'll notice that the Parrot build process currently depends on the
# existence of Perl 5 to build certain header files and preprocess the
# opcode table. So if we know we've got Perl 5 hanging around, we know
# we've already got a config file which tells us things like how big IVs
# are, what header files we have around, and so on. Furthermore, we
# can write a Perl program which uses Config.pm to give us this
# information in a hash, and hence we can use that to produce a
# config.h
# specific to a given machine.
#
# So I'd like to see a patch which consists of a program to
# automatically generate Parrot's config.h from Perl's Config.pm. You
# could be really clever, and also have it conditionally include some
# of the header files mentioned in parrot.h depending on whether the
# i_... values in Config.pm say we have them. (You may need to move the
# "#include"s of the system header files from parrot.h to config.h)
# No prizes will be awarded for using Perl's config.h, or C preprocessor
# abuse. :)
I'm starting to do some hacking on this. (Hey, I can't sleep... :^) )
Since Perl 5 already has this stuff, it seems like it should be pretty
easy. (Famous last words?) The $64,000 question is, what do I have to
copy over? A simple "autogenerate what's already in Parrot's config.h"
is easy--I've already written a prototype (pasted after my sig)--but
seems like it's too easy considering what you're talking about. What
else does it need to do?
The prototype below properly defines IV and NV (most of the time) based
on Perl 5's IV and NV. It also sets up HAS_HEADER_FOO for each of the
i_ symbols in Config.pm. Let me know if I should change the symbol I
define. (If the comment line with my name in it seems improper, feel
free to remove it.)
I'm on Win32, so I don't have the tools to make a diff (I'm trying to
get PPT working) so you'll have to turn it into a patch yourself.
Sorry.
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
~~~
#!/usr/bin/perl -w
#we want -w on
#Configure.pl, written by Brent Dax
use strict;
use Config;
print <<"END";
Parrot Configure
Copyright (C) 2001 Yet Another Society
Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.
Rules are the same as Perl 5's Configure--defaults are in
square brackets, and you can hit enter to accept them.
END
#Some versions don't seem to have ivtype or nvtype--provide
#defaults for them.
#XXX Figure out better defaults
my($iv, $nv)=(($Config{ivtype}||'long'), ($Config{nvtype}||'long
double'));
my $input;
print "How big would you like integers to be? [$iv] ";
chomp($input=);
$iv=$input||$iv;
print "How about your floats? [$nv] ";
chomp($input=);
$nv=$input||$nv;
my($config_h)=<<"END_OF_CONFIG_H";
/* config.h
*
* Platform-specific config file
*
* DO NOT EDIT THIS FILE!
* This file was autogenerated by Configure.pl--please
* rerun that! Changes to this file may be lost!
*
*/
#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
typedef $iv IV
typedef $nv NV;
typedef struct _vtable VTABLE;
typedef void DPOINTER;
typedef void SYNC;
//typedef IV *(*opcode_funcs)(void *, void *) OPFUNC;
#define FRAMES_PER_CHUNK 16
#define FRAMES_PER_PMC_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_NUM_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_INT_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_STR_REG_CHUNK FRAMES_PER_CHUNK
#define MASK_CHUNK_LOW_BITS 0xf000
END_OF_CONFIG_H
print <<"END";
Okay. Now I'm gonna probe Perl 5's configuration to see
what headers you have around. This could take a bit on slow
machines...
END
#set up HAS_HEADER_
foreach(grep {/^i_/} keys %Config) {
$config_h.=defineifdef((/^i_(.*)$/));
}
$config_h.="\n#endif";
open(CONFIG_H, ">config.h");
print CONFIG_H $config_h;
print <<"END";
Okay, we're done!
You can now use `make test_prog' (or your platform's equivalent to
`make')
to build your Parrot. Happy Hacking,
The Parrot Team
END
sub defineifdef {
my $thing=shift;
if($Config{"i_$thing"}) {
return "#define HAS_HEADER_\U$thing\E\n";
}
else {
return "#undef HAS_HEADER_\U$thing\E\n"; #XXX do we want this?
}
}
Re: Configure system
On Tue, Sep 11, 2001 at 02:22:13AM -0700, Brent Dax wrote: > A simple "autogenerate what's already in Parrot's config.h" is easy This is a good start. > --I've already written a prototype (pasted after my sig)--but > seems like it's too easy considering what you're talking about. What > else does it need to do? I'd rather it took a config.h.in or similar and slapped the IV/NV/etc. typedefs in the middle. This means we can hack the template each time we need it to change, instead of hacking the Perl script that generates config.h. Thanks for working on this. Simon
Re: Math functions? (Particularly transcendental ones)
On Mon, 10 Sep 2001 18:48:01 -0400, Dan Sugalski wrote: >At 12:35 AM 9/11/2001 +0200, Bart Lateur wrote: >>On Mon, 10 Sep 2001 17:13:44 -0400, Dan Sugalski wrote: >> >> >Who the heck is going to override arctangent? (No, don't tell me, I don't >> >want to know) >> >>Perhaps you do. Think BigFloat. Or Complex. > >I'm not too worried about bigfloats, since the precision loss you get >converting the argument to a float isn't a big deal. (All the >transcendentals are only good to four or six places anyway, so...) Perhaps that might just be the reason to overload them? Somebody might want higher precision transcendentals? It won't be fast... -- Bart.
RE: Configure system
Simon Cozens: # On Tue, Sep 11, 2001 at 02:22:13AM -0700, Brent Dax wrote: # > A simple "autogenerate what's already in Parrot's config.h" is easy # # This is a good start. # # > --I've already written a prototype (pasted after my sig)--but # > seems like it's too easy considering what you're talking # about. What # > else does it need to do? # # I'd rather it took a config.h.in or similar and slapped the IV/NV/etc. # typedefs in the middle. This means we can hack the template each time # we need it to change, instead of hacking the Perl script that # generates # config.h. Good idea. Why didn't I think of it? :^) # Thanks for working on this. No problem--I'm just helping the best way I can at this point. Attached are new Configure.pl and config.ht files. Feel free to rename config.ht if you want. (They may have Windows newlines, unless e-mail clients do some translating of those behind the scenes that I don't know about.) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet." Configure.pl config.ht
A discussion of writing to the GCC front end
http://cobolforgcc.sourceforge.net/cobol_14.html
Re: Configure system
On Tue, Sep 11, 2001 at 02:49:24AM -0700, Brent Dax wrote: > Attached are new Configure.pl and config.ht files. Feel free to rename > config.ht if you want. I did. Thanks, applied. Now go to sleep. :) Simon
Re: Parrot configure stuff, first stab
On Tuesday 11 September 2001 01:14 am, Simon Cozens wrote: > On Mon, Sep 10, 2001 at 11:42:01PM -0700, Matthew Cline wrote: > > This is a first stab at the configure stuff for Parrot. > Damn, I knew I should have got that mail out last night. Sorry, > Matthew. Well, the autoconf/automake configure system does more than just generate a config.h file. It also determines what compiler and linker flags to use, if the needed libraries are present (with needed versions), takes care of stuff like dependencies, and lets you maintain a simple make file which it translates into a big-and-hairy makefile (22 lines for my Makefile.am versus 465 lines for the output Makefile). I have no clue as to how gcc does automatic dependency checking, but I just have to add one line to configure.in and it magically happens. Is parrot going to have it's own makefile generator, or should it use autoconf? -- Matthew Cline| Suppose you were an idiot. And suppose that [EMAIL PROTECTED] | you were a member of Congress. But I repeat | myself. -- Mark Twain
Re: Parrot configure stuff, first stab
On Tue, Sep 11, 2001 at 03:06:27AM -0700, Matthew Cline wrote: > Is parrot going to have it's own makefile generator, or should it use > autoconf? Please read my other mail on this. Simon
JavaVM -> ParrotVM
Seeing as Simon's gone to all the trouble of releasing the source to
Parrot now, I wondered what I could have a play with. I've did simple
Parrot assembler and thought about different types of bytecode. Like
bytecode for the Java virtual machine, which it turns out is stack
based. Could I convert JVM->PVM? I think so ;-)
[Yes, this is a proof of concept, and the parrot assembler will change
in many ways rsn, so this is just a head up to show it's possible]
Given the following Java code:
class HelloWorld {
public static void main (String args[]) {
int i = 1;
int j = 1;
while(i < 10) {
System.out.print(i);
System.out.print(j);
i++;
j += i;
}
}
}
(which prints out: 112336410515621728836945)
That actually gets translated into the the following JVM bytecode:
0 iconst_1
1 istore_1
2 iconst_1
3 istore_2
4 goto 28
7 getstatic #2
10 iload_1
11 invokevirtual #3
14 getstatic #2
17 iload_2
18 invokevirtual #3
21 iinc 1 1
24 iload_2
25 iload_1
26 iadd
27 istore_2
28 iload_1
29 bipush 10
31 if_icmplt 7
34 return
And my magic script (http://astray.com/java2parrot.pl.txt)
converts it to the following Parrot assembler code:
set_i_ic I1, 1
set_i I63, I1
set_i_ic I1, 1
set_i I62, I1
branch_ic LAAA
LAAB: set_i I1, I63
print_i I1
set_i I1, I62
print_i I1
inc_i I63
set_i I1, I62
set_i I2, I63
add_i I1, I1, I2
set_i I62, I1
LAAA: set_i I3, I63
set_i_ic I4, 10
lt_i_ic I3, I4, LAAB, LAAC
LAAC: end
which outputs:
I reg 1 is 1
I reg 1 is 1
I reg 1 is 2
I reg 1 is 3
I reg 1 is 3
I reg 1 is 6
I reg 1 is 4
I reg 1 is 10
I reg 1 is 5
I reg 1 is 15
I reg 1 is 6
I reg 1 is 21
I reg 1 is 7
I reg 1 is 28
I reg 1 is 8
I reg 1 is 36
I reg 1 is 9
I reg 1 is 45
Cool, huh. Much more on this soon! Leon
--
Leon Brocard.http://www.astray.com/
Iterative Software...http://www.iterative-software.com/
... If you eat yogurt you'll have lots of culture
Re: Patch: missing comparison _ics
On Tuesday 11 September 2001 04:13 am, Simon Cozens wrote: > On Mon, Sep 10, 2001 at 09:24:33PM -0400, Bryan C. Warnock wrote: > > This patch (temporarily) fixes the missing _ic on comparison opcodes. > > Didn't apply cleanly. Can you try again from CVS? > > Simon I'll wait until the rest of the opcode mess congeals... it may be moot. -- Bryan C. Warnock [EMAIL PROTECTED]
Parrot coredumps on Solaris 8
Hi. I've just tried getting Parrot running on a Solaris 8 box here, but it's coredumping on me with test2.pasm and test3.pasm: cass87:pak:~/data2/parrot$ ./test_prog test.pbc I reg 1 is 1000206849 I reg 5 is 1000206859 I reg 2 is 1000 I reg 2 is 10 I reg 4 is 3000 N reg 1 is 3000.00 I reg 2 is 10 N reg 2 is 10.00 N reg 1 is 300.00 cass87:pak:~/data2/parrot$ perl assemble.pl t/test2.pasm > test2.pbc cass87:pak:~/data2/parrot$ ./test_prog test2.pbc Bus Error cass87:pak:~/data2/parrot$ perl assemble.pl t/test3.pasm > test3.pbc cass87:pak:~/data2/parrot$ ./test_prog test3.pbc I reg 1 is 0 Segmentation Fault This is apparently consistent across various Solaris boxes here; the machine above is: cass87:pak:~/data2/parrot$ uname -a SunOS cass87 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10 Has anyone else seen this behaviour, or am I going to have to do some digging? Cheers, Phil -- Philip Kendall <[EMAIL PROTECTED]> http://www.srcf.ucam.org/~pak21/
Re: Muddled Boundaries - Perl 6 vs Parrot
--- Simon Cozens <[EMAIL PROTECTED]> wrote: > On Mon, Sep 10, 2001 at 11:26:03AM -0700, Benjamin Stuhl > wrote: > > > It's not a prioirty, but it's so much easier to walk > the > > > correct path from the start. Since it's all Parrot, > it's even easier. > > > > Hear, hear! I remember the pain in 5.005_5* of turning > off > > PERL_POLLUTE. I expect that there may still be CPAN > modules > > that won't build without manually defining it. > > You are, of course, correct; I back down. However, if you > care that > much, I'm going to make you prove it by implementing it. > :) On my personal todo list for this afternoon is to go through each of the source files and enforce the coding PDD. However, before I do this, I would like to bring up the question of prefixes once again. Do we really need a 7 letter, mixed-case prefix (Parrot_)? If Apache can do ap_, why can't we do par_ (and maybe parp_ for private stuff)? Also, I am planning to go through the structs and prefix them (STRING -> PAR_STRIN, for instance) and clean up the subsystem naming. What do you think of par_gc_* for memory management (yes, that means that uncollected memory is gotten by par_gc_memalloc_nogc(), but if you really want it, you deserve to type in all those letters) and par_io_* for I/O? -- BKS __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
Feature testing API?
It seems to me that Parrot should expose a "feature testing" API. Something on the order of int [read: boolean] par_has_feature(PAR_STRING *feature); (yes, I _do_ think that claiming STRING is unnecessary namespace pollution - sepecially as ANSI compilers, AFAIK, aren't required to be case-sensitive) This would be very useful for any language running on Parrot, so that they can just test (via some language binding) its presence at the beginning of a program, rather than bombind out in the middle when they hit an unimplemented call. Example features might be async I/O, run-time compilation (eval) of different languages, dynamic loading, etc. Basically, I would like to be able to say: use features qw[asyncio eval(perl6)]; and know that if my program loads, it's not going to panic when it gets to an eval 'Async::queueio_out($out_fh, $text);'; What d'y'all think? -- BKS __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
Re: Muddled Boundaries - Perl 6 vs Parrot
At 05:25 AM 9/11/2001 -0700, Benjamin Stuhl wrote: >However, before I do this, I would like to bring up >the question of prefixes once again. Do we really need a 7 >letter, mixed-case prefix (Parrot_)? Externally exposed, yes. That's not to say that the programmer working inside the core needs to ever use 'em. Preprocessors are a nifty thing. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String API
Simon Cozens wrote: > On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote: > > Have you guys seen Topaz? > > I may have heard of it, yes. That's it? You're rejecting all of that work without learning anything from it? Building strings on buffers looked like a really good idea. In general I think Parrot is missing critical abstractions. The string/buffer relation is one. Others are the use of stacks in the interpreter and the dispatch of opcodes in runops(). This code is going to be very difficult to work with because assumptions of the data structures are made in lots of different places. IMHO this is the main reason why Perl 5 is difficult to understand -- and Parrot is repeating it. > > The other major suggestion I have is to avoid "void *" > > interfaces. > > I'm using void * to avoid char *. :) > ... > Look at the code for string_make. If you're already > passing *in* a UTF32 buffer, why do we need any special > processing for UTF32? My point is that a "void *" API turns off all compiler type checking -- it's unsafe as a public API. I have looked at string_make() and it doesn't do any special processing based on encoding. It *requires* that the raw bits are compatible with the encoding. The only reason I'm bringing this up is that the whole intent behind handling platform encodings is to integrate better with user environments. A really nice interface would type check the arguments when making strings so that a user sees a type mismatch error when compiling. For example, on Win32, Parrot might use string_make_utf16 take only LPWSTR. I don't know much about encodings, but I do know that type casts make perl really difficult to understand. Casts suck. They're the goto for data structures. > No, that's a really bad way to do it. We can special-case > things like UTF16 to UTF32. Ok. Are you planning on compiling in all the encodings or can a module dynamically load one? You might want a slow-but-standard encoding conversion algorithm anyways. - Ken
Parrot demo at tonight's Boston perlmonger meeting is *off*
Folks, If anyone was planning to go to the Boston perlmongers meeting to see the parrot demo, be aware that the meeting has been cancelled. We'll try again at the next meeting. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String API
On Tue, Sep 11, 2001 at 12:15:37PM -0400, Ken Fox wrote: > Simon Cozens wrote: > > On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote: > > > Have you guys seen Topaz? > > > > I may have heard of it, yes. > > That's it? You're rejecting all of that work without > learning anything from it? You may also have heard of the British art of ironic understatement. > In general I think Parrot is missing critical abstractions. > The string/buffer relation is one. Who says we don't have one? The memory management hasn't been finalised, and the string vtables haven't been completed. So the strings can very well end up allocating from buffers. If you're willing to provide a patch, that is. > Others are the use of stacks in the interpreter and the dispatch of opcodes > in runops(). This code is going to be very difficult to work with because > assumptions of the data structures are made in lots of different places. Please be more specific. > IMHO this is the main reason why Perl 5 is difficult to > understand -- and Parrot is repeating it. It looks like all the work I'm putting into documentation is wasted. :( Perhaps you'd like to help me out with some more? > My point is that a "void *" API turns off all compiler > type checking -- it's unsafe as a public API. If you can get a compiler to type-check a string buffer as being valid UTF8, I'm all ears. > I have looked > at string_make() and it doesn't do any special processing > based on encoding. It *requires* that the raw bits are > compatible with the encoding. That's right! > > No, that's a really bad way to do it. We can special-case > > things like UTF16 to UTF32. > > Ok. Are you planning on compiling in all the encodings > or can a module dynamically load one? Compiling in. It's only 12 functions, max. Simon
Re: String API
At 01:35 PM 9/11/2001 -0400, Ken Fox wrote: >Dan Sugalski wrote: > > If you're speaking of multiple buffers for a string or something like that, > > you're looking at too low a level. That's something that should go in the > > variables, not in the string bits. (We do *not* want all string ops slow to > > support flexibility of this sort. Only the bits that need it) > >I think of buffers as more primitive than strings. That's OK, I don't. :) >They are segments of >bits. They can be copied, extended, garbage collected, etc. They don't >have character encodings. A string is just a buffer with a few more >semantics. Strings and buffers are mildly different or the same, depending on how you look at them. They ought not be conflated, really. And, honestly, there's nothing to stop you from adding a buffer type if you don't like what we've got. :) >Perhaps you intend to make parrot_string.bufstart hold a buffer structure. No, I don't. It points to a chunk of memory. The encoding library associated with the string type knows what sort of data's there and its format. > > >Others are the use of > > >stacks in the interpreter and the dispatch of opcodes in > > >runops(). > > > > So what's wrong with this? > >Lots of duplicated code in register.h. We really need a stack template. Oh, good grief. This is version *0.01*! Sheesh, not everything is going to look like Hemmingway writing C. >The interpreter knows the internals of the stack structure and is >responsible for managing it. No, it doesn't. The opcode functions do. The interpreter knows nothing to speak of about the format of the stack, and even if it does so what? It *should*. The stack is part of the interpreter. >To change the stack implementation, we'll >have to carefully examine all the interpreter code. No, we won't. We change some opcode functions. So? And deep carnal knowledge of the interpreter guts is just fine for other parts of the interpreter. Putting walls in at this level gets in the way in performance far more than the abstraction would help people writing code. >The semantics of >the stack aren't real clear either. For example, when changing the >stack code what invariants must be preserved? If the stack had an API >the interpreter used I think this would be much clearer. It might, the code's still young. It might not, too. That's fine as well. >runops() is hard-wired with assumptions on the ops. What if we want >to generate a switch-based runops()? How much code is going to make >the same assumption that runops() does now? runops() should be generated >similarly to the opcode table. You must have missed that part of the discussion. This has always been part of the plan, with the actual core being platform dependent for performance reasons. (Switch isn't faster everywhere) >There should be an API for calling ops >so we don't have to jump through the same hoops required for perl 5. There will *always* be hoops non-interpreter-core code needs to jump through to call ops. In fact, no non-interpreter-core code should *ever* call an op. Ever. > > Compiler type checking isn't going to work for us at this level--we'd need > > runtime checking for it to work properly. > >I'm talking about the interface between Parrot and user code -- the >XS layer in Perl 5. You're looking in the wrong place. We haven't written *any* code or documentation on how extensions should interface to the core. This is all interpreter-guts-level stuff, and no extension should *ever* call it. I may well randomly generate structure offsets and such at build time to make sure nothing does. > > String encodings will be dynamically loadable. I'm going to add > > documentation for those ops in soon. (I was hoping today or tomorrow, but > > things are kinda screwy here at the moment) > >Simon just said the opposite. Does this mean that the C and Unicode >encodings will be built-in and everything else dynamically loadable? No, it means Simon and I haven't talked this out yet. All string libraries will be potentially dynamically loaded. You'll probably get one or two built in. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Muddled Boundaries - Perl 6 vs Parrot
Simon Cozens writes: > I am in two minds here. I want to have Parrot_... prefices on > functions even if they're *not* completely necessary /pour > encourager les autres/. However, I don't want to go the way of > opening up everything in a public API righht now, because once > you've exported a symbol for developers to use, you can never take > it away from them again - whereas if nearly everything's private and > not exported, you can always open it up later. Part of "configuration" could be building a #define pile so you can use foo and bar in the .c files, but they're invisibly translated into Parrot_ and so on equivalents. Preprocessing hurts my ass, though, when it comes time to debug. Nat
Re: String API
At 12:15 PM 9/11/2001 -0400, Ken Fox wrote: >Simon Cozens wrote: > > On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote: > > > Have you guys seen Topaz? > > > > I may have heard of it, yes. > >That's it? You're rejecting all of that work without >learning anything from it? Building strings on buffers >looked like a really good idea. If you're speaking of multiple buffers for a string or something like that, you're looking at too low a level. That's something that should go in the variables, not in the string bits. (We do *not* want all string ops slow to support flexibility of this sort. Only the bits that need it) >In general I think Parrot is missing critical abstractions. >The string/buffer relation is one. Well, we are putting an extra layer of abstraction in here. The string abstraction's something we don't have in perl 5, certainly not to this degree. >Others are the use of >stacks in the interpreter and the dispatch of opcodes in >runops(). So what's wrong with this? >This code is going to be very difficult to work >with because assumptions of the data structures are made >in lots of different places. > >IMHO this is the main reason why Perl 5 is difficult to >understand -- and Parrot is repeating it. Perl 5 is difficult to understand for a number of reasons. Some of those are inherent to interpreters, and those folks will just have to deal with. > > > The other major suggestion I have is to avoid "void *" > > > interfaces. > > > > I'm using void * to avoid char *. :) > > ... > > Look at the code for string_make. If you're already > > passing *in* a UTF32 buffer, why do we need any special > > processing for UTF32? > >My point is that a "void *" API turns off all compiler >type checking -- it's unsafe as a public API. Compiler type checking isn't going to work for us at this level--we'd need runtime checking for it to work properly. >I have looked >at string_make() and it doesn't do any special processing >based on encoding. It *requires* that the raw bits are >compatible with the encoding. This is a first cut, and things will change. But requiring internal consistency isn't unreasonable. You make sure things get checked properly going in, but once they're in you can assume they stay correct. >A really nice interface >would type check the arguments when making strings so >that a user sees a type mismatch error when compiling. Right. That's a place for either the assembler or the compiler to complain. *Not* the interpreter, as a general rule. >Ok. Are you planning on compiling in all the encodings >or can a module dynamically load one? You might want a >slow-but-standard encoding conversion algorithm anyways. String encodings will be dynamically loadable. I'm going to add documentation for those ops in soon. (I was hoping today or tomorrow, but things are kinda screwy here at the moment) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Muddled Boundaries - Perl 6 vs Parrot
On Tue, Sep 11, 2001 at 10:20:57AM -0600, Nathan Torkington wrote: > Part of "configuration" could be building a #define pile so you can > use foo and bar in the .c files, but they're invisibly translated into > Parrot_ and so on equivalents. If I do this, people *will* complain I'm going the way of Perl 5. That doesn't mean I'm not going to do it. I'm sure the Parrot programmers are bright enough to get their heads around simple renaming. Simon
Re: PDD 6: Parrot Assembly Language
"Bryan C. Warnock" wrote:
> On Monday 10 September 2001 09:30 pm, Dan Sugalski wrote:
> > gotos into scopes might not be allowed.
>
> That's how it currently is for most scopes, and it certainly saves a
> whole lot of trouble and inconsistencies.
I'm not sure I understand what you mean. Perl 5 allows us to enter
and leave scopes with goto:
sub foo {
my($x, @y) = @_;
if ($x) {
goto START;
}
while (@y) {
$x = shift @y;
START:
print "$x\n";
}
}
And of course the keywords last, next and redo are just restricted
gotos. Those are able to leave one or more scopes.
It isn't clear to me that explicit ops are the way to go
for scope management -- that seems to shift the burden of scope
management onto the compiler. A declarative interface between
the compiler and interpreter might be best. The compiler will
probably need that for communicating debugging info anyways.
- Ken
Re: PDD 6: Parrot Assembly Language
At 12:41 PM 9/11/2001 -0400, Ken Fox wrote: >And of course the keywords last, next and redo are just restricted >gotos. Those are able to leave one or more scopes. Leaving scopes is easy. You just walk up the stack and deconstruct things. (Or, in this case, potentially run the end-of-scope code attached to each scope) >It isn't clear to me that explicit ops are the way to go >for scope management -- that seems to shift the burden of scope >management onto the compiler. I'm not seeing the problems with explicit scope management. Something's got to set up and tear down the various scopes, after all. Explicit management is a bit of a pain for the compiler, granted, but it gives us a lot of flexibility we wouldn't otherwise have. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot coredumps on Solaris 8
It also coredumps on Solaris 7, when running the test2.pbc - test.pbc is fine. The coredump doesn't show much, only that it keeled over at interpreter.c line 16, which is the while() loop. Once upon a time Philip Kendall shaped the electrons to say... > > > Hi. > > I've just tried getting Parrot running on a Solaris 8 box here, but it's > coredumping on me with test2.pasm and test3.pasm: > > cass87:pak:~/data2/parrot$ ./test_prog test.pbc > I reg 1 is 1000206849 > I reg 5 is 1000206859 > I reg 2 is 1000 > I reg 2 is 10 > I reg 4 is 3000 > N reg 1 is 3000.00 > I reg 2 is 10 > N reg 2 is 10.00 > N reg 1 is 300.00 > cass87:pak:~/data2/parrot$ perl assemble.pl t/test2.pasm > test2.pbc > cass87:pak:~/data2/parrot$ ./test_prog test2.pbc > Bus Error > cass87:pak:~/data2/parrot$ perl assemble.pl t/test3.pasm > test3.pbc > cass87:pak:~/data2/parrot$ ./test_prog test3.pbc > I reg 1 is 0 > Segmentation Fault > > This is apparently consistent across various Solaris boxes here; the > machine above is: > > cass87:pak:~/data2/parrot$ uname -a > SunOS cass87 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10 > > Has anyone else seen this behaviour, or am I going to have to do some digging? -D -- berkeley db - it's mostly about the hash()
Re: String API
Dan Sugalski wrote: > If you're speaking of multiple buffers for a string or something like that, > you're looking at too low a level. That's something that should go in the > variables, not in the string bits. (We do *not* want all string ops slow to > support flexibility of this sort. Only the bits that need it) I think of buffers as more primitive than strings. They are segments of bits. They can be copied, extended, garbage collected, etc. They don't have character encodings. A string is just a buffer with a few more semantics. PMCs might implement split strings or some higher abstraction using several parrot_strings. Perhaps you intend to make parrot_string.bufstart hold a buffer structure. That'd be good, except that now parrot_string.buflen is not really owned by the string anymore -- the buffer structure is probably going to need to mess around with the string's internals. That increases the coupling between buffers and strings. Coupling is bad. ;) > >Others are the use of > >stacks in the interpreter and the dispatch of opcodes in > >runops(). > > So what's wrong with this? Lots of duplicated code in register.h. We really need a stack template. The interpreter knows the internals of the stack structure and is responsible for managing it. To change the stack implementation, we'll have to carefully examine all the interpreter code. The semantics of the stack aren't real clear either. For example, when changing the stack code what invariants must be preserved? If the stack had an API the interpreter used I think this would be much clearer. runops() is hard-wired with assumptions on the ops. What if we want to generate a switch-based runops()? How much code is going to make the same assumption that runops() does now? runops() should be generated similarly to the opcode table. There should be an API for calling ops so we don't have to jump through the same hoops required for perl 5. > Compiler type checking isn't going to work for us at this level--we'd need > runtime checking for it to work properly. I'm talking about the interface between Parrot and user code -- the XS layer in Perl 5. Sometimes compile-time checking is possible. We should try to take as much advantage of those situations as possible. For example, in Win32 we *know* that certain things are 16 bit Unicode. If we try to build a utf8 parrot_string with them, the compiler should barf. > String encodings will be dynamically loadable. I'm going to add > documentation for those ops in soon. (I was hoping today or tomorrow, but > things are kinda screwy here at the moment) Simon just said the opposite. Does this mean that the C and Unicode encodings will be built-in and everything else dynamically loadable? - Ken
Re: PDD 6: Parrot Assembly Language
On Tuesday 11 September 2001 12:41 pm, Ken Fox wrote: > I'm not sure I understand what you mean. Perl 5 allows us to enter > and leave scopes with goto: Perl 5 allows you to leave most scopes (sort being the only exception), but just over half the constructs that introduce scope allow you to enter via goto. (And three of those should be footnoted as well...) > > And of course the keywords last, next and redo are just restricted > gotos. Those are able to leave one or more scopes. Yes, leaving is okay. I was referring just to entering. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote: > Nothing should read out of interp_guts.h. That's autogenerated from > opcode_table. Or it was yesterday, but things might've changed. :) Sorry, but things have changed. This is now where the op number assignments are stored. Simon
Re: length_s_i patch
On Mon, Sep 10, 2001 at 09:10:17PM -0400, Bryan C. Warnock wrote: > Okay, we'll start small. "length_s_i" is backwards - should be "length_i_s". > Patch fixes code and test. Thanks, applied.
