[RFC] __debug

Lars Strojny

12 years ago

Hi Sara,

On 21 Jan 2014, at 22:26, Sara Golemon <pollita@php.net> wrote:

> Something new to argue about:
>
> https://wiki.php.net/rfc/debug-info

Love it, two things: the var_dump() properties will be replaced (not merged) with the "real" properties in the object (I am asking as that would make it very very cool for stuff like doctrine, where lazy loaded entities are way too large to dump)? As for the name, I would prefer __debugInfo() as in __callStatic(). I know there is __set_state() but that's something that needs deprecation and fixing :)

cu,
Lars

Sara Golemon

12 years ago

On Tue, Jan 21, 2014 at 1:37 PM, Lars Strojny <lars@strojny.net> wrote:

> On 21 Jan 2014, at 22:26, Sara Golemon <pollita@php.net> wrote:
>> https://wiki.php.net/rfc/debug-info
>
> Love it, two things: the var_dump() properties will be replaced (not merged) with the "real" properties in the object (I am asking as that would make it very very cool for stuff like doctrine, where lazy loaded entities are way too large to dump)? As for the name, I would prefer __debugInfo() as in __callStatic(). I know there is __set_state() but that's something that needs deprecation and fixing :)
>

Replaced.  The idea being that if you want to merge with the base
props, you can return (array)$this + ['other'=>'props']; or similar.

EXCELLENT point on the method naming, I'll put that version 1.1 of the RFC.

-Sara

Pierre Joye

12 years ago

hi,

On Tue, Jan 21, 2014 at 10:37 PM, Lars Strojny <lars@strojny.net> wrote:

> Hi Sara,
>
> On 21 Jan 2014, at 22:26, Sara Golemon <pollita@php.net> wrote:
>
>> Something new to argue about:
>>
>> https://wiki.php.net/rfc/debug-info
>
> Love it, two things: the var_dump() properties will be replaced (not merged) with the "real" properties in the object (I am asking as that would make it very very cool for stuff like doctrine, where lazy loaded entities are way too large to dump)? As for the name, I would prefer __debugInfo() as in __callStatic(). I know there is __set_state() but that's something that needs deprecation and fixing :)

I can only second both statements. Love the idea (very useful!) and it
should indeed follow other "magic" method naming convention.

One additional comment, I am not sure about the manual merge of
properties. Maybe it should create an additional property called
"debugInfo" or something similar and store the result of __debugInfo
in it? It could be more user-friendly and less confusing.

Cheers,

--
Pierre

@pierrejoye | http://www.libgd.org

Sara Golemon

12 years ago

On Tue, Jan 21, 2014 at 9:46 PM, Pierre Joye <pierre.php@gmail.com> wrote:

> One additional comment, I am not sure about the manual merge of
> properties. Maybe it should create an additional property called
> "debugInfo" or something similar and store the result of __debugInfo
> in it? It could be more user-friendly and less confusing.
>

Functionally speaking, the merge has to happen regardless since we
can't just put temporary elements into the properties table and return
that.  Sure we could do the work for the user by putting the merge in
the standard object handler, but what does it buy us?

From my point of view, it buys us less options for the user.  By
returning the result of __debugInfo() as-is, the class author can
replace, merge, or stuff debug into an extra prop at their discretion.
By making a unilateral decision to merge, we exclude the option of
not including certain props.  By making the decision to put
__debugInfo() result into a specific '__debug' prop, we take all the
options away.

Personally, I'm for giving power to the user here.  (Not least because
my use-case would quite like being able to control what's shown for
var_dump())

-Sara

Sara Golemon

12 years ago

Updated my branch to use __debugInfo() and updated the RFC to reflect
this and include comments from the list about different ways to handle
the return (replace, merge, sub-element) as well as expanding the
scope to include a ReflectionClass::getDebugInfo() method.

Yasuo Ohgaki

12 years ago

Hi all,

Sorry for off topic.

On Wed, Jan 22, 2014 at 6:37 AM, Lars Strojny <lars@strojny.net> wrote:

