So here's my .. well not much of a clue ..
[gc] Garbage 0x100101740=ptest::write_string[1][1/1] [#a=6,#d=3]
[gc] Garbage 0x100101840=fdoc_paragraph::bp[1][1/1] [#a=3,#d=1]
[gc] Sweeped 2
[gc] Free 0x100101740
[gc] Free 0x100101840
[gc] Reaped 2 objects
[gc] Still allocated 19 objects occupying
On 13/01/2014, at 4:37 AM, john skaller wrote:
> This is a bug:
>
> class A [T] { virtual fun f : 1 -> T; }
> instance A[int] { fun f : 1 -> int = "1"; }
> instance A[long] { fun f : 1 -> long = "2L"; }
> open A[long];
> //open A[int];
> println$ f ();
Now fixed. And since the original problem
This is a bug:
class A [T] { virtual fun f : 1 -> T; }
instance A[int] { fun f : 1 -> int = "1"; }
instance A[long] { fun f : 1 -> long = "2L"; }
open A[long];
//open A[int];
println$ f ();
prints 2. If I uncomment the A[int] case it prints 1.
Even if I swap the order of the two opens or the two
On 05/03/2013, at 1:29 PM, john skaller wrote:
> The algorithm which calculates ptf usage is flawed.
Fixed.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
--
Everyone hates slow websites. So do
The algorithm which calculates ptf usage is flawed.
That's "pointer to thread frame", the global store object.
Only manifests on low inlining. Will be fixed shortly.
Basically, certain primitives and operations "require" the ptf.
Eg if they need to do a heap allocation they need the gc which
needs
Felix type A -> B is a function and A --> B is a C function.
If you have the type
A * B --> C
this normally should be the C function type:
C (f)(A, B)
i.e. with separated arguments. Of course this is a hack because this:
(A * B) --> C
would be a different type:
C (f) (A
On 23/03/2008, at 10:30 AM, Erick Tryzelaar wrote:
>
> typeclass Value[t] {
> virtual proc dump: cptr[t] = "$1->dump();";
> }
>
> But shouldn't this be a type error? It's neat that if we have a fully
> implemented typeclass that it works on all types, but here it
> obviously won't work. Didn't
And just to be clear, if we have a purely virtual function, then it
will require an instance:
//
requires package "llvm";
open C_hack;
typeclass Value[t] {
virtual proc dump: cptr[t];
}
module Type {
requires header "#include ";
type t = "::
I'm binding the llvm libraries to felix, and I think I've run into a
typeclass bug. This is compiles through felix fine, but errors out at
the c++ compilation:
//
requires package "llvm";
open C_hack;
typeclass Value[t] {
virtual proc dump: cptr[
Erick Tryzelaar wrote:
> Thats good to know. We probably should then change all the binaries to
> have --inline=0 or below be converted to --inline=1? If you haven't
> started doing this, I can if you'd like.
>
I added this to subversion, but the email hasn't come out yet for some
reason.
-
skaller wrote:
> Turning off inlining is not allowed any more :)
>
> You can reduce inlining to low value, but not turn it off.
> 0 is equivalent to off.
>
Thats good to know. We probably should then change all the binaries to
have --inline=0 or below be converted to --inline=1? If you haven'
On Sun, 2007-03-25 at 20:54 -0700, Erick Tryzelaar wrote:
> Here's a new one:
> > ./flx -I. --force --inline=0 foo2.flx
Turning off inlining is not allowed any more :)
You can reduce inlining to low value, but not turn it off.
0 is equivalent to off.
> CLIENT ERROR
> Virtual call of 5115 dispa
Here's a new one:
#import
typeclass Show2[T] {
virtual fun str2: T -> string;
virtual fun repr2 (t:T) : string => str2 t;
}
instance Show2[bool] {
fun str2 (x:bool) => "foo";
}
open Show2[bool];
print $ "repr: " + (repr2 true); endl;
Errors out with:
> ./flx -I. --force --inline=0 fo
13 matches
Mail list logo
