official word on Globals & Lasso9

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

official word on Globals & Lasso9

Steve Upton

so… is there an official word on Globals & Lasso9?

No, sessions won't do the job. I'm caching values in maps for quick access.

Globals did a great job in Lasso 8. Do they exist in L9? (Jolle implied they did in one post I saw)

Do I need to go the thread route?

Regards,

Steve Upton


#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: official word on Globals & Lasso9

Ke Carlton-3
No press release, but based on past conversations (and experience)
globals were effectively a bad thing thing — nice idea, poor in
practice.

Good or bad, it doesn't matter — effectively they're now redundant:

// Constant example
define myglobal => array('x','y','z')

// Thread object
define menuglobal => thread {
    parent = array
}

menuglobal->insert('Home' = '/')
menuglobal->insert('About us' = '/about-us')

The above approaches effectively cover all of the functionality of
globals — without the downsides (one big object prone to thread
locking and memory bloat).

If you're stuck with a specific thing, fire it through and I'm sure
myself or others on the list will be able to offer up effective
solutions / replacements...

Ke

On 12 June 2012 20:56, Steve Upton <[hidden email]> wrote:

>
> so… is there an official word on Globals & Lasso9?
>
> No, sessions won't do the job. I'm caching values in maps for quick access.
>
> Globals did a great job in Lasso 8. Do they exist in L9? (Jolle implied they did in one post I saw)
>
> Do I need to go the thread route?
>
> Regards,
>
> Steve Upton
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: official word on Globals & Lasso9

Jolle Carlestam-3
In reply to this post by Steve Upton
12 jun 2012 kl. 21:57 skrev "Steve Upton" <[hidden email]>:

> Do I need to go the thread route?

Need?
Going the thread route is a good choice. The best choice even.
Why are you avoiding it?


HDB
Jolle

Sent from a thin, flat, touchy device from an undetermined place in space.
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: official word on Globals & Lasso9

Jonathan Guthrie-3
In reply to this post by Steve Upton
"Globals" as used in pre-9 are problematic.

I think it's far better to use this:

        define keepme => 'stuff'
        // ... or
        define keepme => { return 'stuff' }

Note that the second has a capture, and you can have whole blocks of stuff in there... but the value returned has to be returned using "return"

Once it's defined, it will stay defined for the duration of the instance uptime.
You can change the value by redefining it.

        define keepme =>'cat'
        keepme
        ', '
        define keepme =>'donkey'
        keepme

> cat, donkey

However, you can't do this:
        define keepme =>'cat'
        keepme = 'dog'
else it will error horribly.

Threads have other advantages, and I would advocate for using them if you have larger data or arrays, maps etc (as Ke showed in his reply a few minutes ago)


On 2012-06-12, at 3:56 PM, Steve Upton wrote:

>
> so… is there an official word on Globals & Lasso9?
>
> No, sessions won't do the job. I'm caching values in maps for quick access.
>
> Globals did a great job in Lasso 8. Do they exist in L9? (Jolle implied they did in one post I saw)
>
> Do I need to go the thread route?
>
> Regards,
>
> Steve Upton

Jono

----------------------------
Jonathan Guthrie
[hidden email]
LassoSoft Inc.
+1 888-286-7753 ext 708

#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: official word on Globals & Lasso9

Steve Upton
In reply to this post by Jolle Carlestam-3

On Jun 12, 2012, at 1:22 PM, Jolle Carlestam wrote:

> 12 jun 2012 kl. 21:57 skrev "Steve Upton" <[hidden email]>:
>
>> Do I need to go the thread route?
>
> Need?
> Going the thread route is a good choice. The best choice even.
> Why are you avoiding it?

No prejudicial reason, just code momentum (and limited L9 familiarity)

I'd like to move our site over to Lasso 9 with as little fuss as possible.

I'd also like to know the pros and cons of different methods / techniques so that when we actually want to refactor things we can make the best decisions.

Maps are what our use is really about. We put localized text into them. Raw integer and other values come out of the DB and then get associated / replaced with the appropriate text values for the user from RAM (global maps). It's quick and fairly painless and worked very will under L8.

Regards,

Steve

#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: official word on Globals & Lasso9

fletcher sandbeck-2
In reply to this post by Jolle Carlestam-3
On Jun 12, 2012, at 1:22 PM, Jolle Carlestam wrote:

> 12 jun 2012 kl. 21:57 skrev "Steve Upton" <[hidden email]>:
>
>> Do I need to go the thread route?
>
> Need?
> Going the thread route is a good choice. The best choice even.
> Why are you avoiding it?

Shouldn't [Globals] just be implemented this way for compatibility?  And, isn't it?

define globals => thread { parent = map }

The [global] and [global_defined] tags are just shortcuts for access to this map in LP8 anyway.  The only thing you're going to lose is $ shortcuts.

[fletcher]

#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: official word on Globals & Lasso9

fletcher sandbeck-2
On Jun 12, 2012, at 1:35 PM, Fletcher Sandbeck wrote:

> On Jun 12, 2012, at 1:22 PM, Jolle Carlestam wrote:
>
>> 12 jun 2012 kl. 21:57 skrev "Steve Upton" <[hidden email]>:
>>
>>> Do I need to go the thread route?
>>
>> Need?
>> Going the thread route is a good choice. The best choice even.
>> Why are you avoiding it?
>
> Shouldn't [Globals] just be implemented this way for compatibility?  And, isn't it?
>
> define globals => thread { parent = map }
>
> The [global] and [global_defined] tags are just shortcuts for access to this map in LP8 anyway.  The only thing you're going to lose is $ shortcuts.