> Love it, two things: the var_dump() properties will be replaced (not
> merged) with the "real" properties in the object (I am asking as that would
> make it very very cool for stuff like doctrine, where lazy loaded entities
> are way too large to dump)? As for the name, I would prefer __debugInfo()
> as in __callStatic(). I know there is __set_state() but that's something
> that needs deprecation and fixing :)

Could anyone add __setState() for 5.6?
Thank you.

BTW, I like the RFC.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Derick Rethans

12 years ago

On Wed, 22 Jan 2014, Yasuo Ohgaki wrote:

> Hi all,
>
> Sorry for off topic.
>
> On Wed, Jan 22, 2014 at 6:37 AM, Lars Strojny <lars@strojny.net> wrote:
>
> > Love it, two things: the var_dump() properties will be replaced (not
> > merged) with the "real" properties in the object (I am asking as that would
> > make it very very cool for stuff like doctrine, where lazy loaded entities
> > are way too large to dump)? As for the name, I would prefer __debugInfo()
> > as in __callStatic(). I know there is __set_state() but that's something
> > that needs deprecation and fixing :)
>
>
> Could anyone add __setState() for 5.6?

Why would you want to do that? If at all, all the *newer* methods should
be __debug_info etc. __set_state was first and changing it to
__setState() would mean that var_export'ed() variables in < PHP 5.6
would now no longer work? Or the other way around? It's a cosmetic
change that helps nobody—just like renaming other standard functions to
make them more "organised".

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

Yasuo Ohgaki

12 years ago

Hi Derick,

On Thu, Jan 23, 2014 at 3:35 AM, Derick Rethans <derick@php.net> wrote:

> > Hi all,
> >
> > Sorry for off topic.
> >
> > On Wed, Jan 22, 2014 at 6:37 AM, Lars Strojny <lars@strojny.net> wrote:
> >
> > > Love it, two things: the var_dump() properties will be replaced (not
> > > merged) with the "real" properties in the object (I am asking as that
> would
> > > make it very very cool for stuff like doctrine, where lazy loaded
> entities
> > > are way too large to dump)? As for the name, I would prefer
> __debugInfo()
> > > as in __callStatic(). I know there is __set_state() but that's
> something
> > > that needs deprecation and fixing :)
> >
> >
> > Could anyone add __setState() for 5.6?
>
> Why would you want to do that? If at all, all the *newer* methods should
> be __debug_info etc. __set_state was first and changing it to
> __setState() would mean that var_export'ed() variables in < PHP 5.6
> would now no longer work? Or the other way around? It's a cosmetic
> change that helps nobody—just like renaming other standard functions to
> make them more "organised".
>
> cheers,

I mean add alias for __set_state() to keep consistent names.
__set_state() should be there very long time or forever for compatibility.

It's small cosmetic change, but it would assure PHP to be a good
language to learn in the future. IMHO.

Anyway, I would like to write RFC for aliasing. Aliases may be added
in the future.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Derick Rethans

12 years ago

On Thu, 23 Jan 2014, Yasuo Ohgaki wrote:

> On Thu, Jan 23, 2014 at 3:35 AM, Derick Rethans <derick@php.net> wrote:
>
> > > On Wed, Jan 22, 2014 at 6:37 AM, Lars Strojny <lars@strojny.net> wrote:
> > >
> > > > Love it, two things: the var_dump() properties will be replaced
> > > > (not merged) with the "real" properties in the object (I am
> > > > asking as that would make it very very cool for stuff like
> > > > doctrine, where lazy loaded entities are way too large to dump)?
> > > > As for the name, I would prefer __debugInfo() as in
> > > > __callStatic(). I know there is __set_state() but that's
> > > > something that needs deprecation and fixing :)
> > >
> > > Could anyone add __setState() for 5.6?
> >
> > Why would you want to do that? If at all, all the *newer* methods
> > should be __debug_info etc. __set_state was first and changing it to
> > __setState() would mean that var_export'ed() variables in < PHP 5.6
> > would now no longer work? Or the other way around? It's a cosmetic
> > change that helps nobody—just like renaming other standard functions
> > to make them more "organised".
>
> I mean add alias for __set_state() to keep consistent names.
> __set_state() should be there very long time or forever for
> compatibility.

