Re: [PHP-DEV] [RFC] Destructuring Coalesce

[Bob Weinand]

> Am 16.10.2022 um 23:11 schrieb Bob Weinand :
> 
> Hey,
> 
> I've written a small RFC about adding coalesce ability to list() 
> destructuring.
> 
> This should enhance the ability to easily, concisely and readably destructure 
> arrays with default values.
> 
> https://wiki.php.net/rfc/destructuring_coalesce 
> 
> 
> Bob

Hey, 

Given  haven't heard much feedback, I'll open the vote by end of the week,

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

[Marco Pivetta]

Since this topic fits like a glove, just dropping the "why I don't use
`__toString()`" argument here:
https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460085493

A falsifiable object is worse than `__toString()` in this context, IMO.

Marco Pivetta

https://twitter.com/Ocramius

https://ocramius.github.io/


On Mon, 31 Oct 2022 at 20:38, Josh Bruce  wrote:

> Hello Interntals,
>
> Someone reached out to me outside of internals regarding the RFC I
> submitted on being able to declare objects falsifiable, so, I decided to
> update and re-enter the fray.
>
> I’ve updated the references section as many of the RFCs that were under
> discussion at the time have since been implemented.
>
> I still find myself in situations where having the capability would be
> beneficial. Specifically, I’m noticing with API responses where I want to
> pass the body received from a ResponseInterface the object can check
> itself. I currently use methods such as:
>
> ->isValid()
> ->isInvalid()
> ->toBool()
>
> And similar - the isValid and isInvalid() methods are just aliases of
> toBool(), which speaks to the ability for adopters to make their interfaces
> compatible without breaking changes in their code.
>
> In the case of a conditional - looks like this:
>
> $obj = Object::init($response);
> If ($obj->isValid()) {
> // do something with $obj
> }
>
> Or:
>
> If (
> $obj = Object::init($response) and
> $obj->isValid()
> ) {
> // do something with $obj
> }
>
> Would like to be able to do something like:
>
> If ($obj = Object::init($response)) {
> // do something with $obj
> }
>
> As of today, the last example is always true. You wouldn’t be able to
> create a guard clause for the negation:
>
> If (
> $obj = Object::init($response) and
> $obj === false
> ) {
> // handle invalid object, which could include something like
> $obj->failed()
> }
>
> Cheers,
> Josh
>
> > On Sep 26, 2020, at 5:20 PM, Josh Bruce  wrote:
> >
> > Hey Internals,
> >
> > So, I received a message that said of the mail I should have received
> from internals bounced; so, this is part test and part update.
> >
> > I’ve started mapping out call paths in the project that brought this
> concept to light.
> >
> > The project, Shoop, never uses is_bool() - instead it always uses empty,
> then reverses that for:
> >
> > 1. Booleans
> > 2. Numbers
> > 3. Arrays
> > 4. Strings
> > 5. stdClass or data-only classes
> > 6. Json strings, which it treats as #5
> >
> > I essentially get standard SPL behavior when I do this.
> >
> > For the object definition I can define two interfaces:
> >
> > 1. Falsifiable
> > 2. Emptiable
> >
> > The checks go like this:
> >
> > 1. if the object implements Falsifiable: the __toBool method would be
> called and would return the result. (This check would be inside is_bool()
> and could use the empty() implementation)
> > 2. if the object implements Emptiable: the __isempty method would be
> called and return the result. (This check would be inside empty())
> > 3. else: standard output from is_bool() or empty() would be used when
> passing an instance to either of those SPL functions, depending on which
> the user is using.
> >
> > Because the concepts of emptiness and falsiness are so tightly coupled,
> I’m wondering if it would be better to implement both with this RFC??
> >
> > Otherwise, Emptiable would be a future enhancement consideration.
> >
> > I’d like to hear what the rest of Internals thinks.
> >
> > Next for me: I’m going to finish solidifying the Shoop project and make
> sure my other projects can use latest and then continue going through the
> tutorials from Nikita and others on doing development Internals.
> >
> > Cheers,
> > Josh
> >
> >> On Aug 30, 2020, at 9:32 AM, Josh Bruce  j...@joshbruce.dev>> wrote:
> >>
> >> Hey Tyson,
> >>
> >> This is great! Thank you so much, sincerely.
> >>
> >> Still slow goings, which is fine, we have at least a year. lol
> >>
> >> Static analyzers seem to be the biggest concern to date.
> >>
> >> Haven’t been able to get one running locally - though I’ve only spent a
> few minutes here and there; definitely on the list.
> >>
> >> A use case for this sort of thing is also a concern or question. I came
> across Pipeline from the PHP League and saw their interruptible processor
> and was wondering if something like this would be helpful there - for
> pipeline patterns in general:
> https://github.com/thephpleague/pipeline/blob/master/src/InterruptibleProcessor.php
> >>
> >> While working on another project, saw this line from the PHP
> array_filter docs:
> >>
> >> "If no callback is supplied, all entries of array equal to FALSE
> (see converting to boolean) will be removed."
> >>
> >> I’m still field testing the latest iteration of my base project, but
> wanted to put a working (non-internals) implementation out there (note this
> covers emptiness and falseness for the purposes of the project):
> >>
> >> Tests -
> 

