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
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
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 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
> >>
--- 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
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
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 a
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 ;
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
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
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
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 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
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 bonu
--- 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
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
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
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 chan
# 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
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
"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
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 h
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
38 matches
Mail list logo