You seem to misunderstand what __set_state() is for. It is for reliably
representing a value so that you can "include" it's contents with
var_export(). If 5.6 would suddenly start spitting out
Class::__setState() instead of Classs::__set_state() then older PHP
versions can't parse/include that outputted data anymore.

> It's small cosmetic change, but it would assure PHP to be a good
> language to learn in the future. IMHO.

But it makes as much sense as adding a str_len() function as alias for
strlen() — which really just adds more clutter.

>
> Anyway, I would like to write RFC for aliasing. Aliases may be added
> in the future.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

Yasuo Ohgaki

12 years ago

Hi Derick,

On Thu, Jan 23, 2014 at 8:30 PM, Derick Rethans <derick@php.net> wrote:

> > > > Could anyone add __setState() for 5.6?
> > >
> > > Why would you want to do that? If at all, all the *newer* methods
> > > should be __debug_info etc. __set_state was first and changing it to
> > > __setState() would mean that var_export'ed() variables in < PHP 5.6
> > > would now no longer work? Or the other way around? It's a cosmetic
> > > change that helps nobody—just like renaming other standard functions
> > > to make them more "organised".
> >
> > I mean add alias for __set_state() to keep consistent names.
> > __set_state() should be there very long time or forever for
> > compatibility.
>
> You seem to misunderstand what __set_state() is for. It is for reliably
> representing a value so that you can "include" it's contents with
> var_export(). If 5.6 would suddenly start spitting out
> Class::__setState() instead of Classs::__set_state() then older PHP
> versions can't parse/include that outputted data anymore.
>

I have to check code, but don't we have options for this?
We may use __set_state() for var_export and still have alias as __setState.
People are using var_export exchange PHP data, so we should be careful.
I agree this.

> It's small cosmetic change, but it would assure PHP to be a good
> > language to learn in the future. IMHO.
>
> But it makes as much sense as adding a str_len
>

I understand both opinion, strlen could be str_len. Other str function may
be reamed.

Some names are easy to decide, some are not. We may have list of votes
for these. I'll make list after 5.6 release :)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Rowan Collins

12 years ago

Yasuo Ohgaki wrote (on 23/01/2014):

>> You seem to misunderstand what __set_state() is for. It is for reliably
>> >representing a value so that you can "include" it's contents with
>> >var_export(). If 5.6 would suddenly start spitting out
>> >Class::__setState() instead of Classs::__set_state() then older PHP
>> >versions can't parse/include that outputted data anymore.
>> >
> I have to check code, but don't we have options for this?
> We may use __set_state() for var_export and still have alias as __setState.
> People are using var_export exchange PHP data, so we should be careful.
> I agree this.

Is there a use case for __set_state *other than* var_export()?

In other words, if not var_export(), what code would ever include a
reference to __setState() if it were added as an alias?

--
Rowan Collins
[IMSoP]

Yasuo Ohgaki

12 years ago

Hi Rowan,

On Thu, Feb 6, 2014 at 4:36 AM, Rowan Collins <rowan.collins@gmail.com>wrote:

>
>  You seem to misunderstand what __set_state() is for. It is for reliably
>>> >representing a value so that you can "include" it's contents with
>>> >var_export(). If 5.6 would suddenly start spitting out
>>> >Class::__setState() instead of Classs::__set_state() then older PHP
>>> >versions can't parse/include that outputted data anymore.
>>> >
>>>
>> I have to check code, but don't we have options for this?
>> We may use __set_state() for var_export and still have alias as
>> __setState.
>> People are using var_export exchange PHP data, so we should be careful.
>> I agree this.
>>
>
> Is there a use case for __set_state *other than* var_export()?
>
> In other words, if not var_export(), what code would ever include a
> reference to __setState() if it were added as an alias?

My bad.
var_export() does not specify method, so it can alias safely.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Will Fitch

12 years ago

