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
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
Good catch.
I've fixed the URLs.
-R
At Thu, 4 Mar 2004 00:39:50 -0500,
Will Coleda wrote:
>
>
> 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/Ticke
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
# New Ticket Created by Will Coleda
# Please include the string: [perl #27369]
# in the subject line of all future correspondence about this issue.
# 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 changes i
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
> Bored now!
/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
Here's some more.
27305 - just applied by Leo today. (but not closed! bad leo, no donut!
=-)
27303 - spam
27308 - applied, with a note that the applier didn't have perms to
close it.
27336 - mine, patch applied by chromatic, needs closing.
25948 - fix committed by leo.
Bored now!
On Wednesday,
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
problem
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 ag
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 UT
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 specifi
> 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
> > 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 upda
> ... and then I got bored.
;)
Thanks, all those changes applied.
-R
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" j
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, t
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.
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 s
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) w
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 t
"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
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
j
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, turn
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_ can be synthesized from
add_days. This scarcity of operations yields the eleganc
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 po
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. Is
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 preci
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, 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. :-)
Ar
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,
> and our time value'll be a 64-bit integer.
At 10:29 AM -0800 3/3/04, Larry Wall wrote:
But the overriding consideration is that normal users should
I 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.
--
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
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 ide
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
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 value
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
> >
> 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 ha
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
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 modul
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
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.
Wha
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, it'
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
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 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 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
und
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 repo
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 allo
> 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 pri
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 add
McHarity @ Vendian . Org <[EMAIL PROTECTED]> wrote:
> Steps:
> (1) delete directory ./languages/plot/ and all its contents.
> (2) apply patch
(1) is more a sequence of cvs remove -f / cvs ci
cvs update -dP then should remove the local files/dirs.
Applied & done, thanks
> Mitchell
leo
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 thi
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 interpreter->lo_v
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #27304]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=27304 >
Steps:
(1) move ./libnci.def to ./src/libnci.def
(2) apply patch
Patch upda
Il giorno 02/mar/04, alle 04:12, Larry Wall ha scritto:
[...]
: Problem solved!!! ;-)
I think you prove my point. :-)
Very nice "certamen".
You would be probably thrilled by an italian Usenet poster I'm honoured
to know, who manually justifies every single post he writes. No extr
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #27308]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=27308 >
This patch modifies ./languages/LANGUAGES.STATUS, breaking the current
BASIC ent
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 interpre
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:
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #27305]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=27305 >
Steps:
(1) delete directory ./languages/plot/ and all its contents.
(2) appl
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 t
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 tes
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 2>&1
I dont' see any show-stopping warnings here, nothing that could
inidicate the huge amount
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
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
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
66 matches
Mail list logo
