Dan Sugalski wrote:
> At 8:53 PM +0200 9/1/03, Christian Renz wrote:
> >Clemens,
> >
> >>"classpath"
> >
> >I guess the proper term would be class library. The path is only where
> >you look for the libraries :).
> >
> >It doesn't seem to be the Perl way to limit yourself to one option
> >only ("Th
At 8:53 PM +0200 9/1/03, Christian Renz wrote:
Clemens,
"classpath"
I guess the proper term would be class library. The path is only where
you look for the libraries :).
It doesn't seem to be the Perl way to limit yourself to one option
only ("There's more than one way to do it").
I'd worry less a
At 8:38 PM +0200 9/2/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Every PMC should have a next_for_GC pointer. You moved it to the ext
structure, ...
I moved it there for a good reason: speed. The smaller a PMC the faster
is the interpreter.
Right, and this part is only nee
Zellyn Hunter writes:
> On Tuesday 02 September 2003 13:09, Amir Karger wrote:
> > A couple more questions on the coding front:
> >
> > (1) Even though it's supposed to be "native" Parrot support, I'm still
> > allowed to write in PIR, right? Because that'll be translated to pasm
> > and thereby be
On Tuesday 02 September 2003 13:09, Amir Karger wrote:
> A couple more questions on the coding front:
>
> (1) Even though it's supposed to be "native" Parrot support, I'm still
> allowed to write in PIR, right? Because that'll be translated to pasm
> and thereby be native.
>
> (2) WinFrotz, one of
I'm looking for, but not finding, information regarding the character
type and encoding on parrot io objects.
As an example of why... I found this in io.ops :
op write(in PMC) {
PMC *p = $1;
STRING *s = (VTABLE_get_string(interpreter, p));
if (s) {
PIO_write(interpreter, PIO_STDOUT(int
Amir Karger <[EMAIL PROTECTED]> wrote:
> I got my fifteen bytes of fame in the P6 summary ...
Geewhillikins ... But you can always get more: Convert it into
Unicode (~:
_VL_
"But how can we do it if we don't know what it is?"
"Why, blame it all, we've GO
Leopold Toetsch wrote:
[snip]
> [1] when we want to thaw/clone big structures, we should have some means
> to estimate the amount of needed headers. If we will not have enough, we
> do a DOD run before clone/thaw and then turn DOD off - it will not yield
> any more free headers anyway. This can avo
> > C. #if defined/undefined vs 0/1 issue
> >
> > I'm for ifdef/ifndef.
>
> For complex combinations of conditionals you have to write things like
>
> #if defined(A) || defined (B)
Sure. But I didn't precisely mean ifdef/ifndef. I was and am for
defined/undefined and used ifdef/ifndef there just a
I don't know why this didn't show up anywhere else, but on Solaris 8 with
perl5.00503, the imcc/t/syn/file.t tests that tried to load temp.pbc were
all failing. The reason turned out to be that the temp.imc files hadn't
been flushed to disk yet. Explicitly closing the files ensures
that they are
A couple more questions on the coding front:
(1) Even though it's supposed to be "native" Parrot support, I'm still
allowed to write in PIR, right? Because that'll be translated to pasm
and thereby be native.
(2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I
steal code or ideas
Darn. I was all set to write an amusing email about how I wasn't
offended that noone responded to my email, when someone went and
responded to my mail. OTOH, in the meantime I got my fifteen bytes of
fame in the P6 summary, plus the opportunity to play this week's Perl
Golf instead of mucking about
Darn. I was all set to write an amusing email about how I wasn't
offended that noone responded to my email, when someone went and
responded to my mail. OTOH, in the meantime I got my fifteen bytes of
fame in the P6 summary, plus the opportunity to play this week's Perl
Golf instead of mucking about
Though I haven't been following this thread, it seems you're coming up
with some File::Spec-like thing for Parrot?
I'd recommend looking at Ken Williams' excellent Path::Class module
which gives you actual file and directory objects. EXTREMELY useful when
you're in an ultra-cross platform environ
Clemens,
"classpath"
I guess the proper term would be class library. The path is only where
you look for the libraries :).
It doesn't seem to be the Perl way to limit yourself to one option
only ("There's more than one way to do it"). Of course we wouldn't
want five different implementations of Un
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Every PMC should have a next_for_GC pointer. You moved it to the ext
> structure, ...
I moved it there for a good reason: speed. The smaller a PMC the faster
is the interpreter.
> ... but it's there, and they all ought to have one. Any PMC that
> gets fr
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > Doing the walk is *also* easy. You clear the next PMC pointer, just as
> > with a normal DOD run setup. call the DOD mark on the inital PMC
>
> there is no mark() for a plain PMC scalar (and no next pointe
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Doing the walk is *also* easy. You clear the next PMC pointer, just as
> with a normal DOD run setup. call the DOD mark on the inital PMC
there is no mark() for a plain PMC scalar (and no next pointer inside
the PMC). If the PMC has a mark routine this ca
Hello,
Now I use my brand new commit access:
Non-Terminal IO-Layers often call down to the lower-lying
layers. Until now this was done in a while-loop reimplemented in every
upper layer (At the moment there is only one io_buf but there will be
more). This commit introduces new io_system private h
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Tue, 2 Sep 2003, Leopold Toetsch wrote:
>
> >> So if it was mark()ed already we return. That's not possible for freeze,
> >> thaw, dump, clone whatever. These must keep track of already visited
> >> object
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 2 Sep 2003, Leopold Toetsch wrote:
>> So if it was mark()ed already we return. That's not possible for freeze,
>> thaw, dump, clone whatever. These must keep track of already visited
>> objects via an hash for freeze, dump, clone, and via an ID arr
On Tue, Sep 02, 2003 at 06:39:23AM +0300, Vladimir Lipskiy wrote:
> C. #if defined/undefined vs 0/1 issue
>
> I'm for ifdef/ifndef.
For complex combinations of conditionals you have to write things like
#if defined(A) || defined (B)
but I think that we can live with that.
> D. Function parame
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Tue, 2 Sep 2003, Leopold Toetsch wrote:
>
> >> and no, not that one inside DOD, that one doesn't handle duplicates.
>
> > Yes, yes it *does* handle duplicates. Otherwise it'd get caught in
> > infinite lo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 2 Sep 2003, Leopold Toetsch wrote:
>> and no, not that one inside DOD, that one doesn't handle duplicates.
> Yes, yes it *does* handle duplicates. Otherwise it'd get caught in
> infinite loops every time it came across a circular data structure. T
Will Coleda writes:
> Should I expect:
>
> parrot -o foo.pasm foo.imc
> parrot foo.pasm
>
> to work like:
>
> parrot foo.imc
No. imcc doesn't emit local labels properly (as you seem to have
discovered).
> ? (it doesn't appear to be de-mangling two different "outer:" labels,
> each of whi
Should I expect:
parrot -o foo.pasm foo.imc
parrot foo.pasm
to work like:
parrot foo.imc
? (it doesn't appear to be de-mangling two different "outer:" labels,
each of which is in it's own enclosing .sub)
I'm trying to track down a bug where a .local var that's a PerlArray is
getting replace
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
> and no, not that one inside DOD, that one doesn't handle duplicates.
Yes, yes it *does* handle duplicates. Otherwise it'd get caught in
infinite loops every time it came across a circular data structure. That's
what the next pointer in the PObj heade
> Though I haven't been following this thread, it seems you're coming up
> with some File::Spec-like thing for Parrot?
Exactly.
> I'd recommend looking at Ken Williams' excellent Path::Class module
Surely, I will.
> So yes, you must distinguish between concatenating directories and files.
>
>
This patch adds a new item to the must part of pdd7.
Pdd7's still missing:
A. Solving the problem of typedef struct a *a
Summarizng Leo's, Juergen's, and Brent's ideas,
I propose the following:
To have an underscore prepended to the stuct ParrotInterp.
To use ParrotInterp defined as typedef str
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
> And I think you're saying that it'll be illegal to use this pointer PMC
> if the aggregate changes or anything like that, so the proxy can be as
> dumb and fast as possible... right? And that it wouldn't really need a
> header. S
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Further: having clone implemented in terms of freeze + thaw needs
>> additional memory for the intermediate frozen image. Isn't that
>> suboptimal?
> Only slightly -- It's just *one single* PMC's data that's stored in that
>
Leopold Toetsch writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 11:17 PM +0200 9/1/03, Leopold Toetsch wrote:
>
> >>I don't see the point here especially why we would need a temporary PMC.
> >>If we have an array of packed ints, I just need a pointer to the element
> >>to work on it. This
All~
If we don't have direct operations on aggregate elements but instead
have to do a fetch and perform the operation on what we fetch, it
means we have to create a temporary PMC for each 'fake' entry, one
potentially with a fair amount of knowledge about how the aggregate
works, which means that
Will Coleda <[EMAIL PROTECTED]> wrote:
> Should I expect:
[ Luke already did answer it, but some more hints ]
> parrot -o foo.pasm foo.imc
> parrot foo.pasm
> to work like:
> parrot foo.imc
No. as mentioned. The most useful thing here probably is:
$ parrot -o- foo.imc # | less
to have a
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:37 PM +0200 8/29/03, Leopold Toetsch wrote:
>>Aren't you saying the opposite of above here? I want to be able to
>>traverse from a given start point (being it the own interpreter or some
>>PMC) as deeply down as there is something. You did say, that w
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:17 PM +0200 9/1/03, Leopold Toetsch wrote:
>>I don't see the point here especially why we would need a temporary PMC.
>>If we have an array of packed ints, I just need a pointer to the element
>>to work on it. This is very similar to the C opcode I h
36 matches
Mail list logo
