Converting TickZOOM Engine to C++? Support C++,Java,& C#?

Quote from Pippi436:

What i don't like is that your project still takes a different direction every week. If this continues, how could i invest work either for personal purposes or contributing something if i don't know whats the situation a week/month from now when your next idea comes up that turns things around again? You need a plan, and stick to it in my opinion. It just doesn't instill much confidence if the project-leader changes language a few days before wanting to going public. With a tool that doesn't exist yet. To a language you didn't use since 10 years.

I don't want to come across as negative, i still think the basic idea is very good, but i am a bit skeptical about the endless zig-zag. Hopefully i will be surprised in the end tho.

Regrads,
P.
More...

Believe me, I feel like a yo yo too. I *think* this is a more solid plan now.

Wayne
 
That’s a good point. I also believe that it is difficult to change the programming language that short time before release of the first version. I follow the way Wayne takes all the time and think it is a very good base to start. A lot of ideas and a good license base – that should be OK and really a good base. So now that everything seems to be fixed it is not a good idea to change things just before release date. I have had the same problems long time ago and decided not to go ‘Open Source’ – anyway the app is free for everyone. Maybe not the best solution, but the best way for me to go. I also develop in C++ and know that it will take much longer to develop that anything in C# or Java – and for me it is the only way to go since I’m only good in C++.

Just my 2 cents,
Daniel
 
Quote from TrailingStop3:

That�s a good point. I also believe that it is difficult to change the programming language that short time before release of the first version. I follow the way Wayne takes all the time and think it is a very good base to start. A lot of ideas and a good license base � that should be OK and really a good base. So now that everything seems to be fixed it is not a good idea to change things just before release date. I have had the same problems long time ago and decided not to go �Open Source� � anyway the app is free for everyone. Maybe not the best solution, but the best way for me to go. I also develop in C++ and know that it will take much longer to develop that anything in C# or Java � and for me it is the only way to go since I�m only good in C++.

Just my 2 cents,
Daniel
More...


FYI, Daniel, did you see my post about SWIG? It's very cool. Does automated interfacing to those other languages.

I'm checking on a strategy for it to call back out to C# (or Java). Not quite there but I think so.

I hope you're mistaken about the time it might take.

I've done a lot of porting in times past.

In my experience automated translators like I'm using make it take only a fraction of the time otherwise.

We'll see.

Hey, sorry, but I have bored too many people talking about licensing. You can pm or email me (email at tickzoom.org) if you want on that topic.

Sincerely,
Wayne
 
Folks, I figured it out. It's actually pretty easy.

In fact, I realized that my MB Trading interface via COM does this already.

Basically COM interops almost seamlessly with C#.

So a C# object can implement a COM interface and then get passed into the COM DLL engine.

Anyway, I can figure this out.

For Java it works similarly with SWIG although Java doesn't need to use COM.

Hmmm I wonder how Mono handles COM on linux.

But if the engine is released as a C++ shared library with an API (and Java classes).

The people will probably use it directly with C++ or Java without bothering with mono on Linux?

I know it's techie stuff but some people do care about these details.

Wayne
 
Hey, this is cool. It shows how COM can be used on Linux with Mono and C# via the libcom.

http://linux.lsdev.sil.org/blog/?cat=10

So, in theory a person could write C# code on Windows and then run it on the engine in Linux without code change.

If not they can just deploy to Windows or else use Java or C++.

But I just wanted to make sure there was a path for those things.

So the plan and design and initial trial are done. Converting the engine will begin in earnest tomorrow evening. Hopefull be done by the end of the weekend.

If the regression testing all works (who knows?) then it will be finished and bug free.

Or I might get stuck resolve issue for a while longer.

We'll see.

I'm open to any advice on these technical issues. Or the direction.

But I think it fits the technical direction everyone has been recommending.

It's kind of cool that I have experience professionally working with COM, C++, Java, and C# otherwise, this would be a monster undertaking.

Wayne
 
Hi Wayne,

Yes I saw you post about SWIG, but to be honest I do not think that it is a good idea to change the programming languages and using only a utility to make this change. I would be afraid that I run into much more problems than I have before I go this way. Nobody would care if TickZOOM is that fast in the first release, but there will be some people are disappointed if you delay the release because of the change in the programming language. And belief me: C++ is not that simple and will have surely a surprise for you to spend your time with.
Anyway I run into most of these problems myself with my project in the past – but that will not mean that you have to make the same mistakes. I wish you the best with TickZOOM. Most of what I read sounds really good – so continue your work! If I would have more time left I would be happy to help. But working all day and after that developing my project need all my time (and the family need their share as well!) ;(

Daniel
 
Hey, can you imagine that making the engine into a COM DLL will provide awesome power to anything that uses COM?

That applies to Excel, VB, and just about anything Microsoft related.

Making it seamlessly work as classes in Java will offer the same kind of power there.

Of course the C++ folks can use it natively.

Maybe we should do the same kind of thing with other components over time like the charts, or the TickReader, etc.

Anyway, only the engine for now.


Wayne
 
Quote from greaterreturn:

But if the engine is released as a C++ shared library with an API (and Java classes).

The people will probably use it directly with C++ or Java without bothering with mono on Linux?

I know it's techie stuff but some people do care about these details.

Wayne
More...
If you provide me a documented API, I'll use that either from Java (likely) or C++ if I feel like learning that.

It's "techie stuff" but this is a product geared at techies AFAICT so those of us who are interested in the project will be interested in this sort of information. Actually this is sort of the meat and potatoes of what we need to know.

- Andrew.
 
Quote from anonymous:

If you provide me a documented API, I'll use that either from Java (likely) or C++ if I feel like learning that.

It's "techie stuff" but this is a product geared at techies AFAICT so those of us who are interested in the project will be interested in this sort of information. Actually this is sort of the meat and potatoes of what we need to know.

- Andrew.
More...

Sure. I was just thinking that once it's available via Java classes, the engine still needs tick data.

So to run the engine you have to pass one end of a TickQueue object.

The other end (in C#) comes from the TickReader.

So in Java all you'll have is the engine and need to create a TickReader.

But, well, the TickReader is only about 20 lines it just opens the file.

The KEY will be to reimplement the TickImpl object for Java.

Then you can read ticks, pass them to the engine for processing.

You know what? It would damage performace significantly to leave the Tick object marshalled from Java or C#.

I wasn't planning it but I'll have to convert the Tick object and TickReader to c++ also.

That way you pass the TickObject a binary buffer for it to parse into itself.

And it also produces a binary buffer for you to write to a file.

Yes. That will be necessary.

Thanks for making me think about this.

I believe strongly in "design" or thinking it through before coding.

That save oodles of time from re-coding rather than realize later you didn't think of something.

Wayne
 
What about other side - I mean the engine calling the custom strategy code which is still written in C# ? Are there any such calls?

What's your estimation of the performance penalty payed ? Is it still worth the effort from performance POV ?
 
You must log in or register to reply here.
Back
Top