220 39697 article Path: news.gmane.org!.POSTED!not-for-mail From: florian.csdt@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Thoughts about relocation Date: Sat, 11 Aug 2018 01:51:03 -0700 (PDT) Lines: 473 Approved: news@gmane.org Message-ID: References: <19d8d86c-f4cf-47a9-bb42-9e2ba06dccab@isocpp.org> <4fb6a8b4-05a1-424e-88b1-275878e1f66a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_940_1286523968.1533977464053" X-Trace: blaine.gmane.org 1533977342 11931 195.159.176.226 (11 Aug 2018 08:49:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 11 Aug 2018 08:49:02 +0000 (UTC) Cc: florian.csdt@gmail.com, arthur.j.odwyer@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC26HM4V3MIRB6GGXLNQKGQE2ZTKW5I@isocpp.org Sat Aug 11 10:48:58 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f70.google.com ([209.85.161.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1foPZv-0002vY-Tm for gclcip-std-proposals@m.gmane.org; Sat, 11 Aug 2018 10:48:56 +0200 Original-Received: by mail-yw1-f70.google.com with SMTP id r144-v6sf16090995ywg.9 for ; Sat, 11 Aug 2018 01:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=Zk4lxI37vny93vGPuGi96/AUgLG6f3UM7p6XZDB9eeM=; b=sc8xFPoX13dVYYehxtsJGFm5kaVK34nODUGMg7hbgaTYaZ6hOnBERN0M5q9j6+8Aju EmMU2E30P6p6jPwptHDVhb9A3MWptTsRb+1fEmgmotuvmISae+Kw4U77z/Bq5orrIvnl IREanUPvHWY287XvhUFntYlT1iQdkWapR0g9jqouJbt55AQTFSRlZFAT8CFhW28XiaG3 ZVQHPUFHEJ77PADvkLi5TLMN98NG5JoDC0eJwFxITd0sL1ZwygftYpcrsv3sOAKH5G6c EJK+nKFr8lKx4RRlXmBqVVkMlKvNyi5FzttQ8Mh6u4BRa22Gb3ZMg+m7QEEahRx2+MDJ 0S2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=Zk4lxI37vny93vGPuGi96/AUgLG6f3UM7p6XZDB9eeM=; b=aBO2w7ABORm/NJcQ7Bn1crg1Ff/iBFHH8MT9XDEgpyy/yPErOtr/90kFXSrfo3z2gw nA6ep23W9YKGgaVlOasobHZqy4etbmKR3gb5OsPblssmKbbc/iikrJAg7BhXFsdbrY1W L4l/olWYBb+DRUAaQXNZ2hjBsh/H6CSjfSXNnRpFfnRBLZQFRqMUaTloDABSa1xNza1M wkAjWuU1hkbFrq6UdQK0qk9c5BNoXbtIxWgtY970A4wf7SeqT/CWOkyRWDOYeGTeDRXm Pk5bDbmorVyXbqbd4Birelq4qyl4WCUYQQBO/Qfp6dyTCArtrN3ii69D1dGTFYemMQu4 qYtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=Zk4lxI37vny93vGPuGi96/AUgLG6f3UM7p6XZDB9eeM=; b=sIbSbaHen7RFZFCFNNnzx3id0F5lwYrqEDhzXusdCJZlTHP+nSyHzBBGsxHk08XIac 0UbtHCXs9DEEosb4EWZxfO/WHQtOneiwT8bJFWdEvTCd5qe446kKfB0a9T2SqedlUgO1 I3/GuQ/pYOf50Mtn1fhYmYDP/wXScVrd1vK7uWPZg7Z9ZIPr2CDxAF7j3i0VetCeYS6Z qwOcFdivn4k7XHEvDjiVUVIVWR/qp3Or0cYFfqBNBBUAiOGL12BvS+TD+G0lFy4XRDqd RoXPPxzqOc04Ro0JMcTxUQvDmr93V5AMOEgg+1ZMNhPQ9mR07NG6HtwtviBTPoOuvDCy jArQ== X-Gm-Message-State: AOUpUlE3OUpZszv+zRaxWoHtxHF/QRWoqAk/GH5j/hAMiEQV7UKugFW1 Td6zKlfrSlj0lEODYZgkWftxZA== X-Google-Smtp-Source: AA+uWPxz22YchMCwS1JCNhNDWte61r/6rL2oad70XpLYTYQZQ0hH6/bvDv0iweXQQqSowKL4zcapcA== X-Received: by 2002:a25:bc89:: with SMTP id e9-v6mr2660428ybk.70.1533977466326; Sat, 11 Aug 2018 01:51:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:a08f:: with SMTP id x137-v6ls1815718ywg.37.gmail; Sat, 11 Aug 2018 01:51:04 -0700 (PDT) X-Received: by 2002:a81:78c6:: with SMTP id t189-v6mr219774ywc.7.1533977464497; Sat, 11 Aug 2018 01:51:04 -0700 (PDT) In-Reply-To: <4fb6a8b4-05a1-424e-88b1-275878e1f66a@isocpp.org> X-Original-Sender: florian.csdt@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:39697 Archived-At: ------=_Part_940_1286523968.1533977464053 Content-Type: multipart/alternative; boundary="----=_Part_941_1381808574.1533977464053" ------=_Part_941_1381808574.1533977464053 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le samedi 11 ao=C3=BBt 2018 01:53:41 UTC+2, Arthur O'Dwyer a =C3=A9crit : > > On Friday, August 10, 2018 at 10:19:01 AM UTC-7, floria...@gmail.com=20 > wrote: >> >> No, I was not aware of this very proposal. (That's quite hard to keep=20 >> track of all proposals) >> >> However, it also shares some issues with most other proposals. >> Namely: it talks about destructive move (two different storages, moving= =20 >> the actual object from one to the other). >> Also, only trivial destructive moves are considered (no user defined). >> > > Please elaborate on this last point above ("no user-defined") =E2=80=94 e= ither=20 > here, or in private email if you feel more like it. (I'm the author of=20 > P1144 and definitely want to hear if it doesn't solve your use-case!) > With your proposal, the user cannot write its own relocation code. I'll explain it further to answer your other comments directly. =20 > > =20 > >> But my proposal talks about in-place relocation: there is one single=20 >> storage whose address has changed. >> And the relocation can be user-defined (a std::list could be made nothro= w=20 >> relocatable). >> > > By P1144's definition, std::is_nothrow_relocatable_v> and=20 > not std::is_trivially_relocatable_v>=20 > . I think this agrees with your=20 > definitions as well, right? > Where we agree is about what types would be trivially relocatable (our=20 definitions are compatible here). However, as we don't share the same definition for relocation, not the same= =20 types will be nothrow relocatable. For you, if a type is movable and destructible, it is relocatable. For me,= =20 if there is non-deleted operators delocate/relocate, the type is=20 relocatable. So with my design, it is possible to have non-movable non copyable types=20 that are relocatable (that is probably not a sane default), and it is also= =20 possible to have copyable movable types that are not relocatable. I want to highlight that some part of your proposal is forward compatible= =20 with mine. Namely: which types are trivially relocatible, the fact that types=20 following the rule of 0 would get trivial relocability if all its=20 members/bases are trivially relocatable, and what is possible to do with=20 trivially relocatable types. Your proposed attribute would also be forward compatible, but redondant. However, the notion of nothrow relocatable is different and are mostly not= =20 compatible. So if you want to make your proposal compatible with mine, I would propose= =20 you to say: only trivially relocatable types are relocatable. But the=20 decision is up to you. =20 > > I believe I understand the intuition behind your proposal. Where P1144=20 > defines "relocate(src,dst) =3D move(src,dst) + destroy(src)", you prefer = to=20 > define "relocate(src,dst) =3D memcpy(src,dst) + fixup(src,dst)". Your=20 > `operator relocate` corresponds to the "fixup(src,dst)" step: it is calle= d=20 > on the destination object after the memcpy has happened, and its job is t= o=20 > repair the damage caused by the memcpy. > > After all the other comments, I changed my opinion about what should be the= =20 relocation. Now relocation is done in 2 explicit steps: delocate() and relocate(). Delocate() could be seen as: prepare fixup Relocate() could be seen as: do fixup So "relocate(src, dst)" would be implemented: src.delocate() + memcpy(dst,= =20 src) + dst.relocate(). But yes, my approach is to fix the object after memcpy. (the memcpy might= =20 not happen at all). =20 > In the absolute worst case, "fixup(src,dst)" can be implemented as=20 > "move(src,dst) + destroy(src)". In the average case, it can be implemente= d=20 > as "fixup-after-move(dst) + destroy(src)". In the case corresponding to= =20 > "trivially relocatable", by definition, it can be implemented as a no-op,= =20 > because a trivially relocatable type by definition can be relocated as-if= =20 > by memcpy and therefore requires no extra fixup step *after* the memcpy. > > I have no "fixup(src, dst)". This is not valid view of what I mean by=20 relocation: only one storage exist. This storage can be moved (change=20 address), but the old position of the storage might not be available at the= =20 time of the fixup. And the is no fixup-after-move because there is no move (no move=20 constructor/assignment is called). Yes, with my view, trivial relocation is a noop. =20 > I agree with other commenters (e.g. Nicol) that your approach is much mor= e=20 > damaging to the object model than P1144's. (And I have been told by sever= al=20 > people, I think again including Nicol, that even P1144 is already too=20 > damaging! My hope is that we will get std::bless() to magically fix a= ll=20 > our problems; and in the meantime, P1144 is demonstrably implementable=20 > and usable=20 > =20 > even if it is technically problematic.) > I wouldn't my approach is more damaging to the object model. I would say=20 more intrusive. Sometimes, small fixes are harder to accept because they=20 are patchwork to make something work (I don't say that's your case). Those= =20 times, bigger changes might have more chance to be adopted because they=20 integrate more nicely. So I don't see why making big changes that wouldn't= =20 break code couldn't make it. Of course, it will require more effort to be= =20 accepted, but looking at the big picture, that would be definitely worth it= .. Relocation would be an enabling feature. Concerning std::bless(), I didn't anticipated it, but my proposal ends= =20 up closer and closer to this. So my opinion on this: I would prefer something defined within the class=20 because it needs the possibility to be defaulted. Moreover, as far as I understand, Nial's proposal doesn't say anything=20 about user defined std::bless. That being said, I would say my proposal and Nial's one are orthogonal,=20 they can be adopted in whatever order. My relocation would then be the=20 internal mechanism used by std::bless that could be standardized as such= =20 afterwards. And my proposal doesn't need Nial's one as they are many other= =20 use cases. =20 > > IIUC, you believe that one advantage of your proposal is that it can be= =20 > used even in situations where no physical `memcpy` happens, e.g. when we= =20 > play tricks with mmap and/or page tables to "wormhole" a range of bytes= =20 > from address A to address B without a physical `memcpy`. I believe that= =20 > P1144 applies equally well to these situations =E2=80=94 perhaps better! = In either=20 > your scheme or mine, for trivially relocatable types, we just=20 > memcpy-or-wormhole the bytes from A to B and we're done. Where we differ = is=20 > for non-trivially relocatable types. In P1144's scheme, we just say=20 > "Wormholing non-trivially-relocatable types is not supported; you're on= =20 > your own." In your scheme, you permit the possibility that someone could= =20 > wormhole an object from A to B and then manually call `operator relocate`= =20 > to perform the fixup. But, if we're assuming wormholes exist, then I don'= t=20 > understand why you'd assume that the "source address" of the=20 > `fixup(src,dst)` is still accessible, or even addressable, by the time th= e=20 > wormhole has happened! > > Getting the source address was a defect of the single step apporach (it was= =20 required only if the fixup needed to know by how much it was displaced,=20 basically). But is not required anymore with the two steps approach: delocate() and=20 relocate() don't take any argument (apart from this). So it now support any crazy byte moving operation. And wormholing is not an= =20 issue. =20 > An obvious example here is if we're sharing a memory segment between two= =20 > processes, so that the destination end of the wormhole is in a completely= =20 > different address space from the source end. Neither side of the shared= =20 > memory segment has enough information to run `fixup(src,dst)`. However,= =20 > I'll admit that shared-memory-segment is a bad use-case for "trivially=20 > relocatable" in general; it really needs a different, larger, more emerge= nt=20 > notion, which I call "position-independent" and which I recently heard=20 > Ronan Keryell call "translation-independent." So I offer=20 > shared-memory-segment as an easily understandable example of a wormhole= =20 > with mutually unaddressible ends, where `fixup(src,dst)` is inexpressible= =E2=80=94=20 > an example of why your scheme *doesn't add any value* for the wormhole=20 > case compared to P1144. I don't offer it as an example of P1144=20 > solving problems related to shared-memory-segment in general (because it= =20 > doesn't). > > First, as I explained just above, I changed my design to now require 2=20 steps: delocate()/relocate(). Delocate doesn't know what will be the new=20 address, and relocate doesn't know what was the old address. So if an=20 object needs to know (for whatever reason) by how much it was displaced, it= =20 should store the information required during the delocate step and use it= =20 in the relocate step. These 2 steps makes it possible to tackle the address-space change=20 (communication between processes for instance). However, I don't plan to standardize this part (I let this part to Nial).= =20 For now, I will just say that it is undefined behaviour to delocate an=20 object without relocating it within the program itself, the same with=20 relocating an object that was not delocated in the program. We can make it defined behaviour afterwards. Concerning your notion of position-independent, I have the feeling that=20 this notion would match trivial relocatibility in most cases (all?). --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/b7370533-65ce-4be2-ba22-9a8546df9c2e%40isocpp.or= g. ------=_Part_941_1381808574.1533977464053 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le samedi 11 ao=C3=BBt 2018 01:53:41 UTC+2, Arthur= O'Dwyer a =C3=A9crit=C2=A0:
On Friday, August 10, 2018 at 10:19:01 AM UTC-7, flor= ia...@gmail.com wrote:
No, I was not aware of this very proposal. (That's quite hard = to keep track of all proposals)

However, it also shares some issues = with most other proposals.
Namely: it talks about destructive move (two = different storages, moving the actual object from one to the other).
Als= o, only trivial destructive moves are considered (no user defined).

Please elaborate on this last point abov= e ("no user-defined") =E2=80=94 either here, or in private email = if you feel more like it. (I'm the author of P1144 and definitely want = to hear if it doesn't solve your use-case!)

With your proposal, the user cannot write its own relocati= on code.
I'll explain it further to answer your other comment= s directly.
=C2=A0

=C2=A0
But my proposal talks about in-plac= e relocation: there is one single storage whose address has changed.
And= the relocation can be user-defined (a std::list could be made nothrow relo= catable).

By P1144's definiti= on, std::is_nothrow_relocatable_v<std::list<T>> and no= t std::is_trivially_relocatable_v<std::list<T>>. =C2= =A0I think this agrees with your definitions as well, right?

Where we agree is about what types would be t= rivially relocatable (our definitions are compatible here).
Howev= er, as we don't share the same definition for relocation, not the same = types will be nothrow relocatable.

For you, if a t= ype is movable and destructible, it is relocatable. For me, if there is non= -deleted operators delocate/relocate, the type is relocatable.
So= with my design, it is possible to have non-movable non copyable types that= are relocatable (that is probably not a sane default), and it is also poss= ible to have copyable movable types that are not relocatable.
I want to highlight that some part of your proposal is forward = compatible with mine.
Namely: which types are trivially relocatib= le, the fact that types following the rule of 0 would get trivial relocabil= ity if all its members/bases are trivially relocatable, and what is possibl= e to do with trivially relocatable types.
Your proposed attribute= would also be forward compatible, but redondant.

= However, the notion of nothrow relocatable is different and are mostly not = compatible.
So if you want to make your proposal compatible with = mine, I would propose you to say: only trivially relocatable types are relo= catable. But the decision is up to you.
=C2=A0

I = believe I understand the intuition behind your proposal. Where P1144 define= s "relocate(src,dst) =3D move(src,dst) + destroy(src)", you prefe= r to define "relocate(src,dst) =3D memcpy(src,dst) + fixup(src,dst)&qu= ot;. =C2=A0Your `operator relocate` corresponds to the "fixup(src,dst)= " step: it is called on the destination object after the memcpy has ha= ppened, and its job is to repair the damage caused by the memcpy.


After all the other comme= nts, I changed my opinion about what should be the relocation.
No= w relocation is done in 2 explicit steps: delocate() and relocate().
<= div>Delocate() could be seen as: prepare fixup
Relocate() cou= ld be seen as: do fixup

So "relocate(src, dst= )" would be implemented: src.delocate() + memcpy(dst, src) + dst.reloc= ate().

But yes, my approach is to fix the object a= fter memcpy. (the memcpy might not happen at all).

=
=C2=A0
In the absolute worst case, "fixup(src,dst)" = can be implemented as "move(src,dst) + destroy(src)". In the aver= age case, it can be implemented as "fixup-after-move(dst) + destroy(sr= c)". In the case corresponding to "trivially relocatable", b= y definition, it can be implemented as a no-op, because a trivially relocat= able type by definition can be relocated as-if by memcpy and therefore requ= ires no extra fixup step after the memcpy.


I have no "fixup(src, dst)". Th= is is not valid view of what I mean by relocation: only one storage exist. = This storage can be moved (change address), but the old position of the sto= rage might not be available at the time of the fixup.
And the is = no fixup-after-move because there is no move (no move constructor/assignmen= t is called).

Yes, with my view, trivial relocatio= n is a noop.
=C2=A0
I agree with other commenters (e.= g. Nicol) that your approach is much more damaging to the object model than= P1144's. (And I have been told by several people, I think again includ= ing Nicol, that even P1144 is already too damaging! =C2=A0My hope is that w= e will get std::bless<T>() to magically fix all our problems; and in = the meantime, P1144 is demonstrably implementable an= d usable even if it is technically problematic.)

I wouldn't my approach is more damaging to the ob= ject model. I would say more intrusive. Sometimes, small fixes are harder t= o accept because they are patchwork to make something work (I don't say= that's your case). Those times, bigger changes might have more chance = to be adopted because they integrate more nicely. So I don't see why ma= king big changes that wouldn't break code couldn't make it. Of cour= se, it will require more effort to be accepted, but looking at the big pict= ure, that would be definitely worth it.
Relocation would be an en= abling feature.

Concerning std::bless<T>= (), I didn't anticipated it, but my proposal ends up closer and closer = to this.
So my opinion on this: I would prefer something defined = within the class because it needs the possibility to be defaulted.
Moreover, as far as I understand, Nial's proposal doesn't say any= thing about user defined std::bless<T>.

That= being said, I would say my proposal and Nial's one are orthogonal, the= y can be adopted in whatever order. My relocation would then be the interna= l mechanism used by std::bless<T> that could be standardized as such = afterwards. And my proposal doesn't need Nial's one as they are man= y other use cases.
=C2=A0

IIUC, you believe that = one advantage of your proposal is that it can be used even in situations wh= ere no physical `memcpy` happens, e.g. when we play tricks with mmap and/or= page tables to "wormhole" a range of bytes from address A to add= ress B without a physical `memcpy`. =C2=A0I believe that P1144 applies equa= lly well to these situations =E2=80=94 perhaps better! =C2=A0In either your= scheme or mine, for trivially relocatable types, we just memcpy-or-wormhol= e the bytes from A to B and we're done. Where we differ is for non-triv= ially relocatable types. In P1144's scheme, we just say "Wormholin= g non-trivially-relocatable types is not supported; you're on your own.= " =C2=A0In your scheme, you permit the possibility that someone could = wormhole an object from A to B and then manually call `operator relocate` t= o perform the fixup. But, if we're assuming wormholes exist, then I don= 't understand why you'd assume that the "source address" = of the `fixup(src,dst)` is still accessible, or even addressable, by the ti= me the wormhole has happened!

<= br>
Getting the source address was a defect of the single step ap= porach (it was required only if the fixup needed to know by how much it was= displaced, basically).
But is not required anymore with the two = steps approach: delocate() and relocate() don't take any argument (apar= t from this).
So it now support any crazy byte moving operation. = And wormholing is not an issue.
=C2=A0
An obvious exa= mple here is if we're sharing a memory segment between two processes, s= o that the destination end of the wormhole is in a completely different add= ress space from the source end. Neither side of the shared memory segment h= as enough information to run `fixup(src,dst)`. However, I'll admit that= shared-memory-segment is a bad use-case for "trivially relocatable&qu= ot; in general; it really needs a different, larger, more emergent notion, = which I call "position-independent" and which I recently heard Ro= nan Keryell call "translation-independent." =C2=A0So I offer shar= ed-memory-segment as an easily understandable example of a wormhole with mu= tually unaddressible ends, where `fixup(src,dst)` is inexpressible =E2=80= =94 an example of why your scheme doesn't add any value for the = wormhole case compared to P1144. I don't offer it as an example of P114= 4 solving=C2=A0problems related to shared-memory-segment in general (becaus= e it doesn't).


First, as I explained just above, I changed my design to now require 2 s= teps: delocate()/relocate(). Delocate doesn't know what will be the new= address, and relocate doesn't know what was the old address. So if an = object needs to know (for whatever reason) by how much it was displaced, it= should store the information required during the delocate step and use it = in the relocate step.
These 2 steps makes it possible to tackle t= he address-space change (communication between processes for instance).

However, I don't plan to standardize this part (I= let this part to Nial). For now, I will just say that it is undefined beha= viour to delocate an object without relocating it within the program itself= , the same with relocating an object that was not delocated in the program.=
We can make it defined behaviour afterwards.

Concerning your n= otion of position-independent, I have the feeling that this notion would ma= tch trivial relocatibility in most cases (all?).

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/b7370533-65ce-4be2-ba22-9a8546df9c2e= %40isocpp.org.
------=_Part_941_1381808574.1533977464053-- ------=_Part_940_1286523968.1533977464053-- .