Hi Sara,

On Tue, Jan 21, 2014, at 01:26 PM, Sara Golemon wrote:

> Something new to argue about:
>
> https://wiki.php.net/rfc/debug-info

This is a really good idea.  This will allow customization of the debug
info, and reflection to Reflection.  That said, how/should this
functionality be integrated info Reflection?  For example,
ReflectionClass::getDebugInfo()?

Sara Golemon

12 years ago

On Tue, Jan 21, 2014 at 1:42 PM, Will Fitch <willfitch@php.net> wrote:

> On Tue, Jan 21, 2014, at 01:26 PM, Sara Golemon wrote:
>> Something new to argue about:
>>
>> https://wiki.php.net/rfc/debug-info
>
> This is a really good idea.  This will allow customization of the debug
> info, and reflection to Reflection.  That said, how/should this
> functionality be integrated info Reflection?  For example,
> ReflectionClass::getDebugInfo()?
>

I think it'd make sense to add that as well, yes.  Regardless of
whether or not this RFC gets accepted, in fact.

As to how, I'd treat that method just like getProperties() (Creating
an array of ReflectionProperty objects), just from a different source.

-Sara

Frederic Hardy

12 years ago

Hi all !

Le 21 janv. 2014 à 22:26, Sara Golemon <pollita@php.net> a écrit :

> Something new to argue about:
>
> https://wiki.php.net/rfc/debug-info

Very interesting feature (i have personally thinking about that several time in the past).
However, i think that __dump() is a better name from the end user point of view.
__debug_info() is a good name from the point of view of a C developer which works on the Zend Engine or on C extensions, but from the end user point of view, it’s not the case.
And this new magical method is used internally by var_dump() so __dump() seems to me a better name.
Maybe __set_dump() is an alternative too, because __set_state() is used internally by var_export(), but i’m not sure that it’s a better name than __dump which is very explicit and intuitive.

Best regards,
Fred.

--
========================================================================
Frédéric Hardy : Directeur technique et fonctionnel agile
CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf
Blog : http://blog.mageekbox.net
Twitter : http://twitter.com/mageekguy
========================================================================

Santiago Lizardo

12 years ago

Sara has used stream_get_meta_data in his RFC example and I think is a
good name for the new method, IMHO.

__metadata (or __get_metadata if you prefer an action/verb for methods)

Removing the debug keyword from the equation broadens the possibilities
on how people might use it.

On 01/21/2014 09:42 PM, Frédéric Hardy wrote:

> Hi all !
>
> Le 21 janv. 2014 à 22:26, Sara Golemon <pollita@php.net> a écrit :
>
>> Something new to argue about:
>>
>> https://wiki.php.net/rfc/debug-info
> Very interesting feature (i have personally thinking about that several time in the past).
> However, i think that __dump() is a better name from the end user point of view.
> __debug_info() is a good name from the point of view of a C developer which works on the Zend Engine or on C extensions, but from the end user point of view, it’s not the case.
> And this new magical method is used internally by var_dump() so __dump() seems to me a better name.
> Maybe __set_dump() is an alternative too, because __set_state() is used internally by var_export(), but i’m not sure that it’s a better name than __dump which is very explicit and intuitive.
>
> Best regards,
> Fred.

--
Santiago Lizardo Oscares
http://www.santiagolizardo.com

Ivan Enderlin @ Hoa

12 years ago

Hello :-),

On 21/01/2014 22:42, Frédéric Hardy wrote:

> Hi all !
>
> Le 21 janv. 2014 à 22:26, Sara Golemon <pollita@php.net> a écrit :
>
>> Something new to argue about:
>>
>> https://wiki.php.net/rfc/debug-info
> Very interesting feature (i have personally thinking about that several time in the past).
> However, i think that __dump() is a better name from the end user point of view.
> __debug_info() is a good name from the point of view of a C developer which works on the Zend Engine or on C extensions, but from the end user point of view, it’s not the case.
> And this new magical method is used internally by var_dump() so __dump() seems to me a better name.
> Maybe __set_dump() is an alternative too, because __set_state() is used internally by var_export(), but i’m not sure that it’s a better name than __dump which is very explicit and intuitive.

