Re: Help->v11 to v17 Upgrade or New?

[Patrick Emanuel via 4D_Tech]

4D Tech mailing list wrote
> I am not uploading directly from 4D. I thought about implementing that but
> decided against it since 4D is going that direction them selves. Waiting
> to see what they come up with.

I understood the same from teh Summit.
Anyway, there is an existing  module in QS_Toolbox doing this, but I will
not improve it more that it is today until the 4D Release having this
function (v18?) and will concentrate my work on the others modules.





-
Patrick EMANUEL

Administrator
www.association-qualisoft.eu 
(Soft1002, Simply Asso & QS_Toolbox)
--
Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Help->v11 to v17 Upgrade or New?

[Walt Nelson via 4D_Tech]

Folks,

I would like to suggest you (if you haven’t already) check out a paid product 
from the Foundation Shell App Store by Robert Livingston for a 4D database 
solution to storing the text from all your methods and object methods 
automatically.

ArchiveMethod 

 for $97 compiled

Robert has done a great job of solving version control for your 4D database 
methods.

> ArchiveMethod is a 4D system that collects all your methods in your 4D 
> databases (as many as you want) into a single 4D database for version 
> control, documentation and archiving in a single location. This allows the 
> developer to monitor the changes over time and search for methods or code 
> they have used in the past. If you have ever wondered where your routine for 
> customizing mail addresses lives or what the latest version of your parsing 
> routine is – ArchiveMethod is the tool for you.
> It is written by long-time 4D developer Dr. Robert Livingston to solve a need 
> he had for keeping track of all his database methods. It is now available for 
> all 4D programmers to use. He is always open to feature enhancements and 
> considers every request as an opportunity to improve the product.
> The product includes complete user documentation as well as over-the-shoulder 
> video tutorials on best practices in using the ArchiveMethod system.

Thanks,
Walt Nelson (Seattle)

www.foundationshell.com 
w...@foundationshell.com 


> On Oct 21, 2018, at 1:11 PM, Dani Beaubien via 4D_Tech <4d_tech@lists.4d.com 
> > wrote:
> 
> I use the external git client for diffs against historical commits and I use 
> the Code Analysis component for diffs between what is in the 4D structure 
> compares against the last export to the external folder.

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Help->v11 to v17 Upgrade or New?

[Dani Beaubien via 4D_Tech]

I am not uploading directly from 4D. I thought about implementing that but 
decided against it since 4D is going that direction them selves. Waiting to see 
what they come up with.

My workflow is to use the Code Analysis component to export all my code, 4D 
Structure and form properties (gathered using 4D’s get functions) all into a 
single folder. I then use an external git client to commit changes in that 
folder to a git repository I make sure that I do a commit per bug/feature. When 
I do my commit I include the task id from the bug reporting system that I use 
so I have a complete reference on why certain methods were updated.

I use the external git client for diffs against historical commits and I use 
the Code Analysis component for diffs between what is in the 4D structure 
compares against the last export to the external folder.

Works quite well. Definitely a few extra steps but benefits to be able to go 
back in time and see the change history tied to code commit is amazingly useful.

I ran into an issue where I needed to find out when a particular bug was 
introduced. I was able to use the repository to find the exact commit that 
introduced the bug, what the original (and correct code) used to be and what 
else was changed in that commit. Save me hours and hours of banging my head on 
the keyboard.

Dani Beaubien
Open Road Development


> On Oct 19, 2018, at 5:28 PM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Dani,
> 
> On Fri, Oct 19, 2018 at 8:22 AM Dani Beaubien via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
> 
>> I have been using GitHub to track changes on the exported code. I have
>> projects that go back years that are in GitHub.
> 
> Did I just hear you say something about uploading direct from 4D into
> GitHub... 🙄
> 
> -- 
> Kirk Brooks
> San Francisco, CA
> ===
> 
> *We go vote - they go home*
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Shared Object - NOT!

[Peter Bozek via 4D_Tech]

On Sun, Oct 21, 2018 at 7:36 PM Kirk Brooks via 4D_Tech <
4d_tech@lists.4d.com> wrote:

