My Links
Post Categories
Archives
- May, 2008 (1)
- March, 2008 (3)
- February, 2008 (2)
- January, 2008 (1)
- November, 2007 (2)
- October, 2007 (3)
- August, 2007 (1)
- July, 2007 (10)
- June, 2007 (3)
- May, 2007 (7)
- April, 2007 (1)
- February, 2007 (1)
- January, 2007 (6)
- December, 2006 (2)
- November, 2006 (1)
- August, 2006 (1)
- July, 2006 (1)
- February, 2006 (1)
- January, 2006 (6)
- November, 2005 (1)
- October, 2005 (1)
- September, 2005 (1)
- August, 2005 (2)
- July, 2005 (2)
- May, 2005 (1)
- March, 2005 (7)
- February, 2005 (4)
- January, 2005 (2)
- December, 2004 (1)
- November, 2004 (1)
- October, 2004 (3)
- September, 2004 (2)
- August, 2004 (6)
- July, 2004 (2)
- June, 2004 (2)
- May, 2004 (4)
- April, 2004 (2)
- March, 2004 (3)
- November, 2003 (8)
- October, 2003 (13)
|
It seems the last post about the bringing swf and .Net together was a bit controversial (and confusing). First a few people wrote in thinking that this was a different C#>swf compiler than the one I was working on. To clarify, I work for Xamlon, same company Paul founded, so other than the fact that the new compiler is pretty much a complete rewrite, it is the same one : ). Just it is now a small part of something much bigger.
Second thing, it seems the statement "Flash Professionals can't (until now) use .NET" raised the ire of a few people. Well hey, tough world, but you couldn't. The argument was that you can use remoting to talk to a .Net application on the server, therefore Flash professionals could in fact use .Net. Well by that argument, Flash professionals could "use Linux" in Flash 2, getUrl("slashdot.org") et voila (err, I think they're using Linux, didn't check). What we are making isn't about talking with .Net applications, it arguably 'is' a .Net application. I think the best description is we are compiling .Net assemblies to swf instead of a target processor (the JIT step). So .Net languages, .Net tools, .Net workflow...The whole beauty of webservices and even remoting is you can make calls to platforms your environment knows nothing about. Given that, if a swf talking to a .Net webservice has anything to do with this conversation, pinch me now (that was pinch, not punch!).
Oh, and before some helpful soul pulls out the dictionary and looks up 'use' for me : )... The beauty of conversation is there is context, otherwise we would need to write a book to comment on the weather. It's actually kind of fun to pretend there isn't context sometimes -- even in real life. "Sure is a nice day, eh Frank?" "Define nice you lying bastard!". I tell you, it really cuts through that superficial small town atmosphere in a hurry ; ). For the record, we're aware of getUrl, and still are, but don't feel that counts. At least I don't.
Lastly, some people thought we weren't making components, or we hadn't started... they are actually quite far along, but by no means done. It is coming down to which will make it into V1 (not all of them will), but it certainly isn't something we are tacking on as an afterthought. I think beta 2 will give a better idea where we are at and heading, it's a pretty big leap from beta 1 at least...
posted on Tuesday, March 15, 2005 7:05 AM
Feedback
-
# RE: A Moment of Clarification
Posted @ 3/15/2005 12:26 PM
People sure get pissy when you make something thats a little too cool!
-
# A quesion about porting dlls
Posted @ 3/15/2005 12:56 PM
Hi Robin,
I'm really curious about this porting libraries and dlls concept.
What are the main limitations that one needs to keep in mind when thinking about this? Threads, ok. The player's networking interface, yes? What other limitations would we want to keep in mind when thinking about doing this?
For a concrete example. If I were to take a regular expression or xpath library and compile it, could I get performance that would come close to a native library or would it be more like I had implemented it in actionscript?
Thanks for your thoughts,
-Cort
-
# RE: A Moment of Clarification
Posted @ 3/15/2005 2:57 PM
Hey Cort,
Unfortunatly at that level we have no pixie dust : ). What happens is the dll gets parsed, and it's instructions get converted to swf action bytecode, much like what happens with actionscript. In fact for the most part, you can dump it into ASV and get useable actionscript. So what is slow in actionscript will still be slow in this.
We are working on an 'optimize' mode, which should be a fair bit faster (no names, everything runs off array indexes), but still within the realm of the flash player.
Other than that, the main limitation is you can't use the .Net framework, other than (a subset) of the base class libraries. So that does include things like threads and networking. Also we haven't finished the type system yet, so atm thing like if(x is Button)... won't work atm -- we will get there though. One other subtle difference with .Net C# is we aren't supporting structs as value types (we just treat them as classes, except for primitives). We could do this fairly easily, however it would result in the instances being larger and slower, due to all the cloning and parsing, which kind of defeats the purpose. If we thing of a good way around that we'll put it in for sure, but not so far.
One thing we've been mulling for this kind of thing, we do have a standalone player (a .Net wrapper for the activeX player), and are thinking of setting it up so when in stand alone mode, framework calls (like regex or xpath) could be intercepted and automatically passed out to the container. This could be done with server calls from the player too, though that wouldn't exactly be quick of course, but might be useful in some cases.
Thanks for your thoughts, that is an area I can't wait to explore once I get a chance to start using this for more than tests : ).
Robin
-
# RE: A Moment of Clarification
Posted @ 3/15/2005 4:18 PM
Thanks Robin,
I was going mad with curiosity there, but I suppose that had to be the case.
Still, it will be great just be able to use the nicer tools and syntax where speed isn't a problem. Our greatest job skill as programmers is an extreme tollerance for fustration, but my tollerance for developing in the Flash IDE went into the negative numbers years ago and I've just been hoping for better tools to come ever since.
Anyway, do well,
-Cort
-
# RE: A Moment of Clarification
Posted @ 3/15/2005 4:47 PM
As for new features of the upcoming player 8: How well is xamlon able to adopt them?
Ralf.
-
Posted @ 3/15/2005 4:50 PM
As far as i watched your work, (afaiwyw:) you are translating il to swf. Does that mean we are able to use any language, which supports .Net?
-
# RE: A Moment of Clarification
Posted @ 3/15/2005 5:10 PM
For the VM level, right now we are targeting FP6. This is mostly because we want to go to 5 or even 4 to support common mobile devices, and we want to go up too of course. So 6 is a nice balance with some register support, but still keeping you honest enough to 'down version'. As for 8, just from hearing about the speed jumps etc, it sounds like they will have a much better vm in there, so that would almost certainly be easier rather than harder. I think about half the compiler code is due to quirks and limitations with the F6 bytecode engine. If that was streamlined and upgraded it would make for some very clean gen code at least : ). And of course faster is always better!
For any added functionality to the internal api, that is a (fairly) simple matter of mapping it to stub classes. The harder ones there tend to be older ones, like GetUrl, where arguments are part of the tag rather than inside the vm system itself, or weird ones like Stage or Key, which have events but no prototype. I assume there won't be too many more of those -- or at least dearly hope not ; ).
The last thing, new features like better text, compositing, etc, should bring it more in line with what xaml can express, so that should make life easier too. Not sure what all features it will have, but things that are currently hard are when you get things like a gradient on an outline in xaml - either you do a LOT of math and gen contours, or you just skip it. It seems they are giving the render engine a good workover, so hopefully that will make (everyone's) life easier, including mine : ).
From what I've seen online, the Flash 8 player should totally rock, it will be pretty fun to target : ).
-
# RE: A Moment of Clarification
Posted @ 3/15/2005 5:25 PM
Right you are : ). The first compiler translated C# into swf, but now we are using IL. There are advantages to both, but the big one with IL is you get multi language support. That being said, each language after C# tends to come with a pretty large dll for things that don't map so well to IL. The VB dll isn't bad, so we have mapped what we need in there. For JScript though, if you look at how it is implemented, it is pretty much all calls into the dll. I assume that is mostly to support dynamic code execution, but whatever the reason it isn't really JS>IL (you could run that from C++ as easily as IL). We've looked at it though, and it might not too bad to map. Hard parts are things like when you get to the activation object level, that may be easier with FP7 though.
For other languages, I haven't had a chance to look... if they gen pure IL of course it is easy, but if they rely on a large framework, then it gets harder. I've heard languages like Eiffel needed a lot of glue to get things like multiple inheritance to work, so probably that one is out : ). I breifly looked at Python, but didn't get far enough to really have an idea idea, but that is one we'd really like to officially support.
|
|
Blog Stats
- Posts - 121
- Stories - 1
- Comments - 1441
- Trackbacks - 47
.Net Blogs
01101 Blogs
Flash Blogs
Graphics
People
|
|