To follow up, it was implemented more or less this way last time I looked.  Of course I haven't seen the actual code for a couple years, but this was a pretty simple set of tags.

I would think the only drawback would be that all the globals would be in one thread versus being able to break them out into different threads using the method Ke Carlton described.

[fletcher]

#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: official word on Globals & Lasso9

Ke Carlton-3
Yes, and that's the crux of the issue — it would result in a bloated
single object that's ripe for slowing down and potentially crashing
(or being so slow appear to crash) Lasso after abuse. ie. Hundreds or
thousands of globals storing 100MB's of data... (in a single threaded
object).

The implementation would take a few minutes (just did so for fun) —
but it's definitely better for all if it does not exist...

Ke

On 12 June 2012 21:43, Fletcher Sandbeck <[hidden email]> wrote:
>
> I would think the only drawback would be that all the globals would be in one thread versus being able to break them out into different threads using the method Ke Carlton described.
>
> [fletcher]
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: official word on Globals & Lasso9

Jolle Carlestam-3
In reply to this post by Steve Upton
12 jun 2012 kl. 22:34 skrev "Steve Upton" <[hidden email]>:

>
> Maps are what our use is really about. We put localized text into them. Raw integer and other values come out of the DB and then get associated / replaced with the appropriate text values for the user from RAM (global maps). It's quick and fairly painless and worked very will under L8.

From memory that's what we do with the Knop language type. All language strings are fetched from a table and inserted into maps in a thread.
Works like a treat.

I can't dig up code examples right now, in bed for the night, but I can see what I can provide in the morning.


HDB
Jolle

Sent from a thin, flat, touchy device from an undetermined place in space.
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: official word on Globals & Lasso9

fletcher sandbeck-2
In reply to this post by Ke Carlton-3
On Jun 12, 2012, at 1:50 PM, Ke Carlton wrote:

> Yes, and that's the crux of the issue — it would result in a bloated
> single object that's ripe for slowing down and potentially crashing
> (or being so slow appear to crash) Lasso after abuse. ie. Hundreds or
> thousands of globals storing 100MB's of data... (in a single threaded
> object).

Well sure, but how about dozens of globals storing a couple MBs of data?  Which is a more likely scenario for my servers at least.

> The implementation would take a few minutes (just did so for fun) —
> but it's definitely better for all if it does not exist...

It's the tradeoff between making 9 an easy transition for 8 users or forcing everyone to rewrite everything.

[fletcher]

#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: official word on Globals & Lasso9

Steve Upton
In reply to this post by Ke Carlton-3

On Jun 12, 2012, at 1:20 PM, Ke Carlton wrote:

> No press release, but based on past conversations (and experience)
> globals were effectively a bad thing thing — nice idea, poor in
> practice.
>
> Good or bad, it doesn't matter — effectively they're now redundant:
>
> // Constant example
> define myglobal => array('x','y','z')
>
> // Thread object
> define menuglobal => thread {
>    parent = array
> }
>
> menuglobal->insert('Home' = '/')
> menuglobal->insert('About us' = '/about-us')
>
> The above approaches effectively cover all of the functionality of
> globals — without the downsides (one big object prone to thread
> locking and memory bloat).

OK, I think I'm wrapping my head around this but I do have a remaining question.

the thread object is a singleton, check
it runs on definition and continues indefinitely, check

but how does this technique get around locking? If multiple threads access the same "global thread" at the same time don't they have to wait for each other?

Also, now that I think about it. How does one implement thread locking in this scenario. I don't need anything too fancy. It's just that when I reload the map cache from the tables in the DB (which is only once a week or so), can I lock out other threads?

Regards,

Steve



#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: official word on Globals & Lasso9

Kyle Jessup-2
On Jun 12, 2012, at 7:21 PM, Steve Upton wrote:

> On Jun 12, 2012, at 1:20 PM, Ke Carlton wrote:
>
>> No press release, but based on past conversations (and experience)
>> globals were effectively a bad thing thing — nice idea, poor in
>> practice.
>>
>> Good or bad, it doesn't matter — effectively they're now redundant:
>>
>> // Constant example
>> define myglobal => array('x','y','z')
>>
>> // Thread object
>> define menuglobal => thread {
>>   parent = array
>> }
>>
>> menuglobal->insert('Home' = '/')
>> menuglobal->insert('About us' = '/about-us')
>>
>> The above approaches effectively cover all of the functionality of
>> globals — without the downsides (one big object prone to thread
>> locking and memory bloat).
>
> OK, I think I'm wrapping my head around this but I do have a remaining question.
>
> the thread object is a singleton, check
> it runs on definition and continues indefinitely, check
>
> but how does this technique get around locking? If multiple threads access the same "global thread" at the same time don't they have to wait for each other?

Thread objects do not solve the issue of locking. Instead, you get blocking! It's the same thing, except inverted. What Lasso 9's model does do is completely prevent the data corruption potential of not properly or consistently locking a particular section of code against other threads. Basically, there's no way to screw it up. It is higher level than the manual synchronization of LP8 but was designed to be as care free as possible (except for when it doesn't square with your LP8 code).

We do have some plans to improve on thread objects which do avoid locking: immutable objects, futures/asynchronous sends.

> Also, now that I think about it. How does one implement thread locking in this scenario. I don't need anything too fancy. It's just that when I reload the map cache from the tables in the DB (which is only once a week or so), can I lock out other threads?

Thread objects are the locking primitive in Lasso 9. There is no other. Think of a thread object as a lock object. You provide the functionality for what it does and give it a name so people can reference it and it lives in its own world where all operations operate exclusively.

-Kyle

> Regards,
>
> Steve
#############################################################
This message is sent to you because you are subscribed to
  the mailing list Lasso
[hidden email]
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>