>
>
> Personally I have a lot of concepts about how to do code operation in 4D
> that are strongly rooted in what it was possible to do in 4D. ORDA
> frequently goes in a different direction and the optimal ORDA solutions
> look much different than I'm accustomed to. Usually cleaner, tighter and
> less code. Not always, but usually.
>
>
Kirk,

I think you misunderstood what is in my opinion very good discussion. The
question was not how to refactor some 4D code to ORDA, rather how to solve
some problems (that can be solved with interprocess named selection and
sets) in ORDA. The discussion split to several venues - would it be wise to
implement, can it be circumvented by redesigning the problem and if not,
how to implement it?

While discussion si (I hope) not finished, it seems to me that currently
ORDA does not offer efficient solution - although the situation can change
in the future - and it is wise to try to avoid sharing selections by using
another new feature, support for several active windows within one process.
Such solution may have its own problems, though.

--

Peter Bozek
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Shared Object - NOT!

[Keisuke Miyako via 4D_Tech]

it's a silly example anyway,
but to be clear,

cat:=New collecrtion(cat;cat;cat)

cat[0].food:="prawn"


should read

cats:=New collection(cat;cat;cat)

and

cats[0].food:="prawn"


**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Shared Object - NOT!

[Keisuke Miyako via 4D_Tech]

the sharing of process sets and named selections between a client process and 
its server twin process seems to me like a very deliberate feature.

http://doc.4d.com/4Dv15/4D/15.6/4D-Server-Sets-and-Named-Selections.300-3838966.en.html

for those who are not familiar with this feature,
a process set created on the client side is visible and available in its server 
twin process, and vice versa.

the reason I say it must be deliberate is because the request log clearly shows 
that a copy is performed to make this implicit feature work.

objects are references, so there is no "sharing" across machines.
someone needs to marshal and copy it over the network.

when you pass an object or collection to a method executed on the server, (or 
the other way round, execute on client)
an implicit VARIABLE TO BLOB is performed.

what is different in v17 to is that references "internal" to that object is 
replicated.
that was not the case in v16; it was more like strigification.

one example of an internal reference is a recursive object.

cat:=New object
kitten:=New object("mother":cat)
cat.kitten:=kitten

in this example we have 2 objects, one inside the other.
but the inner object has a recursive reference to the outer,
so a stringified version would go on forever,

cat.kitten.mother.kitten.mother.kitten.

v17 can BLOB-ify this kind of object and pass it to a method executed on the 
server.
it can also save it to a field, or a file, and restore it as a recursive object.

another example is multiple referencing of the same internal object.

cat:=New object("food":"tuna")
cat:=New collecrtion(cat;cat;cat)

in this example we have 2 objects, one inside the other.
but the inner object is referenced multiple times.
if the object is stringified, it would look like there are 4 objects. (3 + 1 
collection)

[{"food":"tuna"},{"food":"tuna"},{"food":"tuna"}]

and parsing it would indeed create 4 objects.

v17 can BLOB-ify and restore these kinds of objects, keeping its internal 
references.

so if the recipient method executed on server does

cat[0].food:="prawn"

all 3 instances of cat.food would be updated, because they all reference the 
same object.



**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Shared Object - NOT!

[Kirk Brooks via 4D_Tech]

Peter,

On Sun, Oct 21, 2018 at 5:04 AM Peter Bozek via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> On Sun, Oct 21, 2018 at 12:41 PM Keisuke Miyako via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
> > the request is more like,
> > "I want to make a query in process B change the current selection of
> > process A, and vice versa".
> > why would you want that?
>
> I am using interprocess sets and named selections - not very often, but I
> still do in all at least a bit more complex projects.
>

I think there are a number of cases where solutions for tricky issues that
work, and work well, in prior versions of 4D do not work well using ORDA.
And frankly attempting to hammer those solutions into the ORDA language
doesn't do any good.

I strongly suspect there is another way to accomplish the end result you
need using tools available in ORDA but it's going to require re-thinking
the problem from the beginning. What is the task or operation you want to
accomplish? What's that result look like as an entity selection, collection
or whatever? Then it becomes 'how do I get that result using the tools
available?' That's where I find ORDA is most powerful - using it for what
it's designed to do. I am not finding it particularly beneficial as a
replacement for perfectly good, old 4D code. The fact it's a shiny new
widget doesn't make it useful for everything.

