praveenvvstgy / crack-language Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/crack-language
License: Other
Automatically exported from code.google.com/p/crack-language
License: Other
What steps will reproduce the problem?
class Foo {
Foo open() {
return Foo(false);
}
oper init(bool openit) {
if (openit) open();
}
}
What is the expected output? What do you see instead?
No method exists matching Foo with these argument types.
---
This happens because oper init has not yet been defined. However, if we switch
the order, init will fail for a similar reason.
This is a real bug from Directory class, where init took an argument that
determined whether the directory should be opened and read on creation or not.
Original issue reported on code.google.com by weyrick
on 30 Jul 2010 at 2:31
Add C-style binary operators.
Original issue reported on code.google.com by [email protected]
on 11 Aug 2010 at 4:56
What steps will reproduce the problem?
1. run "class A : int {}"
What is the expected output?
nothing
What do you see instead?
lt-crack: /home/mmuller/pkg/llvm-2.7/include/llvm/Support/Casting.h:200: typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X = llvm::PointerType, Y = const llvm::Type*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 1 Jul 2010 at 5:38
(feature request)
E.g. running the hello.crk example, the compiler reports:
ParseError: hello.crk:4: No method exists matching puts with these argument
types.
It would be great if the error message mentioned what the argument types were.
Secondly, the compiler should report the available interfaces, e.g.:
Found:
crack.lang.puts(String)
crack.lang.puts(bytearray)
It would also be useful to know the line number of the file where the function
definition was found if possible.
Original issue reported on code.google.com by [email protected]
on 3 Oct 2010 at 1:48
As it stands, field (or instance variable) access gets special treatment from
the compiler: when we see a field access or assignment of the form "x.a" or
"x.a = b" a model object expression gets generate for the reference or the
assignment.
These should instead be represented as a FuncCall object derived from the
function "oper get <fieldname>" and "oper set <fieldname>". Switching to this
form will allow us to overload field accesses and also allow us to better
accommodate extensions (see Issue 49) by generating offsetting code to access
fields in native structures.
There should be no runtime cost associated with this for normal fields: in the
case of instance variables, these functions can be defined to do the same field
access code generation that they do now.
Original issue reported on code.google.com by [email protected]
on 20 Oct 2010 at 12:07
Get an initial version of the new template-based test suite (written in crack)
running. This will require:
* simple process management
* regex
* more string operations
* porting current tests to the template system
Original issue reported on code.google.com by weyrick
on 14 Sep 2010 at 7:44
Add the C-style ternary operator. As in C++, this should verify that both
operands can be converted to a common type.
Original issue reported on code.google.com by [email protected]
on 11 Aug 2010 at 4:58
We should support a Java-like for statement:
for (int i = 0; i < 100; ++i) ;
for (i :in range(1, 100)) ;
Iterator j;
Collection c = getCollection();
for (j in c) ;
Original issue reported on code.google.com by [email protected]
on 7 Oct 2010 at 10:54
What steps will reproduce the problem?
import crack.io cout;
x := 12345678902134;
cout `$x\n`;
What is the expected output? 12345678902134
What do you see instead? 1942893430
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 2 Sep 2010 at 12:22
At present, if you have a module "a" that imports a symbol "b", another module
can import "b" from module "a". This is dangerous. We should disallow these
kinds of second-order imports unless the imported symbol is explicitly exported
by the intermediate module.
Original issue reported on code.google.com by [email protected]
on 15 Sep 2010 at 2:57
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 10 Aug 2010 at 11:51
The extension library now allows you to compose crack classes and map them to
an underlying structure in C or C++. Unfortunately, this doesn't work very
well because the alignments used by the crack compiler and the C/C++ compiler
can vary.
We need a way to be able to fix alignment from both sides: on the crack side,
the extension library's addInstVar() method should be modified to provide an
offset and field accessors need to be able to accomodate operators so we can
generate field accesss instructions as references to these offsets.
On the C/C++ side, we need to be able to generate headers with the appropriate
padding that are platform/compiler/options specific - so an extension structure
can inherit from crack::ext::Object with the intended consequences.
Original issue reported on code.google.com by [email protected]
on 20 Oct 2010 at 11:56
What steps will reproduce the problem?
1. Compile crack and spug with GCC 4.4.2
What is the expected output? What do you see instead?
Successful compilation
What version of the product are you using? On what operating system?
Trunk on ArchLinux x86_64
I've written patches to make it compile correctly.
Original issue reported on code.google.com by [email protected]
on 28 Dec 2009 at 7:21
Attachments:
focusing on the root builder maintaining a list of modules and keeping llvm
specific functionality there.
Original issue reported on code.google.com by weyrick
on 13 Sep 2010 at 8:43
Hex and octal notation should be supported for constants:
i := 0xffffffff;
o := 0777;
Original issue reported on code.google.com by [email protected]
on 8 Sep 2010 at 2:27
What steps will reproduce the problem?
1. Run the script below. You'll get a seg-fault when you run out of stack.
int64 sum(int64 a, int64 b, int64 c, int64 d, int64 e, int64 f, int64 g,
int64 h, int64 i, int64 j, int64 k) {
return a + b + c + d + e + f + g + h + i + j + k;
}
void func() {
while (1 == 1) {
int64 a = 1, b = 2, c = 3, d = 4, e = 5, f = 6, g = 7, h = 8, i = 9,
j = 10, k = 11;
a = sum(a, b, c, d, e, f, g, h, i, j, k);
printint(int(a));
}
}
func();
Original issue reported on code.google.com by [email protected]
on 1 Jul 2010 at 5:24
It should be possible to write crack modules in C or C++. Such modules should
be of the form of shared libraries in the module trees. For example, on a
linux system, the file foo/bar/baz.so would be loaded as a result of "import
foo.bar.baz;".
The interface should be similar to that used for python: there should be a
module init function (preferably the mangled form of foo.bar.baz:init to match
the general module init routine). This function should accept some wrapper
around a Context object as input and should be able to register low-level C/C++
functions as crack functions and methods. It should also be able to create
classes and global variables.
Original issue reported on code.google.com by [email protected]
on 12 Sep 2010 at 4:28
What steps will reproduce the problem?
1. run "void foo(int a) { a = 100; }"
What is the expected output? What do you see instead?
Expect no output, we get an assertion error.
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 12 Jul 2010 at 6:45
What steps will reproduce the problem?
1. run this:
void outer() { int a; int inner() { return a; } }
What is the expected output?
Should get a parser error: referencing outer function scopes is not allowed yet.
What do you see instead?
LLVM errors during optimization.
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 1 Jul 2010 at 5:29
a ticket to track proposed enum support.
syntax:
enum myEnum { a = 0, b, c, d };
class MyClass {
enum myClassEnum { foo, bar, baz };
...
}
<mmuller> [13:48:50] yeah, I prefer having it stored as a plain old integer.
The thing is, the "convert to a string" case is compelling.
<mmuller> [13:49:22] maybe conversion is the way to go, here.
<mmuller> [13:49:55] if not from an object to an integer (which will make the
enums too heavyweight), maybe from an integer to an object.
<mmuller> [13:50:51] so for example, have "formatted(EnumString)" and specific
"oper to EnumString" operators created for each of the enum types
<mmuller> [13:50:59] sorry, "format(EnumString)"
<mmuller> [13:54:47] you know, I think this is actually a sort of "auto-boxing"
(like what new versions of java do)
<mmuller> [13:55:48] an eventual goal is for crack to do autoboxing through the
conversion mechanism, I think this is just a new case of it.
<mmuller> [13:56:52] and maybe "EnumWrapper" instead of "EnumString" so we can
potentially extend into other domains.
<mmuller> [14:06:22] so one snag in this is that for every primitive enum type,
there should be a corresponding high level type
<mmuller> [14:07:02] adding methods and instance variables within the enum
definition should extend that high level type
<mmuller> [14:09:04] but if you want to use the standard "writeTo()" method to
format them, you'll need to define new high level types as well as the
low-level ones
Original issue reported on code.google.com by weyrick
on 4 Aug 2010 at 2:26
Annotations needs a design doc. The basic idea is to allow extending the
compiler in the language. This is a small example:
# module myann
import crack.ann Context;
class PrimWrapper {
void process(Context ctx) {
wrapper := ctx.toker.getToken().getValue();
wrapped := ctx.toker.getToken().getValue();
ctx.toker `class $wrapper {
$wrapped val;
oper init($wrapped val0) : val = val0 {}
$wrapper oper +($wrapper other) {
return $wrapper(val + other.val);
}
}`;
}
}
primWrapper := PrimWrapper();
# main script
import myann primWrapper;
# create an integer wrapper class
@primWrapper Int int
Original issue reported on code.google.com by [email protected]
on 12 Sep 2010 at 4:19
This issue is currently obscured by issue 20.
What steps will reproduce the problem?
import crack.io cout;
int64 i = -1234567890123;
cout `$i\n`;
What is the expected output? -1234567890123
What do you see instead? -1912276171
Original issue reported on code.google.com by [email protected]
on 2 Sep 2010 at 12:30
Crack originally took the C++ approach on default initializers:
A a;
In the definition above, "a" is initialized with the default constructor,
making it equivalent to:
A a = {};
As it turns out, in most of the cases in the current code where we do default
initialization of objects, we want to initialize to null. We should accomodate
the most common case and use null as an initializer.
Original issue reported on code.google.com by [email protected]
on 18 Sep 2010 at 8:52
Something like this:
class BTreeMap[Key, Val] : Map[Key, Val] {
Val get(Key key) { ... }
Val oper []=(Key key, Val val){ ... }
};
m := BTreeMap[String, Int]();
m['test'] = 100; # assuming we get auto-boxing
Original issue reported on code.google.com by [email protected]
on 12 Sep 2010 at 2:53
We need a form of virtual inheritence:
class Writer : *Object, VTableBase {
uint write(String data) { die('not implemented'); }
}
Use of the "*Object" notation indidates that Writer has Object as a virtual
base class. This effectively renders Writer abstract - it can not be directly
instantiated, you have to derive from it by a class that is also
(non-virtually) derived from Object.
Given a Writer object, we can:
- upcast to object (a special function will be added to the vtable to be
implemented by the derived class which will do the upcast given its concrete
inheritence on Object)
- call any Object methods and access any Object attributes (by implicitly
upcasting)
Original issue reported on code.google.com by [email protected]
on 8 Sep 2010 at 2:39
If you try do do something like this:
class A {
oper init() {}
A clone() { return A(); }
}
it won't work because A::oper new doesn't get generated until the end of the
class body.
We need to generate 'oper new' immediately after 'oper init' is parsed (as long
as the user hasn't already defined their own 'oper new')
Original issue reported on code.google.com by [email protected]
on 1 Jul 2010 at 5:35
":=" currently only functions in a definition context. Make it usable in
expression context so we can do things like this:
foo(x := bar());
while (l := src.readLine()) ;
Original issue reported on code.google.com by [email protected]
on 7 Oct 2010 at 10:56
What steps will reproduce the problem?
1. Run "class A { void f() { StaticString(this.class.name); } }"
What is the expected output?
nothing
What do you see instead?
lt-crack: builder/LLVMBuilder.cc:549: void<unnamed>::BBuilderContextData::addPlaceholder(<unnamed>::PlaceholderInstruction*): Assertion `!complete && "Adding placeholder to a completed class"' failed.
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 1 Jul 2010 at 5:31
At this time, if you want to typecast an object to a derived class when the
object may legitimately not be an instance of the derived class, you have to do
this:
if (obj.class.isSubclass(DerivedClass))
derObj = DerivedClass.unsafeCast(obj);
The unsafeCast() avoids doing the check a second time in the cast() function.
In the interests of simplicity and of allowing users to avoid unsafe calls, we
need to introduce a flavor of cast() that does not abort (or throw an
exception, in the long term).
Current possibilities for this include:
Derived cast(Object object, Derived defaultValue);
# code above becomes
newObj = DerivedClass.cast(obj, null);
and:
Derived tryCast(Object object);
# code above becomes
newObj = DerivedClass.tryCast(obj);
Currently leaning towards the first form because it reduces the number of names
in the interface and allows us to use default values other than null (although
I currently can't think of a use-case for that).
Alternately, we could break compatibility and require a second boolean argument
indicating whether to abort/throw or return null.
Original issue reported on code.google.com by [email protected]
on 14 Sep 2010 at 10:49
What steps will reproduce the problem?
import crack.io cout;
float f = 1.0;
cout `float is $f\n`;
What is the expected output? 1.0
What do you see instead? true
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 5 Oct 2010 at 3:21
What steps will reproduce the problem?
import crack.io cout;
void a(uint64 v) {
while (v) {
cout `$v `;
v >>= 1;
}
}
a(4);
What is the expected output? 4 2 1 What do you see instead? 4 4 4 4 ...
Promotion of arguments from registers to allocas is happening in the context
where the argument is assigned: if that context is a loop we'll continually
alloca. The promotion needs to happen in the function's first block.
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 19 Oct 2010 at 10:48
import crack.io cout;
class A {
A other = null;
String name;
oper init(A other0, String name0) : other = other0, name = name0 {}
oper del() { cout `deleting $name\n`; }
}
A a = A(null, 'first');
a = A(a, 'second');
cout `done\n`;
Should print "done", "first" and "second". Instead, "first" gets cleaned up
during the assignment.
Cleanups for assignments need to happen after the value is bound.
Original issue reported on code.google.com by [email protected]
on 27 Jul 2010 at 3:11
(feature request)
It would be nice to have a shorthand for some default implementations of
commonly used types, String, Array and Map.
This can be implemented in a separate module so as to not weigh the runtime
down if not needed.
Maybe this can be done with operators, like
oper ""(ConstantString)
oper [](ConstantArray)
oper {}(ConstantRBMap)
Original issue reported on code.google.com by [email protected]
on 3 Oct 2010 at 1:55
Implement C-like forward declarations:
int a();
int b() { return a(); }
int a() { return 1; }
Original issue reported on code.google.com by [email protected]
on 30 Jul 2010 at 10:49
if imported items aren't used in a script, we should throw a warning
Original issue reported on code.google.com by weyrick
on 4 Aug 2010 at 2:14
The COPYING file contains the GPL, but the web site mentions the LGPL as the
project language.
This should probably be clarified.
Original issue reported on code.google.com by [email protected]
on 5 Oct 2010 at 5:50
What steps will reproduce the problem?
import crack.io cout;
class BaseOne {
void baseOne() { cout `BaseOne.baseOne\n`; }
}
class BaseTwo {
void baseTwo() { }
}
class Multer : BaseOne, BaseTwo {
}
b := BaseOne();
b.baseOne();BaseOne.baseOne
BaseOne.baseOne
m := Multer();
m.baseOne();
What is the expected output? What do you see instead?
expect:
BaseOne.baseOne
BaseOne.baseOne
instead:
BaseOne.baseOne
Segmentation fault
If the second base class for Multer is commented out, so that it only inherits
from BaseOne, it runs as expected.
Original issue reported on code.google.com by weyrick
on 7 Aug 2010 at 1:52
Currently only uints are allowed.
Original issue reported on code.google.com by [email protected]
on 8 Oct 2010 at 6:29
What steps will reproduce the problem?
int i=0; i=i+1;
gives:
token 1 was not expected at this time, expected semicolon or a block terminator
needs to parse as + operator, but is (probably) parsing as a literal. a space
makes it work:
int i=0; i=i+ 1;
Original issue reported on code.google.com by weyrick
on 8 Jul 2010 at 5:10
class A {
oper init(int val) {}
}
class B : A {} # should get its own oper init(int val)
We can only do this if all of the rest of the instance variables and base
classes have default constructors.
Original issue reported on code.google.com by [email protected]
on 12 Sep 2010 at 4:42
What steps will reproduce the problem?
class A { }
class B {
A a;
oper init(): a=5 { }
}
Output:
Bad IR is generated which fails LLVM moduleverification.
Notes:
There seems to be no type checking in the initializer lists.
Original issue reported on code.google.com by weyrick
on 1 Jul 2010 at 7:35
Introduce support for versioned libraries and crack binary in CMake.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
Original issue reported on code.google.com by weyrick
on 10 Sep 2010 at 3:28
class BadError : Exception {}
try {
throw BadError();
} catch (BadError ex) {
cerr `got a bad error: $ex\n`;
}
Original issue reported on code.google.com by [email protected]
on 12 Sep 2010 at 4:33
interpolates strings currently translate like this:
cout `a$(b)c`; --> if (cout) { cout.format('a'); cout.format(b); cout.format('c') }
Make them more like this:
cout ? (cout.enter(); cout.format('a'); cout.format(b); cout.format('c');
cout.leave()) : 0;
So in other words, provide enter() and leave() hooks, if the leave() hook
returns non-void let it be used as the value of the expression.
Original issue reported on code.google.com by [email protected]
on 12 Aug 2010 at 11:30
What steps will reproduce the problem?
import cout;
cout `test\
text`;
Should produce "testtext", not "test\ntext"
Original issue reported on code.google.com by [email protected]
on 31 Jul 2010 at 11:24
Right now, crack depends on spug++ by virtue of its use of 4 spug++ header
files. Remove this dependency by moving the files into the crack source tree.
Original issue reported on code.google.com by [email protected]
on 12 Aug 2010 at 1:15
What steps will reproduce the problem?
echo "float32 f; if (f);" | crack -
What is the expected output? nothing
What do you see instead?
crack: /home/mmuller/pkg/llvm-2.7/include/llvm/Instructions.h:635:
llvm::ICmpInst::ICmpInst(llvm::CmpInst::Predicate, llvm::Value*, llvm::Value*,
const llvm::Twine&): Assertion `(getOperand(0)->getType()->isIntOrIntVectorTy()
|| getOperand(0)->getType()->isPointerTy()) && "Invalid operand types for ICmp
instruction"' failed.
Original issue reported on code.google.com by [email protected]
on 31 Jul 2010 at 8:29
int and uint are currently aliases for either their 32 bit or 64 bit
counterparts. This causes problems because, for example, the code:
int i = int64(n);
... will compile successfully on a 64 bit platform but fail on a 32 bit
platform. int and uint should therefore be separate types where:
1) both are at least 32 bits.
2) both will allow implicit conversion to their 64 bit counterparts but not to
32 bit.
3) both will allow implicit conversion from their 32 bit counterparts but not
from 64 bit
Original issue reported on code.google.com by [email protected]
on 10 Jul 2010 at 10:00
Make the CMake and autoconf builds driven from common file lists.
Original issue reported on code.google.com by [email protected]
on 19 Jul 2010 at 1:51
Adding this to try out the new group.
Original issue reported on code.google.com by [email protected]
on 29 Jul 2010 at 11:07
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.