search for: tart

On Jul 25, 2011, at 10:58 PM, Talin wrote: > To handle the fact that types do not (and can not, at least as long as we intend to support obscure languages like "C" :) have linkage, the the linker uses a "best effort" approach. It attempts to merge types and rewrite IR to use the merged types where it can, but it doesn't make any guarantees. > > I want to add an

...ow, we discussed a similar problem on this list earlier, and it was stated that the cause was due to calls to llvm.gcroot() not being in the first block. However, that's not the case this time - here's the function being processed (according to I.Parent.Parent->dump()): define internal %tart.core.Object* @"tart.core.Object.coerce[int32](int32)->tart.core.Object"(i32 %value) gc "tart-gc" { prologue: call void @llvm.dbg.declare(metadata !{i32 %value}, metadata !48487) %gc_root = alloca %"tart.core.ValueRef[char]"*, !dbg !48488 store %"tart.core...

...migrate to Postfix/Dovecot mbox and later worry about migrating to maildir (as suggested on the Dovecot wiki mailbox format page). I have configured private (also as default) and public namespaces with the public mailboxes stored in /var/mail/public. /var/mail/public has rwxrws--- and is group tarts (the shared "company" group for this server). Initially I had procmail configured via the mailbox_command. Initial test mail sent to user tarts triggered creation of /var/mail/tarts with 660 permissions as expected. I then changed the configuration to use deliver via the mailbox_com...

Could someone verify if 1) sieve can fileinto shared public mbox? 2) if it can, what I might be doing wrong? I am getting errors in the log when I try to have sieve fileinto a shared public mbox. 11/04/10 06:08:12 pm n3 dovecot deliver(tarts): sieve: msgid=<201011050108.oA5187sm003711 at JaySmith.com>: failed to store into mailbox 'public/SPAM/SPAMMM': Mailbox doesn't exist: public/SPAM/SPAMMM 11/04/10 06:08:12 pm n3 dovecot deliver(tarts): sieve: execution of script /home/tarts/.dovecot.sieve failed,...

...ome more, and the DIEs don't look valid to me. Take a look at this output from dwarfdump -v: > > 0x000000c7: TAG_subprogram [3] > 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" ) > 0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] = "tart.reflect.Parameter.construct(tart.core.String)" ) > 0x000000d0: AT_decl_file( 0x3d ( "/Users/talin/Projects/tart/trunk/lib/std/tart/reflect/Parameter.tart" ) ) > 0x000000d1: AT_decl_line( 0x0d ( 13 ) ) > 0x000000d2: AT_type( cu + 0x00000066 => {0x00000103} (...

...hile due to a number of unexpected circumstances, including a hard drive failure on my primary desktop machine. However, the good news is that after 4 years of work, my LLVM-based compiler is nearing the state where I feel comfortable declaring an official 0.1 release. The language is called "Tart" and the one line summary is "Tart is to C++ as Python is to Perl". There's no one big idea that defines Tart, instead there are hundreds of little ideas, mostly inspired by other languages such as C#, Python, Scala, and many more. It's intention is to be a general-purpose, s...