Re: [PHP-DEV] Change email address associated with account

[Christoph M. Becker]

On 31.10.2022 at 21:09, Sara Golemon wrote:

> On Mon, Oct 31, 2022 at 2:48 PM Josh Bruce  wrote:
>
>> I’d like to change my email address for internals but don’t want to lose
>> ownership (??) of the falsifiable RFC:
>> https://wiki.php.net/rfc/objects-can-be-falsifiable
>>
>> Is this possible? Should I be posting this somewhere else, if so, where?
>
> If you're talking about an @php.net address, that's not trivial, but it is
> doable.  Ultimately simpler to create a new account and kill the old one.
>
> If you're just talking about mailing list subscription, then you can unsub
> from the old one and resub with the new one.  Email to `
> internals-subsc...@lists.php.net` and `internals-unsubscr...@lists.php.net`
> from the relevant addresses and you'll be responded with a message to
> bounce back and confirm.  All self-servicey.
>
> As for the wiki, there's not /really/ such a thing as "ownership" of an RFC
> in a formal sense.  Anyone with wiki karma can edit any RFC, there's just a
> gentleperson's agreement to not edit the RFCs of others without their
> permission.  So again, if you get a new wiki account, and kill the old one,
> that's sufficient.

Chaning the email address of a Wiki account can be done in the admin
area; I just would have to know to which address.

If it is just about changing the email address in the RFC, just go ahead. :)

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Change email address associated with account

[Sara Golemon]

On Mon, Oct 31, 2022 at 2:48 PM Josh Bruce  wrote:

> I’d like to change my email address for internals but don’t want to lose
> ownership (??) of the falsifiable RFC:
> https://wiki.php.net/rfc/objects-can-be-falsifiable
>
> Is this possible? Should I be posting this somewhere else, if so, where?
>
>
If you're talking about an @php.net address, that's not trivial, but it is
doable.  Ultimately simpler to create a new account and kill the old one.

If you're just talking about mailing list subscription, then you can unsub
from the old one and resub with the new one.  Email to `
internals-subsc...@lists.php.net` and `internals-unsubscr...@lists.php.net`
from the relevant addresses and you'll be responded with a message to
bounce back and confirm.  All self-servicey.

As for the wiki, there's not /really/ such a thing as "ownership" of an RFC
in a formal sense.  Anyone with wiki karma can edit any RFC, there's just a
gentleperson's agreement to not edit the RFCs of others without their
permission.  So again, if you get a new wiki account, and kill the old one,
that's sufficient.

-Sara

[PHP-DEV] Change email address associated with account

[Josh Bruce]

Hey Internals!

Apologies if this is the wrong space.

I’d like to change my email address for internals but don’t want to lose 
ownership (??) of the falsifiable RFC: 
https://wiki.php.net/rfc/objects-can-be-falsifiable

Is this possible? Should I be posting this somewhere else, if so, where?

Cheers,
Josh

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

[Josh Bruce]

Hello Interntals,

Someone reached out to me outside of internals regarding the RFC I submitted on 
being able to declare objects falsifiable, so, I decided to update and re-enter 
the fray.

