Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>I know that. The current scheme is safe WRT these problems. A signal
>>originates from the signal handler, incrementing a sig_atomic_t variable
>>per signal.
> That doesn't work.
??? It's one of the few safe actions what you can do in an interrupt
handle
Jens Rieks wrote:
I've added them to experimental.ops, random.t is now in t/op/
We still need to consider what's an opcode and what not. We are going to
blow reasonable code size soon.
leo
Juerd wrote:
Juerd skribis 2004-05-12 20:15 (+0200):
But I think I still want to have some non-mutating version of s/// that
returns the modified string, so that you can just write something like
print s:gx/\w+/WORD/ for <>;
Actually, can't we just use the . for s///?
You'd then use $foo.s///
On Wed, May 12, 2004 at 11:37:44PM +0200, Juerd wrote:
: Aaron Sherman skribis 2004-05-12 17:30 (-0400):
: > I like C<...> I like it a LOT. In fact, I'm partial to the idea that
: > it should be usable anywhere
:
: I agree. It'd make even more of my pseudo code (#perlhelp and
: perlmonks.org) val
[EMAIL PROTECTED] (Aaron Sherman) writes:
> is it really that new and scary?
No, but not for the reasons you think. You seem to believe that you're
comparing Perl and a Perl-derived language and pointing out that they're
both like Perl, but it looks like you're comparing two Algol-derived
language
Aaron Sherman writes:
> On Wed, 2004-05-12 at 14:22, Juerd wrote:
>
> > Actually, can't we just use the . for s///?
>
> Well, that brings up something that I don't think Larry has covered yet.
> That is, it brings into question what s/// *is* in the grammar.
Well, I imagine it's just a macro ca
Matthew Walton writes:
> Juerd wrote:
>
> >my $n = IO::Socket::INET.new LocalPort => 20010, Listen => 5;
>
> Or, if I'm remembering correctly:
>
> my IO::Socket::INET $n .= new LocalPort => 20010, Listen => 5;
>
> I really hope I'm remembering correctly. Is this turning into the 'look
> ho
Juerd wrote:
my $n = IO::Socket::INET.new LocalPort => 20010, Listen => 5;
Or, if I'm remembering correctly:
my IO::Socket::INET $n .= new LocalPort => 20010, Listen => 5;
I really hope I'm remembering correctly. Is this turning into the 'look
how great Perl 6 is' thread?
Aaron Sherman skribis 2004-05-12 17:30 (-0400):
> I like C<...> I like it a LOT. In fact, I'm partial to the idea that
> it should be usable anywhere
I agree. It'd make even more of my pseudo code (#perlhelp and
perlmonks.org) valid syntax :).
Juerd
I like C<...>
I like it a LOT.
In fact, I'm partial to the idea that it should be usable anywhere:
class {
has $.a;
has $.b;
...;
}
or
my Foo $a = ...; # Ask Bob what this should be -Bill
In all cases, I'm a fan of C<...>
I am trying to nail down exactly how Cygwin behaves
with the various options turned on. I noticed that
testg does not have the -g option it should. I am on
my way out the door or I would provide a patch (I just
modified the Makefile directly for my testing).
Cheers
Joshua Gatcomb
a.k.a. Limbic~R
On Wed, 2004-05-12 at 14:22, Juerd wrote:
> Actually, can't we just use the . for s///?
Well, that brings up something that I don't think Larry has covered yet.
That is, it brings into question what s/// *is* in the grammar.
Is it a special type of calling convention, e.g.:
sub s (Rege
I have finally sorted out the details of the flags stuff, which I will
present below. Any comments are highly appreciated. Be warned: I am going
to implements this if there are no objections. ;-)
- Targets "shared" and "static" are provided, to build a shared or static
parrot library.
- The fol
Brent 'Dax' Royal-Gordon wrote:
> Gordon Henriksen wrote:
>
> >> Oh, it's worse than thatGUI commands need to be issued
> from the main
> >> thread, at least with OS X. (There's no actual requirement
> as to which
> >> thread handles the actual events as long as you treat the OS event
> >>
I have commited several revisions and additions to the 03handle.t test
file to the SVN repository. They are detailed as follows:
- increased number of tests from 68 to 101
- added tests to check conditions/assumptions prior to running
groups of tests,
which compliment the testing of th
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Good. So you can step through the JIT code.
>
Yes and no. On Monday, arithmetics_26 was not
coredumping parrot under JIT that I can remember. It
is now, but I am able to debug/trace with JIT. I am
not sure what to do since comparing the trace to
That's really and truly evil. I love it.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
On Wed, May 12, 2004 at 12:08:08PM -0400, Dan Sugalski wrote:
> Okay, so I'm working on redoing the events document based on the
> critiques from folks so far. (Which have been quite helpful) I should
> have a second draft of the thing soon.
>
> It does, though, sound like we might want an alter
"Luke Palmer" <[EMAIL PROTECTED]> wrote
> Well, the IO-objects are iterators, and you use <$iter> to iterate. It
> makes sense that <> would iterate over $*ARGV by default.
When I read this, I instinctively thought to myself: "why does this need to
be global?". And that thought progressed to: "wh
Hi,
On Wednesday 12 May 2004 20:23, Aaron Sherman wrote:
> On Wed, 2004-04-28 at 09:54, Aaron Sherman wrote:
> > A simple implementation of rand() and srand() which may not be ideal for
> > Perl. Also included is the test file for random ops. If anyone can think
> > of a good way to ALWAYS know th
On Wed, May 12, 2004 at 08:48:07PM +0200, Juerd wrote:
: Some tools like Irssi and my own PLP tie a handle and then select it, to
: intercept the output of normal print statements. But STDOUT can still be
: specified explicitly if that's where you want things to go.
:
: This makes the tools compa
Luke Palmer skribis 2004-05-12 12:46 (-0600):
> Well, the IO-objects are iterators, and you use <$iter> to iterate. It
> makes sense that <> would iterate over $*ARGV by default.
$*ARGS?
> my $n = new IO::Socket::INET: LocalPort => 20010, Listen => 5;
I'd like to be able[1] to write
my
At 8:02 PM +0200 5/12/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 9:41 AM +0200 5/12/04, Leopold Toetsch wrote:
$SIG{CHLD} = sub { 1; };
This could probably create the event PMC, associate the user callback
with it, enable SIGCHLD and be done with it. It's the same as
Larry Wall skribis 2004-05-12 11:39 (-0700):
> On Wed, May 12, 2004 at 08:15:36PM +0200, Juerd wrote:
> : A2 says $*STDIN and $*STDOUT. Has this been changed?
> It's $*IN and $*OUT.
I like this change!
> : I'd hate to have to specify stdin and stdout in throw away scripts.
> Just because there's
Aaron Sherman writes:
> Right off the bat, let me say that I've read A1-6, E7, A12, S3, S6, E1,
> E6 and much of this mailing list, but I'm still not sure that all of
> what I'm going to say is right. Please correct me if it's not.
Did you really need to ask me to? ;-)
> Perl 5:
>
> #!/u
On Wed, May 12, 2004 at 08:15:36PM +0200, Juerd wrote:
: A2 says $*STDIN and $*STDOUT. Has this been changed?
It's $*IN and $*OUT.
: Also, will there no longer be the concept of a selected filehandle?
That is correct.
: I'd hate to have to specify stdin and stdout in throw away scripts.
Just b
Larry Wall wrote:
On Wed, May 12, 2004 at 09:47:04AM +0100, Matthew Walton wrote:
: For some reason, lots of people don't like it when indentation is
: what's controlling their code structure...
Indentation is a wonderful form of commentary from programmer to
programmer, but its symbology is larg
On Wed, 2004-04-28 at 09:54, Aaron Sherman wrote:
> A simple implementation of rand() and srand() which may not be ideal for
> Perl. Also included is the test file for random ops. If anyone can think
> of a good way to ALWAYS know that a number we got back was "random",
> throw that into the test ;
Juerd skribis 2004-05-12 20:15 (+0200):
> But I think I still want to have some non-mutating version of s/// that
> returns the modified string, so that you can just write something like
> print s:gx/\w+/WORD/ for <>;
Actually, can't we just use the . for s///?
You'd then use $foo.s/// to ge
Aaron Sherman skribis 2004-05-12 14:04 (-0400):
> Perl 5:
> #!/usr/bin/perl
> while(<>) {
> s/\w+/WORD/g;
> print;
> }
> Perl 6:
> #!/usr/bin/perl
> while $stdin.getline -> $_ {
Empty <> uses ARGV, not STDIN. It only uses STDIN if
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:41 AM +0200 5/12/04, Leopold Toetsch wrote:
>> $SIG{CHLD} = sub { 1; };
>>
>>This could probably create the event PMC, associate the user callback
>>with it, enable SIGCHLD and be done with it. It's the same as with a
>>timer event.
> Which is swel
On Wed, 2004-05-12 at 12:08, Dan Sugalski wrote:
> It does, though, sound like we might want an alternate name for this
> stuff. While event is the right thing in some places it isn't in
> others (like the whole attribute/property mess) we may be well-served
> choosing another name. I'm open to
On Wed, 2004-05-12 at 11:22, Simon Cozens wrote:
> [EMAIL PROTECTED] (Luke Palmer) writes:
> > familiar. You'll find this in the earlier Exegeses, Piers Cawley's
> > article "Perl 6: Not Just for Damians"
> > (http://www.perl.com/pub/a/2001/10/23/damians.html), some of the
> > presentations from t
Dan Sugalski wrote:
> It does, though, sound like we might want an alternate name for this
> stuff. While event is the right thing in some places it isn't in others
> (like the whole attribute/property mess) we may be well-served choosing
> another name. I'm open to suggestions here...
>
incid
At 9:41 AM +0200 5/12/04, Leopold Toetsch wrote:
Uri Guttman <[EMAIL PROTECTED]> wrote:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Because of this, you have the event PMC for a Named event before the
DS> event occurs and thus can wait on it. You *don't* have the event PMC
DS
On Tue, May 11, 2004 at 10:48:22AM -0400, Dan Sugalski wrote:
: >Certainly some things won't be recursive-descent anyway (operator
: >precedence).
:
: Oh, don't be too sure of that. :)
Oh, I think Allison can be quite sure of that. :-)
In fact, I'd go so far as to say that it's almost impossibl
Gordon Henriksen wrote:
Oh, it's worse than that—GUI commands need to be issued from the main
thread, at least with OS X. (There's no actual requirement as to which
thread handles the actual events as long as you treat the OS event
queue as the thread-unsafe thing it seems to be) Or so the docs
Dan Sugalski wrote:
It does, though, sound like we might want an alternate name for this
stuff. While event is the right thing in some places it isn't in others
(like the whole attribute/property mess) we may be well-served choosing
another name. I'm open to suggestions here...
Notice? (Too sim
At 12:14 PM -0700 5/11/04, Dave Whipp wrote:
"Dan Sugalski" <[EMAIL PROTECTED]> wrote:
The terminology there's a bit strained, and I think it's in large
part responsible for most of the rest of the confusion.
They're probably better called Named and Anonymous events, though
that's a bit dodgy i
Dan Sugalski wrote:
Okay, so I'm working on redoing the events document based on the
critiques from folks so far. (Which have been quite helpful) I should
have a second draft of the thing soon.
It does, though, sound like we might want an alternate name for this
stuff. While event is the right
On Wed, May 12, 2004 at 09:47:04AM +0100, Matthew Walton wrote:
: although it might perhaps be a little early to go for Python-like syntax.
s/early/late/
Python's syntax succeeds in combining the mistakes of Lisp and Fortran.
I do not contrue that as progress.
Larry
Okay, so I'm working on redoing the events document based on the
critiques from folks so far. (Which have been quite helpful) I should
have a second draft of the thing soon.
It does, though, sound like we might want an alternate name for this
stuff. While event is the right thing in some places
On Wed, May 12, 2004 at 09:47:04AM +0100, Matthew Walton wrote:
: For some reason, lots of people don't like it when indentation is
: what's controlling their code structure...
Indentation is a wonderful form of commentary from programmer to
programmer, but its symbology is largely wasted on the
[EMAIL PROTECTED] (Luke Palmer) writes:
> familiar. You'll find this in the earlier Exegeses, Piers Cawley's
> article "Perl 6: Not Just for Damians"
> (http://www.perl.com/pub/a/2001/10/23/damians.html), some of the
> presentations from the last few conference seasons, and scattered about
> the c
Pedro Larroy writes:
> Yes, thanks a lot for your answers. I appreciate them.
>
> I think I'm now pretty attached to perl culture and I'm just a little
> worried, as a humble perl programmer, about "things changing too much"
> in perl6. Specially after reading coments like getting rid of the
> pa
Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> parrot trans_9.pasm
> ok 1
> ok 2
> parrot -j trans_9.pasm
> ok 1
> not ok 2
[ ... ]
> (gdb) add-symbol-file arithmetics_26.o 0
> add symbol table from file "arithmetics_26.o" at
> .text_addr = 0x0
> (y or n) y
> Reading symbols from arithmetic
On Wed, May 12, 2004 at 12:57:15AM -0400, Andrew Rodland wrote:
> On Tuesday 11 May 2004 10:13 pm, Larry Wall wrote:
> > On Tue, May 11, 2004 at 08:31:55PM -0400, Andrew Rodland wrote:
> > : On Tuesday 11 May 2004 08:00 pm, Pedro Larroy wrote:
> > : > Hi
> > : >
> > : > Is there any chance that in
On May 12, 2004, at 09.12, Dan Sugalski wrote:
At 2:59 PM -0400 5/11/04, Gordon Henriksen wrote:
As I pointed out in another post, this doesn't work for integrating
with at least two significant "event sources:" Windows and the Mac
OS. :) UI events need to be handled synchronously on the thread t
At 2:47 PM -0400 5/11/04, Gordon Henriksen wrote:
Dan Sugalski wrote:
At 10:33 AM -0700 5/11/04, chromatic wrote:
>On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
>
>> >I'm also curious how to write an interface to an
existing event system.
>> >Being able to write it all in PASM is a bonus
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> > ... This is
> > the result of running 'make testj'.
>
> > Failed Test Stat Wstat Total Fail Failed List
> of
> > Failed
> >
>
--
> > t/
At 2:59 PM -0400 5/11/04, Gordon Henriksen wrote:
Dan Sugalski wrote:
chromatic wrote:
> So for SDL, I'd start a separate thread that blocks on
SDL_WaitEvent,
> creating and posting events when they happen. My main program would
> handle the events as normal Parrot events. Standard producer
c
At 2:33 PM -0700 5/11/04, TOGoS (via RT) wrote:
# New Ticket Created by TOGoS
# Please include the string: [perl #29517]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29517 >
There were 2 simultaneous patches and it got ful
On Tue, May 11, 2004 at 06:15:58PM -0400, stevan little wrote:
> Tim,
>
> I see a few issues crop up with -T in the she-bang line (I made the
> change to my working copy to see), but when I do 'prove -T' I see the
> same issues crop up, plus then the zvpp* stuff fails (it basically
> fails to l
On Tue, May 11, 2004 at 03:23:40PM -0700, chromatic wrote:
> On Tue, 2004-05-11 at 15:19, stevan little wrote:
>
> > If 5.6.1 is the official minimum, then maybe this brings back up the -w
> > vs. warnings issue? Since Ovid pointed out that 5.6 was the minimum for
> > the warnings pragma, and 5.
Ilya Martynov <[EMAIL PROTECTED]> wrote:
> If I try example from dynclasses directory it segfaults:
> [EMAIL PROTECTED]:~/devel/parrot$ LD_LIBRARY_PATH=.:blib/lib ./parrot
> dynclasses/dynfoo.pasm
> ok 1
> 55
> ok 2
> 42
> Segmentation fault (core dumped)
Yep. Memory desruption related to MMD an
Stéphane Payrard wrote:
Le Wed, May 12, 2004 at 02:00:42AM +0200, le valeureux mongueur Pedro Larroy a dit:
Hi
Is there any chance that in perl6 there will be the possibility to write
if/else statements without {}s with the condition at the beginning?
Like
if (condition)
statement;
In ord
Le Wed, May 12, 2004 at 02:00:42AM +0200, le valeureux mongueur Pedro Larroy a dit:
> Hi
>
> Is there any chance that in perl6 there will be the possibility to write
> if/else statements without {}s with the condition at the beginning?
>
> Like
>
> if (condition)
> statement;
>
> In orde
Leopold Toetsch wrote:
I think, we have to split the main MANIFEST a bit into:
- core
- ICU
- languages
Why?
- cvs updates that hit MANIFEST take really long and are likely to collide
- language maintainers, who only have privs for their language
directory, should be able to do *all* needed chang
# New Ticket Created by TOGoS
# Please include the string: [perl #29517]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29517 >
There were 2 simultaneous patches and it got full of
diff garbage. This will clean it back u
# New Ticket Created by Alex Gutteridge
# Please include the string: [perl #29509]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29509 >
Hi,
The example Perl6 'Game of Life' program
(parrot/languages/perl6/examples/lif
# New Ticket Created by Ilya Martynov
# Please include the string: [perl #29511]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29511 >
-
If I try example f
"Dan Sugalski" <[EMAIL PROTECTED]> wrote:
> The terminology there's a bit strained, and I think it's in large
> part responsible for most of the rest of the confusion.
>
> They're probably better called Named and Anonymous events, though
> that's a bit dodgy in some ways too. Maybe specific and gen
You wrote:
>i don't think there is a need for all those variants. why would alarm
>need any special opcode when it is just a timer with a delay of abs_time
>- NOW? let the coder handle that and lose the extra op codes.
No, you don't want to do it that way. Becasue you want to make the latency
bet
Uri Guttman <[EMAIL PROTECTED]> wrote:
>settimer Pevent, Idelay_seconds, Iinterval_seconds[, Pcallback,
>Puserdata]
> so now all you have is two signatures (for float or integer seconds).
No. Above C definition expands to 8 different functions for
INTVAL arguments only:
Parrot
Uri Guttman <[EMAIL PROTECTED]> wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> DS> Because of this, you have the event PMC for a Named event before the
> DS> event occurs and thus can wait on it. You *don't* have the event PMC
> DS> for an anonymous event, so you can't wait o
William Coleda wrote:
Leopold Toetsch wrote:
I think, we have to split the main MANIFEST a bit into:
Other things that reside outside of our directory:
o dynclasses (Tcl), classes (Perl 6), tests for same.
o makefiles (./config/gen)
Yep. For the latter, there is no rule that tcl-makefile.in has t
Chromatic <[EMAIL PROTECTED]> wrote:
> Hi there,
> This one-line change to t/pmc/nci.t demonstrates an apparent bug
> somewhere in passing arrays of structs to NCI functions.
No.
> Alternately, I could be doing things wrong again. :)
Yes.
The test is passing an array of structs to the C funct
67 matches
Mail list logo
