Sphillips <[EMAIL PROTECTED]> wrote:
>
> While you're rehashing/justifying sensible design decisions made years
> ago ;-) I was wondering why you decided to roll-your-own GC rather than
> use an established one e.g. Hans Boehm's.
Mainly two reasons: no one did try to implement e.g. Boehm GC with
> Robert Spier wrote:
> >>>Doesn't work when svk is used to check out the copy. But in that case
> >>>svk list -R does.
> >>
> >>Hmm. Maybe this should be a commit action and not a test.
> > It was under CVS. I'm pretty sure everyone ignored it there :)
>
> Well, it always depends, how responds
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 1 May 2005 11:18:47 +0200
Bob Rogers <[EMAIL PROTECTED]> wrote:
> I have started writing a t/op/n_arithmetics.t test, based directly on
> t/op/arithmetics.t.
Great, thanks.
No problem. See attached. It should cover everyth
Garrett,
On May 1, 2005, at 5:44 PM, Garrett Rooney wrote:
I might have this wrong, but isn't the 'is export' trait on a
subroutine supposed to indicate that it's exported into the namespace
of the code that uses or requires the module? That doesn't seem to be
happening right now. Well, it is
On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
> On Fri, 29 Apr 2005, Brent 'Dax' Royal-Gordon wrote:
>
> >David Storrs <[EMAIL PROTECTED]> wrote:
> >>Could we see some code that shows why this is a good idea? My initial
> >>reaction is horror; I can very easily see huge numbers
I might have this wrong, but isn't the 'is export' trait on a subroutine
supposed to indicate that it's exported into the namespace of the code
that uses or requires the module? That doesn't seem to be happening
right now. Well, it is happening, but it's also happening for
subroutines without
On Sun, May 01, 2005 at 10:59:59AM -0400, Aaron Sherman wrote:
> On Sat, 2005-04-30 at 16:55 -0700, Brent 'Dax' Royal-Gordon wrote:
> > Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > > On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
>
> > > > That would be absolutely horrible.
>
> You all s
On behalf of the Pugs team, I am delighted to announce the release of
Pugs 6.2.2, the first version with a thread-safe, deadlock-free internal
storage, based on software transactional memory (STM).
Also, the performance is much, much better with this release; it is at
least 10x faster than the def
On Sat, 2005-04-30 at 16:55 -0700, Brent 'Dax' Royal-Gordon wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
> > > That would be absolutely horrible.
> > Str|Int is simply the type of "Yes"|1, isn't it? That would certainly
> > make sig
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 30, 2005 at 10:40:12AM +0200, Leopold Toetsch wrote:
>> And maybe even
>>
>>foo(x, ...) @TAIL_CALL # tail function call
>>
>>o.foo(x, ...) @TAIL_CALL# tail method call
> This would be *really* nice. I'm assuming here th
Bob Rogers wrote:
Also, I notice that n_ceil and n_floor are not implemented. Should
they be?
floor, ceil is currently implemented for native types only. As long as
we don't have PMC variants, we don't have n_ceil and n_floor either.
I don't know, if we need PMC variants and vtable functions.
Bernhard Schmalhofer via RT <[EMAIL PROTECTED]> wrote:
> Propably due to recent charset changes, I found that httpd.imc was no
> longer working under Linux. The op 'recv' seems to return a 'binary'
> string. However for 'binary' the 'index' op is not implemented, thus
> httpd.imc can't check for "
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:19 AM +0200 4/30/05, Leopold Toetsch wrote:
>>BTW shouldn't we really separate C and C? The latter
>>would be overridable by user code, the former frees allocate memory.
> I can't really think of a reason to have two cleanup actions. Maybe
> I'm miss
Bob Rogers <[EMAIL PROTECTED]> wrote:
> How about extending ".return" to cover these:
> .return foo(x, ...) # tail function call
> .return o.foo(x, ...) # tail method call
> Otherwise, it may be easier to miss the fact that the call also does a
> return. (This is clos
Bob Rogers <[EMAIL PROTECTED]> wrote:
> I have started writing a t/op/n_arithmetics.t test, based directly on
> t/op/arithmetics.t.
Great, thanks.
> ... But I notice that if I try
> P0 = n_add P0, 1
> I get the error:
Accidentally converted to an inplace operation. Is fixed here already
Cory Spencer <[EMAIL PROTECTED]> wrote:
>-> (* 2 3.2)
>9.6
>-> (+ 1.2 3)
> I'm not sure what kind of magic you worked last time with Integers,
> Leo, but would you mind working it again? (Or pointing me in the right
> direction so that I can fix it myself. :)
Short answer: will be f
Robin Redeker writes:
> On Sat, Apr 30, 2005 at 05:02:54PM -0400, Dan Sugalski wrote:
> > destroy. There's a vtable method that's called by the GC system when
> > an object is no longer reachable from the root set.
>
> Actually, not when, but some (indefinite) time after that has happened,
> righ
On 5/1/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Anyway, "for" doesn't need "is lazy", because it simply evaluates the
> list it is given and iterates over it. The fact that evaluating the
> list may be a no-op because of laziness is unrelated to "is lazy"
> (another hint that it's the wrong na
Juerd writes:
> Luke Palmer skribis 2005-05-01 1:17 (-0600):
> > Umm... maybe I'm totally misunderstanding you, but I think it doesn't,
> > since I'm implementing statement:, not statement:.
>
> Sorry, I wasn't clear enough. How would the same "is lazy" thing be
> useful with "for", given this ex
Luke Palmer skribis 2005-05-01 1:17 (-0600):
> Umm... maybe I'm totally misunderstanding you, but I think it doesn't,
> since I'm implementing statement:, not statement:.
Sorry, I wasn't clear enough. How would the same "is lazy" thing be
useful with "for", given this example?
Juerd
--
http://
Juerd writes:
> Luke Palmer skribis 2005-04-26 9:37 (-0600):
> > sub statement: (&cond is lazy, &block) {
>
> How does that handle
>
> for { closure }, { closure } -> { ... }
>
> and why? :)
Umm... maybe I'm totally misunderstanding you, but I think it doesn't,
since I'm implementing s
Luke Palmer skribis 2005-04-26 9:37 (-0600):
> sub statement: (&cond is lazy, &block) {
How does that handle
for { closure }, { closure } -> { ... }
and why? :)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gaji
I have been enjoying the recent discussion of GC vs refcounting. Thanks.
While you're rehashing/justifying sensible design decisions made years
ago ;-) I was wondering why you decided to roll-your-own GC rather than
use an established one e.g. Hans Boehm's.
I ask this not because I have any cri
23 matches
Mail list logo