I’ve updated the references section as many of the RFCs that were under 
discussion at the time have since been implemented.

I still find myself in situations where having the capability would be 
beneficial. Specifically, I’m noticing with API responses where I want to pass 
the body received from a ResponseInterface the object can check itself. I 
currently use methods such as:

->isValid()
->isInvalid()
->toBool()

And similar - the isValid and isInvalid() methods are just aliases of toBool(), 
which speaks to the ability for adopters to make their interfaces compatible 
without breaking changes in their code.

In the case of a conditional - looks like this:

$obj = Object::init($response);
If ($obj->isValid()) {
// do something with $obj
}

Or:

If (
$obj = Object::init($response) and
$obj->isValid()
) {
// do something with $obj
}

Would like to be able to do something like:

If ($obj = Object::init($response)) {
// do something with $obj
}

As of today, the last example is always true. You wouldn’t be able to create a 
guard clause for the negation:

If (
$obj = Object::init($response) and
$obj === false
) {
// handle invalid object, which could include something like $obj->failed()
}

Cheers,
Josh

> On Sep 26, 2020, at 5:20 PM, Josh Bruce  wrote:
> 
> Hey Internals,
> 
> So, I received a message that said of the mail I should have received from 
> internals bounced; so, this is part test and part update.
> 
> I’ve started mapping out call paths in the project that brought this concept 
> to light.
> 
> The project, Shoop, never uses is_bool() - instead it always uses empty, then 
> reverses that for:
> 
> 1. Booleans
> 2. Numbers
> 3. Arrays
> 4. Strings
> 5. stdClass or data-only classes
> 6. Json strings, which it treats as #5
> 
> I essentially get standard SPL behavior when I do this.
> 
> For the object definition I can define two interfaces:
> 
> 1. Falsifiable
> 2. Emptiable
> 
> The checks go like this:
> 
> 1. if the object implements Falsifiable: the __toBool method would be called 
> and would return the result. (This check would be inside is_bool() and could 
> use the empty() implementation)
> 2. if the object implements Emptiable: the __isempty method would be called 
> and return the result. (This check would be inside empty())
> 3. else: standard output from is_bool() or empty() would be used when passing 
> an instance to either of those SPL functions, depending on which the user is 
> using.
> 
> Because the concepts of emptiness and falsiness are so tightly coupled, I’m 
> wondering if it would be better to implement both with this RFC??
> 
> Otherwise, Emptiable would be a future enhancement consideration.
> 
> I’d like to hear what the rest of Internals thinks.
> 
> Next for me: I’m going to finish solidifying the Shoop project and make sure 
> my other projects can use latest and then continue going through the 
> tutorials from Nikita and others on doing development Internals.
> 
> Cheers,
> Josh
> 
>> On Aug 30, 2020, at 9:32 AM, Josh Bruce > > wrote:
>> 
>> Hey Tyson,
>> 
>> This is great! Thank you so much, sincerely.
>> 
>> Still slow goings, which is fine, we have at least a year. lol
>> 
>> Static analyzers seem to be the biggest concern to date.
>> 
>> Haven’t been able to get one running locally - though I’ve only spent a few 
>> minutes here and there; definitely on the list.
>> 
>> A use case for this sort of thing is also a concern or question. I came 
>> across Pipeline from the PHP League and saw their interruptible processor 
>> and was wondering if something like this would be helpful there - for 
>> pipeline patterns in general: 
>> https://github.com/thephpleague/pipeline/blob/master/src/InterruptibleProcessor.php
>> 
>> While working on another project, saw this line from the PHP array_filter 
>> docs:
>> 
>> "If no callback is supplied, all entries of array equal to FALSE (see 
>> converting to boolean) will be removed."
>> 
>> I’m still field testing the latest iteration of my base project, but wanted 
>> to put a working (non-internals) implementation out there (note this covers 
>> emptiness and falseness for the purposes of the project):
>> 
>> Tests - 
>> https://github.com/8fold/php-shoop/blob/master/tests/RfcObjectCanBeDeclaredFalsifiableTest.php
>> 
>> Interface - 
>> https://github.com/8fold/php-shoop/blob/master/src/FilterContracts/Interfaces/Falsifiable.php
>>  - for our purposes the efToBool would be __toBool
>> 
>> Default implementation - 
>> https://github.com/8fold/php-shoop/blob/master/src/Shooped.php#L216
>> 
>> “Type system” implementation - 
>> https://github.com/8fold/php-shoop/blob/master/src/Filter/TypeAsBoolean.php
>> 
>> Cheers,
>> Josh
>> 
>>> On Aug 9, 2020, at 3:59 PM, tyson 