...nction and the others like it basically call llvm::ConstantExpr::getSizeOf() and then multiple the result by 8. Looking at the generated IR, I can see that the expressions look correct to me (I've added some line breaks for clarity): !15 = metadata !{i32 589826, metadata !2, metadata !"tart.core.Object", metadata !12, i32 9, i64 mul (i64 ptrtoint (%tart.core.Object* getelementptr (%tart.core.Object* null, i32 1) to i64), i64 8), i6 4 mul (i64 ptrtoint (%tart.core.Object* getelementptr ({ i1, %tart.core.Object }* null, i64 0, i32 1) to i64), i64 8), i64 0, i32 0,...

...Allocator (this=0x1016e48a8) at /Users/talin/Projects/llvm/lib/Support/Allocator.cpp:29 #3 0x0000000100f3f095 in llvm::BumpPtrAllocator::~BumpPtrAllocator (this=0x1016e48a8) at /Users/talin/Projects/llvm/lib/Support/Allocator.cpp:28 #4 0x00000001000aeb3a in llvm::StringMap<llvm::SmallVector<tart::Defn*, 4u>, llvm::BumpPtrAllocator>::~StringMap (this=0x1016e4890) at StringMap.h:406 #5 0x00000001000aeaa5 in llvm::StringMap<llvm::SmallVector<tart::Defn*, 4u>, llvm::BumpPtrAllocator>::~StringMap (this=0x1016e4890) at StringMap.h:403 #6 0x00000001000aea7c in tart::SymbolTabl...

...the others like it basically call llvm::ConstantExpr::getSizeOf() and then multiple the result by 8. Looking at the generated IR, I can see that the expressions look correct to me (I've added some line breaks for clarity): > > !15 = metadata !{i32 589826, metadata !2, metadata !"tart.core.Object", metadata !12, i32 9, > i64 mul (i64 ptrtoint (%tart.core.Object* getelementptr (%tart.core.Object* null, i32 1) to i64), i64 8), This does not work. The DebugInfo accessors uses getSizeInBits() to get an integer for the size. You will have to modify it to get the value...

Interestingly, I also get a similar error in a different executable (my unittest): pure virtual method called terminate called without an active exception 0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53 1 tartc 0x00000001010a88cc SignalHandler(int) + 364 2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26 3 libSystem.B.dylib 0x7261742e65637365 _sigtramp + 3796906437 4 libstdc++.6.dylib 0x00007fff878da5d2 __tcf_0 + 0 5 l...

On Sat, Aug 28, 2010 at 4:05 PM, Talin <viridia at gmail.com> wrote: > On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: > >> >> On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: >> >>> I recently started getting this error when I try to debug my >>> LLVM-compiled program in GDB: >>> >>> Dwarf Error: Cannot find DIE at 0x16769 referenced from DIE at >>> 0x1713c [in module >>> /home/talin/Projects/tart/build-eclipse/test/stdlib/ReflectionTest] >&g...

...ke it basically call > llvm::ConstantExpr::getSizeOf() and then multiple the result by 8. Looking > at the generated IR, I can see that the expressions look correct to me (I've > added some line breaks for clarity): > > !15 = metadata !{i32 589826, metadata !2, metadata !"tart.core.Object", > metadata !12, i32 9, > i64 mul (i64 ptrtoint (%tart.core.Object* getelementptr > (%tart.core.Object* null, i32 1) to i64), i64 8), > > > > This does not work. The DebugInfo accessors uses getSizeInBits() to get an > integer for the size. You will h...

...39;ve spent the better part of a day trying to figure out why my generated assembly code isn't correct. Here is the IR code for my loop: loopbody2: ; preds = %test1 %i14 = load i32* %i5 ; <i32> [#uses=1] %get15 = call %tart.core.String* @"tart.core.Array[tart.core.String]..index.get(int)->tart.core.String"(%"tart.core.Array[tart.core.String]"* %s, i32 %i14) ; <%tart.core.String*> [#uses=3] %src.data = getelementptr %tart.core.String* %get15, i32 0, i32 4 ; <[0 x i8]*> [#uses=1] %...

On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: > > On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: > >> I recently started getting this error when I try to debug my LLVM-compiled >> program in GDB: >> >> Dwarf Error: Cannot find DIE at 0x16769 referenced from DIE at 0x1713c >> [in module >> /home/talin/Projects/tart/build-eclipse/test/stdlib/ReflectionTest] >> >> I'm...

...ell, I am much happier now that I understand about dsymutil, and can actually step through my program in gdb. However, there are still some issues that are puzzling me. 1) First off, the debugger appears to stop at odd points. The IR for my main function looks correct to me: define i32 @"main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"* %args) { entry: call void @llvm.dbg.func.start({ }* bitcast (%llvm.dbg.subprogram.type* @llvm.dbg.subprogram to { }*)) call void @llvm.dbg.stoppoint(i32 6, i32 22, { }* bitcast (%llvm.dbg.compile_unit.ty...

...ers like it basically call llvm::ConstantExpr::getSizeOf() and then multiple the result by 8. Looking at the generated IR, I can see that the expressions look correct to me (I've added some line breaks for clarity): >> >> !15 = metadata !{i32 589826, metadata !2, metadata !"tart.core.Object", metadata !12, i32 9, >> i64 mul (i64 ptrtoint (%tart.core.Object* getelementptr (%tart.core.Object* null, i32 1) to i64), i64 8), > > > This does not work. The DebugInfo accessors uses getSizeInBits() to get an integer for the size. You will have to modify...

On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > I recently updated my version of LLVM from revision 140108 to 142082, and > several things broke, most of which were easily fixed. However, I'm now > getting a "pure virtual method called" exception (__cxa_pure_virtual) which > I wasn't getting before. This is happening in the destructor of

I'm playing around with different combinations of LTO passes, and I've run into a strange problem: I have a 'main' function that looks like this: define i32 @"main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"* %args) { entry: call void @llvm.dbg.func.start(metadata !0) call void @llvm.dbg.stoppoint(i32 2, i32 19, metadata !1) %integerLimitsTest = call { } @integerLimitsTest() ; <{ }> [#uses=0] call v...

...e, and the DIEs don't look valid to > me. Take a look at this output from dwarfdump -v: > > 0x000000c7: TAG_subprogram [3] > 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" ) > 0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] = > "tart.reflect.Parameter.construct(tart.core.String)" ) > 0x000000d0: AT_decl_file( 0x3d ( > "/Users/talin/Projects/tart/trunk/lib/std/tart/reflect/Parameter.tart" ) ) > 0x000000d1: AT_decl_line( 0x0d ( 13 ) ) > 0x000000d2: AT_type( cu + 0x00000066 => {0x000001...

...en checking this out some more, and the DIEs don't look valid to me. Take a look at this output from dwarfdump -v: 0x000000c7: TAG_subprogram [3] 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" ) 0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] = "tart.reflect.Parameter.construct(tart.core.String)" ) 0x000000d0: AT_decl_file( 0x3d ( "/Users/talin/Projects/tart/trunk/lib/std/tart/reflect/Parameter.tart" ) ) 0x000000d1: AT_decl_line( 0x0d ( 13 ) ) 0x000000d2: AT_type( cu + 0x00000066 => {0x00000103} ( ) ) 0x000000d...