Re: 4D World Tour - Denver
Ditto to what everyone else has already said about the 4D World Tour 2017 in Denver. Sorry I’m late posting, but all I can add is the knowledge and advice gained from the training is “priceless.” The ROI is off the charts. All the presenters were well prepared and explained a lot of the new features of v16 with excellent demos. Even the “new” guy. ;) Add was great as usual and JPR is JPR. :) It was great seeing several of the old timers and some new, much younger, developers as well! BTW, the term JPR used for the “hypothetical” new version of 4D was it, hypothetically, will be a “quantum leap.” Also, you better be all over C_OBJECT. Floyd Zink QMed Corporation ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: 4D World Tour - Denver
Sorry, I failed to mention, but of course, JPR's "poof" was in an eelven on a scale of one to ten! Tom Dillon wrote: >I know I'm late to this and that there's only the one World Tour event >left (I had a three day, drinking from a firehose client meeting after >the WT). BUT, I thought about not going, because, ya know, maybe JPR >might have lost some of the perk in his "poof, it is done". And I don't >have enough time to practice how to pronounce Add Komoncharoensiri (I >have trouble with double letters). But, learning what I did about >workers and, in particular, a better way of doing modular form design, >made it more than worth it. > >I know, it's tomorrow and I probably can't make most of the first day! >Do it anyway. You'll thank me, and everyone else who posted about the >World Tour, probably with a beer at the next 4D Summit. -- -- Tom Dillon 825 N. 500 W. DataCraft Moab, UT 84532 tomdil...@datacraft-inc.com 720/209-6502 -- Never apologize for a joke that nobody realized was dirty. --- Sunastar -- ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: 4D World Tour - Denver
I know I'm late to this and that there's only the one World Tour event left (I had a three day, drinking from a firehose client meeting after the WT). BUT, I thought about not going, because, ya know, maybe JPR might have lost some of the perk in his "poof, it is done". And I don't have enough time to practice how to pronounce Add Komoncharoensiri (I have trouble with double letters). But, learning what I did about workers and, in particular, a better way of doing modular form design, made it more than worth it. I know, it's tomorrow and I probably can't make most of the first day! Do it anyway. You'll thank me, and everyone else who posted about the World Tour, probably with a beer at the next 4D Summit. -- -- Tom Dillon 825 N. 500 W. DataCraft Moab, UT 84532 tomdil...@datacraft-inc.com 720/209-6502 -- Even on a road with no turns you can head out across the open field. --- Sunastar -- ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: 4D World Tour - Denver
On Sat, May 6, 2017 at 6:24 AM, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com > wrote: You are correct. This is exactly how JPR described it. > This reminds me to tell a story I've shared before. My first job at 4D was working in the Tech Support 'pit'. And again, apologies to anyone that reached me :-0 The Tech Support manager back then was Thom Hickey, who some of you may know or remember. He gave me about the best advice I've ever gotten: "Hey man, never lie! If someone calls and you don't know or aren't sure, put them on hold and try it. Create a small database from scratch and try it out. Never. Lie." Solid advice. If you're not sure, check it out. I very quickly not to be afraid to create little databases and throw them away. I _still_ do this. If I want to try out a new 4D feature, I don't do it in a real code base, I do it in a scratch database. I know I'll throw it away (if not immediately, a bit down the track) so I've got no investment. I can let my hair down and be messy. The whole point is to focus on one thing and move fast. For something like CALL FORM and CALL WORKER, I must have made more than a dozen disposable databases. I've also done a couple of really massive ones with real code to test out more intricate questions - but a lot can be done with throw-away databases. Case in point: I was wondering "Huh. You can post code to the execution hopper with CALL FORM before a form is loaded. Will it execute before On Load or after?" There is no way to know a priori and it's not in the docs. So I tried it. It took less time than writing this up - just a few minutes. Well, On Load runs first. It didn't have to be that way, but it turns out that it is that way. I wrote to Thomas Maul and he confirmed with Engineering that the behavior is something that we can rely on. I tried to update the docs with a comment, didn't know how...and never got back to doing it. The point is that a lot of this stuff isn't a mystery, it just isn't well documented. But you can find out for yourself in a few minutes or an hour. It's fun! But then again, I'm a fan of black-box testing... So, like yesterday, I strongly encourage people to try out CALL FORM and CALL WORKER in a scratch database. If you've got 30-60 minutes when you're feeling awake, relaxed, and curious - see what you can figure out first-hand. There's nothing like trying stuff out directly to build a solid mental model. And mastery of these commands does require building an accurate mental concept of how it all works. With this in mind, I'd also encourage people to try and ignore the documentation's "mailbox" metaphor. It's not entirely wrong, but it's more wrong than it is right. For anyone that's ever dealt with a request queue, we don't have that. You need to understand that there is a queue *underneath* to understand how multi-process-calls and self-call work, but that's it. Instead, try to think about a *thread of control.* Namely, a process. Either worker or a window with a form. A worker is easier to explain but the concepts apply either way. Imagine that you are a worker. What are you? You're a process that executes code, like any code. But instead of dying when the code runs out, you go to sleep. It's like 4D has put your code in a magic repeat loop: Repeat Run code <-- this is the worker code that you write Sleep Until (shutting down) CALL WORKER does this: Repeat Run code <-- this is the worker code that you write Sleep Wake up <-- this is what CALL WORKER provokes --- Go back to the top of the loop and 'run code' provided by CALL WORKER Until (shutting down) Imagine now that you're developing and the debugger comes up in your worker. What happens to CALL WORKER requests to the worker? They proceed normally as there is no result from CALL WORKER. The 'queue' (within 4D) gets a new entry. But that's it, nothing gets processed and the queue keeps getting bigger and bigger. But you can't detect that, can's see the queue, can't do anything to it. Well, you can kill the worker, clear the queue and let 4D restart it, but that's it. Try to think about workers *from their point of view.* The queue is from *4D's* point of view. And, for anyone that's used queues before, you just don't have the facilities you would expect. There is no On Message event or routine. There is no chance to inspect the code before it executes. It just runs. The CALL commands are *code dispatchers*. They move a block of code from one place (where you run it) to another place (at the end of a thread of execution in the same or a different process.) They're like unregulated remote procedure calls. You can use them to send IP messages (I do) but, by their nature, that's not what they are - they're little blocks of code that you're moving into another process. That can be great because you have the full context of that process - like selections, variables, etc. It can also be dangerous because the called process can't block, suspend, reject, or insp
Re: 4D World Tour - Denver
On May 5, 2017, at 2:00 PM, David Adams wrote: > You seem excited about the event ;-) Keep in mind that not everyone can > attend because they either live to far away, have a scheduling conflict, or > are reading these posts in the future. Unless they invent a time travel > machine, it won't be possible to attend...Ultimately, if information isn't > in the docs (language ref, tech notes, tips, recorded sessions, etc.), it's > easily lost or ignored. I was trying to be silly, not serious. I guess I should have put a :) next to my post. And I am excited about the 2018 4D Summit. JPR says it is going to be big. He provided no details except for one little hint. So as not to offend and keep anything secret here is his comment. If you are using periods in variable names, you might want to stop doing that. You take from that comment whatever you want. I think I know what it coming and it’s something we had a discussion about in the last month here on the iNUG. Something that will definitely be interested in. But that’s just my opinion and speculation. It will be April 2018 before we all know for sure what is coming. And they also mentioned that the 4D Summit in Paris next year will also be done in English and French with translators available in all sessions. So if you can’t make it to America… there’s always France. > As far as the sequence of events goes, it's basic information that should > be in the documentation. There's nothing advanced about it and it's nothing > that should be secret. It's a bit of the mechanics that it's important to > understand so that you don't tie yourself in knots. Here's how it works > (I've posted it here before): > > * When you call Open window (etc.) a 'queue' is created. This is *before* > any form is shown. So, the queue is a property of the window, not the form. > > * You can post code blocks to the queue via CALL FORM *as soon as the > window reference is returned.* > > * ...but then there's no form context to execute the command(s) you've > supplied. > > * Once you open the form, On Load runs. *Your queued commands are still in > the queue.* > > * After On Load, the queued commands are executed in order. The code you > pass in through CALL FORM is held in a First In First Out structure. That's > what a queue is. 4D's CALL WORKER and CALL FORM are 100% reliable about > executing code in the sequence it was received. That's a promise and it > makes things a lot simpler than they might otherwise be. Since this is > FIFO, not truly asynchronous or a stack (LIFO), the code is executed in the > order that you sent it. You are correct. This is exactly how JPR described it. Tim Tim Nevels Innovative Solutions 785-749-3444 timnev...@mac.com ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: 4D World Tour - Denver
On May 5, 2017, at 2:00 PM,Cannon Smith wrote: > Well, I thought I was talking about workers in general, but that was under > the assumption that all processes have some kind of execution cycle. Are you > saying that a non-UI process (ex. pre-emptive thread) won’t have an execution > cycle? Sure workers have an execution cycle. They constantly look in their mailbox for any messages. As soon as there is one, it executes the method in the message. When the method finishes executing it checks the mailbox for any more messages if there are some, it get the next one off the queue and executes that method. That continues until the message queue is empty. As far as I know there are no delays in the execution cycle. The only delay is if there is already a method executing. If there is, then the worker waits until the method has finished. Then it gets the next message off the queue and executes that. Methods are executed one at a time and in the order they were received in the worker message queue. > In either case, the only place I can think of where this might matter is in a > worker process that has UI in it, so yes, CALL FORM is where the rubber meets > the road here. I was trying to be more exact, but maybe assumed too much? Yes that is what JPR was trying to get across. The only delayed action is to redraw the window of a form. Tim Tim Nevels Innovative Solutions 785-749-3444 timnev...@mac.com ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: 4D World Tour - Denver
> (Example: if you open a window and then do CALL FORM before you issues a
DIALOG command,
> exactly what happens related to the form events? Not gonna tell you. Go
to the
> 4D World Tour and let JPR tell you!)
You seem excited about the event ;-) Keep in mind that not everyone can
attend because they either live to far away, have a scheduling conflict, or
are reading these posts in the future. Unless they invent a time travel
machine, it won't be possible to attend...Ultimately, if information isn't
in the docs (language ref, tech notes, tips, recorded sessions, etc.), it's
easily lost or ignored.
As far as the sequence of events goes, it's basic information that should
be in the documentation. There's nothing advanced about it and it's nothing
that should be secret. It's a bit of the mechanics that it's important to
understand so that you don't tie yourself in knots. Here's how it works
(I've posted it here before):
* When you call Open window (etc.) a 'queue' is created. This is *before*
any form is shown. So, the queue is a property of the window, not the form.
* You can post code blocks to the queue via CALL FORM *as soon as the
window reference is returned.*
* ...but then there's no form context to execute the command(s) you've
supplied.
* Once you open the form, On Load runs. *Your queued commands are still in
the queue.*
* After On Load, the queued commands are executed in order. The code you
pass in through CALL FORM is held in a First In First Out structure. That's
what a queue is. 4D's CALL WORKER and CALL FORM are 100% reliable about
executing code in the sequence it was received. That's a promise and it
makes things a lot simpler than they might otherwise be. Since this is
FIFO, not truly asynchronous or a stack (LIFO), the code is executed in the
order that you sent it. So, the overall sequence of events listed above
breaks down like this:
Open windowQueue is created
CALL FORM Commands are posted to the queue pending execution
DIALOG, etc. On Load runs pretend that you use CALL FORM here
ExecuteThe commands you posted before calling DIALOG (etc.) run,
then the ones from your On Load phase.
For illustration, let's say that you're logging something with these calls.
For this case, let's say it's numbers in sequence.
$winref:=Open window
CALL FORM($winref;"LogThingy";1)
CALL FORM($winref;"LogThingy";2)
CALL FORM($winref;"LogThingy";3)
DIALOG("MyForm")
// Form method
On Load
CALL FORM($winref;"LogThingy";4)
CALL FORM($winref;"LogThingy";5)
CALL FORM($winref;"LogThingy";6)
That's the sequence *in the code*, here's the sequence *in execution*
Open window
On Load
LogThingy(1)
LogThingy(2)
LogThingy(3)
LogThingy(4)
LogThingy(5)
LogThingy(6)
I've made that as simple to follow as I can but, in truth, it's pretty hard
to follow if you start mixing CALL FORM in with loading the process and the
form. In this context, the command is more like
DEFER METHOD
The current process/thread of control is consuming some code - and you're
adding new code to the end of that. I won't talk about the dangers inherent
in unsupervised uses of GOTO or self-modifying code. But, those of you who
remember those subjects know what I'm talking about. As a
sanity-preserving measure and to make life easier for the next programming,
here's my recommendation:
Make the code's order in the Method Editor match its order of
execution, as much as possible.
There are times when you'll want to mess with that...there are times when
it's a solid idea to go a different way...but as a rule of thumb, I'd
advise against writing code that takes a lot of mental energy to track.
With CALL FORM, you have to keep in mind that *it does not run where you've
typed it.* It runs at the end of the current code in the context you push
the code into. Actually, I should make a distinction between CALL FORM and
CALL WORKER here. If you've got CALL FORM, about the only funny bit is this
business described above. In the normal lifecycle of a form and it's code,
CALL FORM is a pretty natural fit. It can be handy, for example, to post a
CALL FORM to yourself. Apart from fancy reasons...this can also help get
around glitches in 4D's execution cycle. Many of you will remember using
POST KEY in the past. Just a few days ago I couldn't get a list row
highlight to work (no idea why) so I appended a CALL FORM callback and it
worked out fine.
With CALL WORKER it's *much* easier to tie yourself in knots. Depending on
what your worker does, there may be times when it makes sense to CALL
WORKER on yourself. That does get confusing. It can also get unpredictable
because other events may arrive from other processes before your deferred
code is executed. In such cases, I've found it easier to avoid self-calling
workers going through the queue. For example, imagine a worker that starts
by initializing some data it needs. A C_OBJECT or something. If you post
some code back to the queue to complete that task, how do you kno
Re: 4D World Tour - Denver
Well, I thought I was talking about workers in general, but that was under the assumption that all processes have some kind of execution cycle. Are you saying that a non-UI process (ex. pre-emptive thread) won’t have an execution cycle? In either case, the only place I can think of where this might matter is in a worker process that has UI in it, so yes, CALL FORM is where the rubber meets the road here. I was trying to be more exact, but maybe assumed too much? -- Cannon.Smith Synergy Farm Solutions Inc. Hill Spring, AB Canada 403-626-3236 > On May 4, 2017, at 1:46 PM, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > I think you are talking about using CALL FORM and not about workers in > general. In the past if you did CALL FORM 10 times to the same form, it would > do a redraw after each CALL FORM and thus could cause some flickering. Now > when a windows starts dealing with a CALL FORM it handles all the CALL FORMs > and then at the end it does a screen redraw. ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: 4D World Tour - Denver
On May 4, 2017, at 2:00 PM,Cannon Smith wrote: > I also learned that in previous versions a worker would check for the next > message once per execution cycle. Right now that has changed so that the > worker will continue executing whatever it needs to empty the message queue > all in one event cycle. There are pros and cons each way (although I wish it > were the former way), but this can affect UI updating in some cases, so it is > good to be aware of. I think you are talking about using CALL FORM and not about workers in general. In the past if you did CALL FORM 10 times to the same form, it would do a redraw after each CALL FORM and thus could cause some flickering. Now when a windows starts dealing with a CALL FORM it handles all the CALL FORMs and then at the end it does a screen redraw. Tim Tim Nevels Innovative Solutions 785-749-3444 timnev...@mac.com ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: 4D World Tour - Denver
On May 4, 2017, at 12:21 PM,David Adams wrote: > Thanks for all of the details from your time at the tour, it sound really > great. I'm happy to see that CALL FORM and CALL WORKER are being promoted, > that's great. I strongly encourage everyone to try these features out. If > you can find 30-60 minutes when you've got the feeling to experiment, you > can master the basic mechanics. Several months later, I'm still sorting > through nuances ;-) The documentation on the basic commands is excellent, > although I find the overall 'about workers' page possibly more misleading > than clarifying. And this is where the 2nd day of the 4D World Tour and JPR’s presentation is so valuable. He spends a lot of time talking about the worker process system. The ideas behind how it works. The detail of when things happen. (Example: if you open a window and then do CALL FORM before you issues a DIALOG command, exactly what happens related to the form events? Not gonna tell you. Go to the 4D World Tour and let JPR tell you!) All this background information is so helpful. And because the meetings are small with less than 50 people, you can ask questions at any time. JPR also talks about “slicing” and “chunking” and why you need to use these techniques and provides examples of their use with workers. Important information needed so that your finished implementation using these new commands is smooth and polished. > I'm glad that Tim pointed out that these commands work in 32-bit and don't > require compilation to execute. I think that these commands may have come > out of 4D's work on making more of the language pre-emptive. That's > understandably lead to some conflation of the two subjects. Pre-emptive > mode and these new CALL commands can be treated as unrelated subjects. So > if you don't care about pre-emptive, you should still find out about these > commands - they're a vast improvement over past options. And for another clarification, you CAN have a worker generate a UI, open windows, etc. The caveat is you can only do this if the worker is interpreted, or the worker compiled but set to not running preemptively. You only get the illegal command error messages when compiling and you have set the method to run preemptively. (Reminds me of a Dirty Harry saying… “a man’s got to know his limitations.”) And 4D has had preemptive processes for a long time. They are now exposing this existing technology to developers for us to use. An example is the “DB4D Server" process running on the server. (And it could very well be that any process running on 4D Server with “State” of “Running” is a preemptive process. I didn’t ask JPR that question, I’m just guessing here.) Tim Tim Nevels Innovative Solutions 785-749-3444 timnev...@mac.com ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: 4D World Tour - Denver
I also just got back from the World Tour. It was great to see some of you again and the information was very helpful. Add had some great demos and JPR shared a lot of great information. One thing JPR helped me understand better is that a worker is basically just a process ready to do things. You can actually start a worker process without any method at all. It just starts and sits there waiting for you do ask it to do something. Maybe not helpful in real life, but knowing that helped me understand the concept better. I also learned that in previous versions a worker would check for the next message once per execution cycle. Right now that has changed so that the worker will continue executing whatever it needs to empty the message queue all in one event cycle. There are pros and cons each way (although I wish it were the former way), but this can affect UI updating in some cases, so it is good to be aware of. Thanks to 4D for putting the Tour on! -- Cannon.Smith Synergy Farm Solutions Inc. Hill Spring, AB Canada 403-626-3236 ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
RE: 4D World Tour - Denver
David, I completely agree!!! Call Form and Call Worker are really more accurately named and described by your naming. > As a quick heads-up, I think that the most accurate names for these commands > are respectively: > > EXECUTE METHOD IN WINDOW > EXECUTE METHOD IN WORKER Thanks Justin Will ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: 4D World Tour - Denver
Tim, Thanks for all of the details from your time at the tour, it sound really great. I'm happy to see that CALL FORM and CALL WORKER are being promoted, that's great. I strongly encourage everyone to try these features out. If you can find 30-60 minutes when you've got the feeling to experiment, you can master the basic mechanics. Several months later, I'm still sorting through nuances ;-) The documentation on the basic commands is excellent, although I find the overall 'about workers' page possibly more misleading than clarifying. Seriously folks, jump in! Make a silly new database with one form and a few methods - that's all it takes to figure out the basics. After enough people are using these tools and familiar with their standard behaviors, we can start to exchange some better ideas about how best to use them. As a quick heads-up, I think that the most accurate names for these commands are respectively: EXECUTE METHOD IN WINDOW EXECUTE METHOD IN WORKER They not sending messages in any traditional sense, they moving code into a different context where it's executed. They're more like an unusual control structure or a remote procedure call than to a message. Although you can build a more traditional messaging system on top of these commands. By "traditional messaging", I mean computer-to-computer messaging, not person-to-person. (I've been into message-oriented, networked systems architectures for a long time - like many on this list.) So, yeah, dive in, try them out and have some fun. They're pretty neat. And there are some very nice advantages to using workers. Oh, and just as another couple of technical heads up: Any 4D code can *send* using the new commands, but only a window or a worker can *receive.* These are pure calls - there is no concept of a return, but you can add a callback if you're coming from a window or worker. The concept of the queue is of limited usefulness because we can't see it, control it, or change it in any sort of fine-grained way. I'm glad that Tim pointed out that these commands work in 32-bit and don't require compilation to execute. I think that these commands may have come out of 4D's work on making more of the language pre-emptive. That's understandably lead to some conflation of the two subjects. Pre-emptive mode and these new CALL commands can be treated as unrelated subjects. So if you don't care about pre-emptive, you should still find out about these commands - they're a vast improvement over past options. ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