Re: [PHP-DEV] Microseconds to error log

[Rowan Tommins]

On 31/10/2022 10:16, Craig Francis wrote:
On Sun, 30 Oct 2022 at 17:42, Rowan Tommins  
wrote:


In case of any confusion, I think this should be configurable as
"include microseconds: on / off", not configurable as "enter date
format".



Any reason it can't be configured to use ISO 8601?



That is really a separate question: ISO 8601 actually defines a whole 
set of date/time formats, and allows any fraction of a second you want, 
or none, or even omitting the seconds completely.


My main point is that I don't think it's necessary to complicate the 
error handling routines with handling for arbitrary user-supplied date 
formats; a single on/off ini setting would be a single if statement in 
the C code, and only two possibilities that tools would need to parse if 
they wanted to support both run-time modes.


I guess we could have the setting be "use new date format", and control 
both the precision and whether the format is ISO 8601 compliant, but I'm 
not convinced of the value.


Regards,

--
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Re: RFC [Discussion]: Randomizer Additions

[Tim Düsterhus]

Hi

On 10/29/22 00:44, Jordan LeDoux wrote:

I had a discussion with Tim about this naming topic as well, and want to
convey my suggestion along with the reasoning.

I think the enum should be `Random\IntervalBoundary` with the enum cases:


Yes, I agree this is a much better name for the enum itself and just 
adjusted the implementation and RFC.



`IntervalBoundary::Open`
`IntervalBoundary::Closed`
`IntervalBoundary::OpenRight` or `IntervalBoundary::HalfOpenRight`
`IntervalBoundary::OpenLeft`  or `IntervalBoundary::HalfOpenLeft`



But for the enum members I prefer the existing naming of 
(Closed|Open)(Closed|Open), unless someone has a good argument for a 
different naming scheme:


- It's very explicit, which I consider useful for two reasons which are 
likely related:


(a) I don't have to think about what "OpenRight" means for the left 
boundary.
(b) As not-a-native-speaker-of English I find OpenRight or HalfOpenRight 
not completely obvious and would likely need to look up what exactly 
OpenRight means, whereas ClosedOpen is understandable more intuitively. 
Especially since a half-open interval is sometimes referred to as 
half-open and sometimes as half-closed. The preferred variant might even 
differ across languages.


- It's nicely symmetric from the naming.

- It's the naming used by Prof. Goualard in the Drawing Random 
Floating-Point Numbers from an Interval paper (though in a shortened CC, 
CO, OC, OO variant).


Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Request for Wiki karma

[Jordan LeDoux]

On Mon, Oct 31, 2022 at 10:43 AM Codito - Grzegorz Korba <
grzegorz.ko...@codito.pl> wrote:

>
> I don't want to edit someone else's RFCs, but I saw there are several
> pages related to the process itself, which I find not as helpful as they
> should be  I will work on the docs through the PRs, but wanted to make
> some adjustments on the Wiki pages too, if you don't mind.
>
> I have some small RFC in mind too, but I'll send it separately 
>
> Sorry for the duplicate, wrong click.
>

No worries! I just wanted to make sure there wasn't any confusion. :) I'm
not actually the person that would give wiki karma.

Jordan

Re: [PHP-DEV] Request for Wiki karma

[Codito - Grzegorz Korba]

pon., 31 paź 2022, 18:34 użytkownik Jordan LeDoux 
napisał:

