Arthur Bergman [EMAIL PROTECTED] wrote:
So today we managed to solve the problem.
I wasn't aware that the Parrot DOD/GC would run even if I wasn't
running any parrot bytecode, so when we started executing larger
amounts of perl code, things got ugly because parrot was GCing from
under our
Nigelsandever @ Btconnect . Com [EMAIL PROTECTED] wrote:
Does the naming and placement of this test fit convention?
Your are talking of a new test file called t/pmc/exec.t, don't you?
Good. I'd prefer t/op/exec.t, as it isn't really PMC related.
Where is the test?
leo
Jens Rieks [EMAIL PROTECTED] wrote:
The following code results in a
clone() not implemented in class 'ParrotClass'
Can cou try to add this to parrotclass.pmc:
PMC* clone() {
return SELF;
}
jens
leo
Joshua Hoblitt wrote:
On Tue, 2 Mar 2004, Leopold Toetsch wrote:
AMD originally was calling it x86-64.
Yep.
I've attached the results of:
perl Configure.pl
make ./parrot_build-x86_64.txt 21
I dont' see any show-stopping warnings here, nothing that could
inidicate the huge amount of
Nick Kostirya [EMAIL PROTECTED] wrote:
If to define _STRUCT_TIMESPEC, then compilation is successfully.
Does NetBSD have pthread? Can you try to create a hint file netbsd.pl.
s. config/init/hints/*.pl
% make test
All tests successful, 2 tests and 69 subtests skipped.
Good.
% make testexec
Dan Sugalski [EMAIL PROTECTED] wrote:
If you have a pmc class that inherits from delegate you're out of
luck. All of delegate's methods, save init, are autogenerated, and as
such can't be inherited from.
I've put in a hackish patch to delegate object vtables to delegate.pmc.
Seems to be time
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #27305]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27305
Steps:
(1) delete directory ./languages/plot/ and all its contents.
(2)
Eirik Berg Hanssen [EMAIL PROTECTED] wrote:
Surprise -- linux-x86-gcc3.2.3, which is what I happen to have here,
was missing from PLATFORMS. No surprise -- every test passed. Patch
for PLATFORMS attached.
I'm not sure, if we should add each single gcc version.
(Schizophrenia as in: `ps
Goplat [EMAIL PROTECTED] wrote:
Attached patch adds native exec support for win32's COFF format .o files. I
had to change some code that assumed the bytecode being used was from the
interpreter-code-src block, which wasn't the case when it's not being mmaped.
The bytecode is at
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #27308]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27308
This patch modifies ./languages/LANGUAGES.STATUS, breaking the current
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #27304]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27304
Steps:
(1) move ./libnci.def to ./src/libnci.def
(2) apply patch
Patch
Applied.
I would close the ticket but RT tells me I have no permission to view
it.
Mike
On 2 Mar 2004, at 14:34, [EMAIL PROTECTED] (via RT) wrote:
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #27308]
# in the subject line of all future correspondence about
As promised.
The new site is now live.
-R
thank you! this looks fantastic, and the html docs will be a valuable and
welcome addition.
--jerry
**
This e-mail and any files transmitted with it may contain
This works now:
newclass P1, Foo
find_global P2, init
store_global Foo, __init, P2
find_type I1, Foo
new P3, I1
print ok 2\n
end
.pcc_sub init:
print ok 1\n
invoke P1
Missing is some call all parents contructors. But above is good enough
to allocate
Dan Sugalski wrote:
Since we need a new system to handle ok/nok/full bug reports, how
'bout we add in:
parrotstatus-ok
parrotstatus-nok
parrotbug
all @parrotcode.org. The first for automated OK reports, the second
for automated nok reports, and the third for actual bug reports.
At 10:29 AM +0100 3/3/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
If you have a pmc class that inherits from delegate you're out of
luck. All of delegate's methods, save init, are autogenerated, and as
such can't be inherited from.
I've put in a hackish patch to delegate
At 7:37 PM -0500 3/2/04, Simon Glover wrote:
I think I've figured out what's happening here. Stepping through the
code with gdb shows that the first subclassing works fine, but the second
blows up in Parrot_single_subclass at line 233:
temp_pmc =
VTABLE_clone(interpreter,
At 7:15 PM -0800 3/2/04, Brent \Dax\ Royal-Gordon wrote:
Nigel Sandever wrote:
If my lack of experience with OSS/unix makes my willingness to
contribute to the project unviable, then a simple statement; stop
bothering us will stop me wasting your time and mine.
If I may, most of the US East
Yep, time to dive into yet *another* swamp. (Isn't this fun?)
Right now we've got the capability of getting the current time in
epoch seconds with the time op. This is good. However there's the
issue of actually *doing* something with it.
I'm torn here as to what to do. On the one hand,
Okay, here's a sketch of where I'm going with the initialization,
finalization, and fallback method locating. We need to do this
because we're in the semi-unenviable position of supporting multiple
languages that do this but that *don't* aggree on method names. So we
can't depend on those.
On Wed, Mar 03, 2004 at 11:37:09AM -0500 it came to pass that Dan Sugalski wrote:
FWIW, if we start getting into the What should our base time for the
epoch be arguments, I'll warn you that the answer if I have to make
one is probably Nov 17, 1858 at midnight, give or take a bad memory,
At 11:37 AM 3/3/2004 -0500, Dan Sugalski wrote:
I'm torn here as to what to do. On the one hand, it's supremely tempting
to punt and not have parrot do a darned thing with the time and leave it
to library code to handle it. On the other, CPAN is littered with the
carcasses of time and date
At 6:46 PM +0100 3/3/04, Jos Visser wrote:
On Wed, Mar 03, 2004 at 11:37:09AM -0500 it came to pass that Dan
Sugalski wrote:
FWIW, if we start getting into the What should our base time for the
epoch be arguments, I'll warn you that the answer if I have to make
one is probably Nov 17, 1858 at
What I'm thinking we may want to do is provide a minimal
interface--turn the time integer into a string rep or split out into
an array, something like:
localtime Sx, Iy
gmtime Sx, Iy
You almost have to provide at least these, as you have to deal with
how various OS's handle
On Wed, Mar 03, 2004 at 01:11:46PM -0500 it came to pass that Dan Sugalski wrote:
At 6:46 PM +0100 3/3/04, Jos Visser wrote:
On Wed, Mar 03, 2004 at 11:37:09AM -0500 it came to pass that Dan
Sugalski wrote:
FWIW, if we start getting into the What should our base time for the
epoch be
On Wed, Mar 03, 2004 at 11:37:09AM -0500, Dan Sugalski wrote:
: FWIW, if we start getting into the What should our base time for the
: epoch be arguments, I'll warn you that the answer if I have to make
: one is probably Nov 17, 1858 at midnight, give or take a bad memory,
: and our time
At 7:15 PM +0100 3/3/04, Jos Visser wrote:
On Wed, Mar 03, 2004 at 01:11:46PM -0500 it came to pass that Dan
Sugalski wrote:
At 6:46 PM +0100 3/3/04, Jos Visser wrote:
On Wed, Mar 03, 2004 at 11:37:09AM -0500 it came to pass that Dan
Sugalski wrote:
FWIW, if we start getting into the What
On 3 Mar 2004, at 08:09, Leopold Toetsch wrote:
I wasn't aware that the Parrot DOD/GC would run even if I wasn't
running any parrot bytecode, so when we started executing larger
amounts of perl code, things got ugly because parrot was GCing from
under our feet!
Do you initialize
Arthur Bergman wrote:
On 3 Mar 2004, at 08:09, Leopold Toetsch wrote:
Do you initialize interpreter-lo_var_ptr? If you aren't entering any
runloop and this pointer isn't set, you will still have DOD bugs,
because the processor stack will not be marked properly.
You can set this pointer to the
At 10:35 AM + 3/3/04, Arthur Bergman wrote:
On 3 Mar 2004, at 08:09, Leopold Toetsch wrote:
I wasn't aware that the Parrot DOD/GC would run even if I wasn't
running any parrot bytecode, so when we started executing larger
amounts of perl code, things got ugly because parrot was GCing from
When updating the old version I had at the TD machine to the current cvs
version I realize that it fails right after start running, entering in an
eternal loop, I could not find out exactly what is the problem but I think
it's related to threads.
It's Debian 3.0 on parisc using gcc 3.0.4
Any
At 6:03 PM + 3/3/04, [EMAIL PROTECTED] wrote:
What I'm thinking we may want to do is provide a minimal
interface--turn the time integer into a string rep or split out into
an array, something like:
localtime Sx, Iy
gmtime Sx, Iy
You almost have to provide at least these, as you
At 10:29 AM -0800 3/3/04, Larry Wall wrote:
But the overriding consideration is that normal users should
Inever have to remember the units of the fractional seconds.
Is it nanoseconds this week?
Right, the units will always be seconds. That, at least, will stay constant.
--
On Wed, 3 Mar 2004, Larry Wall wrote:
Well, you can do whatever you like with Parrot, but I want Perl 6's
standard interface to be floating point seconds since 2000. Floating
point will almost always have enough precision for the task at hand,
and by the time it doesn't, it will. :-)
At 10:13 AM -1000 3/3/04, Joshua Hoblitt wrote:
On Wed, 3 Mar 2004, Dan Sugalski wrote:
FWIW, if we start getting into the What should our base time for the
epoch be arguments, I'll warn you that the answer if I have to make
one is probably Nov 17, 1858 at midnight, give or take a bad memory,
On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote:
: On Wed, 3 Mar 2004, Larry Wall wrote:
:
: Well, you can do whatever you like with Parrot, but I want Perl 6's
: standard interface to be floating point seconds since 2000. Floating
: point will almost always have enough
At 12:59 PM -0800 3/3/04, Larry Wall wrote:
On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote:
: On Wed, 3 Mar 2004, Larry Wall wrote:
: Anyways, I recall some discussion on p6l from years ago about using
: TAI (and I think specifically libtai) as the internal time format
: for p6.
At 18:46 +0100 3/3/04, Jos Visser wrote:
Nahhh Epoch should be 1-1-1970 at 12:00am midnight, *but* we will
have to allow for negative time values so that we can span either side
of eternity...
That's not so strange. On of the, very few, things Microsoft has done right is to use
floating
Oracle actually has the most elegant Gregorian time manipulation
implementation I've seen. The only operations it really supports are
add_months and add_days. Year +/- can be implemented with add_months*12.
All of add_week|hour|minute|second|ms|us|ns can be synthesized from
add_days. This scarcity
On Wed, Mar 03, 2004 at 04:18:14PM -0500, Dan Sugalski wrote:
: Don't get me wrong--I think the concept of TAI time is great.
: It's just always going to be a fixed number of seconds different than
: Perl 6 time, is all, whatever the TAI time is for Jan 1, 2000, UTC.
:
: That, as they say, turns
On Wednesday 03 March 2004 20:03, Jerome Quelin wrote:
cvsuser 04/03/03 11:03:10
Added: . parrotbug
Log:
Initial revision of parrotbug
parrotbug is missing in MANIFEST which causes a make test error.
http://tinderbox.perl.org/tinderbox/bdshowbuild.cgi?tree=parrot
jens
Dan Sugalski [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Reasonable enough, though there's something to be said for a
completely meaningless (to most people) epoch so folks stop treating
the number as a number with meaning and instead treat it as a black
box thing they can do
Jerome Quelin [EMAIL PROTECTED] wrote:
Then the question arises:
- should we include myconfig in ok reports?
No IMHO. But *if* possible, enough information to keep PLATFORMS (or a
better variant of that) up to date - which still needs a bit more inside
tests but I think that we should go
Dan Sugalski [EMAIL PROTECTED] wrote:
What I'm thinking of instead is to put properties on the class
namespace PMC that indicate which method, if any, in the namespace is
the proper method. And because initialization and finalization are...
interesting (don't ask, we'll go there later) we
Dan Sugalski [EMAIL PROTECTED] wrote:
Ah, I was thinking it was a single-level clone of data--basically a
shallow copy. I'll go fix.
I still don't know, how deep vtable-clone should really go. Currently
its of course still borken: it clones recursive-deeply and fails on
self-referentials
Daniel Grunblatt [EMAIL PROTECTED] wrote:
When updating the old version I had at the TD machine to the current cvs
version I realize that it fails right after start running, entering in an
eternal loop, I could not find out exactly what is the problem but I think
it's related to threads.
It's
Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:13 AM -1000 3/3/04, Joshua Hoblitt wrote:
TAI is 1958-01-01T00:00:00.
And that's a good base time too, other than it being off of clock
time for everyone by 32 seconds, give or take. Tempting, though.
Bahh, these few seconds. Dan, the year, the
Dan Sugalski [EMAIL PROTECTED] wrote:
However, note that the base date is different on Windows ...
... and depending on the compiler version and vendor. This is a snippet
from an app, which of course was written when I was younger, but this
was the code that accumulated to get a base date just
... and then I got bored.
;)
Thanks, all those changes applied.
-R
26898, 26904, 26927, 26939, 26941, 26945, 26953,
26956, 26964, 26976, 27097, 27098, 27143, 27150 -- spam
already reported these and they are to be cleaned out soon ;)
(there have been a few spam slippages lately)
Killed.
I still need to go back and do the monthly spam filter update.
-R
parrotbug is missing in MANIFEST which causes a make test error.
This kind of bug shouldn't happen if people actually read the messages
the cvs commit spits out.
It will tell you that the manifest check it runs on every commit
fails. Please don't ignore it.
-R
On Wed, 3 Mar 2004, Dan Sugalski wrote:
At 12:59 PM -0800 3/3/04, Larry Wall wrote:
On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote:
: On Wed, 3 Mar 2004, Larry Wall wrote:
: Anyways, I recall some discussion on p6l from years ago about using
: TAI (and I think specifically
On Wed, 3 Mar 2004, Dan Sugalski wrote:
Gah. OK, I'm about to declare that the time op *always* returns time
as GMT, though without specifying an epoch, unless someone's got a
good reason not to. That takes at least one variable out of the
problem.
The GMT system is dead... do you mean UTC
At 2:19 PM -1000 3/3/04, Joshua Hoblitt wrote:
On Wed, 3 Mar 2004, Dan Sugalski wrote:
At 12:59 PM -0800 3/3/04, Larry Wall wrote:
On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote:
: On Wed, 3 Mar 2004, Larry Wall wrote:
: Anyways, I recall some discussion on p6l from years ago
At 2:21 PM -1000 3/3/04, Joshua Hoblitt wrote:
On Wed, 3 Mar 2004, Dan Sugalski wrote:
Gah. OK, I'm about to declare that the time op *always* returns time
as GMT, though without specifying an epoch, unless someone's got a
good reason not to. That takes at least one variable out of the
willowBored now!/willow
/me runs and hides.
Applied!
(I should just give you access.)
-R
On Wednesday, March 3, 2004, at 06:39 PM, Robert Spier wrote:
... and then I got bored.
;)
Thanks, all those changes applied.
-R
--
Will Coke Coleda
For those of you not up to speed on how much date and time confusion there is,
I remember this article by Dave Rolsky as being interesting:
http://www.perl.com/pub/a/2003/03/13/datetime.html
# New Ticket Created by Will Coleda
# Please include the string: [perl #27369]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27369
When dumping a PMC type that isn't one dumper knows about, this small
patch
http://www.parrotcode.org/openpatches.html
points to, e.g.:
http://www.parrotcode.org/rt3/Ticket/Display.html?id=27304
instead of the more likely:
http://rt.perl.org/rt3/Ticket/Display.html?id=27304
On Wednesday, March 3, 2004, at 01:15 AM, Robert Spier wrote:
As promised.
The new site is
On Wed, 3 Mar 2004, Zellyn Hunter wrote:
For those of you not up to speed on how much date and time confusion there is,
I remember this article by Dave Rolsky as being interesting:
http://www.perl.com/pub/a/2003/03/13/datetime.html
You might also be interested in what Dave and others have
Will Coleda [EMAIL PROTECTED] wrote:
Here's some more.
27305 - just applied by Leo today. (but not closed! bad leo, no donut!
As openpatches used to be dead for a long time, I stopped looking at it.
Now it's up again, so I'll close tickets.
leo
61 matches
Mail list logo
