Am Dienstag, 15. Juli 2008 23:35 schrieb Patrick R. Michaud:
> On Tue, Jul 15, 2008 at 11:17:23PM +0200, Leopold Toetsch wrote:
> > 21:51 < pmichaud> so unicode:"«" and unicode:"\xab" would produce
> > exactly the same result.
> > 21:51 <
Hi,
I just saw that and such (too late) at #parrotsketch:
21:52 < NotFound> So unicode:"\xab" and utf8:unicode:"\xab" is also the same
result?
In my opinion and (AFAIK still in the implementation) is it that the encoding
bit of PIR is how the possibly escaped bytes are specifying the codepoi
Hi,
there was some benchmarking and discussion about perl5 slowness in ...
http://groups.google.at/group/perl.perl5.porters/browse_thread/thread/4ad7f6edacc97e1b/75af8abf89420f8c?hl=de&;
... and of course there were some remarks re parrot.
I'm not subscribed to p5p, so feel free to forward the me
Am Montag, 21. April 2008 22:49 schrieb chromatic:
> On Monday 21 April 2008 13:44:44 Patrick R. Michaud wrote:
> > On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
> >
> > Thanks again. I was misreading from comments in stack_push, which
> > say that it pushes things onto the "generic
Am Freitag, 11. April 2008 21:02 schrieb Nuno 'smash' Carvalho:
> Greetings all,
>
> I just posted a little Parrot benchmark in my use.perl's journal
Just a reminder:
Please don't use unoptimzed builds for benchmarking. There are a lot of code
asserts and other slowdowns due to compiler goodwil
Am Samstag, 12. April 2008 02:27 schrieb chromatic:
> I've committed a couple of minor optimizations which speed up Rakudo and
> Perl OO in general by about 35%. There may be a few more lurking, but I
> keep running into three spots which dominate most of the other optimization
> strategies I migh
Am Mittwoch, 2. April 2008 22:34 schrieb Will Coleda:
> Can we get an idea of how many parrot hackers are planning on
> attending YAPC::EU this year? (will be held in Copenhagen, Denmark, on
> 13-15 August 2008.)
>
> http://www.yapceurope2008.org/ye2008/
It's very likely that I'll be there. "Parro
Hi,
while I wanted to help Infinoid finding `make -jn` bugs, I had an idea: build
a static parrot and compare nm symbols for diffs [1].
But the static build failed. I used to do:
[EMAIL PROTECTED]:~/svn/parrot/leo> cat doits
perl Configure.pl --maintainer --parrot_is_shared=0 "$@" 2>&1 | tee ma
Am Samstag, 8. März 2008 13:59 schrieb Simon Cozens:
> Hi folks,
> I think I've finished doing what I can with
> docs/pdds/draft/pdd28_character_sets.pod for the time being.
> Please have a look at it, and let me know if there's anything wrong,
> anything unclear, anything missing or an
Am Donnerstag, 13. März 2008 23:01 schrieb chromatic:
> It looks like the UnionVal is two pointers long, so if we rearranged things
> such that flags comes first, would the Buffer structure get padded so that
> anything after that in memory starts at the appropriate alignment for a
> pointer?
Look
Am Dienstag, 11. März 2008 22:39 schrieb Ron Blaschke:
> > if (!x) \
There were of course some parens missing ...
if (!(x)) \
leo
Am Dienstag, 11. März 2008 20:43 schrieb Ron Blaschke:
> void
> Parrot_assert(INTVAL condition, ARGIN(const char *condition_string),
> ARGIN(const char *file), unsigned int line)
> ...
>
> PARROT_ASSERT is used to assert pointers too, for example in src/string.c:
What about making Parrot_
Am Sonntag, 24. Februar 2008 10:55 schrieb chromatic:
> PMCs that *do* need a special mark() are troublesome; they may contain
> pointers to non-constant PObjs that *do* need live marking, lest they get
> swept away during the second half of GC. If these constant PObjs don't get
> marked, there's
Am Donnerstag, 24. Januar 2008 00:18 schrieb Leopold Toetsch:
> a) help the register allocator with the 'tmp' reallocation (the register
> allocator is currently very dumb)
The answer was probably a bit terse, more info is here:
In src/pic_jit.c are some tests, if a subroutine
Am Donnerstag, 24. Januar 2008 00:03 schrieb chromatic:
> On Wednesday 23 January 2008 14:35:22 [EMAIL PROTECTED] wrote:
> > Author: leo
> > Date: Wed Jan 23 14:35:19 2008
> > New Revision: 25177
> >
> > Modified:
> >trunk/examples/shootout/recursive.pir
> >
> > Log:
> > speed up shootout/recur
Hi,
with a few modifications (r25177, r25178) the speed of that test is again at
parrot's peak (it was at some 4m14s before):
23:43 <@leo> $ time ./parrot -Oc -Cj examples/shootout/recursive.pir 11
23:43 <@leo> real0m2.307s
23:43 <@leo> $ time ./recursive 11 # gcc version 4.1.0 w/ -O3
Am Freitag, 14. Dezember 2007 04:01 schrieb Will Coleda:
> From PDD17:
>
> Methods are declared in the body of the C or C
> declaration with C.
>
> METHOD inspect(STRING *what :optional, int got_what :opt_flag) {...}
>
> [NOTE: There is an older C keyword, which is deprecated. The
> current C wil
Am Dienstag, 1. Januar 2008 08:39 schrieb Andy Lester:
> Just reporting what GCC tells me, and I don't see that it's wrong. It
> says that time_struct below is not initialized before use, and I sure
> don't see that it isn't.
Fixed in 24405.
> struct timespec *time_struct;
This is a pointe
Am Dienstag, 9. Oktober 2007 22:25 schrieb Paul Cochrane:
> In compilers/imcc/optimizer.c:move_ins_out() there is the todo item:
I really appreciate all the effort to todo-ize these items. But it shouldn't
be done too mechanically.
a few greps in optimizer.c reveal:
* move_ins_out() is only use
Am Montag, 8. Oktober 2007 19:05 schrieb Paul Cochrane:
> So, the patch is right (however, for my wrong reasoning)? Is everyone
> happy if I apply it then?
$ svn ann src/pmc/pair.pmc
8374leo A Pair PMC represents one key => value mapping like a one
element hash.
I actually can't remem
Hi,
some days ago near #parrot:
17:13 if you get a chance, allison has modified pdd17 (pmc). i'm
reviewing it, but i think you'd be a better judge of its implications on gc,
etc.
17:14 I'll have a look at it - thx
Well, xx days after, I had a very brief look at it:
- it's mostly a summary o
Am Sonntag, 23. September 2007 20:19 schrieb Bram Geron:
> To test if 'from_ctx' is redundant, I tried removing the field and all
> accesses to it, and no extra tests failed (see patch).
Did you run a memory leak test? The from_ctx is refcounted for some reason.
leo
Am Montag, 27. August 2007 22:27 schrieb Paul Cochrane:
> Mehmet and Joshua,
>
> I can't believe I missed the comment! How embarassing! Thanks
> heaps to you both for pointing that out for me :-)
Just in case:
http://en.wikipedia.org/wiki/Halt_and_Catch_Fire
Have fun,
leo
Am Sonntag, 26. August 2007 20:14 schrieb Paul Cochrane:
> The variable ins2 is freed by the call to subst_ins() but is then
> later assigned to later in the if-block. Um, this isn't a good idea
> is it?
Why shouldn't you be able to assign a new value to a freed mem location? Your
proposed chang
Am Mittwoch, 15. August 2007 20:05 schrieb Ron Blaschke:
> As you can see, the code is heavily optimized. The pointer to the
> interpreter is kept on the stack as it should stay the same, only the
> opcode is exchanged. *should* is the key word here.
Well, another note.
This optimization reache
Am Mittwoch, 15. August 2007 20:05 schrieb Ron Blaschke:
> Visual C++ seems to optimize quite heavily, and it looks like it reuses
> the memory on the stack where arguments are passed for local variables.
> mov dword ptr [ebp+0Ch],edx
All I know about intel calling convs would summarize this
Am Mittwoch, 1. August 2007 00:39 schrieb Bram Geron:
> Leopold Toetsch wrote:
> > It might be on the stack or just in a CPU register. While we have
> > code to mark all possible pointers on the stack, this isn't generally
> > true for CPU registers, as that's rathe
Am Donnerstag, 19. Juli 2007 19:16 schrieb chromatic:
> >
> > The problem is as follows:
> >
> > 1) PObj_custom_mark_SET(SELF);
> > 2) counter = pmc_new(INTERP, enum_class_Integer);
> > 3) PMC_data(SELF) = counter;
> >
> > In 1) you enable marking. 2) might cause a garbage collection, while the
> >
Am Donnerstag, 19. Juli 2007 02:48 schrieb Will Coleda:
> I am trying to write a PMC version of PGE::CodeString, and while I
> have a PMC now that passes all the old tests, I get GC errors during
> the build process for TGE & JSON.
>
> I know they are GC related because running the affected ste
Am Sonntag, 8. Juli 2007 17:41 schrieb Klaas-Jan Stol:
> hi,
>
> I was planning to do some updates for the "book' (docs/dev/book), and it's
> still saying that one can use 0-31 registers in PASM.
It doesn't make sense to start updating such minor things. You'll end up
rewriting almost all of the
Am Dienstag, 19. Juni 2007 16:52 schrieb Patrick R. Michaud:
> perl6 is now passing all of the 01-sanity tests.
Woot.
Wouldn't that qualify for a 0.5.0 release number.
leo
Am Montag, 18. Juni 2007 23:48 schrieb Andy Lester:
> Is there a reason we use
>
> memcpy( dest, src, sizeof(FOO) );
>
> instead of
>
> *dest = *src;
>
> The latter should be the exact same code, but be much less likely to
> be screwed up.
I'm using a lot of the first kind. The main reason
Am Mittwoch, 13. Juni 2007 05:02 schrieb chromatic:
> PMC * const key = VTABLE_nextkey_keyed(interp, key_new(interp),
> ns, ITERATE_FROM_START);
>
> If a GC run happens in the rest of this function, it could collect the
> newly created Key -- PMCs created and held outside of structures vi
Am Montag, 4. Juni 2007 03:40 schrieb chromatic:
> > > #define c_b 25245
> >
> > Another WTF from code history.
> >
> > leo - please remove this - kthx.
>
> We have to replace it with something; any ideas?
Well, just the "normal" way of parsing commands. Chained ifs:
if (!memcmp(cmd
Am Montag, 28. Mai 2007 01:45 schrieb pancake:
> I have been reading the source code of he virtual machine a bit and found
> some confusing things and other stuff that imho should change.
>
> Most of this patches are merely stupid, so they are easy to fix and will
> reflect on a clenaer and reduced
Am Samstag, 26. Mai 2007 21:19 schrieb chromatic:
> > > Whoops, that just broke a couple of platforms. As I understand it,
> > > some picky compilers only allow simultaneous declarations and
> > > assignments at the start of a function, not within any block.
> >
> > They wouldn't be C89 conformant
Am Mittwoch, 23. Mai 2007 15:26 schrieb Andy Dougherty:
> /*
> * These constants correspond to the debugger commands and are
> * used in src/debug.c. To map command strings to their
> * numeric values, use the algorithm from parse_command() in that file.
> */
>
> #define c_b 25245
Am Mittwoch, 23. Mai 2007 04:05 schrieb Patrick R. Michaud:
> Here's the perl 6 code:
>
> my $a = sub { ... }; # $a is a subroutine reference
> my $b := $a;
> # ...;
> $a = 4; # $a is now an Int
>
> How to do the above in PIR if we can't morph a Sub?
I may be
Am Sonntag, 20. Mai 2007 21:51 schrieb Bram Geron:
> Bram Geron wrote:
> > The patch in fixes the problem for me.
>
> I realized that contexts currently initially have a ref_count of 0, if
> they're not used as :outer targets for other subs. So in 'normal'
> situations, the caller's context's ref_
Am Mittwoch, 16. Mai 2007 11:50 schrieb tewk:
> A couple of questions:
>
> 1: Only two pmcs have the const_too flag SArray and ParrotLibrary.
> This seems redundant given that all pmcs except abstract, singleton, and
> const_too pmcs get a read only variant of the vtable. Is there any
> reason, w
Am Dienstag, 15. Mai 2007 21:28 schrieb Nicholas Clark:
> On Tue, May 15, 2007 at 12:10:09PM -0700, Mike Mattie wrote:
> > If someone remembers the magic to muzzle the compiler around free( from )
> > in memory.c please feel free to amend the patch.
>
> I remember being told that there's a trick in
Am Dienstag, 15. Mai 2007 01:17 schrieb chromatic:
> Hi everyone,
>
> I'm handling the release tomorrow, so please hold off on changes to the
> core code until after the release. Documentation and typo fixes are fine.
> Language changes are fine too. Not-too-invasive bug fixes are good.
>
> In th
Am Donnerstag, 10. Mai 2007 23:07 schrieb Andrew Dougherty:
> On Wed, 9 May 2007, Andy Dougherty wrote:
> > Ok, I've got it compiling, at least. I'll let it run tests overnight and
> > submit a cleaned-up patch tomorrow. I've gone back and reviewed the
> > alignment issue and think I have impleme
-- Weitergeleitete Nachricht --
Subject: [Vienna-pm] YAPC Europe 2007 Reminder - CFP and CFH Deadlines
Approaching
Date: Dienstag, 8. Mai 2007 11:04
From: Michael Kröll <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Hi,
The deadline to submit Hackathon proposals for this year's Y
Am Sonntag, 6. Mai 2007 12:32 schrieb pancake:
[ no TOFU please ]
> I think that the right way to handle paddings for memory alignment
> is using the pack(1) pragma directive to make everything fit on 1
> byte and ensure by code that what we do is correct (instead of
> relaying this task to the c
Am Samstag, 5. Mai 2007 10:00 schrieb chromatic:
> On Thursday 03 May 2007 18:04:48 chromatic wrote:
> > I'll debug the segfault and see if that reveals anything interesting.
> >
> > The shootout tests are dodgy anyway sometimes.
>
> In this case, sorting the vtable functions put the init vtable me
Am Mittwoch, 2. Mai 2007 21:25 schrieb Yehoshua Sapir:
> I'm working on ticket #38929
> ( http://rt.perl.org/rt3//Public/Bug/Display.html?id=38929 )
>
> As far as I can tell, there's a JIT_EMIT #define that the .c files set
> before they #include jit_emit.h, and what it does is switch out parts of
Am Freitag, 27. April 2007 22:10 schrieb chromatic:
> This part bothers me:
Indeed, your feeling is totally legitimate.
> +++ src/mmd.c (working copy)
> @@ -1703,7 +1703,12 @@
> +#ifndef __INTEL_COMPILER
> assert((PTR2UINTVAL(mmd_table[i].func_ptr) & 3) == 0);
The assert is of course
Am Donnerstag, 26. April 2007 21:44 schrieb Andy Dougherty:
> Does anyone understand the 'dummy' element in
> include/parrot/stacks.h? Here is the relevant snippet:
>
> typedef struct Stack_Chunk {
> pobj_t obj;
> int size;
> const char * name;
> struct Stack_Ch
Am Donnerstag, 26. April 2007 16:43 schrieb Steve Peters:
> - long * const out_array = mem_sys_allocate((sizeof (long)) * (arraylen
> + 1)); + long * const out_array = (long *)mem_sys_allocate((sizeof
> (long)) * (arraylen + 1));
I don't understand the rational for such patches nor the mem_a
Am Montag, 23. April 2007 23:18 schrieb Jonathan Worthington:
> Proposal: PMCs can have attributes just as classes in HLLs have
> attributes. This is somewhat related to variable sized PMCs; note you
> can leave PMC headers fixed size and just have a pmc_ext like structure
> that is the variable si
Am Dienstag, 24. April 2007 07:45 schrieb chromatic:
> Here's my solution; don't allocate zero-sized buffers. Let them be empty.
Great catch. Thanks.
Indeed - zero-size allocs should just be ignored or/and even the source of
such requests be weeded out.
leo
Am Montag, 23. April 2007 18:07 schrieb Jonathan Worthington:
> > /* turn on marking of the class_data array */
> > PObj_data_is_PMC_array_SET(self);
> >
>
> I saw those before and thought they were very suspect;
It's not per se suspect. The (data*) points to an array of obje
Am Montag, 23. April 2007 20:23 schrieb chromatic:
> On Thursday 05 April 2007 16:56, Mehmet Yavuz Selim Soyturk wrote:
> > The next program causes a memory leak for me.
> >
> > .sub main :main
> > loop:
> > $P0 = new .String
> > goto loop
> > .end
That's an endless loop. How does one meas
Am Sonntag, 22. April 2007 23:34 schrieb Patrick Rutkowski:
> + const int slot;
> + /* round reg_alloc up to the nearest multiple of 8 */
> + reg_alloc = ((reg_alloc + 7) >> 3) << 3;
> +
> + /* reg_alloc now divides evenly by 8 because of the previous
> + rounding. A granualrity o
Am Sonntag, 22. April 2007 23:14 schrieb chromatic:
> I figured it was a rounding, but I saw two magic numbers and didn't want to
> guess what it was.
Well, sorry. I thought the rounding was obvious. But obviously I was wrong.
Some macros for rounding up are for sure a good thing. The packfile c
Am Sonntag, 22. April 2007 22:47 schrieb Patrick Rutkowski:
> Yes, I see that now, but that doesn't answer the questions.
>
> Why did you choose reg_alloc/8 as an index into free_list?
A granualrity of 8 is of course arbitratly, could be some bigger power of 2
too.
> Why does the code need to in
Am Sonntag, 22. April 2007 14:40 schrieb Patrick Rutkowski:
> Ok, so I see now that reg_alloc is rounded up to a multiple of 8 by
> the following two lines:
>
>/*code*/ const int slot = (reg_alloc + 7) >> 3;
>/*code*/ reg_alloc = slot << 3;
>
> However, this still begs the question of what
Am Sonntag, 22. April 2007 09:11 schrieb Patrick Rutkowski:
> I think Leo would be the best person to go to for an explanation,
> especially if you plan to dramatically rework the code.
> >> This is where I start not to understand. Why reg_alloc + 7? Why
> >> shift left
> >> and right by 3?
> >
Am Dienstag, 17. April 2007 23:48 schrieb Steve Peters:
> + strncpy(format, fmt, sizeof(format - 1));
Me thinks, that it's better to check the len of the format as it grows,
considering the amount what would be strcat'ed. If an index really would
overflow format, a proper syntax error cou
Am Mittwoch, 11. April 2007 00:25 schrieb Allison Randal:
> 3) Modify the core PMC implementation so it tracks information about
> which the different containers (registers, temporary variables,
> namespace entries, etc.) that hold a particular PMC, and which
> particular container was used to make
Am Donnerstag, 5. April 2007 17:22 schrieb via RT:
> # New Ticket Created by
> # Please include the string: [perl #42313]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=42313 >
>
>
> load_func is not a void pointer.
>
> Inde
Am Donnerstag, 5. April 2007 07:35 schrieb jerry gay:
> developers shouldn't live in fear of $^O
And the docs for some such are not far away:
$ perldoc perlvar
/\$\^O
leo - yes, typing this needs escaping, but you knew that already - it's
Perl ;)
Am Donnerstag, 5. April 2007 00:39 schrieb Jonathan Worthington:
> Don't really need a policy to tell me that breaking stuff for languages
> folks sucks. :-) I try hard to avoid it, but unfortunately stuff slips
> through the net occasionally. In this case, I wasn't even aware that you
> could use
Am Dienstag, 3. April 2007 06:56 schrieb Allison Randal:
> > The major problem is probably, that there are no specific iterator
> > interface vtable functions that an iterator would use.
>
> Isn't that what nextkey_keyed is for? Though, looking at it, it seems
> more like part of the problem of ent
Am Montag, 2. April 2007 08:24 schrieb Allison Randal:
> The significant differences between the two are that Iterator's
> shift_pmc throws an exception if the iteration key is -1 while
> shift_string doesn't bother to check (it probably should), and
> shift_string calls VTABLE_get_string_keyed on
Am Montag, 2. April 2007 07:37 schrieb Joshua Isom:
> I'm not sure how the imcc compiler handles the .Foo syntax internally,
> but there's a file, runtime/parrot/include/pmctypes.pasm that at least
> appears as though it's magically included into the beginning of every
> pir/pasm file.
Nope the pm
Am Samstag, 31. März 2007 00:23 schrieb Paul Cochrane:
> > It would be pretty simple to make this a settable/queryable interpreter
> > property. Would that be valuable?
>
> It's already a gettable interpreter property
> (interp->recursion_limit). I'm guessing it would be valuable to be
> able to
Am Freitag, 30. März 2007 00:44 schrieb Steve Peters:
> Sweeping dirt under the rug doesn't mean that the house has been cleaned
> up.
It's not related to hiding other possible errors. Some warnings are just not
appropriate to the usage of the very code, and there are a lot of them.
leo
Am Donnerstag, 29. März 2007 23:01 schrieb chromatic:
> On Thursday 29 March 2007 13:27, Leopold Toetsch wrote:
> > > Compactness does not supersede good design.
> >
> > Basically & in theorie yes, but don't always forget performance.
>
> Until we get compl
Am Donnerstag, 29. März 2007 00:00 schrieb Alek Storm:
> On 3/28/07, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> > 1) This ism't needed, these pointers are only valid and needed up to the
> > next
> > sub call/return.
>
> The current_results member alrea
Am Mittwoch, 28. März 2007 20:41 schrieb Nicholas Clark:
> Getting parrot to build under -ansi -pedantic is left as an exercise to the
> reader.
By filtering other useless and/or nonsensical warnings - yes - else no.
leo - been there, done that
Am Mittwoch, 28. März 2007 03:14 schrieb Alek Storm:
> This patch moves args_signature, params_signature, returns_signature,
> current_args, current_params, and current_returns from Parrot_Interp
> to Parrot_Context. This makes the interpreter more reentrant, which
> is always a good thing.
Nope.
Am Dienstag, 27. März 2007 21:55 schrieb Andrew Dougherty:
> On Tue, 27 Mar 2007, Andy Dougherty wrote:
> > I think you'll find a lot of lower-level cleanups are in order.
>
> [other stuff deleted.]
>
> Oops! My previous message was not appropriate, and I didn't mean to send
> it. Please ignore i
Am Dienstag, 27. März 2007 21:39 schrieb Andy Dougherty:
> Leo
> tended to assume all pointers could equally well point anywhere, and often
> ignored alignment issues.
Nope. Sorry.
leo
Am Dienstag, 27. März 2007 19:52 schrieb Andy Dougherty:
> Instead of sprinking (opcode_t *) casts everywhere, wouldn't it be better
> to declare the invoke() function as returning an (opcode_t *) ?
True. But while invoke() et al receive and return an (opcode_t*) the actual
running runloop (wi
Am Dienstag, 27. März 2007 16:19 schrieb Andy Dougherty:
> Many of the examples in examples/shootout specify preferred flags. For
> example, ack.pir starts with
>
> #!./parrot -Oc -Cj
>
> I don't know what -Oc does. docs/running.pod doesn't say. It refers to
> the non-existent F for more det
Am Dienstag, 13. März 2007 11:55 schrieb Nuno Carvalho via RT:
> so IMHO the max allowed size of the register name in the lexer
> should be the max allowed for an INTVAL.
Please folks, get serious. INTVAL allows 2^31/2^63 registers. A register is
taking 4/8 bytes of mem. Multiply.
Or IOW allowin
Am Montag, 12. März 2007 21:34 schrieb chromatic:
> What does this do to the register allocator and to memory usage? If I use
> integer registers 10,000 and 100,000, will Parrot allocate a sparse data
> structure?
Of course not ;) PASM regs are "physical" registers. The register allocator
alloca
Am Donnerstag, 8. März 2007 20:25 schrieb Jerry Gay:
> either move this to experimental.ops, or remove it entirely. i vote to
> remove it. we don't need temporary hacks as core ops.
$ find . -name '*.pir' | xargs grep substr_r
...
./examples/shootout/revcomp.pir:$S0 = substr_r line, i, 60
Am Sonntag, 25. Februar 2007 12:28 schrieb Klaas-Jan Stol:
> Can you tell whether pbc_output_is() can take PIR code and compile it
> during running the test? Or does is always expect the pbc file to be
> present?
As said, it doesn't make sense to feed .pir code into these tests. So no /
yes.
leo
Am Samstag, 24. Februar 2007 17:05 schrieb Klaas-Jan Stol:
> it seems the .pbc files are stored in the repository is that
> desirable?
Yes for these files.
> IMO, it would be enough to store the PIR only, and have that
> compiled to PBC
If you have a closer look at these .pbcs, you'll see
Am Dienstag, 6. Februar 2007 17:54 schrieb Allison Randal:
> This is a failing test Leo added in r16783. It looks to me like calling:
> > o = new 'MyClass', $P0
>
> actually should call init_pmc, rather than init, even when $P0 is null.
> Leo, are you saying the choice between init and init_pmc
Am Mittwoch, 31. Januar 2007 12:00 schrieb Klaas-Jan Stol:
> So, my question is now, why do we still need the PASM registers
PASM registers are physically allocated within the Parrot virtual machine.
PIR registers are virtual registers, like .local variable w/o a name. The
register allocator assi
Am Donnerstag, 25. Januar 2007 06:23 schrieb Matt Diephouse:
> > This change is just adding more mess to object construction and argument
> > passing.
> >
> > I've made several attempts to unify object construction with new calling
> > convs
> > but no one seems to be listening :-(
>
> That was a c
Hi,
some changes not too long before the release did break pg.t. I was now able to
track it down:
now the object constructor:
$I0 = find_type ['Pg';'Conn']
o_con = new $I0, con
does _not_ call
.sub init :vtable :method
anymore
it's calling init_pmc instead.
This change is just
Am Donnerstag, 18. Januar 2007 21:58 schrieb Matt Diephouse:
> ~/Projects/parrot mdiep$ cat test.pir
> .sub main :main
> null $P0
> multi($P0) # should print "Any\n"
> .end
>
> .sub multi :multi(String)
> say "String"
> .end
>
> .sub multi :multi(_)
> s
Am Mittwoch, 17. Januar 2007 02:07 schrieb jerry gay:
> i never officially closed the repo to commits, but for those of you
> awaiting parrot's release, it's now complete. you may commit freely.
> thanks for your patience.
Congrats. Well done.
> ~jerry
Thanks
leo
Am Mittwoch, 3. Januar 2007 16:43 schrieb Nicholas Clark:
> I would think that Sparc Solaris, building 64 bit, would be the best single
> target to aim for to increase portability spread.
During the last few releases I did, I built/tested with gcc and sun cc on the
z1.t2000... box, but it seems t
fixed in r16383
Am Mittwoch, 20. Dezember 2006 20:24 schrieb Ron Blaschke:
> - The assertion seems to check that the lowest two bits of a function
> pointer are zero. Why's that?
That's a bigger hack to discern function from PMC pointers in that table. That
hack and the whole table needs to be replaced by a mor
Am Mittwoch, 20. Dezember 2006 05:59 schrieb Will Coleda:
> Are Hash and Array supposed to have different results on unset keys?
The .Undefs returned by Arrays are IMHO and unfortunate leftover of he early
PerlArrays. We've managed to change the return result of hashes to .Null, so
this should b
Am Sonntag, 17. Dezember 2006 09:45 schrieb chromatic via RT:
> garaud and I hope to have fixed this as of r16139, though he still has
> some dynext and dynpmc failures on his FreeBSD 6.2-tobe box.
>
> Can anyone still confirm?
This issue is looking much like a BSD linker options thingy to me. I c
Am Montag, 18. Dezember 2006 04:50 schrieb chromatic via RT:
> On Mon May 09 07:36:14 2005, leo wrote:
> > If you are embedding or extending Parrot and linked against libparrot
> > you now have to additionally link with one of:
> >
> >src/null_config.o
> >src/parrot_config.o # prefix :
Am Freitag, 8. Dezember 2006 22:43 schrieb Patrick R. Michaud:
> Does anyone have any suggestions about what sort of PIR
> code and/or PMCs we need to be able to do make the following
> Perl 6 code work...?
>
> my @a;
> @a[4] = 'Hello';
>
> my $b := @a[4];
> say $b; #
Am Dienstag, 5. Dezember 2006 22:07 schrieb Matt Diephouse:
> Constant PMCs are marked, but are constant STRINGs?
As STRINGs aren't pointing to other items, there's no extra code to deal with
constant strings. They are marked, when refered to from other locations or
maybe not. This is ok, as the
Am Dienstag, 5. Dezember 2006 20:39 schrieb Matt Diephouse:
> The portion of the assertion that
> fails is
>
> !(((s)->obj.flags) & b_PObj_on_free_list_FLAG
>
> which means that this string has been garbage collected. I saw a
> couple different instances of this problem and in all of them, the
Am Donnerstag, 30. November 2006 01:20 schrieb Matt Diephouse:
> Matt Diephouse <[EMAIL PROTECTED]> wrote:
> > We've basically run into the fact that there's no spec for MMD. I'll
> > see if I can provide a patch that just makes "_" match native types,
> > but I think it'll be somewhat more involve
Am Mittwoch, 29. November 2006 05:50 schrieb Matt Diephouse:
> It also means that "string", "int", and "float" no longer work as MMD
> types -- you can't distinguish between native types and PMCs. I think
> this is the right way to go now that we have autoboxing; I don't see
> any reason to d
Am Dienstag, 28. November 2006 08:51 schrieb Patrick R. Michaud:
> But come to think of it, if we had something like Capture PMCs
> available as a standard type (and an easy way to generate
> them in PIR), then the existing :vtable('init') would be
> quite sufficient.
Another note. Yes, a core Cap
1 - 100 of 5280 matches
Mail list logo
