Home > Delphi, JavaScript, Object Pascal, OP4JS, Smart Mobile Studio > Smart Data, working on it!

Smart Data, working on it!

Right! Its been two hell of a couple of weeks. I’m multi-tasking as best I can between:

  • Re-writing large parts of the VJL
  • Writing a book
  • Talking to key figures in the community
  • Presenting ideas and meeting with the Smart Pascal Consortium
  • Yoga and inner peace
  • Kids, GF and a snapping 3-level spinal injury
  • Not in that order

Whats on the table?

In short, a quantum leap. We have the technology but it’s all buried in unit files and the lack of documentation is just “enough”. So I have gotten to the stage where I will just deal with it come hell or high water.

I have had a little debate with David Berneda, owner and all-round super-coder over at Steema software about databases. He knows data since his components run on several platforms, under many different languages — so he was indeed the guy to talk to and get some inspiration.

The problem with data is threefold:

  • The pascal side of things
  • How data is dealt with in the JS community in general
  • Traditional access to data via nodeJS and native drivers

In effect Smart Mobile Studio needs to have a system that covers all these aspects. The pascal code (regardless of what is wrapped or underneath) should be, well, pascal. It should be directly readable, infinitely intuitive for Lazarus and Delphi programmers – but at the same time flexible and expose all the dynamic features JavaScript has (that Delphi doesnt).

A kid made $4 million on a flashlight app, a blank white screen written in Javascript. When Delphi finally got to Appstore, it was all over.

And no, I’m not out to get Delphi; A bit pissed at EMB for screwing over the community on iOS and Android (not to mention the pricing which is just ridicules), but still a loyal Spartan (!).

What I am trying to do, and in fact the whole SMS team, is to get your native Delphi products into places where Embarcadero cannot reach. To compliment Delphi and rejuvinate your skill-set which is being phased out due to the mistakes of EMB (and they did inherit a fair bit of mistakes from Borland so its not all their fault).

And JSVM is not on their to-do list, they are strictly native. Same with Remobjects. So SMS is the only one surfing on the JavaScript virtual machine.

Speaking of data

Then you have inter-operative functionality. Namely that you want your SMS applications talking to off-the-shelves JS solutions out there. If the data in SMS is to “Delphi” and we have to do conversion just to get Linq.js to chew it, then we have lost something.

