On Wed, 27 Jul 2016 17:43:48 -0700, lloyd.fo...@gmail.com wrote:
> By flag_map I mean ctx->callsite->arg_flags:
>
> (lldb) p ctx->arg_flags
> (MVMCallsiteEntry *) $8 = 0x
> (lldb) p ctx->callsite->arg_flags
> (MVMCallsiteEntry *) $9 = 0x10a72533 ""
>
> On Mon, Jul 11, 2016
Here is a script that demonstrates this issue relatively consistently.
https://gist.github.com/scmorrison/d7506b69e5778381c8374163435ae651
Sometimes it works fine, but mostly not. I have tried several variations of
this and any that use the >>.map, hyper, or promises fail.
Sam
> I think things would go faster with this one if it was golfed down.
I will try to golf it when I have time. In the meantime, I have occasionally
seen the same error in place of the memory errors described in #131889. If that
one is resolved then this one may go away too.
I think things would go faster with this one if it was golfed down.
Given the previous warnings saying “Use of uninitialized value $key of type Any
in string context.”, the issue is quite possibly in Uzu itself (or maybe even
Mustache). The ticket is of course valid because the error should not co
None of the provided environmental variables reliably fixed the issue.
MVM_SPESH_INLINE_DISABLE=1 seemed to provide slightly better results overall,
but that may have been due to random chance, and the original error still
sometimes appeared.
>
>
> I'm using the Rakudo nom and MoarVM master. A call to "await" on an array
> of Promises is failing with the error:
>
> No such method 'cache' for invocant of type 'NQPMu'
> in any at
> /Users/emiller/Code/rakudo/i
>
>
> I'm using the Rakudo nom and MoarVM master. A call to "await" on an array
> of Promises is failing with the error:
>
> No such method 'cache' for invocant of type 'NQPMu'
> in any at
> /Users/emiller/Code/rakudo/i
ray
of Promises is failing with the error:
No such method 'cache' for invocant of type 'NQPMu'
in any at
/Users/emiller/Code/rakudo/install/share/perl6/runtime/CORE.d.setting.moarvm
line 1
The full error can be seen here:
https://github.com/scmorrison/uzu
nth doesn’t cache, but is fully lazy
- :nth(N) gives the Nth match, or Nil if there isn’t an Nth match
- :nth(*|Inf) gives the last match, or Nil if there aren’t any matches
- :nth(anything that can do .iterator) gives a list of matches on the proviso
that the numeric values of the iterator
I've been getting segfaults in this area recently. The trace is a bit
different but I guess it's related. It seems that flag_map in gc_mark is no
longer allocated so I get segfault.
(lldb) r
There is a running process, kill it and restart?: [Y/n] y
Process 75673 exited with status = 9 (0x0009)
By flag_map I mean ctx->callsite->arg_flags:
(lldb) p ctx->arg_flags
(MVMCallsiteEntry *) $8 = 0x
(lldb) p ctx->callsite->arg_flags
(MVMCallsiteEntry *) $9 = 0x10a72533 ""
On Mon, Jul 11, 2016 at 3:59 AM Lloyd Fournier
wrote:
> I've been getting segfaults in this area re
On Sat Jul 09 07:13:48 2016, jn...@jnthn.net wrote:
> On Tue Jul 05 17:51:46 2016, ug...@cpan.org wrote:
> > Note that the final decode-base64 candidate shows the correct results
> > when debugging statements are added
> >
> > This gist also shows a small change that makes it produce the correct
>
By flag_map I mean ctx->callsite->arg_flags:
(lldb) p ctx->arg_flags
(MVMCallsiteEntry *) $8 = 0x
(lldb) p ctx->callsite->arg_flags
(MVMCallsiteEntry *) $9 = 0x10a72533 ""
On Mon, Jul 11, 2016 at 3:59 AM Lloyd Fournier
wrote:
> I've been getting segfaults in this area re
I've been getting segfaults in this area recently. The trace is a bit
different but I guess it's related. It seems that flag_map in gc_mark is no
longer allocated so I get segfault.
(lldb) r
There is a running process, kill it and restart?: [Y/n] y
Process 75673 exited with status = 9 (0x0009)
On Tue Jul 05 17:51:46 2016, ug...@cpan.org wrote:
> Note that the final decode-base64 candidate shows the correct results
> when debugging statements are added
>
> This gist also shows a small change that makes it produce the correct
> values but it still segfaults more often than not
> https://g
On Tue Jul 05 17:51:46 2016, ug...@cpan.org wrote:
> Note that the final decode-base64 candidate shows the correct results
> when debugging statements are added
>
> This gist also shows a small change that makes it produce the correct
> values but it still segfaults more often than not
> https://g
Note that the final decode-base64 candidate shows the correct results when
debugging statements are added
This gist also shows a small change that makes it produce the correct values
but it still segfaults more often than not
https://gist.github.com/ugexe/baa168a641894a0731595c812724f76d
org/ugexe/zef/jobs/142611302#L1178
Relevant code:
https://github.com/ugexe/Perl6-Base64/blob/master/lib/Base64.pm6#L41
The first multi dispatch cache commit only caused failures sometimes. The
commit afterwards (d4ac15c) to fix a different multi dispatch cache problem
causes it to always fail,
-lists.pod
Log Message:
---
Clarify calling .cache more than once
:
M S07-lists.pod
Log Message:
---
We *can* call .cache multiple times
It will just return the same lazy list. The removed line seems to
contradict that.
e
rest of the string in Perl 6?
.split(//)
ooh
nom: say 'foobar'.split(//).perl
nom acbec8: OUTPUT«No type check cache and no type_check
method in meta-object in method reify [...]
How in the hell...
jnthn: indeed.
I get the same output locally
* masak submits rakudobug
OK, what is a
On Tue Oct 02 10:24:02 2007, pcoch wrote:
> In the file src/mmd.c there is the todo item within
> mmd_create_builtin_multi_meth_2():
>
> * TODO cache the namespace
>
> Do this. (please)
This function (and the TODO) are no longer present after the recent MMD
mer
On Sat May 17 14:55:53 2008, pmichaud wrote:
> On Mon Jun 12 16:30:13 2006, jonathan wrote:
> > Both Parrot_store_global and store_sub call
> Parrot_invalidate_method_cache,
> > however the versions of these that take keys (Parrot_store_global_p and
> > store_sub_p) fail to do so.
>
> Is this t
On Mon Jun 12 16:30:13 2006, jonathan wrote:
> Both Parrot_store_global and store_sub call
Parrot_invalidate_method_cache,
> however the versions of these that take keys (Parrot_store_global_p and
> store_sub_p) fail to do so.
Is this ticket still relevant after the pdd15oo changes incorporated
hod cache invalidation should be a namespace function */
Parrot_invalidate_method_cache(interp, str_key, globalname);
ary hack to notice when key is actually a string, so that
* the legacy logic for invalidating method cache will be called; this
* is not good enough but it avoids regressesions for now
hod cache invalidation should occur */
ect()):
/*
* quick'n'dirty method cache
* TODO: use a hash if method_name is not constant
* i.e. from obj.$Sreg(args)
* If this hash is implemented mark it during DOD
*/
One would guess this needs implementing more robustly
h_2():
* TODO cache the namespace
Do this. (please)
# New Ticket Created by Jonathan Worthington
# Please include the string: [perl #39430]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39430 >
Both Parrot_store_global and store_sub call Parrot_invalidate_method_cache,
ho
Brad Bowman (via RT) wrote:
Looking through pobj.h, I found what seems to be a dated
comment referring to "cache.*". I don't think this exists
anymore, unless it's referring to hashval in some oblique way.
Sorry for the delay, I must have missed it. Anyway, your obser
to "cache.*". I don't think this exists
anymore, unless it's referring to hashval in some oblique way.
UINTVAL hashval; /* cached hash value computation; not yet used */
};
-/* cache.* is intended to just be *shortcuts* to*/
-/* commonly-accessed
On Jul 9, 2005, at 19:37, Nicholas Clark wrote:
On Fri, Jul 08, 2005 at 06:52:28PM +0200, Leopold Toetsch wrote:
No, for sure not. And AFAIK it's not needed nor used. Please drop
this line.
Done, although curiously it did involve changing 1 line in io/io.c
Thx. Fixed that line too.
Nic
On Fri, Jul 08, 2005 at 06:52:28PM +0200, Leopold Toetsch wrote:
> No, for sure not. And AFAIK it's not needed nor used. Please drop this line.
Done, although curiously it did involve changing 1 line in io/io.c
Nicholas Clark
Nicholas Clark wrote:
Line 216 of pobj.h has:
#define cache obj.u
Is redefining such a common name a good idea?
No, for sure not. And AFAIK it's not needed nor used. Please drop this line.
Nicholas Clark
Thx,
leo
Line 216 of pobj.h has:
#define cache obj.u
Is redefining such a common name a good idea?
Nicholas Clark
If a name is stored into a namespace that starts with two underscores,
the method cache is invalidated now.
The follwing program runs now as expected:
.sub main @MAIN
.local pmc o, cl
newclass cl, "Foo"
subclass cl, cl, "Bar"
$I0 = typeof cl
o = new $I0
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>$P1 = interpinfo .INTERPINFO_CURRENT_CONT
>>$P1 = clone $P1
>>
>>I'm still inclined to make this sequence an opcode, though. The
>>cloning is still necessary, as the return continuation is returned.
> Hrm. I think the returned continuation should b
Piers Cawley <[EMAIL PROTECTED]> wrote:
> And, dammit, making a full continuation isn't something a programmer
> should do lightly.
BTW I had to change your example code (you remember it for sure, it's in
t/op/gc_13 inv CVS)
(define (choose . all-choices)
(let ((old-fail fail))
(call
to sweep through, as well as speeding
> up allocation (since we're more likely to have ones at hand, and
> likely in cache too) of the things in the first place.
And, dammit, making a full continuation isn't something a programmer
should do lightly.
sed in the near-overwhelming majority of the cases
-- that is, when nothing can possibly have a hold of 'em. That leaves
a lot fewer objects for the DOD to sweep through, as well as speeding
up allocation (since we're more likely to have ones at hand, and
likely in cache too) of the things in th
All~
I don't like the idea of having to dig down through the entire return
chain promoting these guys. Is there a reason not to use DOD/GC to
recycle continuations?
Matt
On Tue, 2 Nov 2004 14:10:09 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote
At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote:
* The stack frame caching is back, hopefully now implemented correctly:
1) when a return continuation is invoked the stack frame is recycled
2) when a continuation is created, all the return continuations up the
call chain are converted to re
* The stack frame caching is back, hopefully now implemented correctly:
1) when a return continuation is invoked the stack frame is recycled
2) when a continuation is created, all the return continuations up the
call chain are converted to real continuations by changing the
vtable. This
Here are recent numbers with the new method cache:
$ perl tools/dev/parrotbench.pl -c=parrotbench.conf -b=^oo
Numbers are relative to the first one. (lower is better)
parrotj parrot parrotC perl-th perlpython ruby
oo1 100%104%106%98% 83% 54% 70%
oo2
I am still _way_ behind on my perl6 e-mail but there has been
a spate of discussion on gcc list about how garbage collector
is bad for data-cache locality (particularly temporal locality).
At least some of gcc folk are considering a switch to refcounts
to try and get gcc-3.* back to nearer
Ars Technica's got a reasonably nice explanation of CPU caches at
http://arstechnica.com/paedia/c/caching/caching-1.html, for the
interested.
--
Dan
--"it's like this"---
Dan Sugalski
This is the first step of three major changes coming over the weekend.
The only change visible to the assembler will be the syntax 'set
P0[3],7' and 'set P5["foo"],P30[7]' for accessing array and hash
aggregates. The changes should also allow us to implement
multidimensional arrays.
--
Jeff <[EMAI
At 03:48 PM 9/28/00 +, John van V wrote:
>How would the byte-compiled caches relate to the compiled C code XS'd into
>the modules??
When a module is built, in addition to transforming any XS code (or
whatever it ultimately is) into an executable, perl will also compile any
perl code into b
How would the byte-compiled caches relate to the compiled C code XS'd into the
modules??
Could it be embedded, I think not, but please enlighten me.
he neck to install in AFS. It's one of the
hardest software packages that we have to support because of the cache
directory. We tried to maintain it like it's supposed to work, and it
failed miserably. We finally had to give up completely and wrap Purify to
redirect the cache directo
st
RA> compile at installation time and then leave it alone.
This isn't really a problem. Purify does this already. If it is not
allowed to write into the original directory, You give it a cache
directory and it does appropriate magic to map to the original file
and associate the correct user t
Michael Maraist <[EMAIL PROTECTED]> writes:
> I suggested this a while ago, and the response was that automatically
> writing files is a security risk. You should extend your RFC to
> describe a caching directory or configuration.
This will be completely impossible to implement in some installa
t_ cause problems if not implemented correctly
(namely that a perl and module version is associated with each .p[lm]c
file).
In general, I'm for the idea, but I figured I'd pass on the obsticles I
encountered.
To further your RFC, I'd suggest working out a configuration for a .*c
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Cache byte-compiled programs and modules
=head1 VERSION
Maintainer: Simon Cozens <[EMAIL PROTECTED]>
Date: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 301
Version: 1
Status: Deve
55 matches
Mail list logo