>
>
> On Mon, Oct 31, 2022 at 12:32 AM Codito - Grzegorz Korba <
> grzegorz.ko...@codito.pl> wrote:
>
>> Hi Internals!
>>
>> I would like to ask for Wiki karma (account: codito) in order to be able
>> to
>> edit Wiki pages. I feel like I can help with providing helpful examples or
>> improve existing docs. In the future I'm most probably going to make RFCs
>> too.
>>
>> For those who don't know me, here's my blog post about PHP8.2 new
>> features:
>> https://blog.codito.dev/2022/05/new-in-php-8.2/
>> so you can see how I write. Some of you probably know me from Twitter:
>> https://twitter.com/_Codito_
>>
>> Having those sources you can probably evaluate if you want my help :-)
>>
>> Have a nice day everyone,
>> Grzegorz Korba
>>
>
> Are you asking for wiki karma to work on the documentation? The
> documentation isn't part of the wiki, it has its own github repo. The wiki
> is mainly used for posting RFCs, but generally people with wiki karma don't
> change someone else's RFC with what they think might "improve" it.
>
> If you have an RFC you want to do, you can definitely get wiki karma. :)
> Just want to make sure we're helping you get the thing you're looking for.
>
> Jordan
>


I don't want to edit someone else's RFCs, but I saw there are several pages
related to the process itself, which I find not as helpful as they should
be  I will work on the docs through the PRs, but wanted to make some
adjustments on the Wiki pages too, if you don't mind.

I have some small RFC in mind too, but I'll send it separately 

Sorry for the duplicate, wrong click.

Re: [PHP-DEV] Request for Wiki karma

[Jordan LeDoux]

On Mon, Oct 31, 2022 at 12:32 AM Codito - Grzegorz Korba <
grzegorz.ko...@codito.pl> wrote:

> Hi Internals!
>
> I would like to ask for Wiki karma (account: codito) in order to be able to
> edit Wiki pages. I feel like I can help with providing helpful examples or
> improve existing docs. In the future I'm most probably going to make RFCs
> too.
>
> For those who don't know me, here's my blog post about PHP8.2 new features:
> https://blog.codito.dev/2022/05/new-in-php-8.2/
> so you can see how I write. Some of you probably know me from Twitter:
> https://twitter.com/_Codito_
>
> Having those sources you can probably evaluate if you want my help :-)
>
> Have a nice day everyone,
> Grzegorz Korba
>

Are you asking for wiki karma to work on the documentation? The
documentation isn't part of the wiki, it has its own github repo. The wiki
is mainly used for posting RFCs, but generally people with wiki karma don't
change someone else's RFC with what they think might "improve" it.

If you have an RFC you want to do, you can definitely get wiki karma. :)
Just want to make sure we're helping you get the thing you're looking for.

Jordan