+1 for `__debug` which is simpler than `__debugInfo`. The -info suffix
does not add any relevant meaning about the method behavior.

Moreover, is this method able to throw an exception?

Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

Alexander Lissachenko

12 years ago

Hello!

I would like to notice, that there is method __set_state() that can be used
to set internal state of object. We can introduce __get_state() method that
will be invoked in var_dump(), etc... Personally I don't like __lower_caps
name of this method, but it will be consistent with __set_state() :)


2014/1/22 Ivan Enderlin @ Hoa <ivan.enderlin@hoa-project.net>

Derick Rethans

12 years ago

On Wed, 22 Jan 2014, Alexander Lisachenko wrote:

> Hello!
>
> I would like to notice, that there is method __set_state() that can be used
> to set internal state of object. We can introduce __get_state() method that
> will be invoked in var_dump(), etc... Personally I don't like __lower_caps
> name of this method, but it will be consistent with __set_state() :)

__set_state() is only meant for userland, not for internals.

Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

Lars Strojny

12 years ago

Hi Derick,

On 22 Jan 2014, at 19:38, Derick Rethans <derick@php.net> wrote:

> __set_state() is only meant for userland, not for internals.

Sure, it still is still inconsistent with the remaining methods.

cu,
Lars

Derick Rethans

12 years ago

On Thu, 23 Jan 2014, Lars Strojny wrote:

> On 22 Jan 2014, at 19:38, Derick Rethans <derick@php.net> wrote:
>
> > __set_state() is only meant for userland, not for internals.
>
> Sure, it still is still inconsistent with the remaining methods.

You seem to have the order of events the wrong way around. __callStatic,
and __toString were added after __set_state() so *these* additions made
things "inconsistent".

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

Andrew Faulds

12 years ago

On 22/01/14 08:10, Ivan Enderlin @ Hoa wrote:

> +1 for `__debug` which is simpler than `__debugInfo`. The -info suffix
> does not add any relevant meaning about the method behavior.

I feel the same here. PHP already has plenty of names which are longer
than they ought to be, or redundant, let's not add another. :)

--
Andrea Faulds
http://ajf.me/

Johannes Schlueter

12 years ago

Hi

On Tue, 2014-01-21 at 13:26 -0800, Sara Golemon wrote:

> Something new to argue about:
>
> https://wiki.php.net/rfc/debug-info

What impact does this have to debuggers like Xdebug?

A comment: PHP in most places like var_dump() usually shows the truth, I
think that is nice ... reason why internal classes have this hook is
that there is no truth.

I assume a cast to array and ReflectionObject will still show the truth?
This should be mentioned in the RFC so it can be added to var_dump()
docs in case this is accepted.

johannes

Sara Golemon

12 years ago

On Tue, Jan 21, 2014 at 1:56 PM, Johannes Schlüter
<johannes@schlueters.de> wrote:

> What impact does this have to debuggers like Xdebug?
>

I'd want Derick to weigh in on that.  I'm not sure if XDebug only
looks at the get_properties hook, or considers the get_debug_info hook
as well.

> A comment: PHP in most places like var_dump() usually shows the truth, I
> think that is nice ... reason why internal classes have this hook is
> that there is no truth.
>

I'm not sure I agree with the latter part of that statement.  If the
hook existed to allow internal classes to "expose truth", they could
do so via get_properties.

> I assume a cast to array and ReflectionObject will still show the truth?
>

Yes.  Cast to array and ReflectionObject::getProperties() both look at
the get_properties handler which is not impacted.

-Sara

Derick Rethans

12 years ago

On Tue, 21 Jan 2014, Sara Golemon wrote:

> On Tue, Jan 21, 2014 at 1:56 PM, Johannes Schlüter
> <johannes@schlueters.de> wrote:
> > What impact does this have to debuggers like Xdebug?
> >
> I'd want Derick to weigh in on that.  I'm not sure if XDebug only
> looks at the get_properties hook, or considers the get_debug_info hook
> as well.

