-The outlets bound in Gorm are nil rather than referencing the
objects
they should. (However, actions bound in Gorm work - selecting a menu
item runs the connected Smalltalk method.)
I added a small sample app, GormSmalltalkSample in my branches
directory which shows the problem.
I'm not sure why this should be. I am not sure how you connected the
outlets though - GORM usually needs to have a header file to find
outlets. Can you CC this to Gregory and ask him to have a look?
For now, the easiest thing to do with classes you need to use in Gorm
is to create the class in ObjC with no methods, and write a category
in Smalltalk that implements the methods. This way Gorm has a header
file it can parse.
Working now! (In Smalltalk, one step of passing ivar information to
the backend was missing.)
You can do all of the setup in Gorm - in the Class menu, subclass,
say, NSObject, then add
outlets/actions with the inspector pane. It's handy if you don't feel
like making a header file :)
-Calling ETSerializer serializerWithBackend: nil forURL: nil. gives
an error:
Melodie: CodeGenModule.cpp:210: llvm::Value*
CodeGenModule::Unbox(llvm::IRBuilder*, llvm::Function*, llvm::Value*,
const char*): Assertion `false && "Unable to transmogriy object to
compound type"' failed.
Aborted
It looks like the Class type isn't handled in that switch statement
in
CodeGenModule.
Ah, this is my bug. I don't handle classes at all in the type
encoding. In Smalltalk (and, in fact, in ObjC, to a large degree),
classes are just objects, so I didn't add cases for them. Should be
fixed now.
Seems to work now. Thanks.
There are a few things that would be nice to have, but I can proably
get Melodie working without:
- access self from within a block. You can work around by assigning
self to a local variable outside the block, and using that.
This is something that should be working, but I forgot about in the
middle of implementing. Self is always the first bound variable in
blocks so that it can be used for access to instance variables.
- subclassing classes you define in the same smalltalk file
This is difficult, since a lot of the semantic checking currently
works by introspecting the runtime. I'd have to add a lot of special
cases for it to work, and I'm not really in favour of doing it since
it encourages bad code. It's cleaner if each of your classes is in a
separate file. Each file will be compiled separately, so you can
subclass classes declared in other files easily.
Sounds fine.
- defining class methods/variables
Supported in CodeGen, but not in the parser. I'm not sure the best
syntax for this - the GST syntax looks really ugly to me - so
suggestions are welcome.
- calling class methods from inside a block
e.g. 1 ifTrue: [NSObject new.]. doesn't compile.
That's a bug. It actually seems to be a symptom of the same bug that
prevented self working. Fixed now.
Nice, it works for me too.
Thanks! If any of these would be pretty simple to fix with some tips
on what to do, I would be happy to try.
Adding stuff to the parser is easy - the grammar is defined in
smalltalk.y (Lemon source). The AST is defined in the .m files, with
an ObjC class for each AST node type. The .cpp files are all related
to LLVM code generation, and are pretty ugly (they're not too bad by C
++ standards, but that's not saying much - I've never met anyone who
can write really elegant code in C++).
Eric
p.s. The NSRange example still doesn't work :( I updated llvm+clang
and Smalltalk a minute ago, and did make clean's.
2008-08-10 17:12:58.873 st[3637] Creating range from 0 to 9
2008-08-10 17:12:58.879 st[3637] Created Range: 0, 9
2008-08-10 17:12:58.882 st[3637] Create range:
2008-08-10 17:12:58.902 st[3637] {location=0, length=9}
st: Uncaught exception NSRangeException, reason: in
substringWithRange:, range { 136633408, 1900770 } extends beyond size
(26)
This is exactly the error I used to see on FreeBSD. It's a bug in
supporting the platform ABI, which means it's LLVM's fault. I'll try
to put together a simple test case and file an LLVM bug soon (if you
feel like writing some LLVM IR, you can too - just write a simple
program that calls a function that returns a structure and then
passes a structure as an argument, and write these functions in C and
compile them with your platform compiler).
Thanks again for the quick fixes! I'll have a look at making a test
case for the LLVM bug.
I committed my first attempt at Smalltalk Melodie. It's not quite
usable yet; I have to work on a few things, but it's a start :)
-Eric
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