Re: [PHP-DEV] Proposal: Expanded iterable helper functions and aliasing iterator_to_array in `iterable\` namespace

[Larry Garfield]

On Sun, Oct 30, 2022, at 3:25 PM, Tim Düsterhus wrote:
> Hi
>
> On 10/30/22 17:22, Larry Garfield wrote:
>> 2. There are ample use cases for most operations to return an array or a 
>> lazy iterable.  Both totally exist.  I solved that by also having a separate 
>> version of each function, eg, amap() vs itmap().  The former returned an 
>> array, the latter returned a generator that generated the equivalent array.  
>> It would be a fatal design flaw to not account for this.  Yes, this balloons 
>> the number of such functions, which sucks, but that's PHP for you.
>
> Please not. Only provide functions that return an iterable without 
> giving any further guarantees, because …
>
>> A possible alternative would be to always return a lazy iterable in all 
>> circumstances and assume someone can use to_array() or equivalent on the 
>> result if they want it as an array.  (That's effectively what Python 3 does 
>> with comprehensions.)  However, that could have non-trivial performance 
>> impact since generators are slower than plain arrays.
>
> … this works. The users should not need to think about what return type 
> is more useful for their specific use case.
>
> The heavy lifting / optimization should be left to the compiler / 
> engine, similarly how a fully qualified 'is_null()' is also optimized, 
> such that no actual function call happens [1].
>
> Even if this kind of optimization does not happen in the first version, 
> this should not be a reason to clutter the API surface.

I'm open to this approach, but we should be mindful of the ergonomics.  
Specifically, I don't think to_array() as an answer is workable unless we have 
some built-in chaining mechanism, pipes or similar.  Otherwise, you're 
effectively requiring anyone who wants to ensure they have an array (which will 
be a lot of people) to write

to_array(some_stuff_here());

All the time, which is considerably less ergonomic than 

some_stuff_here() |> to_array();

Especially if there's more than one operation involved.  

Side note: Should there instead be to_list() (which implies dropping keys and 
reindexing) and to_assoc() (which implies keeping keys and merging on key if 
appropriate)?  That seems much more self-documenting than to_array(true) or 
whatever.

>> 3. Feel free to borrow liberally, design-wise, from the above code.  There's 
>> a few more methods in there that could be of use, too.  Note, though, that 
>> all are designed to be used with a pipe(), so they mostly return a closure 
>> that has been manually partially applied with everything except the 
>> iterable, so you get a single-argument function, which is what a pipe() or 
>> compose() chain needs.
>> 
>> Third, speaking of pipe, I disagree with Tim that putting the callback first 
>> would be easier for pipe/partials.  If we ever get partials similar to 
>> previously implemented, then the argument order won't matter.  If we get 
>> pipes as I've previously proposed, then none of these functions are directly 
>> usable because they're multi-argument.
>> 
>> The alternative I've considered is somewhat inspired by Elixir (assuming I 
>> understand the little Elixir I've read), in which a function after a |> is 
>> automatically assumed to be partially applying everything but the first 
>> argument.  So $list |> map($callable) translates to map($list, $callable).  
>> I've not decided yet if that's a good way to avoid needing full partial 
>> application or a good way to make horribly confusing code.  But if that were 
>> to happen, it would only work if all of these functions took the iterable, 
>> the "object to be operated on", as their first argument.
>> 
>
> With Haskell, from which my functional programming experience comes, 
> it's the exact inverse: All functions are automatically partially 
> applied [2], thus in a pipe the "missing" parameter comes last, not 
> first as with Elixir.
>
> So I guess there is no right or wrong and it depends on the programming 
> language which variant feels more natural. I still prefer having the 
> callback first for the reasons I've outlined, but in the end I'm happy 
> as long as it's consistent.

Mm, yes, the root question is what kind of auto-partialing we are going to 
have.  Right now we have none, which is problematic for any sort of 
composition, which these iterable functions are going to want to have.  Whether 
we partial from the left or from the right will determine how we order 
parameters for functions we expect to be partialed.  

We should bear in mind that PHP has a couple of features that complicate 
matters; namely optional arguments, variadics, and named arguments.  The 
previous RFC that Joe wrote handled all of those as gracefully as I think is 
possible, but the complexity was apparently too high for too many folks.  He 
didn't seem confident that a less-complex approach was possible, though.

I know this is veering off topic, but one idea I had kicked around that Joe 
didn't like was a function call 

Re: [PHP-DEV] Microseconds to error log

[Craig Francis]

On Sun, 30 Oct 2022 at 17:42, Rowan Tommins  wrote:

> In case of any confusion, I think this should be configurable as
> "include microseconds: on / off", not configurable as "enter date format".
>


Any reason it can't be configured to use ISO 8601?

Apache 2.4 allows you to use `LogFormat "...
[%{%Y-%m-%dT%H:%M:%S}t.%{msec_frac}t] ..." format_name`

https://httpd.apache.org/docs/trunk/mod/mod_log_config.html

And MySQL uses "-MM-DDThh:mm:ss.uu":

https://dev.mysql.com/doc/refman/8.0/en/error-log-format.html#error-log-format-system-variables

When I'm doing some quick log checking, I often forget that PHP uses a
different date format... admittedly, it can help having the month spelled
out, so no one accidentally thinks it's the American format :-)

Craig

[PHP-DEV] Request for Wiki karma

[Codito - Grzegorz Korba]

Hi Internals!

I would like to ask for Wiki karma (account: codito) in order to be able to
edit Wiki pages. I feel like I can help with providing helpful examples or
improve existing docs. In the future I'm most probably going to make RFCs
too.

For those who don't know me, here's my blog post about PHP8.2 new features:
https://blog.codito.dev/2022/05/new-in-php-8.2/
so you can see how I write. Some of you probably know me from Twitter:
https://twitter.com/_Codito_

Having those sources you can probably evaluate if you want my help :-)

Have a nice day everyone,
Grzegorz Korba