Not yet, but I was hacking on a branch that uses that hook too, as it's
pretty handy to expose through the debugger. I'd probably namespace it
though so it doesn't conflict with "real" properties.

cheers,
Derick

Crypto Compress

12 years ago

Hi,

why not use __toString?

class File {
// "Resource(stream)" isn't all that useful
private $fp;

// But all the stream meta data is
public function __toString() {
return $this->fp ? print_r(stream_get_meta_data($this->fp),
true) : ''; // var export, what ever you like
}

public function open($filename, $mode = 'r'){
$this->fp = fopen($filename, $mode);
}
}

$f = new File;
echo $f; // object(File)#1 { }
$f->open('http://php.net');
echo $f;

cryptocompress

Will Fitch

12 years ago

On Tue, Jan 21, 2014, at 02:18 PM, Crypto Compress wrote:

> Hi,
>
> why not use __toString?
>
> class File {
>      // "Resource(stream)" isn't all that useful
>      private $fp;
>
>      // But all the stream meta data is
>      public function __toString() {
>          return $this->fp ? print_r(stream_get_meta_data($this->fp),
> true) : ''; // var export, what ever you like
>      }
>
>      public function open($filename, $mode = 'r'){
>          $this->fp = fopen($filename, $mode);
>      }
> }
>
> $f = new File;
> echo $f; // object(File)#1 { }
> $f->open('http://php.net');
> echo $f;
>
> cryptocompress

Because the __toString allows a class to decide how to react when
treated like a string.  Sure, that could be debug info, but it could be
printing a full-blow decorator implementation (e.g. Zend\Form\Form), a
number, class name, etc.  What Sara is proposing is specific to object
debugging.

Andrew Faulds

12 years ago

On 21/01/14 22:21, Will Fitch wrote:

> Because the __toString allows a class to decide how to react when
> treated like a string.  Sure, that could be debug info, but it could be
> printing a full-blow decorator implementation (e.g. Zend\Form\Form), a
> number, class name, etc.  What Sara is proposing is specific to object
> debugging.

Right. To see the difference better, I suggest looking at what Python
does. It has a __string__() magic method and a __repr__() magic method,
for string conversion and debug info, respectively. For a date, these
result in:

>>> x = datetime.datetime(1996, 02, 17)
>>> x

datetime.datetime(1996, 2, 17, 0, 0)

>>> str(x)

'1996-02-17 00:00:00'

>>> repr(x)

'datetime.datetime(1996, 2, 17, 0, 0)'

While the str() result is what you want for displaying that date, the
repr() result shows you how it was constructed, which is more useful for
debugging.

For another example, see what Python strings do here:

>>> n = "line 1\nline 2"
>>> print n

line 1
line 2

>>> print repr(n)

'line 1\nline 2'

The first one's might not be very useful for debugging, because it
outputs control characters raw. The debug output version, however, is
much better for this.

--
Andrea Faulds
http://ajf.me/

Andrew Faulds

12 years ago

On 21/01/14 21:26, Sara Golemon wrote:

> Something new to argue about:
>
> https://wiki.php.net/rfc/debug-info

Good proposal. Python has __repr__, and it's a useful feature for
debugging. I see no reason why PHP shouldn't have its own equivalent.

--
Andrea Faulds
http://ajf.me/

[RFC] __debug_info()

Sara Golemon

Lars Strojny

Sara Golemon

Pierre Joye

Sara Golemon

Sara Golemon

Yasuo Ohgaki

Derick Rethans

Yasuo Ohgaki

Derick Rethans

Yasuo Ohgaki

Rowan Collins

Yasuo Ohgaki

Will Fitch

Sara Golemon

Frederic Hardy

Santiago Lizardo

Ivan Enderlin @ Hoa

Alexander Lissachenko

Derick Rethans

Lars Strojny

Derick Rethans

Andrew Faulds

Johannes Schlueter

Sara Golemon

Derick Rethans

Crypto Compress

Will Fitch

Andrew Faulds

Andrew Faulds