In this case your previous work may be perfectly fine and not worth the
effort to retro fit.

Personally I have a lot of concepts about how to do code operation in 4D
that are strongly rooted in what it was possible to do in 4D. ORDA
frequently goes in a different direction and the optimal ORDA solutions
look much different than I'm accustomed to. Usually cleaner, tighter and
less code. Not always, but usually.

-- 
Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Shared Object - NOT!

[Kirk Brooks via 4D_Tech]

Miyako,


On Sat, Oct 20, 2018 at 9:29 PM Keisuke Miyako via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> if you do the same across processes,
> i.e. pass a New object or New collection to New process, CALL WORKER or
> CALL FORM,
> the object or collection is not shared between the 2 methods, caller and
> callee,
> because they are not running in the same process.
>
I know this has also been true when passing an object to a method which
execute on server. Is it something that may change in the future? I'm
thinking about the characteristic os sets to be shared between the twin
server process and the client within a process and wondering if it may
extend to objects?

-- 
Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Shared Object - NOT!

[Chip Scheide via 4D_Tech]

Not to mention how much old/legacy code would likely break

> 
> the language might be more consistent if 4D got rid of all native 
> scalar types and treating everything as an object,
> but there is a performance advantage (memory footprint and speed) in 
> having scalar native types.

Hell is other people 
 Jean-Paul Sartre
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Shared Object - NOT!

[Keisuke Miyako via 4D_Tech]

in addition to the distinction between shared and non-shared objects,
we need to be aware of the distinction between objects and non-objects.

the 4D language is different from script coding languages such as JS or PHP,
in that scalar types such as boolean, long, date, time are not objects.
they are native data types.

for instance, we know that

collection1:=collection2

is just a duplication of the object reference, not the object itself.

but long:=collection.longProperty

is a duplication of a native scalar value itself,
because numbers in 4D are not objects.

you can see the distinction in the documentation of "For each".

http://doc.4d.com/4Dv17/4D/17/For-eachEnd-for-each.300-3754311.en.html

(jump to keyword "scalar")

if you run a "For each" on a collection of objects,
the item you get in $1 is an object in the collection, which is a reference.
so updating it will directly update the object inside the collection.

but if you run a "For each" on a collection of scalar values,
the item you get in $1 is a copy of the value in the collection,
so updating it will not change the value inside the collection.

the ":=" operator is not inconstant.
what is really "inconsistent", is the nature of value types.

assigning an object or collection to another
is like assigning a DocRef (time), MenuRef (string), XMLRef (string), List 
(number) to another.
the operator never created a new file pointer, menu, XML node or list.

an object or collection property of a shared object is shared,
but a scalar property of a shared object is not,
because a scalar property is not an object,
which means it is not a reference,
which means there is no concept of sharing.

the language might be more consistent if 4D got rid of all native scalar types 
and treating everything as an object,
but there is a performance advantage (memory footprint and speed) in having 
scalar native types.

2018/10/21 21:04、Peter Bozek 
mailto:peter.bo...@gmail.com>>のメール:

it would be nice if assignment operator honored shared property as well and 
constructs like
collection:=selection.ID
would keep collection a shared one if it was before (and similar to assignment 
of collection created with .copy() .)




**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Shared Object - NOT!

[Peter Bozek via 4D_Tech]

On Sun, Oct 21, 2018 at 12:41 PM Keisuke Miyako via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> you will probably not like my answer, but here goes.
>
> for creating a shared collection from a 4D array,
> ARRAY TO COLLECTION has a special syntax that does just that.
> the trick is to pass a New shared collection to the command.
>
> http://doc.4d.com/4Dv17/4D/17/ARRAY-TO-COLLECTION.301-3730916.en.html
>
>
it would be nice if assignment operator honored shared property as well and
constructs like
collection:=selection.ID
would keep collection a shared one if it was before (and similar to
assignment of collection created with .copy() .)


>
> I believe that such feature is in development and will be available pretty
> soon.
>




> but on entity collections, I don't understand why that would be necessary.
>
> first, I disagree with the interprocess named selection analogy.
>
> the request is more like,
> "I want to make a query in process B change the current selection of
> process A, and vice versa".
> why would you want that?
>