This is what Linq (from C#) looks like under JavaScript (we can do better!). You can use Linq with SMS today, its actually childs-play to wrap it in a unit.

Linq.JS -- 1:1 identical with C# and the dot net framework -- and you can use this today in smart if you like

Linq.JS — 1:1 identical with C# and the dot net framework

Just look at that mess. Seriously, we can do better and make it worthy object pascal.

I want SMS programmers to just go “damn! this rocks! Now I can get my Delphi data running on my website, my phone, my embedded devices and whatever IOT comes next” without having to wait 2-3 years for Embarcadero to write yet-another-compiler.

Do you know why im so pissed at Embarcadero? Because they cheated us not once, but twice! First with the iPhone and then Android. By the time we got to code for these platforms the market was saturated. Every possible application was done and every concivable window of opportunity you may have had dead.

A kid made $4 million on a flashlight app, a blank white screen written in Javascript. When Delphi finally got to Appstore, it was all over.

And they did this not once, but twice! 

We just can’t have an infrastructure or programming language that takes 2 blody years to pivot. It’s just not acceptable. Freepascal was able to support iOS in what, 3 weeks? And even with stealing their codebase it took Embarcadero 2 years? And people ask “why JavaScript”. It should be considered a global intellectual emergency that a company can charge these prices.

Dude, Javascript has what — 20.000 commiters? Millions of active users and the amount of coders contributing to the runtime ranks in the tens of thousands (if not more). The V8 LLVM powered JSVM has seen more commits and improvements than Microsoft Windows. It is being payed for by Google, Apple and a whole range of Linux companies. JS is able to pivot on a dime and target a piece of hardware in less than an hour. Especially with the LLVM sub-strata. I also noticed a fork by Apple using Clang, so native languages and the desktop has an expiration date. Just saying..

Do you think we picked JSVM just for fun?

You have missed the rise of the full stack JavaScript developer, and its happening right now, while the desktop is being marginalized at rapid pace.

A whole new world

Did you know that JavaScript ranks #8 on the list of used languages in the world? Did you know that 50% (fifty percent!) of all the programs being written right now on this planet, is written in JavaScript? Just let that sink in for a moment.

There is a whole reality of IOT and business that Delphi developers are missing. Jobs thin on the ground? No. Not really. But if you limit yourself to only delivering pascal projects then sure. Add JavaScript to the list and see what happens.

This is a podcast I find quite interesting: https://javascriptair.com/

Any-ho, then, just when things are looking cosy and within grasp data-side, nodeJS and IO goes and adds support for native database plugins. You know, stuff that pretty much looks like what we already have in Lazarus and Delphi (although slightly perverted being javascript after all).

“Fine, I only have one bullet so your gonna have to share!”
-Source: Deadpool, the movie

For a taste of how RAW NodeJS DB connectivity looks like, have a taste of this. Not really elegant is it? So im going to make that puppy into easy to use, sexy, slick and (drumroll) object pascal style components.

Now, I'm about to do to you what Limp Bizkit did to music in the late 90s.

Now, I’m about to do to you what Limp Bizkit did to music in the late 90s.

I’m thinking MSSQL, MySQL, MariaDB and Oracle should be more than enough to get you started (server-side). We already have Remobjects SDK support and Datasnap, Websocket.. that should about cover it (when the docs are done).

mORMotsupport, finally!

Got in touch with Arnaud Bouchez over at Synopse, and we will finally add built-in support for mORMot. No time-table on that yet, but ill keep you posted as we move along. Arnaud has some great code and I am really looking forward to getting the IDE talking with their framework!

Also super tempted to have a stab at compiling his Spidermonkey fork of the Mozilla Javascript virtual machine, on ARM to see if we can get that linked and running under freepascal on the PI3. That would be awesome.

Non visual components

Yes, it’s finally in the RTL. Again, no time-table on the IDE changes but it’s now an actual part of the inheritance chain. TW3Widget is now the ancestor of TW3TagObj, so we keep the SmartCL namespace (document object model) away from the non-visual ancestor for now. But it’s there and working!

TAction and TActionManager

Yup. Done, tested and very sexy! Again no time-table on when we get this into the IDE, but from the VJL point of view you can now create actions and bind that to controls that supports it (in the traditional 1 action – many subscribers). That is something i have missed!

Tweening and software animation

We already have GPU animations and control under wraps, thats been there for quite some time now (smartcl.effects.pas), but tweening gives you better control and for desktop applications it can be a better option. And it’s there. Hopefully we can get a visual aid for it, although an editor for tweening is overkill.. really. But if it makes it easier to use, so be it.

A tweening prototype you can play with straight away can be found here (its more evolved in the RTL naturally).

Is there more?

Yes. But thats hush-hush stuff so I cant talk about it.

 

 

Advertisements
  1. May 25, 2016 at 3:10 am

    About a light visual component

    I created a “Lightweight Visual Project” template. So, the idea was enable/disable some features using directives. I set some scope symbols around the SmartCL Framework, such as REMOVE_DIALG, REMOVE_FX, REMOVE_PAGE_TRANSITION, REMOVE_EVENT_HANDLERS, my attempt is try to remove some features and reduce the final runtime overhead.

    In my experiments, I was successfully able to create a visual component which inherits from TW3MovableControl, a lightweight alternative to TW3CustomControl (which brings in a more heavy infrastructure).

    I’m discovering that, like Neo, we can massage the heart of the Matrix.

    I sincerely don’t know if this is correct, I set a custom directive named REMOVE_EVENT_HANDLERS to omit the “published scope” events in the TW3CustomControl = partial class(TW3MovableControl)

    this way, the property/Events Inspector will only show the published events of each component, instead of all events. Using this approach, we have to implement the event handlers manually/override. Anyway I’ve got the uncompressed final source code much smaller around 160,454 bytes | 64K obfuscated.

    • Jon Lennart Aasenden
      May 25, 2016 at 6:32 am

      The event sub-system stems from the first incarnation of SMS, so indeed – its due for an overhaul.
      The best approach would be to go for event-objects completely, like i have demonstrated before — so that each event is handled by its own object, using addEventlistner() API.
      That way the overhead would never be more than what you have added of events, and also – You could create many event-handlers for the same event as well.

      But yes you are right, TW3CustomControl brings in a more heavy infrastructure. But also note that most of that is created on demand. So the aux objects like Font, Background etc.. is created the first time you call them. Its the event-code thats overly massive

  2. May 26, 2016 at 10:54 pm

    Jon, I’ve discovered something I think it’s due for an overhaul.
    A visual blank form app, SMS generates 272,291 bytes, but if you set this custom directive USE_SMS_LITE, we have a small uncompressed source: 258,778 bytes.

    {.$DEFINE USE_SMS_LITE}

    TW3CustomControl = partial class(TW3MovableControl)
    private
    { private declarations }
    protected
    { protected declarations }

    public
    { public declarations }

    {$IFDEF USE_SMS_LITE}
    public
    {$ELSE}
    published
    {$ENDIF}

    published
    { published declarations }
    property Angle: Float read FAngle write SetAngle;
    property Zoom: Float read GetZoom write SetZoom;
    property BorderRadius: Integer read GetBorderRadius write SetBorderRadius;

    end;

    • Jon Lennart Aasenden
      May 30, 2016 at 5:39 am

      Send me an email on this, or PM me on facebook?

  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: