On Tue, 4 May 2004, Luke Palmer wrote:
> Abhijit A. Mahabal writes:
> > Needing to know "the entire P6 grammar" isn't mouth watering.
>
> grammar Grammar::ReqNamed {
> is Grammar::Perl;
Ah, I see. That does answer my question. I had forgotten that grammers can
be inherited from and y
At 4:25 PM -0700 5/4/04, Jeff Clites wrote:
On May 4, 2004, at 9:02 AM, Dan Sugalski wrote:
While Parrot will do async IO, we are making ordering guarantees
for reads and writes (though reads and writes will be considered
separate and ordered separately). That is, if you issue two or more
reads
Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
ICU somehow manages (optionally?) to suffix all it its symbols with the
version number, automagically (meaning, they don't look that way in the
source or the headers).
urename.h is responsible for this. All the symbols get a vers
On May 4, 2004, at 6:55 AM, Joshua Gatcomb wrote:
Is it possible that parrot is coredumping for
some other reason? The parrot.exe is around 3MB. I
know that it isn't dying immediately upon execution
because if the data file isn't in the directory it is
supposed to be, invoking parrot.exe will com
On May 4, 2004, at 9:02 AM, Dan Sugalski wrote:
While Parrot will do async IO, we are making ordering guarantees for
reads and writes (though reads and writes will be considered separate
and ordered separately). That is, if you issue two or more reads or
writes, they will be satisfied in order a
Abhijit A. Mahabal writes:
> As I try writing P6 programs I do find myself needing required named
> params, and I thought I'd like something like ++$named_req for myself as a
> shorthand for "+$named_req is required" or whatever is decided.
>
> Now, larry often says (only partly jokingly) "go writ
Dov Wasserman writes:
> Long-time lurker, first time poster. Dittos, kudos, etc.
Welcome aboard.
> Since in the rest of Perl 6, the '~' operator involves string
> representation, perhaps the standard +$foo marker should really be ~$foo:
> i.e., $foo only has a (string) name, not a numeric positio
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Or just issue a generic process_events op and spin through the events
DS> in the event queue forevermore. :)
i love spinning the cpu. idle loops are your friend! :)
>> if you set the callbacks, they should be triggered. but if you
At 1:07 PM -0400 5/4/04, Uri Guttman wrote:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> sure. a simple double buffering stream program. it starts an async read
>> and waits for it. when ready starts another read in the other buffer, it
>> mungs the data in the first buffer and
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> sure. a simple double buffering stream program. it starts an async read
>> and waits for it. when ready starts another read in the other buffer, it
>> mungs the data in the first buffer and does an async write out (say, to
>> a sock
At 12:00 PM -0400 5/4/04, Aaron Sherman wrote:
On Tue, 2004-05-04 at 11:36, Dan Sugalski wrote:
At 11:25 AM -0400 5/4/04, Aaron Sherman wrote:
>So, all Parrot IO will be asynchronous? Does that mean that there's no
>way to perform an atomic read or write?
Yes, and there isn't now anywhere anyw
Chromatic <[EMAIL PROTECTED]> wrote:
> On Tue, 2004-05-04 at 00:48, Leopold Toetsch wrote:
>> Yes, the code didn't handle this case where we are creating nested
>> structures, which are chained by pointers. Should be fixed now, i.e. the
>> test succeeds now.
> Thanks, that does make the test pass
At 11:03 AM -0400 5/4/04, Uri Guttman wrote:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> However...
DS> There are those pesky repeating events, and events from outside
DS> sources. Signals, mouse clicks, window resizes, repeating timer
DS> firings... stuff like that. Can any
On Tue, May 04, 2004 at 03:41:58PM +0200, Aldo Calpini wrote:
: but: what if Animal does inherits from something else? what I would like
: to do (what I was trying to do with wrappers, that is) is to call the
: inherited constructor, then do something with the returned object.
: something like:
:
Since it's bound to come up, we might as well get this out of the way now.
While Parrot will do async IO, we are making ordering guarantees for
reads and writes (though reads and writes will be considered separate
and ordered separately). That is, if you issue two or more reads or
writes, they
On Tue, 2004-05-04 at 11:36, Dan Sugalski wrote:
> At 11:25 AM -0400 5/4/04, Aaron Sherman wrote:
> >So, all Parrot IO will be asynchronous? Does that mean that there's no
> >way to perform an atomic read or write?
>
> Yes, and there isn't now anywhere anyway so it's not a big deal.
I was speaki
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The way things are going to work with specific actions a program has
DS> asked to be done, such as a disk read or write, is that you get back a
DS> handle PMC that represents the request, and you can wait on that
DS> handle for the
At 4:17 PM +0200 5/4/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... stuff like that. Can anyone think of a reason that someone
would want to wait *specifically* on one type of event like this,
Well, just for symmetry
new Px, EventWait
set Px, 0.1
waitfor Px
But
At 11:25 AM -0400 5/4/04, Aaron Sherman wrote:
On Tue, 2004-05-04 at 09:25, Dan Sugalski wrote:
Okay, I'm working up the design for the event and IO system so we can
get that underway (who, me, avoid the unpleasantness of strings?
Nah... :) and I've come across an interesting question.
The way
Abhijit A. Mahabal skribis 2004-05-04 10:27 (-0500):
> As I try writing P6 programs I do find myself needing required named
> params, and I thought I'd like something like ++$named_req for myself as a
> shorthand for "+$named_req is required" or whatever is decided.
What's wrong with just specifyi
As I try writing P6 programs I do find myself needing required named
params, and I thought I'd like something like ++$named_req for myself as a
shorthand for "+$named_req is required" or whatever is decided.
Now, larry often says (only partly jokingly) "go write your own grammar".
But I do not kno
On Tue, 2004-05-04 at 09:25, Dan Sugalski wrote:
> Okay, I'm working up the design for the event and IO system so we can
> get that underway (who, me, avoid the unpleasantness of strings?
> Nah... :) and I've come across an interesting question.
>
> The way things are going to work with specific
On Tue, 2004-05-04 at 00:48, Leopold Toetsch wrote:
> Yes, the code didn't handle this case where we are creating nested
> structures, which are chained by pointers. Should be fixed now, i.e. the
> test succeeds now.
Thanks, that does make the test pass here.
Now for the case when applying a lay
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... stuff like that. Can anyone think of a reason that someone
> would want to wait *specifically* on one type of event like this,
Well, just for symmetry
new Px, EventWait
set Px, 0.1
waitfor Px
But that's normally (and now) done like:
sle
All:
While there are definately ICU issues on Cygwin, I
have gotten it to link to parrot both statically and
dynamically several different ways. The problem is
that the resulting parrot.exe coredumps upon
execution. I had always assumed that the problem was
related to ICU since it was immediately
On Fri, 2004-04-30 at 19:01, Larry Wall wrote:
> That would almost certainly fail with an error saying that it couldn't
> find your &new subroutine. The & sigil does not imply dispatch, and
> the default .new is inherited, not autogenerated, last I checked. :-)
ouch. too true.
so I guess my Ani
Okay, I'm working up the design for the event and IO system so we can
get that underway (who, me, avoid the unpleasantness of strings?
Nah... :) and I've come across an interesting question.
The way things are going to work with specific actions a program has
asked to be done, such as a disk re
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> 'libnci.so' is used for testing the native call interface. However I noticed
> that the tests in t/pmc/nci.t were skipped, because 'libnci.so' wasn't built
> by default. The attached patch adds that library to the target 'all'.
Thanks, applied. Le
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Dan Sugalski wrote:
>> 3) The embedding wrapper is responsible for setting and resetting the
>> top of stack.
> Proof-of-concept:
Looks good.
Thanks, applied.
leo
Another todo list task for the interested. A perl & linker thing.
Right now, through the wonders of the Unix default linking
conventions, every function in parrot gets exported whether we want
them to be or not, and generally we don't. That needs fixing.
The right way to fix this is to have a f
> ICU somehow manages (optionally?) to suffix all it its symbols with
> the version number, automagically (meaning, they don't look that way
> in the source or the headers). We should figure out how they are doing
> that, and see if we can use the same approach. I don't know if it's
> linker magic,
Long-time lurker, first time poster. Dittos, kudos, etc.
Back on the topic of required named parameters, I think John Siracusa's
initial post did a good job of separating the two concepts of parameter
mandate (required vs. optional) and parameter designation (by position vs.
by name). Each of thes
On Mon, 3 May 2004, Dan Sugalski wrote:
> At 4:00 PM +0200 5/2/04, Marcus Thiesen wrote:
> >it seems as if the ICU makefiles don't work that well with BSD style makes
> >like the one in OpenBSD core and NetBSD. As I'm no makefile expert it's quite
> >hard for me to fix this, don't know if it is po
Ron Blaschke <[EMAIL PROTECTED]> wrote:
> Is there anything specific that is known to be broken/not yet implemented
> on Win32? Anything else I can help with?
One more thing comes to my mind. That's dynamic loading of classes and
bytecode (dynclasses/ and dynoplibs/). Win32 needs AFAIK much more
Chromatic <[EMAIL PROTECTED]> wrote:
> int bpp = surface->format->BytesPerPixel;
> The attached test patch demonstrates what I think is a problem.
Yes, the code didn't handle this case where we are creating nested
structures, which are chained by pointers. Should be fixed now, i.e. the
tes
35 matches
Mail list logo
