On 2020-06-08 15:12, Richard Hainsworth wrote:
Todd,
I wrote Informative a while ago. So as to make it self-contained, I
copied code from GTK::Simple (as stated in the comments).
The reason for this is that GTK::Simple itself is quite large with a lot
of boilerplate for many functions.
So,
. "--force-build" does not work either
Anyone know how to fix this?
Many thanks,
-T
K:\Windows\NtUtil>Issues with "zef install Informative"
===> Searching for: Informative
===> Building: Inform:ver<1.2>:auth
[Inform] At line:1 char:192
[Inform] + ... ystem.io.
Hi All,
Window 10-2005
Rakudo version 2020.05.1 built on MoarVM version 2020.05
Informative installs perfectly in Fedora (Linux), but
not Windows 10. "--force-build" does not work either
Anyone know how to fix this?
Many thanks,
-T
K:\Windows\NtUtil>Issues with "zef i
Hi All,
I am reading the output of
curl https://www.bleepingcomputer.com/download/adwcleaner/ -o -
and looping through it with split.
This gets me about 1/20th of the lines:
for split "\n", $WebPage -> $Line {
AAAH!
Doing a hex edit on the downloaded file, the delimiter is 0H0A
On 03/12/2018 01:13 AM, Steve Mynott wrote:
On Sun, Mar 11, 2018 at 11:01:08PM -0700, ToddAndMargo typed:
How do I fix this?
# rpm -qa rakudo\*
rakudo-zef-0.1.30-1.fc27.x86_64
rakudo-0.2018.02.1-1.fc27.x86_64
# zef install Net::SMTP
===SORRY!===
Failed to open file
/usr/lib64/perl6/site/dist/
On Sun, Mar 11, 2018 at 11:01:08PM -0700, ToddAndMargo typed:
> How do I fix this?
>
> # rpm -qa rakudo\*
> rakudo-zef-0.1.30-1.fc27.x86_64
> rakudo-0.2018.02.1-1.fc27.x86_64
>
> # zef install Net::SMTP
> ===SORRY!===
> Failed to open file
> /usr/lib64/perl6/site/dist/863D6AAB4F5E7259BA381C4EBE0
Hi All,
Help!
How do I fix this?
# rpm -qa rakudo\*
rakudo-zef-0.1.30-1.fc27.x86_64
rakudo-0.2018.02.1-1.fc27.x86_64
# zef install Net::SMTP
===SORRY!===
Failed to open file
/usr/lib64/perl6/site/dist/863D6AAB4F5E7259BA381C4EBE0F88BAA358090E: No
such file or directory
# ls -al /usr/lib64/p
Turned out IRC::Client's grammar is relying on a bug with `:ratchet` being
ignored in || which was fixed as part of
https://rt.perl.org/Ticket/Display.html?id=130117
IRC: https://irclog.perlgeek.de/perl6-dev/2017-10-20#i_15331049
Turned out IRC::Client's grammar is relying on a bug with `:ratchet` being
ignored in || which was fixed as part of
https://rt.perl.org/Ticket/Display.html?id=130117
IRC: https://irclog.perlgeek.de/perl6-dev/2017-10-20#i_15331049
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #132191]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132191 >
There is very little known about the problem. I'm creating this ticke
On 03/09/2017 04:00 AM, Timo Paulssen wrote:
Hey,
X11::Xlib::Raw is buggy. It has to have all modules it uses internally
inside its "provides" section in the META6.json, otherwise "use" will
not find them.
I'll open a ticket with the module author.
HTH
- Timo
Hi Timo,
As long as Inlin
Hey,
X11::Xlib::Raw is buggy. It has to have all modules it uses internally
inside its "provides" section in the META6.json, otherwise "use" will
not find them.
I'll open a ticket with the module author.
HTH
- Timo
On 08/03/17 22:08, ToddAndMargo wrote:
> Hi All,
>
> What is wrong with this?
On 03/08/2017 01:08 PM, ToddAndMargo wrote:
Hi All,
What is wrong with this?
$ perl6 -MX11::Xlib::Raw -e 'say "hi";'
===SORRY!===
Could not find X11::Xlib::Raw::X at line 5 in:
/home/tony/.perl6
/usr/share/perl6/site
/usr/share/perl6/vendor
/usr/share/perl6
CompUnit::Reposit
Hi All,
What is wrong with this?
$ perl6 -MX11::Xlib::Raw -e 'say "hi";'
===SORRY!===
Could not find X11::Xlib::Raw::X at line 5 in:
/home/tony/.perl6
/usr/share/perl6/site
/usr/share/perl6/vendor
/usr/share/perl6
CompUnit::Repository::AbsolutePath<68732640>
CompUnit::Rep
The remaining issues are resolved now. Therefore, I'm closing this ticket.
I think this is another *compile-time closure loses it's outer ctx at
runtime* bug. I was trying to keep track of them:
https://rt.perl.org/Public/Bug/Display.html?id=125634
Your lovely module has a compile time closure here (EXPORT Is called at
compile time):
https://github.com/zoffixznet/perl6-
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #128483]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128483 >
The Pretty::Topic module exports this sub:
sub term:<♥> { $CALLER::_ }
If a user-m
As a status update: things are substantially better now (2016.04-218-gaa2715d)
-- thanks to nine++
and psch++
+ stresstest runs in a reasonable time again (precompiled Test.pm can be used)
+ test for RT #114354 passes again
+ FIRST works now
The remaining issues are:
- 'make install' still fa
Running the following code with RAKUDO_MODULE_DEBUG=1 revealed that rakudo-j
did precompile a module, but was unable to use it afterwards -- and therefore
removed it:
$ echo '#' > Foo.pm6
$ RAKUDO_MODULE_DEBUG=1 ./perl6-j -I. -e 'use Foo'
Since that happened with Test.pm as well, the long spect
# New Ticket Created by Christian Bartolomaeus
# Please include the string: [perl #128094]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128094 >
There are different issues with Rakudo on JVM after the merge of
'relo
On Mon Sep 21 09:12:15 2015, coke wrote:
> At this point, POST {} doesn't compile at all:
>
> 12:00 < [Coke]> m: POST {}
> 12:00 <+camelia> rakudo-moar b578b4: OUTPUT«===SORRY!===Lexical '$_'
> already
> declared»
Did a bisect, ended up with:
$ git bisect bad
a328aab7acd070b5c
At this point, POST {} doesn't compile at all:
12:00 < [Coke]> m: POST {}
12:00 <+camelia> rakudo-moar b578b4: OUTPUT«===SORRY!===Lexical '$_' already
declared»
--
Will "Coke" Coleda
# New Ticket Created by Solomon Foster
# Please include the string: [perl #79356]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=79356 >
colomon: rakudo: * + * * *
p6eval: rakudo 015d77: OUTPUT«===SORRY!===set_number_nativ
/Containers.pod
Log Message:
---
copy-paste issues with new roll method
jkpeters_37++ points out a problem in the new specs for .roll, which
are now revised for (I hope) more clarity.
On Mon, Aug 31, 2009 at 4:26 AM, equinox wrote:
> # New Ticket Created by equinox
> # Please include the string: [perl #68876]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=68876 >
>
>
> Hi,
>
> I found the range contruct
Patrick R. Michaud via RT wrote:
On Mon, Aug 31, 2009 at 02:26:00AM -0700, equinox wrote:
I found the range contructs do not work properly in rakudo at all times.
Example: /a ** ..3/ and /a ** 3../
Omitting values from either side of ".." doesn't make a valid range.
You probably mea
On Mon, Aug 31, 2009 at 02:26:00AM -0700, equinox wrote:
>
> I found the range contructs do not work properly in rakudo at all times.
>
> Example: /a ** ..3/ and /a ** 3../
Omitting values from either side of ".." doesn't make a valid range.
You probably mean to have /a ** 0..3/ and /a ** 3..
# New Ticket Created by equinox
# Please include the string: [perl #68876]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=68876 >
Hi,
I found the range contructs do not work properly in rakudo at all times.
Example: /a **
Now fixed in r35389:
$ ./parrot perl6.pbc
> my $x; say $x, 2
Use of uninitialized value
2
> my $x = undef; say $x, 2;
Use of uninitialized value
2
> my @a; @a[2] = 'b'; say @a;
Use of uninitialized value
Use of uninitialized value
b
> my @a; @a[2] = 'b'; say @a.perl;
[undef, undef, "b"]
>
We prob
# New Ticket Created by Ron Schmidt
# Please include the string: [perl #61324]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=61324 >
As discussed on IRC today 12/11:
my $x; say $x, 2;
Outputs: 2\n
my $x = undef; say $x, 2
Patrick R. Michaud via RT wrote:
Is this still an issue?
If so, can we enumerate the exact things we want this ticket to address?
There's nothing in this area I know of that needs addressing. I suggest
closing the ticket and if we find any specific issues relating to this,
we can open one w
Is this still an issue?
If so, can we enumerate the exact things we want this ticket to address?
Pm
Is this still an issue?
If so, can we enumerate the exact things we want this ticket to address?
Pm
Now fixed in r33193.
Thanks,
Pm
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #57968]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57968 >
- awaiting .HLL capabilities
Fixed in r29283, and your PIR turned into a test.
We might consider caching PMCProxy for all built-in PMCs (where they
have no namespace attached), but with my current understanding, only
classes need it, and then only if they extend built-in PMCs. That seems
somewhat rare.
On Thu, Jul 10, 2008 at 06:50:51PM -0700, chromatic wrote:
>
> Here's a first approach. It breaks a couple of tests, but it's a start:
>
> t/pmc/object-meths (Wstat: 1280 Tests: 37 Failed: 5)
> Failed tests: 1-4, 16
> t/oo/proxy (Wstat: 256 Tests: 5 Fai
On Thursday 10 July 2008 17:33:23 Patrick R. Michaud (via RT) wrote:
> There are a couple of issues with PMCProxy:
>
> 1. The PMCProxy returned from a get_class opcode isn't
> the same as one obtained from using typeof on an instance
> of the type.
>
> 2.
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #56816]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56816 >
There are a couple of issues with PMCProxy:
1. The PMCProxy returned fro
On Mon, 7 Jul 2008, Andrew Whitworth via RT wrote:
> On Thu Mar 13 18:06:21 2008, doughera wrote:
> > I don't know if those calculations are still correct, now that strings
> > are not "bufferlike".
>
> Most of the memory management code uses a cast to (Buffer *) or (PObj *)
> to test a generic o
On Mon, 7 Jul 2008, Andrew Whitworth via RT wrote:
> On Thu Mar 13 18:06:21 2008, doughera wrote:
> > I don't know if those calculations are still correct, now that strings
> > are not "bufferlike".
>
> Most of the memory management code uses a cast to (Buffer *) or (PObj *)
> to test a generic o
As of r29042 these all seem to have been resolved. Thanks to chromatic,
jonathan, and others who all contributed to fixing this particular issue.
Pm
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #56512]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56512 >
This is a meta-ticket on which we can hang other tickets
related to the ongoing le
On Thu, 13 Mar 2008, chromatic via RT wrote:
> On Thursday 13 March 2008 09:14:07 Andy Dougherty wrote:
>
> > On Thu, 13 Mar 2008, Nicholas Clark via RT wrote:
>
> > > Specifically, I am suspecting that if
> > >
> > > offsetof(struct parrot_string_t, bufused) == sizeof(Buffer)
> > >
> > > ma
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
On Thursday 13 March 2008 09:14:07 Andy Dougherty wrote:
> On Thu, 13 Mar 2008, Nicholas Clark via RT wrote:
> > Specifically, I am suspecting that if
> >
> > offsetof(struct parrot_string_t, bufused) == sizeof(Buffer)
> >
> > matters, then something is either looking at or copying (sub)struc
On Thu, 13 Mar 2008, Nicholas Clark via RT wrote:
> Specifically, I am suspecting that if
>
> offsetof(struct parrot_string_t, bufused) == sizeof(Buffer)
>
> matters, then something is either looking at or copying (sub)structures than
> happen to have padding, and in turn that padding happen
On Wed, Mar 12, 2008 at 07:19:06AM -0700, Andy Dougherty wrote:
> I haven't been able to track down the problem. I vaguely suspect it's
> an alignment/structure padding issue. Specifically, in the old
> version,
> offsetof(struct parrot_string_t, bufused) == sizeof(Buffer),
> but that wasn't
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #51652]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51652 >
There might be a possible alignment issue lurking in the new streamlined
PMC and STRI
Uri Guttman <[EMAIL PROTECTED]> wrote:
> boy, was this easy with this module. all we need to do is mess around
> with the output to get whatever leo needs.
s/leo/Joe R. Parrot Hacker/ - I can craft initializers by hand ;)
1) some script e.g. gen_struct (struct2pasm ...) located in tools/dev or
b
Paolo Molaro <[EMAIL PROTECTED]> wrote:
> The offsets look incorrect. On basically every modern 32 or 64 bit
> OS (with sizeof(int) == 4) it should look like:
Yeah. But in the meantime Parrot should calculate correct offsets :)
> lupus
leo
On 02/05/04 Uri Guttman wrote:
> with this struct (from leo with some minor changes):
>
> struct xt {
> char x;
> struct yt {
> char i,k;
> int j;
> } Y;
> char z;
> } X;
>
> and this trivial script (i pass the filename on the command line):
[.
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> Maybe you ought to capitulate to the hierarchical nature of it all and
> simply push on another struct layout specifier to handle the nesting.
Exactly that's the plan:
.DATATYPE_STRUCT
.DATATYPE_STRUCT_PTR
are already in CVS.
leo
On Thursday, February 5, 2004, at 05:23 , Leopold Toetsch wrote:
Nested structs are ugly. The alignment of the first item seems to depend
on the biggest item in the struct.
[...]
Yeah, the struct is aligned to align the largest element therein. e.g.:
struct { char; struct { char; char; char; } }
boy, was this easy with this module. all we need to do is mess around
with the output to get whatever leo needs.
with this struct (from leo with some minor changes):
struct xt {
char x;
struct yt {
char i,k;
int j;
} Y;
char z;
} X
Uri Guttman <[EMAIL PROTECTED]> wrote:
> > "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
> LT> I'll do the alignment stuff. An util that actually generates the
> good but util(ity) is pronounced with a hard 'u' as in 'you'. so that
> should be 'a' and not an>.
Hey - thanks for that.
> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> Uri Guttman <[EMAIL PROTECTED]> wrote:
>> > "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> i am playing with ExtUtil::XSParser now
LT> ... but I hope that people out there are speaking Perl and can help with
LT>
> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> I'll do the alignment stuff. An util that actually generates the
.
LT> initializer - as outlined in the previous posting - would be great
LT> though.
i am playing with ExtUtil::XSParser now and i have some problems with
it. i w
Uri Guttman <[EMAIL PROTECTED]> wrote:
> LT> Nested structs are ugly. The alignment of the first item seems to depend
> LT> on the biggest item in the struct.
> that is a known rule for alignment of nested structs. since larger items
> usually have strict alignment requirements
Ok. Then I'll t
> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> Chromatic <[EMAIL PROTECTED]> wrote:
LT> [ align issues ]
LT> Nested structs are ugly. The alignment of the first item seems to depend
LT> on the biggest item in the struct.
that is a known rule for alignment of nested structs
On Thu, Feb 05, 2004 at 11:04:40AM +0100, Jens Rieks wrote:
> >
> >
> > I thought of that too. A Perl script that takes a C struct and emits an
> > *ManagedStruct initializer. WRT align: as such struct initializers are
> > in library code and used by different machines, I'd rather have the
> > alig
Jens Rieks <[EMAIL PROTECTED]> wrote:
> I'am currently writing a simple C-parser in imc. My plan is to extract
> all structs, enums, unions and typedefs in order to create
> ManagedStructs automatically. If one goes even a step further, it
> should even be possible to create pasm/imc wrapper for
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> gen_struct --force-align file.imc
It seems that this part finally has to consult the C compiler, i.e.
generate a test program and parse the offsetof() values of struct items.
The problem is nested structs, s. classes/unmanagedstruct.pmc for some
com
Chromatic <[EMAIL PROTECTED]> wrote:
[ align issues ]
Nested structs are ugly. The alignment of the first item seems to depend
on the biggest item in the struct.
struct {
char // 0
struct {
char// 1
}
char // 2
}
struct {
char
Am Donnerstag, 5. Februar 2004 09:45 schrieb Leopold Toetsch:
> Uri Guttman <[EMAIL PROTECTED]> wrote:
> > printf( "%d event.type\n", (char *)&kbevent.type ) - (char *)&kbevent ;
>
> offsetof(struct, item)
>
> is used inside parrot/jit/*
>
> > want me to hack up this little script and c gener
Uri Guttman <[EMAIL PROTECTED]> wrote:
> printf( "%d event.type\n", (char *)&kbevent.type ) - (char *)&kbevent ;
offsetof(struct, item)
is used inside parrot/jit/*
> want me to hack up this little script and c generation stuff? the hard
> part is parsing the struct so i would have to as
> "c" == chromatic <[EMAIL PROTECTED]> writes:
c> I ran this program in lieu of the debugger:
i recall an old trick i learned to get offsets into structs which would
be easier to read than hex addresses:
c> int main ()
c> {
c> SDL_KeyboardEvent kbevent;
c> printf( "0x%08X
On Wed, 2004-02-04 at 13:36, Leopold Toetsch wrote:
> > As I understand it (and correct me if I'm wrong), SDL_keysym needs a
> > byte of padding on my architecture within SDL_KeyboardEvent.
> Brr. I don't know. I've to ask my debugger for that :) If you have
> SDL_keysym alone, that needs 3 bytes
Chromatic <[EMAIL PROTECTED]> wrote:
> In this case, it doesn't, as the struct I'm emulating is:
> typedef struct {
> Uint8 type; /* SDL_KEYDOWN or SDL_KEYUP */
> Uint8 which;/* The keyboard device index */
> Uint8 state;/* SDL_PRESSED or SD
On Wed, 2004-02-04 at 00:52, Leopold Toetsch wrote:
> Pushing zero as offset should do The Right Thing, that is proper
> aligning the item. Tighter packed structures can be achieved with
> explicit offset parameters.
In this case, it doesn't, as the struct I'm emulating is:
typedef struc
Chromatic <[EMAIL PROTECTED]> wrote:
> set layout['member'], .DATATYPE_INT
> push layout, 0
> push layout, 0
Pushing zero as offset should do The Right Thing, that is proper
aligning the item. Tighter packed structures can be achieved with
explicit offset parameters.
Its basical
On Tue, 2004-02-03 at 00:58, Leopold Toetsch wrote:
> Have a look at the third initializer param - this is the offset of the
> item in bytes.
Oh, right. That completely slipped my mind.
> (Albeit untested - seems you got the code to test it :)
Okay, I'll turn this into a test case.
> NCI is p
Chromatic <[EMAIL PROTECTED]> wrote:
> That is, to make the keyed struct work correctly, I had to add extra
> bytes of padding in the appropriate places.
Have a look at the third initializer param - this is the offset of the
item in bytes.
(Albeit untested - seems you got the code to test it :)
Hi there,
While adding support for handling keyboard events to the SDL bindings
(see the attached patch; it's not for applying, as the documentation is
lacking and the interface exposes too many details), I discovered that
the alignment of members within a struct matters quite a bit.
That is, to
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Fix C<$pkg::$var> precedence issues with parsing of C<::>
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last Modified: 23 Sep 2000
Mailing List
On Sat, 16 Sep 2000 19:26:38 -0700, Nathan Wiger wrote:
>My point was more should that be
>
> 'Class'->name
>
>or
>
> Class()->name
There now is another RFC about this: RFC 244. How odd, v1 dates from the
same day as your post. But I think Tom Christiansen has brought this up
before.
The i
> ${$pkg.'::'.$var} = $val;
> ${"$pkg\::$var} = $val;
>
> Still ugly, but not quite as bad as what you came up with.
Thanks - once I saw the first one my brain went "Oh, yeah"
> Ooop, didn't even notice and didn't see the discussion. Let me see if
> I missed anything... I didn't
On Sat, Sep 16, 2000 at 03:24:32AM -, Perl6 RFC Librarian wrote:
> Currently, trying to dynamically assign to unnamed classes is very
> difficult:
>
>$pkg::$var = $val; # error
>${pkg}::$var = $val; # nope
>${$pkg::$var} = $val; # you wish
>${${pkg}::$var} =
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Fix C<$pkg::$var> precedence issues with parsing of C<::>
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last Modified: 15 Sep 2000
Mailing List
79 matches
Mail list logo
