Chromatic <[EMAIL PROTECTED]> wrote:
> Following up on the idea Leo and I discussed this morning, here's a
> patch that expects integer out parameters to be wrapped in some sort of
> INTVALy PMCs.
> This solves my problem rather nicely.
Good. As soon as we have Dan's ok and I'll have JIT adapted
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... Seems that gcc does *not*
> align function pointers by default.
I've now created a new config key:
HAS_aligned_funcptr => 1
which creates
#define PARROT_HAS_ALIGNED_FUNCPTR 1
This key is already set for GCC. So, if you are using another compil
Dave Mitchell wrote:
> On Thu, Apr 29, 2004 at 08:36:11AM +0300, Jarkko Hietaniemi wrote:
>
>>But for things like -r "file" && open(FH, "file") they are of rather
>>dubious value.
>
> Well, I have some scripts that check at the start whether all the
> things they going to need are readable/execut
# New Ticket Created by chromatic
# Please include the string: [perl #29261]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29261 >
Following up on the idea Leo and I discussed this morning, here's a
patch that expects i
On Thu, Apr 29, 2004 at 08:36:11AM +0300, Jarkko Hietaniemi wrote:
> But for things like -r "file" && open(FH, "file") they are of rather
> dubious value.
Well, I have some scripts that check at the start whether all the
things they going to need are readable/executable/whatever, so that they
can
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Thursday 29 April 2004 21:57, Paul Johnson wrote:
> > Exactly! Especially the ability to look at
> >
> > http://pjcj.sytes.net/cpancover/Math-BigRat-0.12/lib-Math-BigRat-pm.htm
> >l
> >
> > without having the "hassle" of downloading/installing Devel::Co
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> Good stuff! One thing leaps to mind when you mention the cache though...
> keep in mind that blowing L2 cache (which we might be in no danger of
> doing at all, but I'm just bringing it up) might be WORSE than you would
> think on P4 and beyond because of
Here is the latest-and-greatest version, incorporating your helpful
feedback.
I've tried using .namespace, but haven't worked out how best to do this.
I also tried removing underscores from some of the names, but didn't
have much success their either, so they're back. It'll be a few days
befor
On Thu, 2004-04-29 at 03:33, Leopold Toetsch wrote:
> As Dan already said there is no performance hit (at least if the MMD
> tables don't blow the caches).
Good stuff! One thing leaps to mind when you mention the cache though...
keep in mind that blowing L2 cache (which we might be in no danger o
Marcus Thiesen <[EMAIL PROTECTED]> wrote:
> On Thursday 29 April 2004 19:26, Dan Sugalski wrote:
>> It's distinctly possible we'll find compilers that flat-out
>> won't allow us to do this, in which case we'll need a Plan B as
>> fallback.
> Found one :-)
No ;)
2.95.x does align functions and do
At 8:27 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Yes, of course. Parrot built with the JIT throws a fatal exception
when loading up the postgres.imc library.
Should be fixed now.
Cool, thanks.
--
Dan
-
Chromatic <[EMAIL PROTECTED]> wrote:
> Would it be easier to require that all out parameters use PMCs instead
> that are converted to their low-level types? For example, for my
> signature of:
> int SDLCALL TTF_SizeText(TTF_Font *font, const char *text, int *w, int
> *h);
A PMC doesn't wo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Yes, of course. Parrot built with the JIT throws a fatal exception
> when loading up the postgres.imc library.
Should be fixed now.
leo
On Thursday 29 April 2004 19:26, Dan Sugalski wrote:
> It's distinctly possible we'll find compilers that flat-out
> won't allow us to do this, in which case we'll need a Plan B as
> fallback.
Found one :-)
gcc 2.95.4 dies during perl Configure.pl with the nice message:
cc1: Invalid option `-falig
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> It's not guaranteed anywhere, so having a fallback is definitely in
> order. It's distinctly possible we'll find compilers that flat-out
> won't allow us to do this, in which case we'll need a Plan B as
> fallback.
Plan B is a bit more expensiv but of cou
On Thu, 2004-04-29 at 10:25, Leopold Toetsch wrote:
> I'm still thinking that we should reduce the amount of signatures. Some
> special pointer types could be ok, though, *if* we can find something
> for/against the in/out problem.
Brainstorming again, I had a bit of insight.
The real problem is
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>cc1: Invalid option `-falign-functions=8'
> The manpage made it sound like it was an absolute thing, but I can
> see it being a power-of-two number. GCC 3.3.3 likes the 8, so I
> hadn't noticed. I've a =3 build going now--if it tests OK I'll commit
> the
At 7:25 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Nah, those work. And I'm using quite a number of them as part of the
postgres wrapper. (One of the reasons I have a non-jit build, since
they're not implemented in it)
If JIT can't build a signature like 'L'
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Nah, those work. And I'm using quite a number of them as part of the
> postgres wrapper. (One of the reasons I have a non-jit build, since
> they're not implemented in it)
If JIT can't build a signature like 'L' or whatnot, it falls back to
hard-wired con
Where would we be without your work ?
Out in the desert to fall prey to any bug ?
At least we can run and get some cover.
Thank you !
Gabor
At 1:15 PM -0400 4/29/04, Simon Glover wrote:
On Thu, 29 Apr 2004, Dan Sugalski wrote:
At 7:07 PM +0200 4/29/04, Leopold Toetsch wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> At 6:43 PM +0200 4/29/04, Leopold Toetsch wrote:
>>>
>>>I can't see, why this patch should break t/pmc/float.t an
On Thu, 29 Apr 2004, Dan Sugalski wrote:
> At 7:07 PM +0200 4/29/04, Leopold Toetsch wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> At 6:43 PM +0200 4/29/04, Leopold Toetsch wrote:
> >>>
> >>>I can't see, why this patch should break t/pmc/float.t and:
> >
> >> Because GCC doesn't align
At 7:12 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
And just to add extra evil, now it works. Seems that gcc does *not*
align function pointers by default.
Almost:
$ perl Configure.pl --maintainer --floatval=double --verbose-step=Determ
...
cc1: Invalid option
At 7:08 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Oh, right, and... this is really, really evil. Which is why I just
put it in. :)
*g*
Should I cleanup and implement the rest? And which opcode of the
(duplicated? mm* ops?
I'll go patch this up. I'm halfway t
At 7:07 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 6:43 PM +0200 4/29/04, Leopold Toetsch wrote:
I can't see, why this patch should break t/pmc/float.t and:
Because GCC doesn't align function pointers unless you ask it to,
Argh. System depend weird stuff.
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> And just to add extra evil, now it works. Seems that gcc does *not*
> align function pointers by default.
Almost:
$ perl Configure.pl --maintainer --floatval=double --verbose-step=Determ
...
cc1: Invalid option `-falign-functions=8'
This one want -malign
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:43 PM +0200 4/29/04, Leopold Toetsch wrote:
>>
>>I can't see, why this patch should break t/pmc/float.t and:
> Because GCC doesn't align function pointers unless you ask it to,
Argh. System depend weird stuff. gcc does function aligning on x86
though
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Oh, right, and... this is really, really evil. Which is why I just
> put it in. :)
*g*
Should I cleanup and implement the rest? And which opcode of the
(duplicated? mm* ops?
leo
At 6:35 PM +0200 4/29/04, Leopold Toetsch wrote:
Chromatic <[EMAIL PROTECTED]> wrote:
Building structs to pass around is currently very verbose and my least
favorite part of NCI. (Again, it's not nearly as tricky as XS, for
which I'm very grateful.)
Building a struct is still the right thing. W
At 11:49 AM -0400 4/29/04, Aaron Sherman wrote:
bit.ops defines some ops on strings, and not others. I was wondering if
anyone thinks the following would be useful (I'm offering to write them,
as it won't be much work):
lsls(inout STR, in INT)
lsrs(inout STR, in INT)
and, of course,
At 4:54 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote:
Another long running discussion: do we need duplicate mmd tables.
Dunno. Don't care, really--I was throwing in two tables as
proof-of-concept just to get thi
On Thu, Apr 29, 2004 at 02:01:12PM +0200, H.Merijn Brand wrote:
> Is it possible to have T::M skip the rest of the script from here on on a
> certain condition?
Its pretty trivial with Test::Builder.
use Test::Builder;
$TB = Test::Buider->new;
sub skip_rest {
my($why) = @_;
my $nu
This is a pretty important release. It fixes a nasty bug in the last
release and improves the coverage collection. To test it I have rerun
cpancover. You can see the results at http://pjcj.sytes.net/cpancover/
If you have had problems recently I suggest upgrading.
Changes since the last announ
On Fri, Apr 02, 2004 at 09:45:24PM -0500, Randy W. Sims wrote:
>
> Paul Johnson wrote:
> >I am considering dropping support for Perl 5.6 in Devel::Cover. Whilst
> >Devel::Cover basically works with Perl 5.6.1 and Perl 5.6.2, there are
> >many parts which are difficult or impossible to implement, l
Is it possible to have T::M skip the rest of the script from here on on a
certain condition?
--8<---
use Test::More tests => 765; # a lot
ok (.);
# many ok (), like (), and such
SKIP: {
$state or skip "What rest?", 0; # <-- I don't know $how_many
:
:
:
:
}
-->8---
or
At 6:43 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
cvsuser 04/04/29 08:56:04
Add in Leo's proof-of-concept single table MMD patch, though it does
kill the float tests right now
I can't see, why this patch should break t/pmc/float.t and:
Because GCC
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> cvsuser 04/04/29 08:56:04
> Add in Leo's proof-of-concept single table MMD patch, though it does
> kill the float tests right now
I can't see, why this patch should break t/pmc/float.t and:
$ perl -Ilib t/pmc/float.t
1..9
ok 1 - basic assignment
Chromatic <[EMAIL PROTECTED]> wrote:
> Building structs to pass around is currently very verbose and my least
> favorite part of NCI. (Again, it's not nearly as tricky as XS, for
> which I'm very grateful.)
Building a struct is still the right thing. We currently already have
some more (unimplem
At 11:42 AM -0400 4/29/04, Dan Sugalski wrote:
At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote:
Another long running discussion: do we need duplicate mmd tables.
Here is a proof of concept to avoid it:
Oh, right, and... this is really, really evil. Which is why I just
put it in. :)
And just to add
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote:
>>
>>Another long running discussion: do we need duplicate mmd tables.
> Dunno. Don't care, really--I was throwing in two tables as
> proof-of-concept just to get things going.
As there can be just one entr
bit.ops defines some ops on strings, and not others. I was wondering if
anyone thinks the following would be useful (I'm offering to write them,
as it won't be much work):
lsls(inout STR, in INT)
lsrs(inout STR, in INT)
and, of course, their appropriate permutations.
For those wh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
I am research student in Ireland and I have been working on this problem for a
while now, I have spent a couple of months getting to grips with gcc
internals, (by the time I finish this project I might not have any hair left
on my head ;o).
On Thu, 2004-04-29 at 03:05, Tim Bunce wrote:
> > Provided we pick a convention that makes sense (that is, out parameters
> > go in I5, I6, ... In, and then the actual returned value goes at the end
> > of the list in In+1) and stick with it, I like option A a little better.
>
> Is there a good r
On Thu, 2004-04-29 at 05:43, Dan Sugalski wrote:
> While it's much nicer to reorder the parameters, I left them in that
> way on purpose. Once you start reordering in and out parameters then
> you get into multiple joined parameters (buffer pointers and lengths)
> and then it starts (well, cont
At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote:
Another long running discussion: do we need duplicate mmd tables.
Here is a proof of concept to avoid it:
Oh, right, and... this is really, really evil. Which is why I just
put it in. :)
--
Dan
--
hi Guys
I am working on this problem as my masters research project.
Details to follow soon
On Saturday 20 March 2004 16:33, Gerald E Butler wrote:
> Hello all,
>
> I've been investigating the possibility of creating a MACHINE
> DESCRIPTION (aka BACK-END) for GCC to target PARROT. My thinki
At 4:10 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Just to double-check--it's OK to register *any* sub as a compiler
module, though for right now it'll ultimately need to call compile
itself to either the pasm or pir compiler module and return the
result of
The first in a hopefully neverending stream of todo items for folks
who want to, well, do something.
In this case your task, if you choose to accept it, is to turn
languages/forth/forth.pasm into a loadable compiler module that you
can compile workable forth code with. (Adding new base words ar
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Just to double-check--it's OK to register *any* sub as a compiler
> module, though for right now it'll ultimately need to call compile
> itself to either the pasm or pir compiler module and return the
> result of that, yes?
That's more a matter of definit
At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Okay, we've a long-running discussion between Leo and I about the
keyed variants for all the binary vtable entries.
Another long running discussion: do we need duplicate mmd tables.
Dunno. Don't care, really
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, we've a long-running discussion between Leo and I about the
> keyed variants for all the binary vtable entries.
Another long running discussion: do we need duplicate mmd tables.
Here is a proof of concept to avoid it:
#v+
--- parrot/src/mmd.cTh
We've talked about specialized code to store pointers for the DOD in
the past, and I think that now it's time to start doing that.
What we want to do, basically, is make sure that all stores of
pointers to DOD-able structures *into* DOD-able places are done with
a mediating function. (Or macro,
Richard Jones is the author of "Garbage Collection: algorithms for automatic
dynamic memory management"
http://www.amazon.com/exec/obidos/tg/detail/-/0471941484. A book that I
believe has been mentioned on the list before.
I do not believe anyone has mentioned his website:
http://www.cs.kent.ac.uk
At 8:56 AM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Looks like compiler modules may be done in one of three ways:
1) A plain sub, which is passed in the string to compile and returns
a sub PMC that represents the compiled code (if it actually does
something
At 9:00 AM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Log:
It's whether JIT_CAPABLE is set, not exists
Ah yes. Thanks. It's too simple to mix these two cases. There were some
approaches to unify that along with unique PARROT_ prefixes.
Yeah. Not a big deal,
At 1:11 PM +0200 4/29/04, Leopold Toetsch wrote:
Stefan Lidman <[EMAIL PROTECTED]> wrote:
Hi,
These patches adds Downcase, upcase and titlecase but only
works for [A-Za-z] so maybe they should not be added.
Yep. But we can use something like that as fallback in the absence of
ICU. ASCII only, t
At 10:36 PM -0700 4/28/04, chromatic wrote:
On Wed, 2004-04-28 at 03:23, Leopold Toetsch wrote:
> Well, that's ok for this one. Bu, what if we have:
int foo(int *i, int *j) {}
in I5 in I6
out I5
We could fake that as:
(i, j, retval) = foo(i, j)
and count each pointer type a
Nick Glencross (via RT) wrote:
# New Ticket Created by Nick Glencross
# Please include the string: [perl #29246]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29246 >
While creating a test script for Digest_MD5.imc (atta
Stefan Lidman <[EMAIL PROTECTED]> wrote:
> Hi,
> These patches adds Downcase, upcase and titlecase but only
> works for [A-Za-z] so maybe they should not be added.
Yep. But we can use something like that as fallback in the absence of
ICU. ASCII only, that's it.
> /Stefan
leo
Stefan Lidman <[EMAIL PROTECTED]> wrote:
> Hi
> I am getting a segfault when trying to set the
> size of a FloatvalArray.
Thanks fixed.
> see test patch
leo
# New Ticket Created by Nick Glencross
# Please include the string: [perl #29246]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29246 >
While creating a test script for Digest_MD5.imc (attached, and should be
placed in
On Wed, Apr 28, 2004 at 10:36:00PM -0700, chromatic wrote:
> > Or, we forget about these special cased pointer to int and pass a
> > managed struct.
>
> That's cleaner from the C side, but it's enough of a pain to set up
> managed structs on the calling side that I'd rather do it only when it's
>
Hi,
These patches adds Downcase, upcase and titlecase but only
works for [A-Za-z] so maybe they should not be added.
/Stefan
Index: ops/string.ops
===
RCS file: /cvs/public/parrot/ops/string.ops,v
retrieving revision 1.22
diff -u -r
Hi
I am getting a segfault when trying to set the
size of a FloatvalArray.
see test patch
/Stefan
Index: t/pmc/floatvalarray.t
===
RCS file: /cvs/public/parrot/t/pmc/floatvalarray.t,v
retrieving revision 1.1
diff -u -r1.1 floatvala
On Fri, 2004-04-23 at 17:24, Larry Wall wrote:
> [...]
>
> On the sixth hand, by that argument, since .dispatcher is aiming at
> a Class, it should be an uppercase C<>. :-)
why not wash all these hands altogether?
IDEA 1
implementing a "final" trait should be trivial enough (it just throws an
On Mon, 2004-04-26 at 16:20, Richard Proctor wrote:
> Issues:
>
> 1) Why does this only use Version and Author? Suppose there are versions
> for different oses or that use other particular libraries that are wanted
> or not?
personally, I think this should be handled in the class itself.
you alw
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Apr 28, 2004, at 4:57 AM, Bryan C. Warnock wrote:
>> Does (that which the masses normally refer to as) binary data
>> fall inside or outside the scope of a string?
> Some languages make this very clear by providing a separate data type
> to hold a "blob
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Log:
> It's whether JIT_CAPABLE is set, not exists
Ah yes. Thanks. It's too simple to mix these two cases. There were some
approaches to unify that along with unique PARROT_ prefixes.
We'd need a more consistent naming of such defines and at best just
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> On Wed, 2004-04-28 at 11:33, Dan Sugalski wrote:
> Only one question. What's the performance hit likely to be and is there
> any way around that performance hit for code that doesn't want to take
> it?
As Dan already said there is no performance hit (at
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Looks like compiler modules may be done in one of three ways:
> 1) A plain sub, which is passed in the string to compile and returns
> a sub PMC that represents the compiled code (if it actually does
> something)
> 2) An NCI sub with the signature pIt
> 3)
Nick Glencross <[EMAIL PROTECTED]> wrote:
> Also, I tried using the @MAIN pragma, this seemed to break with JIT
Brr. Fixed. A bug hanging around really long and waiting for mainly
integer stuff and @MAIN not at byte_code[0].
The JIT optimizer, which also looks at branches didn't look at anything
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Personally I'm of the geometric distance school here, but it can get
> a bit tricky, so I'm all for discussion on it. So... let's have at
> it. :)
If you can provide a distance table for these PMCs:
- PerlUndef
- PerlInt
- PerlNum
- PerlString
- Integer
-
I'll fix these (and some other things mentioned in other posts in this
thread), and repost again in the next day or so,
Thanks all,
Nick
Leopold Toetsch wrote:
Nick Glencross <[EMAIL PROTECTED]> wrote:
for fun I've written md5sum using IMCC, and have attached my first cut.
Yet another f'u
73 matches
Mail list logo
