Studio 6.1 method lines increased to 256K

Wed Aug 6 19:08:37 EDT 2014

Hi,

It would be 'nice' to see a 64bit run time, but I am not sure that the 32bit architecture is a huge bottle neck in the RT that would be solved by 64 vs ram and processor when having to deal with multiple ridiculously long lists and the sql select time over the network is probably more time consuming.

It's nice to see the app server at 64 but I am not sure if concurrency and being able to load thread instances onto individual processor cores / hyper threads would not be more advantageous than time slicing a single thread into sudo threads on a single processor thread and making that individual process faster as 64 vs 32.

It would be nice to have a two or three thread fat client so that similar to worker dams their could be a TCL listener running independently of the thread serving the user gui / events - but that is because I am obsessed with push rather than timer polling.

But there are very few applications that really need to be push vs polling. Ie low frequency of data change or event but high criticallity of real time and lots of client end points - then polling is very inefficient compared to push.  For example email.

The html5 component mentioned with the ability to call JavaScript and get return values is very cool and I can see how I could use that with client side generated html / script to off load that and hopefully get an interrupt on the call back method when complete, all though it might just sit and wait for the return value when calling a JavaScript function, not tested it. I do something similar with php cli client side but it sits and waits rather than interupts on the return / call back and needs php cli on client which isn't very normal, but the html5 / chromium wrapper sounds v interesting.

Ben

On 6 August 2014 23:41:09 BST, Bastiaan Olij <bastiaan at basenlily.me> wrote:
>Hey Geir,
>
>While I did run into problems with the old limitation, ever since the
>first increase I've never run out of space and most of the time my code
>spans many lines in a single method it is only due to heavy
>documentation and that I tent to not use one lines but prefer more
>readable code even at the cost of a few extra lines.
>
>I completely concur with your opinion on code length. While there is
>the
>odd example for the most part, if you reach over 100 lines of code in a
>single method, you need to start thinking about whether you're
>structuring your code well.
>
>My beef at this point in time is very different though.
>
>There are only two enhancements in 6.1 that potentially benefit us. One
>is this increase of code length, which I care little about, the other
>is
>this new report preview window (we've been using adobe on Windows
>because the old preview window was an utter disgrace, on Mac it
>suffices
>us nicely other then limits in scrolling) though I have a hard head at
>this time whether it really is going to improve anything.
>The only enhancement in Studio 6.0 for us was that it actually works on
>Mavericks (and that really is a Studio 5.2 improvement), that they
>finally have a PDF printing device (but we've been using Michaels for
>ages and his is superior), and the worker DAM thing (that we've not had
>a need for so far)
>The only enhancement in Studio 5 for us would have been secure SMTP but
>there was a high cost to going onto it from Studio 4 (unicode
>conversion
>and legacy code that started failing mostly) so we rolled our own in
>Studio 4 and only went to Studio 6 when Mavericks forced us too.
>
>But really, other then a few bugfixes, Studio 6 has added nothing of
>value to us over Studio 4.
>
>The various iterations of Studio 5, Studio 6 and Studio 6.1 have been
>all about the java client and while its an interesting and amazing
>piece
>of kit, it has had little to no value for us so far. As a developer of
>a
>fat client application (which is still the core Omnis developer
>clientele) we're feeling very unloved. The last Omnis version I was
>really excited about was Studio 4 in which Mitford House did excellent
>enhancements, it made some huge steps forward over Studio 3. But other
>then Studio 4 not running on Mavericks and Studio 6 running on
>Mavericks
>there are hardly any differences that have impacted us even since.
>
>It is a real shame that the only real additions to Omnis that the
>community has repeatedly asked for are being build by 3rd parties.
>Brainy Data's PDF Device and oWrite, Fabians new HTML control, the
>excellent externals that have come out of Artsman, and lets not forget
>the contributions of both Kelly and Stefan over the years.
>
>I applaud TigerLogics guts in trying to reach into a new market and
>develop a platform for the web amongst stiff, lower cost, competition.
>It is where the current hype lies and I am far from saying it is
>without
>value. But I do hope that after 2 major releases and several minor
>releases, they might want to give some love to us fat client developers
>again.
>
>Cheers,
>
>Bas
>
>On 6/08/14 8:48 PM, Geir Fjærli wrote:
>> So I see that TL again has catered for those who want their whole app
>in a single method. Now I believe I posted the same when they increased
>it from 100 lines also, so I may be overly spartan…
>>
>> Reminds me of the poor girl who around 1990 had been commisioned to
>create an app in Omnis 5 or 7.1. She knew absolutely nothing about how
>it worked, but she discovered that when she opened the first window
>(which she did manually) it triggered an event. So she ran the entire
>app from that event procedure. Needless to say, she had problems, and
>was not too happy of the prospect of rewriting everything.
>>
>> I have done a bit of Omnis 7 work the last years, and have
>occasionally hit the 100 line limit when updating other people’s code.
>But I don’t think I have gotten there in my own. A procedure call is
>not carrying a large penalty on modern hardware.
>>
>> Now I realize that there are other things beside Omnis code you might
>want to put in a method these days. But still…?
>>
>> Some may say I have retired for a reason, of course. «Keep up with
>the times or else…» ;)
>>
>> Geir :)_____________________________________________________________
>> Manage your list subscriptions at http://lists.omnis-dev.com
>>
>>
>
>
>-- 
>Kindest Regards,
>
>Bastiaan Olij
>e-mail: bastiaan at basenlily.me
>web: http://www.basenlily.me
>Skype: Mux213
>http://www.linkedin.com/in/bastiaanolij
>
>_____________________________________________________________
>Manage your list subscriptions at http://lists.omnis-dev.com

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.