REAL Software

Having the IDE help make the marshaling of data be...

2010-03-19T17:28:23.955-05:00

Having the IDE help make the marshaling of data between the main and helper would be good (this is the API between the two and the act of sending and receiving the data between the two)

It's pretty much what Mars wrote in the post I mentioned.

Certainly not trivial - and it is possible for a person to do this manually at the moment. Doing it in a safe generic way in the IDE so you don't have to work so hard to set it up is a great goal - and a ton of work :)

Norm you said: "Global" and "shared" are part of t...

2010-03-19T12:33:06.365-05:00

Norm you said:
"Global" and "shared" are part of the problems this approach avoids.
----

I'm sorry I don't know the 'right' terminology but lacking a formal computer science background i don't know how to use the right terms.

I mean shared effectively but not in a simple concrete manor.

Global classes meaning having the same definition and that enabling the creation of a mechanism in the language to send instance data of such a global class between helper apps and create a clone of it in the receiving app.

Basically I'm saying are the components of the 'superproject' defines the API between helper apps in a way that is more familiar to most Rb users and takes most of the drugery out of it. making it more accessible.

[quote]
Other processes would be insulated from changes to the data while the process was working, they'd not be able to read old data while the transaction was in progress, etc
[/quote]

I really do think you misread (my fault) the meaning behind what i said. I think i realize the issues in principle and I was not proposing anything different in principle, just in API to make it easier, faster and more approachable to most who are used to writing single apps.

Having the IDE and the language better help us to create, organize and code the architecture of multi-app (main/helper) projects with specific user friendly support would give a huge boost to RB's PERCEIVED power and RADness by many.

- Karen

@Aitch748 if you compile all the helpers ass con...

2010-03-18T22:43:42.513-05:00

@Aitch748
if you compile all the helpers ass console apps with the same version of REALbasic then, for some platforms, its quite possible you can have only a single copy of the dylib / dll.
Console apps are organized slightly differently than GUI apps.

@Karen
"Global" and "shared" are part of the problems this approach avoids.

Making it so processes have to use a very well defined API to share data back and forth is actually a good thing.
In fact a nice design would be to make it so that passing data back and forth was much like a database where you had to start transactions, do work, and then commit / rollback any changes.
Other processes would be insulated from changes to the data while the process was working, they'd not be able to read old data while the transaction was in progress, etc
I'd encourage you to read http://www.redecho.org/2008/12/16/concurrency/ and the related paper from Sun that is mentioned.

Having not done this myself, a perhaps naive seed ...

2010-03-18T16:17:57.609-05:00

Having not done this myself, a perhaps naive seed of an idea occurs to me.

One thing that would help to encourage this type of architecture and increase the power of B would be to have RB build in more high level support for it.

Think of such an architecture supported in the IDE being able to be defined as "super project" where the main app and helper apps are "sub projects" which compile to separate apps in the same folder (or bundle on the mac) using the same libraries.

In the super project. Allow some "super global" classes, constants (and maybe properties) to be defined common to all sub projects.

Then provide language support for sending and receiving copies of instances o these classes between the helper apps, without is having to worry about serialization or communication protocols. ( that support would be why they would be different from external classes included in totally separate projects)

If super global properties are supported. put a transparent mechanism in to safely read and write them .

There are probably other things that would be useful but I can't think of any right now

While this would nor provide anything we could do ourselves (except using the same libraries). this would make using the helper app approach to use multiple core a lot more accessible to more RB users.

- Karen

The downside of this, at least until you get LLVM ...

2010-03-18T07:56:54.553-05:00

The downside of this, at least until you get LLVM baked into REAL Studio, is that each executable has its own copy of the complete framework, so each console app is around a megabyte-and-a-half in size.

Might REAL Software consider a compiler option to compile the framework as a DLL called by each of your executables for a setup like this? (That would save disk space, though I don't know if each program would still require its own copy of the DLL within its process space.)

This approach would also move your architecture to...

2010-03-17T15:29:39.442-05:00

This approach would also move your architecture towards a model-view-controller -design which probably won't hurt anyway.

We've been using this technique to utilize multipl...

2010-03-17T15:08:54.055-05:00

We've been using this technique to utilize multiple cores for over a year now and it works quite well. What's really nice is that it scales to many CPUs if the child processes are designed appropriately.

I think you might be mistaken. I have received no...

2010-03-17T14:22:57.680-05:00

I think you might be mistaken. I have received no such request but he does have a current license.

Maybe REAL Software should take your advice. A few...

2010-03-17T14:19:21.542-05:00

Maybe REAL Software should take your advice. A few weeks ago, Bryan Lunduke said in his live video stream that when he requested a review copy of REAL Studio, he couldn't get one.

Hi Geoff, I really appreciate your comment. It's ...

2010-03-13T18:10:45.763-06:00

Hi Geoff,

I really appreciate your comment. It's very interesting what you say and it's very interesting to have direct communication with the CEO of RealSoft.

- If shared libraries and DLLs can be done in pure RB, I expect as wonderful success not only to developers, but to you. The fast development and easy of use of RB will make a programmer's dream. IMHO, I will prioritize this as much as possible. We need urgently to have as much 3rd party classes to avoid reinventing the wheel as much as possible. And that means money to 3rd parties. Kudos if it can be done soon.

- I Agree with you about the inherent OS limitations of thread safe code. In my projects, I use Client / Server approach done with console projects that communicates with GUI via IPC, JSON, XML, etc.. Most server software I see is written in Java, Python, and other not native code compiled language. A few in C++ following the same approach (I am writting a MMORPG solution in RB). CriticalSections and Mutex are needed, but surely you can get some clever way to aid the developer in avoiding deadlocks. Your team is smart to make it easier... I guess debugging would need to be improved, but it would be a perfect solution for this kind of applications IMHO.

- RBScript is not what I would define an scripting language, since we can not call objects directly outside it. In my opinion it should be deprecated in favor of an open scripting language that is not so based in RB, if DLLs and Shared Libraries are finally a dream come true. Customers could use their skills on these scripting languages to customize our applications. Apart that RBScript has been something not very clear to me, and quite limited.

I appreciate your comment and willing to contribute with ideas and feedback to RealSoftware. If my MMORPG server can be done in RB and not just prototype it, I will keep some ancient C++ dinosaurs mouths...

Kind Regards!

LLVM will help us to be able to build shared libra...

2010-03-13T09:46:24.541-06:00

LLVM will help us to be able to build shared libraries, DLLs and plug-ins but it's not the only piece to that puzzle. But I agree with you that if you could create plug-ins, it would greatly expand the 3rd party market.

As for pre-emptive threads, that's complex. Any part of your code that does anything related to UI will not ever be thread safe. That's an OS issue, not a REAL Studio issue. So the best we can do is work to make the rest of the framework thread safe but then users would have to some how be made aware when they attempted to use something that is not thread safe. Additionally, there are lots of things you must be careful about in your own code when using threads. What people want is to write their code the normal way and just have it work in a pre-emptive thread but that's not how it works in any language. For example, you can't go changing a property value in a pre-emptive thread the way you do in a regular code because some other part of your code could also be running and attempting to do the same thing. So there's a lot more to think about.

Regarding LUA or any other scripting language, LLVM does not help with that at all. The front end of the compiler is what makes the REALbasic language possible so supporting LUA would require writing another front-end to our compiler. The question is, what would you gain from that?

Clever move and hopefully will attract lots of new...

2010-03-12T21:09:03.802-06:00

Clever move and hopefully will attract lots of new customers. Just three things I am really dying, and would like to know if with LLVM can be done with RealStudio.

- DLL / Shared Libraries written in RS?
- Preemptive Threads (Make RS console safe 100%)
- Use LUA or other scripting language with Objects?

IMHO, what RS lacks are 3rd party libraries written in comparisson with the rest of compilers. With a faster a reduced code size, and these features... I see a long long future to RealSoftware.

The goal is not to take a desktop app and run it o...

2010-03-12T11:07:41.387-06:00

The goal is not to take a desktop app and run it on an iPhone. The goal is to provide developers with a way to build iPhone apps as quickly and as easily as they can build desktop apps today and use the skills they already have to do that.

The issue with iPhone is not just the processor su...

2010-03-12T10:27:36.080-06:00

The issue with iPhone is not just the processor support but also all the differences in API and controls used. I find it challenging to even think about a desktop app that would run on iphone as well.

The speed and optimization is very much welcomed by the game developers, combined with the current OpenGL support. I assume LLVM will also make it easier (or possible) to truly utilize GPUs and other DSP chips. If the LLVM works with Cray it should be ok for rest of us as well...

I guess better late than never.

2010-03-07T16:55:20.009-06:00

I guess better late than never.

Awesome news! This is what RB users have wanted f...

2010-03-06T20:32:35.599-06:00

Awesome news! This is what RB users have wanted for a long time and now it is finally taking shape. Thanks!

Great news for 2011!. Cocoa and single executable ...

2010-03-04T18:29:09.161-06:00

Great news for 2011!. Cocoa and single executable are very expected. After that will be a seamless controls pallete beyond the native ones. Something that guarantees that a button, a radio button, a scroll bar, a text box, etc, the entire UI design, will look the same as planned on all platforms. I really wish a write once, run everywhere without changes paradigm.

Thanks for answering my question, to my layman's e...

2010-03-03T17:14:08.871-06:00

Thanks for answering my question,
to my layman's eyes at least, it looks like a great move.

They are not. We had some performance problems aft...

2010-03-03T12:05:23.097-06:00

They are not. We had some performance problems after we made them available to everyone. However, we are working on those issues and should be able to make them available again soon.

I still cant get the on-line docs from http://docs...

2010-03-03T11:55:12.185-06:00

I still cant get the on-line docs from http://docs.realsoftware.com - is there any more news?

I wouldn't say in the near future (if by near futu...

2010-03-03T08:58:21.169-06:00

I wouldn't say in the near future (if by near future you mean, this year) however, it is another step towards supporting smartphones in general.

Does this mean that iphone apps developed with RB ...

2010-03-03T08:21:00.311-06:00

Does this mean that iphone apps developed with RB are in the near future??? This would be great and negate having to learn Objective C.

We will only have to support one platform for the ...

2010-03-02T16:23:59.964-06:00

We will only have to support one platform for the compiler (that platform being LLVM) however, we will still have to support 3 platforms for the framework (Mac OS X, Windows and Linux) which is a much bigger job. And for the compiler, it's really just 2 platforms (PowerPC and x86) though their are 3 different linkers (one for each OS).

The only downside is that it's a lot of work to make this change but once made, there are a lot of benefits.

So REAL will only have to support one platform rat...

2010-03-02T16:20:19.107-06:00

So REAL will only have to support one platform rather than the current 3 and yet users of RB will be able to target more platforms than ever with higher quality code.

Are there any downsides to this?

Now THIS is exciting news. If I have a complaint a...

2010-03-02T12:13:26.629-06:00

Now THIS is exciting news. If I have a complaint about REALbasic, it isn't that it doesn't support Cocoa yet, but that the apps it compiles are so huge in comparison with similar apps built with other development tools (particularly when the apps don't do very much).

Smaller and faster are definitely better.