Hello,
Mathx::Stat and Bayes::Learn should be indexable from holyghost's Perl6 CPAN
directory.
Mathx::Stat is a statistics package unto correlation dimension. Variance,
Estimate are distribution (population) based to enter more data which is
processed. There are also Correlatio
Hello,
I've uploaded Mathx::Stat to cpan's holyghost Perl6 directory. It contains a
statistics package.
I needed the above for a Markov strategy package for writing prospection in
Perl 6 games, e.g. with SDL2::Raw for graphics.
This starts from Markov startegies unto Statistical Ch
t; During the "make install" phase of Rakudo Start 2014.12.1 (but I think
> this is not new)
> I saw this message:
>
>
> Can't stat modules/debugger-ui-commandline/lib: No such file or directory
>
> at tools/build/module-install.pl line 24.
ile/dir that was 'a'.
Subsequent behavior is same as that of 1.
Lacking a .stat method, and a way of notifying removal, there isn't a good way
to track the original target, and figure out nature of the change.
- kan
is is not new)
I saw this message:
Can't stat modules/debugger-ui-commandline/lib: No such file or directory
at tools/build/module-install.pl line 24.
Testing for a symlink with ~~:l on a non-existent file works now (returns
False, but doesn't die). I added a test to S16-filehandles/filetest.t with the
following commit: https://github.com/perl6/roast/commit/58ec1cfdbb
use v6;
> my $f = "a".IO;
> if $f ~~ :r {
>say 'file readable';
> }
> if $f ~~ :l {
> say 'symlink';
> }
>
> the readability and most other test fail and return some undef, but
> checking for :l (symlink) throws an exception if th
return some undef, but
> checking for :l (symlink) throws an exception if the thing does not exist
>
> stat failed: No such file or directory
> in method l at src/gen/CORE.setting:7042
> in method ACCEPTS at src/gen/CORE.setting:5958
> in block at t.pl:7
>
> Is that on
use v6;
my $f = "a".IO;
if $f ~~ :r {
say 'file readable';
}
if $f ~~ :l {
say 'symlink';
}
the readability and most other test fail and return some undef, but
checking for :l (symlink) throws an exception if the thing does not exist
stat failed: No such
# New Ticket Created by William Orr
# Please include the string: [perl #84948]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=84948 >
Parrot introduced some changes which broke most of the functions in
IO::Stat. I fi
# New Ticket Created by Tadeusz SoĊnierz
# Please include the string: [perl #76772]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=76772 >
Here's a patch adding an interface to Parrot's stat Opcode in
On Thu, Oct 23, 2008 at 1:43 AM, via RT Stephane Payrard
<[EMAIL PROTECTED]> wrote:
> This results in 4 stat()s per pbc.
> opening the file and using Parrot_fstat_info_intval() instead of
> Parrot_stat_info_intval() will be less costly.
> this means retooling readbc() that now
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #60060]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60060 >
This results in 4 stat()s per pbc.
opening the file and us
alled Perl 5 is generating a longer number so I'm masking
> it. I will need to investigate why Perl 5 generates a larger inode value
> than Parrot. (Maybe stat is actually broken in Parrot on Cygwin).
That's a strong possibility.
-- c
ted against revision 29913.
The stat and lstat tests in t/pmc/os.t were failing on one install of Cygwin
and not another. It turns out that the expected output generated by the
installed Perl 5 was different on each system. This must be due to the
implicit conversion from integer to decimal string by j
s exception'
# at t\pmc\io.t line 729.
# ''
# doesn't match '/some crazy exception/
# '
ok 39 - utf8 read layer
ok 40 - utf8 read layer - readline
ok 41 - utf8 read layer, read parts
ok 42 - string read/write layer
ok 43 - PIO.slurp() - classmeth
ok 44 - PIO.
# New Ticket Created by Ron Blaschke
# Please include the string: [perl #43438]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43438 >
Attached patch steal the basic layout from
F and makes the
F "stat failed&qu
# New Ticket Created by
# Please include the string: [perl #42312]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42312 >
in src/pmc/os.pmc after retrieving the information of a file with stat or lstat
all the fields
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40731]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40731 >
Need to be more discriminating about the OS related error message in
'stat
On Mon, Jul 03, 2006 at 12:22:15PM -0700, chromatic wrote:
> On Monday 03 July 2006 11:43, Steve Peters via RT wrote:
>
> (from p5p)
>
> > OK, with change #28473, I just added the capabilities to a stat() or -X
> > filetests for systems with the dirfd() libc call avail
On Monday 03 July 2006 11:43, Steve Peters via RT wrote:
(from p5p)
> OK, with change #28473, I just added the capabilities to a stat() or -X
> filetests for systems with the dirfd() libc call available. There are
> two additional steps that need to be done. First, Perl_pp
Thursday, October 7, 2004, 11:38:01 PM, Jonathan Worthington wrote:
> Looks like it probably just needs a win32/stat.c writing...I won't have time
> to look properly for a day or two though. So do feel free to beat me to a
> patch. :-)
Done. ;-) Thanks for your advice.
Please forget the last platform patch. This one should follow style.
Sorry, guess I need some time to warm up on my patches...
platforms-win32-tests-fail.patch
Description: Attached file: platforms-win32-tests-fail.patch
sts fail. I've attached a patch for
PLATFORMS.
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\library\streams.t2 512212 9.52% 14 18
t\pmc\nci.t6 1536466 13.0
Ron Blaschke <[EMAIL PROTECTED]> wrote:
> Removes the #if defined(WIN32) in generic/stat.c, and adds a separate
> implementation in win32/stat.c. The block stats stay implemented as
> internal_exception.
Thanks, applied.
Does it compile, run, and test now? Can you provide an update patch to
PLAT
On Fri, 8 Oct 2004 10:08:13 -0400, Dan Sugalski wrote:
> At 3:59 PM +0200 10/8/04, Ronald Blaschke wrote:
>> > This there a Win32 API stat()-like function that makes it worth to write
>>> win32/stat.c?
>>
>>Not one that I have found. And:
>>perl return
# New Ticket Created by Ron Blaschke
# Please include the string: [perl #31897]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31897 >
Removes the #if defined(WIN32) in generic/stat.c, and adds a separate
implementation
At 3:59 PM +0200 10/8/04, Ronald Blaschke wrote:
> This there a Win32 API stat()-like function that makes it worth to write
win32/stat.c?
Not one that I have found. And:
perl returns no value for block size and blocks on Activestate Perl
5.8.4 (on win32).
All the stat things with _PLATFORM_
> This there a Win32 API stat()-like function that makes it worth to write
> win32/stat.c?
Not one that I have found. And:
perl returns no value for block size and blocks on Activestate Perl
5.8.4 (on win32).
C:\temp>echo "Hello World!" >hello
C:\temp>perl -e "
On Thursday 07 October 2004 22:26, Ron Blaschke wrote:
> config\gen\platform\generic\stat.c(81) : error C2039: 'st_blksize' : is not
> a member of 'stat'
I am working on MINGW support and had this error, too. I just added
#if defined(__MINGW32__)
around those lines.
-DHAS_JIT -DI386 -I. -Fo xx.obj -c xx.c
> src\platform.c
> platform.c
> config\gen\platform\generic\stat.c(81) : error C2039: 'st_blksize' : is
not a member of 'stat'
> C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\sys\stat.h(99) : see declara
ogo -GF -W3 -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DNO_HASH_SEED -Zi
-I./include -IC:\usr\loc
al\icu\include -DHAS_JIT -DI386 -I. -Fo xx.obj -c xx.c
src\platform.c
platform.c
config\gen\platform\generic\stat.c(81) : error C2039: 'st_blksize' : is not a member
of 'stat'
Jens Rieks <[EMAIL PROTECTED]> wrote:
> The _parrotlib bytecode is working, but it disables DOD ATM :-(
The problem is that now the runloop is entered already in the
lexer for the first time (for loading includes). When entering the
run loop the first time, the stack top is set, which is now some
At 12:01 PM +0200 5/25/04, Jens Rieks wrote:
On Tuesday 25 May 2004 01:35, Dan Sugalski wrote:
We can add more to this as we go, but this should be enough to get Jens
going.
Theres no stat op yet, is there?
Ah, dammit--I was too careful with the commit and missed some files.
Update to CVS and
On Tuesday 25 May 2004 01:35, Dan Sugalski wrote:
> We can add more to this as we go, but this should be enough to get Jens
> going.
Theres no stat op yet, is there?
Shall I write it?
The current parrotlib bytecode uses C to test if a file exists, I'll
modify the code to use C then.
At least to start. Simple interface, only 11 queryable items, and
only integer queries so far. (Two of which unconditionally return -1
anyway) But... at least you can go look to see if a file exists. :)
We can add more to this as we go, but this should be enough to get Jens going.
--
At 1:33 PM +0200 5/21/04, Jens Rieks wrote:
PS: we need the stat op!
I'll go do this. The API I outlined earlier is what I'll use, with
all the modifications and deletions folks suggested.
--
Dan
--"
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
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
>>Is it possible to have something along the lines of
>>ME_{READ,WRITE,EXECUTE,DELETE,CD} to say if, as the user the program
>>is running as, you can perform these actions? That strikes me as
>>rather useful. (Alternately, could we have a field indicating if
>>the current user is OWNER, GROUP
At 4:43 PM -0700 4/28/04, Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
OWNER_READTrue if owner can read
OWNER_WRITETrue if owner can write
OWNER_EXECUTETrue if owner can run
OWNER_DELETETrue if owner can delete
GROUP_CDTrue if owner can enter this directory
Is it possible
Dan Sugalski wrote:
OWNER_READTrue if owner can read
OWNER_WRITETrue if owner can write
OWNER_EXECUTETrue if owner can run
OWNER_DELETETrue if owner can delete
GROUP_CDTrue if owner can enter this directory
Is it possible to have something along the lines of
ME_{READ,WRITE,EXEC
At 10:47 PM +0200 4/28/04, Jerome Quelin wrote:
Dan Sugalski wrote:
At 8:08 PM +0200 4/28/04, Jerome Quelin wrote:
>Dan Sugalski wrote:
>> CTIMECreation time
>Will unixen use this for change time? (also spelled ctime too)
Nope, for that they use mtime. We can expand the names
> On top of which, ACLs suffer the same illness of any stat-based
> checking, insofar as checks against them are only an approximation
> to reality, potentially full of race conditions. It's really the OS
> that's going to do the ACL checking, and it'll do it when yo
Dan Sugalski wrote:
> At 8:08 PM +0200 4/28/04, Jerome Quelin wrote:
> >Dan Sugalski wrote:
> >> CTIME Creation time
> >Will unixen use this for change time? (also spelled ctime too)
>
> Nope, for that they use mtime. We can expand the names to skip the
> confusion.
mtime != ctime
mti
g it a simple yes/no indicator that there
: > are some? (Chopping it out's probably the best thing)
:
: Chopping off sounds like less coding :-)
On top of which, ACLs suffer the same illness of any stat-based
checking, insofar as checks against them are only an approximation
to reality, potenti
uct that uses them (other than backup and restore
software ;-)
> >This is true. But good luck in trying to map between the ACL schema of
> >different systems :-(
>
> Yech, good point. I'm not even sure you can do any sort of sane
> abstraction there.
Sure you can. It
On Wed, 2004-04-28 at 14:51, Dan Sugalski wrote:
> At 8:08 PM +0200 4/28/04, Jerome Quelin wrote:
> >Dan Sugalski wrote:
> >[...]
> >> CTIME Creation time
> >
> >Will unixen use this for change time? (also spelled ctime too)
>
> Nope, for that they use mtime. We can expand the names t
At 10:49 PM +0300 4/28/04, Jarkko Hietaniemi wrote:
> Yech, good point. I'm not even sure you can do any sort of sane
abstraction there.
In that case, are we better off chopping it out entirely and leaving
it to library code, or making it a simple yes/no indicator that there
are some? (Choppin
> Yech, good point. I'm not even sure you can do any sort of sane
> abstraction there.
>
> In that case, are we better off chopping it out entirely and leaving
> it to library code, or making it a simple yes/no indicator that there
> are some? (Chopping it out's probably the best thing)
Choppi
At 10:32 PM +0300 4/28/04, Jarkko Hietaniemi wrote:
>>Keeping a niche open for ACLs is probably smart, esp. in the Windows
world.
I think you'll find ACL use is increasing, not decreasing. They've
been tacked on to most recent filesystems, and they're coming into
This is true. But good luck in
>>Keeping a niche open for ACLs is probably smart, esp. in the Windows
>>world.
>
>
> I think you'll find ACL use is increasing, not decreasing. They've
> been tacked on to most recent filesystems, and they're coming into
This is true. But good luck in trying to map between the ACL schema of
d
en a matter of
consensus, and many client languages will be presenting POSIX semantics
through their standard libraries anyway, which they will have to massage
your representation back into.
Which is why I'm fine with yanking all the filename mangling stuff
from stat here.
I would recommend
At 11:39 AM -0700 4/28/04, Larry Wall wrote:
From a Perl 6 language point of view, populating an array is a waste
of time.
Who says we're populating an array? In the common case we'll be
checking individual bits (it'll be a long time before perl 6's the
common case) and in the case where we *do*
At 2:01 PM -0400 4/28/04, Aaron Sherman wrote:
Keeping a niche open for ACLs is probably smart, esp. in the Windows
world.
I think you'll find ACL use is increasing, not decreasing. They've
been tacked on to most recent filesystems, and they're coming into
more widespread use as Linux is getting
>>Which is why I'm fine with yanking all the filename mangling stuff
>>from stat here.
>
>
> I would recommend leaving out from stat()ish layer. An API not
s/out/that out/
ient languages will be presenting POSIX semantics
>>through their standard libraries anyway, which they will have to massage
>>your representation back into.
>
>
> Which is why I'm fine with yanking all the filename mangling stuff
> from stat here.
I would recommend
At 8:08 PM +0200 4/28/04, Jerome Quelin wrote:
Dan Sugalski wrote:
[...]
CTIME Creation time
Will unixen use this for change time? (also spelled ctime too)
Nope, for that they use mtime. We can expand the names to skip the confusion.
Should be OWNER_CD?
Should be SYSTEM_CD?
Should be OTHER_CD?
Ye
of files mutates over time, or as people derive
from the base class. There are no ordering dependencies between the
methods as there are between array elements. Some of the methods can
pull things directly out of the underlying stat structure. Some of
the methods synthesize values. Encapsulat
Dan Sugalski wrote:
[...]
> CTIME Creation time
Will unixen use this for change time? (also spelled ctime too)
> OWNER_READTrue if owner can read
> OWNER_WRITE True if owner can write
> OWNER_EXECUTE True if owner can run
> OWNER_DELETE True if owner can delete
> GROUP_CD True
On Wed, 2004-04-28 at 13:40, Dan Sugalski wrote:
> >ALTERNATE RESPONSE
>
> This is where you go mad, right? :)
Usually ;-)
> > Why abstract within
> >the arbitrary constraints of a POSIX-type stat model?
>
> I wasn't, actually. There's a good sprink
gh their standard libraries anyway, which they will have to massage
your representation back into.
Which is why I'm fine with yanking all the filename mangling stuff
from stat here.
> I'm OK with adding a TYPE to the stat array as well, though more for
an "it's a file/socket/d
gh their standard libraries anyway, which they will have to massage
your representation back into.
> I'm OK with adding a TYPE to the stat array as well, though more for
> an "it's a file/socket/device/directory" type thing, rather than an
> "it's an applic
At 12:15 PM -0400 4/28/04, Aaron Sherman wrote:
On Wed, 2004-04-28 at 11:56, Dan Sugalski wrote:
stat [PINS]x, Sy, Iz
stat Px, Sy
[...]
The returned PMC in the two-arg case could be a hash/array pmc and
allow string-keyed access to elements. If we do that, then the names
correspond to
On Wed, 2004-04-28 at 11:56, Dan Sugalski wrote:
> stat [PINS]x, Sy, Iz
> stat Px, Sy
[...]
> The returned PMC in the two-arg case could be a hash/array pmc and
> allow string-keyed access to elements. If we do that, then the names
> correspond to the constant names that
As part of the great "clean up the dangling bits" sweep...
File stat stuff. Let's do:
stat [PINS]x, Sy, Iz
stat Px, Sy
where Y is the filename. Z is the stat element, and X is the value
for that element. (In the two-arg case it's an array PMC, where the
offset matches t
66 matches
Mail list logo
