Configure.pl *badly* wrong
On Tru64, freshly compiled perl 5.005_03,
Configure.pl decides the correct type for opcode is 'l'
but that is 32 bit! After manually changinq it to 'q'
it mostly[1] works.
Problem is that al line 159 it does:
elsif ($c{ivsize} == 8) {
$c{packtype_i} = 'q';
$c{packtype_op} = 'l';
}
In which platforms was that working?
Regards
Mattia
[1]
Failed TestStat Wstat Total Fail Failed List of Failed
---
t/op/bitwise.t4 1024 44 100.00% 1-4
t/op/stacks.t 6 1536 96 66.67% 1 3 5 7-9
5 subtests skipped.
Failed 2/8 test scripts, 75.00% okay. 10/99 subtests failed, 89.90% okay.
new assemble.pl
Attached is a new assemble.pl. No, it doesn't change anything, it only breaks the code up into easier to follow functions (which are commented). I am going to test it on a few more platforms and then apply it tomorrow if no one has any objections. Having it broken up into functions should make it easier to change (e.g. adding NV to the constants table). Thanks! Tanton
Updated Platforms Status
Collect all the P(ok)emons on the Core Platforms and try to find the secret ways to the None Core Platforms. Then proceed to level 0.0.2. -- CORE PLATFORMS -- === Linux (x86): make ok / test ok === CygWin (1.3.3 / Win98) make ok / test fails (126.36 % okay -- not so good I guess) === Win32 make ok / test ok (with caveats: nmake doesn't do 'test' correctly, and 'clean' doesn't work because of the 'rm' command) === Tru64 make ok / test fails === OpenVMS (Alpha) ?? === Solaris (Sparc) make ok /test fails === FreeBSD (x86) make ok / test ok === - NONE CORE PLATFORMS - === MacOSX 10.1 (PPC) make ok / test ok === Linux (RS6000) make ok / test fails === FreeBSD (Alpha) make ok / test fails === Linux (Alpha) make ok / test stacks fails === IRIX make ok / test fails === Linux (Sparc) make ok / test fails === iPaq (arm) make ok / test fails (float errs) === Linux (ia64) make ok / test fails === Have fun, Buggs
Re: Docs
On Wednesday 26 September 2001 01:36, Dan Sugalski wrote: > At 05:00 PM 9/25/2001 -0400, Will Coleda wrote: > >In parrot_assembly.pod, line 135 seems to trail off... > > Hmmm. Could you paste in the offending bit? I'm not seeing it, so I'm not > sure if I'm looking in the wrong place or have fixed it. line 135: String and integer constants don't need to be put in a separate Then next paragraph Buggs
Re: 0.0.2 needs what?
At 06:26 PM 9/25/2001 -0700, Benjamin Stuhl wrote: >--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > > At 06:07 PM 9/25/2001 -0700, Benjamin Stuhl wrote: > > >But why store it in this > > >format? What we really need to store is the list of what > > we > > >expect in the table and where. > > > > We have 8 bytes per entry. We can store a lot in there. > > :) > >But not enought to allow us to vector Perl-level variable >references - to support run-time aliasing, we need to have >the fixup table entry be built from the symbol names: That stuff's all handled by either the global symbol tables or the lexical pads, both of which are different animals entirely. The fixup section's for referencing constants. Anything else needs more stuff. > > >Can't we just have the bytecode header > > >have > > > > > >int32 *data_template; > > >int32 fixup_space_needed; > > > > > >and build the final table as needed? > > > > If we do that, the fixup section won't be part of the > > same section of > > memory as the bytecode, which means we'll need to touch > > at least some of > > the actual bytecode so we can set the absolute address of > > the fixups. > > Sticking it on the end means we can access it relatively, > > and padding to 8k > > means the section should start on its own memory page so > > we won't be making > > a private copy of anything but the fixup section. > >But it should be just as cheap to have a pointer to the >current fixup section in the interpreter structure and just >vector off of that, rather than doing relative lookups. Nope, it isn't. We can have multiple bytecode sections, so one static pointer's not enough. We need to set it up on scope entry and exit (well, on changed bytecode section scope entry and exit). >Besides, for non-constant entries in the fixup table (PMCs, >again), the fixup section needs to be per-interpreter, >since different interpreters will want to reference their >own PMCs, not someone else's. There won't be non-constant entries in the fixup table. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 0.0.2 needs what?
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 06:07 PM 9/25/2001 -0700, Benjamin Stuhl wrote:
> >Just to make sure that it's making the _right_ sense,
> the
> >fixup section is basically our single level of
> indirection
> >so that we can make the bytecode itself be
> >position-independant, right?
>
> Yup.
>
> >But why store it in this
> >format? What we really need to store is the list of what
> we
> >expect in the table and where.
>
> We have 8 bytes per entry. We can store a lot in there.
> :)
But not enought to allow us to vector Perl-level variable
references - to support run-time aliasing, we need to have
the fixup table entry be built from the symbol names:
e.g. for accessing $Foo::bar, we need
index in bytecode (offset in current fixup table) -> fixup
table entry (constructed by looking up "$Foo::bar" in the
symbol table and getting the address of it's symtab entry)
-> the PMC * from the symtab entry
This extra level of indirection lets us be sure that all
the references to a variable are updated when someone does
%Foo::{'$bar'} = \$glock;
> >Can't we just have the bytecode header
> >have
> >
> >int32 *data_template;
> >int32 fixup_space_needed;
> >
> >and build the final table as needed?
>
> If we do that, the fixup section won't be part of the
> same section of
> memory as the bytecode, which means we'll need to touch
> at least some of
> the actual bytecode so we can set the absolute address of
> the fixups.
> Sticking it on the end means we can access it relatively,
> and padding to 8k
> means the section should start on its own memory page so
> we won't be making
> a private copy of anything but the fixup section.
But it should be just as cheap to have a pointer to the
current fixup section in the interpreter structure and just
vector off of that, rather than doing relative lookups.
Besides, for non-constant entries in the fixup table (PMCs,
again), the fixup section needs to be per-interpreter,
since different interpreters will want to reference their
own PMCs, not someone else's.
-- BKS
__
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger.
http://im.yahoo.com
Re: 0.0.2 needs what?
At 06:07 PM 9/25/2001 -0700, Benjamin Stuhl wrote: >Just to make sure that it's making the _right_ sense, the >fixup section is basically our single level of indirection >so that we can make the bytecode itself be >position-independant, right? Yup. >But why store it in this >format? What we really need to store is the list of what we >expect in the table and where. We have 8 bytes per entry. We can store a lot in there. :) >Can't we just have the bytecode header >have > >int32 *data_template; >int32 fixup_space_needed; > >and build the final table as needed? If we do that, the fixup section won't be part of the same section of memory as the bytecode, which means we'll need to touch at least some of the actual bytecode so we can set the absolute address of the fixups. Sticking it on the end means we can access it relatively, and padding to 8k means the section should start on its own memory page so we won't be making a private copy of anything but the fixup section. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 0.0.2 needs what?
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 07:36 PM 9/25/2001 -0400, Gregor N. Purdy wrote:
> >I'm just waiting for the thumbs-up from Simon and Dan
> before committing
> >that increment and then moving on to do the changes to
> the format to
> >support more than just strings in const_table. A cooler
> packfile/
> >bytecode file format is due post-0.0.2.
>
> Okay, here's a quick idea of how things should work.
>
>
> *) Add a "current_fixup_section" pointer to the
> interpreter structure
> *) Add a "set_fixup_section" opcode which fills in this
> pointer
> *) The generated bytecode segment should be padded on the
> end with NULLs to
> an even multiple of 8K.
> *) Immediately after the padded bytecode (in the on-disk
> image and in
> memory) is the fixup section. This is a list of 8-byte
> entries. The zeroeth
> entry corresponds to the zeroeth constant. On disk these
> can be anything
> you feel appropriate.
> *) At bytecode load time we turn the constants into real
> things in memory
> however we need.
> *) At bytecode load time we run through the fixup section
> and put in real
> pointers to the appropriate constants.
> *) All constant access other than 32-bit integers is now
> "load entry x from
> the table pointed to via current_fixup_section"
>
> Whether we have a set of get_constant_FOO(x) functions
> for the various
> types of FOOs or just force casting is up in the air.
>
> Make sense? There's good reason for it, really there is.
Just to make sure that it's making the _right_ sense, the
fixup section is basically our single level of indirection
so that we can make the bytecode itself be
position-independant, right? But why store it in this
format? What we really need to store is the list of what we
expect in the table and where. This gets more important
when we add in PMCs - we'll want the fixup table to provide
our local binding to the (interpreter-)global symbol table.
To do that, we need fixup entries like:
struct fixup {
int32 type; /* FIXUP_I64, FIXUP_NV, FIXUP_PMC, etc. */
union {
STRING str_val;
I64 i64_val;
NV nv_val;
... /* all the various thing we can fix up */
};
};
and we need to ensure the same structure padding on all
platforms if we really want to be able to load code from
other systems. Beyond the data to _build_ the table, what
else do we need? Can't we just have the bytecode header
have
int32 *data_template;
int32 fixup_space_needed;
and build the final table as needed?
-- BKS
__
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger.
http://im.yahoo.com
Re: 0.0.2 needs what?
At 05:28 PM 9/25/2001 -0700, Damien Neil wrote: >On Tue, Sep 25, 2001 at 08:18:04PM -0400, Dan Sugalski wrote: > > That'd be interesting. Try cobbling up a version of the assembler that > does > > big-endian assembly and a loader that reads and byteswaps, and see what > you > > get for start-to-finish performance. > >I'm going to take a crack at that Real Soon Now. I'm betting that >the penalty is a) overwhelmed by I/O and syscall overhead to load >the bytecode in the first place, and b) very small compared to the >execution time of the bytecode. Bet you'll find that not to be the case. :) While it might not be a huge amount of work, it is extra work that'll have to be done when we could otherwise just not do it. Not doing something's generally more efficient than doing something. :) > > Don't forget that this also kills mmap and the potential to share one copy > > of the code across multiple simultaneous invocations of Parrot. > >Yes. On the other hand, I'm not certain how much of a win mmaping >bytecode will really give us in the long run. It depends on how >large bytecode files are, and what manner of fixups will be needed >on it. (If most bytecode pages are touched during the fixup pass, >mmap isn't a win at all.) If we touch most of the bytecode pages then we've really failed in our on-disk format design. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 0.0.2 needs what?
On Tue, Sep 25, 2001 at 08:18:04PM -0400, Dan Sugalski wrote: > That'd be interesting. Try cobbling up a version of the assembler that does > big-endian assembly and a loader that reads and byteswaps, and see what you > get for start-to-finish performance. I'm going to take a crack at that Real Soon Now. I'm betting that the penalty is a) overwhelmed by I/O and syscall overhead to load the bytecode in the first place, and b) very small compared to the execution time of the bytecode. > Don't forget that this also kills mmap and the potential to share one copy > of the code across multiple simultaneous invocations of Parrot. Yes. On the other hand, I'm not certain how much of a win mmaping bytecode will really give us in the long run. It depends on how large bytecode files are, and what manner of fixups will be needed on it. (If most bytecode pages are touched during the fixup pass, mmap isn't a win at all.) - Damien
Re: Wow.
At 02:57 PM 9/25/2001 +0200, Bart Lateur wrote: >On Mon, 24 Sep 2001 11:29:10 -0400, Dan Sugalski wrote: > > >However... > > > >I was talking about a different instance of "bitmap". More like: > > > > newbm P3, (640, 480, 24, 8) # Make a 640X480, 24 bit image > > # with 8 bits of alpha > > drawline P3, (100, 100, 200, 200, green) # Draw a green line from > > # 100, 100 to 200,200 > > > >and so on. > >Tell me you're joking. Perl 5 has no clue about graphics, and rightfully >so. Implementing graphics primitives into the core sounds like an >extremely bad idea. If anything belongs in a module, this is it. It's really no more of a bad idea than implementing a lot of other stuff at the lowest levels. Why not? It raises the bar, and that's not a bad thing. >What underlying graphics engine would you use? Would it provide for >anti-aliasing (aka "getting rid of the jaggies")? How about support for >text as graphics? Fonts? Etc. the list is endless. That's what the various GD::foo modules would handle. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 0.0.2 needs what?
At 04:24 PM 9/25/2001 -0700, Damien Neil wrote: >In particular, I'd like to see if we can >get empirical data to justify some of the design decisions that >are being assumed. Exactly how expensive, for example, would it >be to use a single bytecode format with platform-independent >encodings? That'd be interesting. Try cobbling up a version of the assembler that does big-endian assembly and a loader that reads and byteswaps, and see what you get for start-to-finish performance. Don't forget that this also kills mmap and the potential to share one copy of the code across multiple simultaneous invocations of Parrot. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 0.0.2 needs what?
At 05:03 PM 9/25/2001 -0700, Damien Neil wrote: >On Wed, Sep 26, 2001 at 12:38:28AM +0100, Simon Cozens wrote: > > But then I'm one of those weird critters who doesn't understand what > all the > > complaining over XS is about. :) I'd be happy to do the XS coding if it > came > > down to it. > >I'll take a look at making the assembler and disassembler use the >C packfile routines through XS. Generally I'd prefer we go either pure perl or vanilla XS. (With my preference being pure perl) I'm not sure Inline works everywhere (might, but I've never tried it on VMS). Pure perl's preferable, as we can ship whatever we need and don't have to force an install of any modules to build Parrot, and I think that's good at the moment. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 0.0.2 needs what?
On Wed, Sep 26, 2001 at 12:38:28AM +0100, Simon Cozens wrote: > But then I'm one of those weird critters who doesn't understand what all the > complaining over XS is about. :) I'd be happy to do the XS coding if it came > down to it. I'll take a look at making the assembler and disassembler use the C packfile routines through XS. As I just mentioned in a previous mail, however, I'm not very happy with the current packfile API... should I go ahead and use the existing one (temporarily, I hope :>), or is this section not covered by the current feature freeze? - Damien
Re: 0.0.2 needs what?
On Tue, Sep 25, 2001 at 07:36:31PM -0400, Gregor N. Purdy wrote: > I'm currently working on some assigned taskes for the bytecode stuff > for 0.0.2. I need to get it to the point where we can stash NVs in > the const_table. I've already got the interpreter using packfile.[hc] > for its work (I posted a patch earlier today). After taking a look at the packfile code, I think the interface needs to be made more generic. I don't believe the file format should be aware of the nature of the contents. For example, rather than having functions to access the constant table, the fixup table, and the bytecode, I would rather see a single set of functions which take a section ID as a parameter. I also feel that the prior discussions on using a preexisting file format were on the right track. With a good API, however, the file format can be completely redefined, so this is a less pressing concern. (I also still think that IFF fits our needs quite closely, although its support for data structure nesting may be more than we want.) - Damien
Re: 0.0.2 needs what?
On Tue, Sep 25, 2001 at 07:51:22PM -0400, Gregor N. Purdy wrote: > Is there hope that 0.0.2 could be out by the end of the week if I get > the tasks assiged to me done RSN? Once we've got NVs into the constant table, we can ensure they're aligned nicely, and all the problems we're seeing on Sparc (I have a Sparc for testing, BTW) will go away. I hope. At that point, we can release 0.0.2. That's if it passes tests on all core platforms. No pass, no release. :) -- Feed me on TOASTIES! There's no HALL for PHILOSOPHERS ON FRIDAYS. - Henry Braun is Oxford Zippy
Re: 0.0.2 needs what?
Simon -- > I think that's exactly what needs work, and one of the things Gregor > is looking at. Here's how it goes. > > Before 0.0.2 is released, we need to pass tests on Sparc, Someone else has to tinker with this this... (no Sparc here) > which means we need to stop dereferencing NVs on bad alignments, (no Sparc here) > which means we need to move NVs into the constant table, I'm prepared to do this very soon (perhaps tomorrow if my patch from earlier today is Good To Go -- let me know). > which means we need to make the constant table grok different types, I'm prepared to do this very soon (see above). > which means we need to rewrite the bytecode structure and code. I'm prepared to do this very soon (see above)l. > I'll post something when I'm not completely and utterly shattered about how I > want us to go about that, including how the interpreter's interface to the > "pack file" - the bytecode with all its segments - will change while we're at > it to allow multiple packs in the same file, something very useful if we want > to do, say, subroutines. I'd like to see the changes for 0.0.2 be just the bare minimum for the const_table containing NVs + SVs. I know a bunch of us have been thinking about the file format stuff and we'll probably want to have another thread about it before adding more stuff (IMHO). Is there hope that 0.0.2 could be out by the end of the week if I get the tasks assiged to me done RSN? Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
Re: 0.0.2 needs what?
At 07:36 PM 9/25/2001 -0400, Gregor N. Purdy wrote: >I'm just waiting for the thumbs-up from Simon and Dan before committing >that increment and then moving on to do the changes to the format to >support more than just strings in const_table. A cooler packfile/ >bytecode file format is due post-0.0.2. Okay, here's a quick idea of how things should work. *) Add a "current_fixup_section" pointer to the interpreter structure *) Add a "set_fixup_section" opcode which fills in this pointer *) The generated bytecode segment should be padded on the end with NULLs to an even multiple of 8K. *) Immediately after the padded bytecode (in the on-disk image and in memory) is the fixup section. This is a list of 8-byte entries. The zeroeth entry corresponds to the zeroeth constant. On disk these can be anything you feel appropriate. *) At bytecode load time we turn the constants into real things in memory however we need. *) At bytecode load time we run through the fixup section and put in real pointers to the appropriate constants. *) All constant access other than 32-bit integers is now "load entry x from the table pointed to via current_fixup_section" Whether we have a set of get_constant_FOO(x) functions for the various types of FOOs or just force casting is up in the air. Make sense? There's good reason for it, really there is. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 0.0.2 needs what?
On Tue, Sep 25, 2001 at 07:36:31PM -0400, Gregor N. Purdy wrote: > I'm currently working on some assigned taskes for the bytecode stuff > for 0.0.2. Hrm, we should probably be using the request tracker to manage these takss. > the const_table. I've already got the interpreter using packfile.[hc] > for its work (I posted a patch earlier today). > I'm just waiting for the thumbs-up from Simon and Dan before committing > that increment I'll look at it in the morning. > Dan? Simon? Is Inline::C ok? >From my point of view, I'm afraid I'd like to say no here. Inline::C is very cool and easy to develop and maintain and all that, but we have to remember what we're trying to achieve: I want Parrot out there, on as many machines as possible, being run and tested and fiddled with. I don't want to force people to have to install more than they need to; we're already bundling Test::More to make it easier for people, and if we develop in Inline::C, we'd have to ship Inline as well. (Unless Ingy did do the Inline->XS compiler thing that means you don't have to ship Inline any more, in which case, go for it!) But then I'm one of those weird critters who doesn't understand what all the complaining over XS is about. :) I'd be happy to do the XS coding if it came down to it. -- buf[hdr[0]] = 0;/* unbelievably lazy ken (twit) */ - Andrew Hume
Re: 0.0.2 needs what?
Damien -- > Are there any issues holding up 0.0.2 that I (or others) could work > on? Failing that, what areas of Parrot are most in need of immediate > work? > > I'm interested in looking at the bytecode loader, if nobody else > has intentions there. In particular, I'd like to see if we can > get empirical data to justify some of the design decisions that > are being assumed. Exactly how expensive, for example, would it > be to use a single bytecode format with platform-independent > encodings? I'm currently working on some assigned taskes for the bytecode stuff for 0.0.2. I need to get it to the point where we can stash NVs in the const_table. I've already got the interpreter using packfile.[hc] for its work (I posted a patch earlier today). I'm just waiting for the thumbs-up from Simon and Dan before committing that increment and then moving on to do the changes to the format to support more than just strings in const_table. A cooler packfile/ bytecode file format is due post-0.0.2. Something that I'm going to have to do unless someone else takes it on (hint, hint) is to use Inline::C (I hope) or XS to make the PackFile::* Perl classes use packfile.[hc] behind the scenes so we only have One True Implementation of the format. Bear in mind that it will be a moving target over time, so whoever does it has to have a fairly high tolerance for tracking a moving target. I would suggest that the time to start that conversion would be after my next commit, and then track the changes that occur wrt NV stowage. Dan? Simon? Is Inline::C ok? If nobody wants to take this on, it will fall to me, and I'll do it once I get the other changes in (which is fine by me). Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
Re: Strings db
On Tue, Sep 25, 2001 at 07:29:01PM -0700, Wizard wrote: > Actually, the thing that I didn't like was using an actual string as the > message_id. I would have expected something more in the way of: > > char *err = get_text_string( THREAD_EXCEPTION_117, \ > "THREAD EXCEPTION: Not enough handles." ); This is a far more error-prone interface in a number of ways: It is very easy for the mapping between the number and the string to be lost. Adding and removing strings is harder: the string list will become filled with holes (or must be renumbered), and the numeric order of the strings will probably not correspond with the logical order. Numerically indexes are far more prone to failure when using out-of-date catalog files, while string-indexed ones will mostly continue to work. (With the obvious exception that messages not contained in the old catalog cannot be displayed from it.) All these disadvantages are a significant penalty to pay for a very minor improvement in efficiency. (If there is one thing that Perl has demonstrated, it is that looking up a string in a hash is fast.) - Damien
Re: Docs
At 05:00 PM 9/25/2001 -0400, Will Coleda wrote: >In parrot_assembly.pod, line 135 seems to trail off... Hmmm. Could you paste in the offending bit? I'm not seeing it, so I'm not sure if I'm looking in the wrong place or have fixed it. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 0.0.2 needs what?
On Tue, Sep 25, 2001 at 04:24:53PM -0700, Damien Neil wrote: > I'm interested in looking at the bytecode loader, if nobody else > has intentions there. I think that's exactly what needs work, and one of the things Gregor is looking at. Here's how it goes. Before 0.0.2 is released, we need to pass tests on Sparc, which means we need to stop dereferencing NVs on bad alignments, which means we need to move NVs into the constant table, which means we need to make the constant table grok different types, which means we need to rewrite the bytecode structure and code. I'll post something when I'm not completely and utterly shattered about how I want us to go about that, including how the interpreter's interface to the "pack file" - the bytecode with all its segments - will change while we're at it to allow multiple packs in the same file, something very useful if we want to do, say, subroutines. -- "I think i'll take my girlfriend to vegas for a win'98 burn/upgrade" -- Megahal (trained on asr), 1998-11-06
Re: [PATCH] print_s_v op (was: RE: variable number of arguments)
Michael -- > I had more time to think about it, and I determined how a compute op-code > could be efficient. > > [snip] You wicked, wicked person! :) I'd like to see some benchmarks on that one vs. the most efficient possible hand-coded separate ops for moderate to complex arithmetic... These sorts of ops should be possible without them being in the core once we have loadable oplibs, as long as the assembler knows how to lay them out... BTW, the ops should probably be: * compute_i_s_v * compute_i_sc_v * compute_n_s_v * compute_n_sc_v > /** FMT: compute v_arg_size, destination-register, fmt_const_string, > ( list of reg-indexes ) The nargs operand is spliced in in place of the 'v' Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
RE: Strings db
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] wrote:
> You quoted something similar to my text above and said you didn't
> like it. I
> believe mostly because it involved reading external files, but
> also because of
> the concept of the message-id.
Actually, the thing that I didn't like was using an actual string as the
message_id. I would have expected something more in the way of:
char *err = get_text_string( THREAD_EXCEPTION_117, \
"THREAD EXCEPTION: Not enough handles." );
where "THREAD_EXCEPTION_117" is defined as:
#define THREAD_EXCEPTION_117 117
and the actual catalog values are defined as an array ("strings[117]"),
either build-time or run-time, from a language file (such as
"./strings/lang.en"). The second string is a 'fallback' string that is
displayed if the value doesn't exist or exists as NULL (and to aid
readability). It just felt weird to me to use the actual string for the
message id.
> I realize that you were merely inciting that we should be able to develop
> something, I was just commenting on performance.
I'm not sure where performance is affected with either scenario, as both
systems could be made to work in a similar manner behind the scene.
Grant M.
0.0.2 needs what?
Are there any issues holding up 0.0.2 that I (or others) could work on? Failing that, what areas of Parrot are most in need of immediate work? I'm interested in looking at the bytecode loader, if nobody else has intentions there. In particular, I'd like to see if we can get empirical data to justify some of the design decisions that are being assumed. Exactly how expensive, for example, would it be to use a single bytecode format with platform-independent encodings? - Damien
Re: [PATCH] print_s_v op (was: RE: variable number of arguments)
At 06:59 PM 9/25/2001 -0400, Michael L Maraist wrote: > > > > I've created a varargs-ish example by making a new op, print_s_v. > > > > This is pretty rough, and I haven't updated the assembler, but it > > > > seems to work. Okay, I've been off the air all day (Sorry 'bout that--cable got nuked) so I didn't get this earlier, but... The rule "No vararg ops" still stands. At some point we might loosen it, but not now. Persuing this is fine (though don't underestimate the sorts of algebraic transforms compilers can and do do) but it's not going into the source. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: (Fwd) Parrot Smoke Sep 25 19:00:04 2001 UTC MSWin32 4.0
On Wed, Sep 26, 2001 at 12:05:49AM +0200, Mattia Barbon wrote: > O O > O O nv=double > O O nv=\"long double\" > O O iv=int > O O iv=int nv=double > O O iv=int nv=\"long double\" > O O iv=long > O O iv=long nv=double > O O iv=long nv=\"long double\" Weird. That probably shouldn't happen. All right, own up, who made the code portable? -- ``Perl is the successfull attempt to make a braindump directly executable.'' - Lutz Donnerhacke in de.org.ccc
Re: [PATCH] print_s_v op (was: RE: variable number of arguments)
Michael Maraist wrote:
> > All --
> >
> > > I've created a varargs-ish example by making a new op, print_s_v.
> > > This is pretty rough, and I haven't updated the assembler, but it
> > > seems to work.
>
>
> With var-args, we could produce highly efficient SIMD instructions.
> printf obviously, multi-push/pop, createArrays/ Hashes.
>
> I toyed with the idea of a stack-based ALU to handle algebra such as:
>
> ( ( a + b*c ) / d + e ) / ( f + g + h )
>
> // compute dest, "fmt", register-names
> compute Rd, "++^*+/+", f, g, h, a, b, c, d, e
>
> Unfortunately I couldn't find a way of garunteeing that it's efficient.
> The best I've come up with so far is to use a mini-switch statement. The
> only reason it might be faster than an optimized switch-statement over all
> op-codes is that the switch has fewer terms.
>
> The above case also gets complex if we don't use multiple registers for
> intermediate calculations.
>
> None the less the possibilities are cool.
>
I had more time to think about it, and I determined how a compute op-code
could be efficient.
Pros:
o First of all, there is no need to assign to temporary registers (as would
be necessary for the compiler).
o Secondly, I'm under the impression that compilers convert algebraic
expressions to reverse polish notation anyway (to reduce the temporaries);
though parallel computing is an obvious exception (when multiple ops can be
executing simultaneously). This theoretically simplifies the job of the
compiler.
o Third, only a single register access is required for each parameter
(where-as an expression might otherwise require multiple accesses).
o Fourth, it's possible to check for a subset of two or more adjacent
operations such as "" which would quickly add four number with n-1
physical adds ('accumulator = a+ b + c + d + e') which can be optimized in
for parallel op-code execution within the physical CPU. Or "^+" which
normally pushes a stack-element, adds top two, then pops. Here it just adds
to the top-element. To prevent d^n number of operations, only common ones
are defined. The default block of the switch checks for individual
operations.
o Fifth, the op-code is a lot more dense: (16 + 6 * var) verses (16 * n).
In inner loops, this could add up with cache-savings (don't pay retail).
Cons:
o The overhead of an op-code is probably not much greater than the total
overhead of this instruction (especially with a switch-based op-dispatcher
and -O2 compilation)
o Potentially long op-chains are possible which could thwart responsiveness
to synchronous event-handling. (Unless there is a max-fmt size)
o Potential portability issues if we deal with 16bit "shorts". Might have to
require 32bit ints as the smallest macro-symbol
/** FMT: compute v_arg_size, destination-register, fmt_const_string, ( list
of reg-indexes )
*contents of fmt_string:
* + //add top two stack el's
* - // sub ..
* * // mul ..
* / // divide ..
* % // take modulous
* & // logical and
* | // logical or
* P // push register onto local stack
* C // push constant onto local stack
* D // duplicate top stack element
* S // switch top two elements
* \0 // end-of-fmt-string. Must be word-aligned with such eofs eg
"PPP++\0\0\0"
**
* Note that the above symbols should probably be part of a c-enum so that
the switch statement can be optimized
**/
AUTO_OP computei_varg {
static int stack[MAX_STACK]; // make 1 larger than the max-size of
allowable varg_size
unsigned int top = 0; // points to safe location
STRING *s = Parrot_string_constants[P2];
int args_offset = 3 +code ; // pointer to the start of parameters (could
have just been word_align( strlen(code[4]) ) )
short * dops = (short*)s->bufstart; // get format
int f_first_two_op;
char * sops; // single_char_ops
// sanity check against varg_size
if ( code[1] > MAX_STACK )
die "invalid size-of operation";
stack[ 0 ] = 0; // null-value (should never read)
stack[ 1 ] = 0; // initially stack contains null
// compare pairs of op-codes (theoretically could nest this into the
default statement of a 4-op comparison)
while (*dops && top) {
switch( *dops ) {
case PUSH_PLUS: // "P+" or ('^' << 8) +'+'
stack[top] += INT_REG( code[ args_offset++ ] );
break;
case CONST_PLUS: // "C+"
stack[top] += code[ args_offset++ ];
case PLUS_PLUS: // "++"
stack[top] += stack[top--] + stack[top--];
...
defailt: // fall back to the single-character case for unrecognized
pairs
f_first_two_op = 0;
sops = (char*)dops;
while(!f_first_two_op++) {
switch( *((char*) sops)) {
case '+': ...
case '-': ...
...
default: die "invalid op-code"
} // end 1char-switch
} // end 1char-while
} // end 2char-switch
} // end 2char-while
if ( top )
INT_REG( P2 ) = stack[top];
else
die "invalid number of pushes";
} // computei_varg
-Michael
Re: [PATCH] Fix IRIX64 warnings
At 12:39 AM 9/25/2001 -0400, Steven W McDougall wrote: >So the declaration of opcode_funcs was at a different level of >indirection than its allocation and use. The compilers weren't >complaining about this because of all the (void *) casts. The IRIX64 >compiler did complain, not about indirection levels, but about >assigning data pointers to function pointers. Gah, my fault, and thanks for fixing it. I was caught in a maze of twisty little indirections, and got rather confused. (Hence the casts all over the place.) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
(Fwd) Parrot Smoke Sep 25 19:00:04 2001 UTC MSWin32 4.0
--- Forwarded message follows --- To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject:Parrot Smoke Sep 25 19:00:04 2001 UTC MSWin32 4.0 Date sent: Tue, 25 Sep 2001 22:00:03 +0200 Automated smoke report for patch Sep 25 19:00:04 2001 UTC v0.01 on MSWin32 using cl version O = OK F = Failure(s), extended report at the bottom ? = still running or test results not (yet) available Build failures during: - = unknown c = Configure, m = make, t = make test-prep Configuration --- O O O O nv=double O O nv=\"long double\" O O iv=int O O iv=int nv=double O O iv=int nv=\"long double\" O O iv=long O O iv=long nv=double O O iv=long nv=\"long double\" | | | +- --debugging +--- normal --- End of forwarded message ---
transcendental math test change
I changed t/op/trans.t to not use loops so you can more easily see which test failed. Thanks! Tanton
Re: Strings db
Wizard wrote: > Michael Maraist [mailto:[EMAIL PROTECTED]] wrote: > > Does you idea allow for: > > int msgid = txtToMsgid( "This feels strange\n" ); > > char *label = msgidToRes( msgid ); > > I'm not sure that I understand your question. This is not my idea, but GNU's > gettext tools. I, myself, am not thrilled with this implementation, and > would suggest using some other implementation (either our own or someone > else's). > Grant M. You quoted something similar to my text above and said you didn't like it. I believe mostly because it involved reading external files, but also because of the concept of the message-id. My statement was that there are efficient reasons to want to use a message-id, so it should be possible to have two api's, one with and one that's direct (which is simply a wrapper around the former). I realize that you were merely inciting that we should be able to develop something, I was just commenting on performance. -Michael
Docs
In parrot_assembly.pod, line 135 seems to trail off...
RE: Strings db
Michael Maraist [mailto:[EMAIL PROTECTED]] wrote: > ... but I'm assuming it involves (among other things) displaying > locale-based error messages. I'm not sure how the catalog would be determined, but I would suggest another mechanism other than locale. Rather, I'd suggest a user-specific environment variable or config file. Grant M. [EMAIL PROTECTED]
RE: Strings db
Michael Maraist [mailto:[EMAIL PROTECTED]] wrote: > Does you idea allow for: > int msgid = txtToMsgid( "This feels strange\n" ); > char *label = msgidToRes( msgid ); I'm not sure that I understand your question. This is not my idea, but GNU's gettext tools. I, myself, am not thrilled with this implementation, and would suggest using some other implementation (either our own or someone else's). Grant M.
Re: [PATCH] print_s_v op (was: RE: variable number of arguments)
> All -- > > > I've created a varargs-ish example by making a new op, print_s_v. > > This is pretty rough, and I haven't updated the assembler, but it > > seems to work. > > Um.. I *have* updated the assembler. Its the *dis*assembler I haven't > updated. This is what happens: > > * *_v ops list their number of args as 1 + the number of fixed > args. They list the types of the fixed args, plus a last arg of 'v'. > > * The assembler sees all this and splices in an arg count for the > 'v' arg place, and then hangs however many args remained on the > line after the count. > > * The op decides how many args it is expecting. For print_s_v, > that is via the format string (but really should take care to > not read more than the "arg count" arg says are present. > > * Since the op is in control of returning the next address to > execute, it is trivial for the op to arrange for excecution to > continue after the last vararg (thanks, Dan!) > > * Since the assembler splices in the arg count, though, the > disassembler won't have to think very hard to find the beginning > of the next op when doing its job. > > * Of course, all this assumes that all args have sizeof() == > sizeof(IV), which won't be true until NV constants are moved to > the constants area. SO DON'T USE THEM. :) > > Anyway, whether or not folks really like the idea of having ops with > variable numbers of args, this proves its not too hard to do with a > small amount of cooperation between the assembler and the op func. With var-args, we could produce highly efficient SIMD instructions. printf obviously, multi-push/pop, createArrays/ Hashes. I toyed with the idea of a stack-based ALU to handle algebra such as: ( ( a + b*c ) / d + e ) / ( f + g + h ) // compute dest, "fmt", register-names compute Rd, "++^*+/+", f, g, h, a, b, c, d, e Unfortunately I couldn't find a way of garunteeing that it's efficient. The best I've come up with so far is to use a mini-switch statement. The only reason it might be faster than an optimized switch-statement over all op-codes is that the switch has fewer terms. The above case also gets complex if we don't use multiple registers for intermediate calculations. None the less the possibilities are cool. -Michael
RE: Strings db
> and a call to the API would be: > char *label = gettext( "This feels strange\n" ); Does you idea allow for: int msgid = txtToMsgid( "This feels strange\n" ); char *label = msgidToRes( msgid ); In addition to the above, since this affords compile-time optimizations? I'm not following this thread with enthusiasm (I'm an English Biggot myself), but I'm assuming it involves (among other things) displaying locale-based error messages. Such messages could be known after compilation. Granted errors don't really need to be fail-fast. -Michael
Re; Bytecodes and packfiles and constants, oh my!
All --
As a first step to moving NV constants out of the byte code stream
and other goodness, I have produced this patch that gets rid of
bytecode.[hc] (for now) and has the interpreter rely on packfile.[hc]
for its bytecode interface.
The packfile.[hc] stuff has been modified a bit in anticipation of
multiple types of constants (NV soon, PV later). It now has a type
field (IV) and a string field (STRING *).
The packing and unpacking of constants has been modified (of course)
to reflect this new structure.
Also, I added 'end' to some of the test cases in t/op/*.t and modified
basic_opcodes.ops to access constants via the new 'code' member of
the Parrot_Interp struct.
I just made clean and test here and things went well. I'd like to get
some feedback from folks on other architectures (I'm on Linux Intel)
so we can know if I've hurt anyone on portability.
Something very much like this is going to be committed soon as part of
our final push for 0.0.2, which requires us to move NVs into the
const_table.
Stay tuned for more...
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc.http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_/
? packfile.patch
Index: MANIFEST
===
RCS file: /home/perlcvs/parrot/MANIFEST,v
retrieving revision 1.21
diff -u -r1.21 MANIFEST
--- MANIFEST2001/09/25 09:12:57 1.21
+++ MANIFEST2001/09/25 16:11:15
@@ -15,7 +15,6 @@
assemble.pl
basic_opcodes.ops
build_interp_starter.pl
-bytecode.c
config_h.in
disassemble.pl
docs/opcodes.pod
@@ -26,7 +25,6 @@
docs/vtables.pod
global_setup.c
hints/mswin32.pl
-include/parrot/bytecode.h
include/parrot/events.h
include/parrot/exceptions.h
include/parrot/global_setup.h
Index: Makefile.in
===
RCS file: /home/perlcvs/parrot/Makefile.in,v
retrieving revision 1.13
diff -u -r1.13 Makefile.in
--- Makefile.in 2001/09/22 17:20:58 1.13
+++ Makefile.in 2001/09/25 16:11:15
@@ -1,9 +1,9 @@
O = ${o}
INC=include/parrot
-H_FILES = $(INC)/config.h $(INC)/exceptions.h $(INC)/io.h $(INC)/op.h
$(INC)/register.h $(INC)/string.h $(INC)/events.h $(INC)/interpreter.h $(INC)/memory.h
$(INC)/parrot.h $(INC)/stacks.h $(INC)/packfile.h $(INC)/bytecode.h
$(INC)/global_setup.h
+H_FILES = $(INC)/config.h $(INC)/exceptions.h $(INC)/io.h $(INC)/op.h
+$(INC)/register.h $(INC)/string.h $(INC)/events.h $(INC)/interpreter.h
+$(INC)/memory.h $(INC)/parrot.h $(INC)/stacks.h $(INC)/packfile.h
+$(INC)/global_setup.h
-O_FILES = global_setup$(O) interpreter$(O) parrot$(O) register$(O) basic_opcodes$(O)
memory$(O) packfile$(O) bytecode$(O) string$(O) strnative$(O)
+O_FILES = global_setup$(O) interpreter$(O) parrot$(O) register$(O) basic_opcodes$(O)
+memory$(O) packfile$(O) string$(O) strnative$(O)
#DO NOT ADD C COMPILER FLAGS HERE
#Add them in Configure.pl--look for the
@@ -48,8 +48,6 @@
interpreter$(O): interpreter.c $(H_FILES) $(INC)/interp_guts.h
memory$(O): $(H_FILES)
-
-bytecode$(O): $(H_FILES)
packfile$(O): $(H_FILES)
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.24
diff -u -r1.24 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/24 16:27:48 1.24
+++ basic_opcodes.ops 2001/09/25 16:11:16
@@ -425,7 +425,7 @@
/* SET Sx, CONSTANT */
AUTO_OP set_s_sc {
- STR_REG(P1) = Parrot_string_constants[P2];
+ STR_REG(P1) = PCONST(P2)->string;
}
/* PRINT Sx */
@@ -436,8 +436,9 @@
/* PRINT sc */
AUTO_OP print_sc {
- STRING *s = Parrot_string_constants[P1];
- printf("%.*s",(int)string_length(s),(char *) s->bufstart);
+ STRING *s = PCONST(P1)->string;
+ IV l = string_length(s);
+ printf("%.*s",(int)l, (char *)s->bufstart);
}
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.19
diff -u -r1.19 interpreter.c
--- interpreter.c 2001/09/24 17:19:47 1.19
+++ interpreter.c 2001/09/25 16:11:16
@@ -21,16 +21,17 @@
* Check the bytecode's opcode table fingerprint.
*/
void
-check_fingerprint(void) {
-if (Parrot_num_string_constants == 0) {
+check_fingerprint(struct Parrot_Interp *interpreter) {
+/*if (PNCONST == 0) { */
+if (interpreter->code->const_table->const_count == 0) {
fprintf(stderr, "Warning: Bytecode does not include opcode table
fingerprint!\n");
}
else {
const char * fp_data;
IV fp_len;
-
Re: SV: Parrot multithreading?
> On Monday 24 September 2001 11:54 am, Dan Sugalski wrote: > > Odds are you'll get per-op event checking if you enable debugging, since > > the debugging oploop will really be a generic "check event every op" > > loop that happens to have the "pending debugging event" bit permanently > > set. Dunno whether we want to force this at compile time or consider > > some way to set it at runtime. I'd really like to be able to switch > > oploops dynamically, but I can't think of a good way to do that > > efficiently. On a side note, back when I was doing some of my initial benchmarking, I came up with this solution to the opcode loop / event check condundrum: eventless events. (An attempt to integrate opcodes, events, and priorities.) For those that want the executive summary, it worked, but was so slow (slow as in measured-in-multiples-rather-than-percentages slow) that I never pursued it further. (Particularly because checking a flag is so relatively inexpensive, really.) Currently, the DO_OP loop is essentially a 1x1 table for opcode dispatch. (By 1x1, I mean one priority level, one pending opcode deep.) Events are a completely separate beast. So I elected to abstract an event as "a set series of opcodes" that run at a given priority, as would be referenced (basically) by the head of that particular branch of the opcode tree. I set an arbitrary number of (and meaning to) priorities, from signals to async i/o to user-defined callbacks. To remove the last vestige of distinction between regular opcodes and events, I abstracted "regular code" as a single event that ran at the lowest priority. (Or the next-to-lowest. I was contemplating, at one point, having BEGIN, INIT, CHECK, and END blocks implemented in terms of priority.) So now every opcode stream is an event, or every event is an opcode stream; depending on how you care to look at it. So now you have an 'p' x 1 table for opcode dispatch, where 'p' is the different possible run-levels within the interpreter, with one pending opcode (branch head) per runlevel. But, of course, you can have pending events. Giving our (Uri, Dan, Simon, and I - way back at Uri's BOF at the OSCon) previous agreement that events at a given priority shouldn't preempt an already scheduled event at that priority, we needed a way to queue events so that they were lost, but would still be processed at the correct time (according to our scheduler). So I lengthened the width of the table to handle 'e' events. I've now an 'p' x 'e' table. (Implemented as an array ['p'] of linked lists ['e'].) Now to offload the event overhead onto the events themselves. Each interpreter has its current priority available. The DO_OP loop uses that priority as the offset into the dispatch table (up the 'p' axis). The first opcode in the list is what gets executed. That opcode, in turn, then updates itself (the table entry) to point to the next opcode within the particular event. When a new event arrives, it appends its branch head to the priority list, and repoints the interpreter's current priority if it is now the highest. (This, in effect, suspends the current opcode stream, and the DO-OP loop begins processing the higher-level code immediately. When regular processing resumes, it picks up more or less exactly from where it left off.) When the event "exits", it deletes its own node in the linked list, and, if it were the last branch at that priority, repoints the current priority to the next highest priority that needs to be processed. It took a while to come up with the necessary incantations to Do The Right Thing when the priority switchers were themselves interrupted by an event at a higher, lower, or identical priority to the one that was just leaving. Sure, events were a lot hairier themselves than how they currently look, but events and prioirties are still rather non-existent on paper - who knows how hairy they may become to work properly. Besides, cleaning up the opcode dispatch itself was supposed to make up the difference. For those of you playing along at home, I'm sure you obviously see why *that's* not the case. Testing equality is one of the more efficient processor commands; more so when testing for non-zero (on machines that have a zero-register, or support a test for non-zero). Which is all a check against an event flag would do. Instead, I replaced it with doubly indirected pointer deferencing, which is not only damn inefficient (from a memory, cache, and paging perspective), but also can't be optimized into something less heinous. An oft-mentioned (most recently by Simon on language-dev) lament WRT Perl 6 is the plethora of uninformed-ness from contributors. So I am now informed. And so are you, if you weren't already. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Wow.
On Tuesday 25 September 2001 09:56 am, Leon Brocard wrote: > I see a great need for OpenGL opcodes (let's forget about > arrays and hashes, right?) ;-) You scoff! A cow-orker and I were just discussing hijacking some of the more powerful graphic boards routines to off-load processing. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: [PATCH] print_s_v op (was: RE: variable number of arguments)
All -- > I've created a varargs-ish example by making a new op, print_s_v. > This is pretty rough, and I haven't updated the assembler, but it > seems to work. Um.. I *have* updated the assembler. Its the *dis*assembler I haven't updated. This is what happens: * *_v ops list their number of args as 1 + the number of fixed args. They list the types of the fixed args, plus a last arg of 'v'. * The assembler sees all this and splices in an arg count for the 'v' arg place, and then hangs however many args remained on the line after the count. * The op decides how many args it is expecting. For print_s_v, that is via the format string (but really should take care to not read more than the "arg count" arg says are present. * Since the op is in control of returning the next address to execute, it is trivial for the op to arrange for excecution to continue after the last vararg (thanks, Dan!) * Since the assembler splices in the arg count, though, the disassembler won't have to think very hard to find the beginning of the next op when doing its job. * Of course, all this assumes that all args have sizeof() == sizeof(IV), which won't be true until NV constants are moved to the constants area. SO DON'T USE THEM. :) Anyway, whether or not folks really like the idea of having ops with variable numbers of args, this proves its not too hard to do with a small amount of cooperation between the assembler and the op func. Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
Re: Wow.
Bart Lateur sent the following bits through the ether: > What underlying graphics engine would you use? I see a great need for OpenGL opcodes (let's forget about arrays and hashes, right?) ;-) Leon -- Leon Brocard.http://www.astray.com/ Nanoware...http://www.nanoware.org/ ... Corrupt REALITY.SYS: Reboot Universe (Y/n)?
Re: Wow.
On Mon, 24 Sep 2001 11:29:10 -0400, Dan Sugalski wrote: >However... > >I was talking about a different instance of "bitmap". More like: > > newbm P3, (640, 480, 24, 8) # Make a 640X480, 24 bit image > # with 8 bits of alpha > drawline P3, (100, 100, 200, 200, green) # Draw a green line from > # 100, 100 to 200,200 > >and so on. Tell me you're joking. Perl 5 has no clue about graphics, and rightfully so. Implementing graphics primitives into the core sounds like an extremely bad idea. If anything belongs in a module, this is it. What underlying graphics engine would you use? Would it provide for anti-aliasing (aka "getting rid of the jaggies")? How about support for text as graphics? Fonts? Etc. the list is endless. -- Bart.
RE: Strings db
I've been looking over the gettext implementation, and I'm not sure that I entirely like it, but let me know if this sounds like I've been programming to long. (Maybe I'm misreading the document) The gettext API uses strings as "msgid". What this means is that in order to get a translated string, you might make a call like this: char *err = gettext( "Can't mmap, code!\n" ); There would then need to be an entry in the "PO" file with a msgid that matches this string. Does this sound strange? Not to sound like I'm set in my ways, or anything (but I am ;-), but I myself would expect msgid to be a #define'd numeric value. Here's a condensed example of a gettext PO entry: ... msgid "This feels strange\n" (this would be used in the gettext call) msgstr "This feels weird\n" (this line would be what's returned) and a call to the API would be: char *label = gettext( "This feels strange\n" ); Sorry, but it just seems weird to me. Couldn't we do a better job of implementing this, as well as creating a conversion system to convert PO files to our format? We would not however, be compatible with the API. Is this a bad thing? Let me know if it's just me, Grant M.
[OFF] - CVS Web reposity viewer
hi, sorry for off-topic, could u point me to the address of CVS Web reposity viewer (u use for cvs.perl.com). Privetely of cource :") Thanx alot.. = iVAN [EMAIL PROTECTED] =
Re: [patch] time.t, bitwise.t, noop tests
On Tue, Sep 25, 2001 at 12:45:02AM +0100, Alex Gough wrote: > noop didn't have a test, ironic yes, but imagine the shame if it didn't work. If noop does anything that could remotely be called work, it's broken. :) Thanks, applied. -- "The Amiga is the only personal computer where you can run a multitasking operating system and get realtime performance, out of the box." -- Peter da Silva
Re: Parrot multithreading?
On Thu, 20 Sep 2001 14:04:43 -0700, Damien Neil wrote: >On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote: >> >For clarification: do you mean async I/O, or non-blocking I/O? >> >> Async. When the interpreter issues a read, for example, it won't assume the >> read completes immediately. > >That sounds like what I would call non-blocking I/O. Nonono. Nonblocking IO returns immediately. Async IO lets the interpreter go on with another thread, until the read is done. -- Bart.