I am using interprocess sets and named selections - not very often, but I
still do in all at least a bit more complex projects.


>
> yet,  the "Use" and "End use" locking system would do nothing to protect
> data integrity,
> because any other process can update or delete an entity outside of the
> entity selection.
> I don't see any value in such a tortured system.
>

The same can be said about interprocess named selections and sets.   While
yes, there is a question of consistency, people understand that well and I
do not remember any complains regarding this. Note that you do not have to
have different processes - you can delete entity belonging to selection
within the same process and run into the same situation.

>
> if the goal is to share entity selections between windows,
> then it would make more sense to run those windows in the same process.
>

Yes, this is true and I was thinking about it. However, I feel that this is
currently not very well documented and there are not many example databases
that would  help me understand how to properly implement multiple active
windows in the same process. Do you have some suggestions what to look at?
(Yes, I know about DIALOG (... ;*) syntax.)


> the scope of an entity selection is the process which has practical
> benefits.
> there must be a really strong argument to justify breaking that rule.
>


I do not fully understand what is the benefit 9or difference) of having, in
one process, two windows showing and manipulating the same entity
selection, or two selections cloned with .copy() command, and having two
windows in two processes displaying two synchronized selections.

--

Peter Bozek
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Shared Object - NOT!

[Keisuke Miyako via 4D_Tech]

you will probably not like my answer, but here goes.

for creating a shared collection from a 4D array,
ARRAY TO COLLECTION has a special syntax that does just that.
the trick is to pass a New shared collection to the command.

http://doc.4d.com/4Dv17/4D/17/ARRAY-TO-COLLECTION.301-3730916.en.html

for objects and collections in general,
there is obviously a need to create a shared copy in one shot,
especially in the context of JSON Parse.

I believe that such feature is in development and will be available pretty soon.

-

but on entity collections, I don't understand why that would be necessary.

first, I disagree with the interprocess named selection analogy.

the request is more like,
"I want to make a query in process B change the current selection of process A, 
and vice versa".
why would you want that?

if an entity selection was shared between processes,
you would have to active its locker mutex,
every time you access it,
 on both sides.

yet,  the "Use" and "End use" locking system would do nothing to protect data 
integrity,
because any other process can update or delete an entity outside of the entity 
selection.
I don't see any value in such a tortured system.

if the goal is to share entity selections between windows,
then it would make more sense to run those windows in the same process.

the scope of an entity selection is the process which has practical benefits.
there must be a really strong argument to justify breaking that rule.

> 2018/10/21 17:17、Peter Bozek のメール:
> is there a way how to convert non-shared collection to shared? Some commands 
> return normal collection, like
> selection.toCollection("ID") or collection:=selection.ID
> and I want to pass the collection to other process without duplication, but 
> have not found a way how to convert normal selection to shared one.




**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Shared Object - NOT!

[Peter Bozek via 4D_Tech]

On Sun, Oct 21, 2018 at 6:29 AM Keisuke Miyako via 4D_Tech <
4d_tech@lists.4d.com> wrote:
>
> the best way to share an object or collection between processes is to
pass a shared object or shared collection as a parameter.
> there is no need to use Storage, there is no need to use interprocess
variables.
> you just create a shared object or shared collection, and pass it as an
argument to another process or worker.
> the received object is not a copy, it is a shared reference to the same
shared object.
>

Keisuke,

is there a way how to convert non-shared collection to shared? Some
commands return normal collection, like
selection.toCollection("ID") or collection:=selection.ID
and I want to pass the collection to other process without duplication, but
have not found a way how to convert normal selection to shared one.

Tried
collection:=New shared collection
collection:=selection.ID
but it seems collection was reverted to normal one. When I tried

Use (Storage)
  Storage.collection:=New shared collection
  Storage.collection:=$settings.ID
End use

I got a runtime error. Even

Use (Storage)
  Storage.collection:=New shared collection
  Storage.collection:=$collection.copy()
End use

is not possible, although this is what I want to avoid.

Best would be to have shared entity selection - like interprocess named
selections - which would then generate shared collections.

--

Peter Bozek
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**