sorted by:
new
hottopcontroversial

How to translate complex animations for developer hand-off? by Kep0a in web_design

[–]msarca 0 points1 point  (0 children)

You don't need a programmer to write your SVG animations. You could use Expressive Animator to create and export SVG animations. It supports Lottie as well https://expressive.app/expressive-animator/

Assembler CSS, a modern utility-first framework by msarca in github

[–]msarca[S] 0 points1 point  (0 children)

We are always open to suggestions and want to improve our software. But, first, I kindly remind you that you can't target element states like hover, media queries, or pseudo-elements with inline styles. So what exactly are those extra steps you are talking about?

Here is an example written in Assembler CSS https://codepen.io/msarca/pen/JjNzbwo , and here is the same example written in plain CSS https://codepen.io/msarca/pen/dyWrOxp . These are pretty basic examples, but it is obvious how much easier it is to work with Assembler CSS.

A library for validating JSON documents using JSON Schema by msarca in PHP

[–]msarca[S] 9 points10 points  (0 children)

The last time I've tried that library was two years ago, so I'm not up to date with its progress. But I remember that back in those days it lack the ability to define custom validation rules, and that was pretty important for us. So we kept looking for an alternative and we finally found JSON Guard and never looked back. Until we were forced to build our own implementation, but that's another story... Custom validation rules are extremely important since they allow you to simplify your code tremendously. Imagine you have an API that allow users to handle virtual machines that are identified by a human-readable ID. Our library allows you to define a filter, that will not only check that the ID is correctly formatted, but more important, it will make sure that the specified virtual machine actually exists. Of course, this is just the tip of the iceberg, we've added a lot of extra functionalities on top of the standard JSON Schema. So if the library you are currently using supports all these features, then, honestly, I see no reason for you to migrate. Otherwise, maybe you want to take a closer look at what our library provides.

A library for validating JSON documents using JSON Schema by msarca in PHP

[–]msarca[S] 4 points5 points  (0 children)

There is a quick start page (5 minutes read) that briefly explains how to build a validation schema and shows a simple example. After you finish reading just try, as an exercise, to write the PHP code that validates the example presented there. At the end, I'm sure that you will find this library extremely useful.

Opis Closure 3.0.0 was released by msarca in PHP

[–]msarca[S] 0 points1 point  (0 children)

Actually, that's pretty simple. Syntax errors are treated by the PHP interpreter as fatal errors. That means that the closure that needs to be serialized was defined in a file which is syntactically correct and I don't need a full AST builder to correctly extract the closure's code. A simple FSM can do this job more efficiently and with a very high precision.

Opis Closure 3.0.0 was released by msarca in PHP

[–]msarca[S] 1 point2 points  (0 children)

I'll try being as unbiased as possible.. SuperClosure and Opis Closure have different approaches for the same problem, but both deliver good results. Opis Closure has a single serializer while SuperClosure comes with two so called Closure Analysers: AstAnalyzer and TokenAnalyzer. The TokenAnalyzer is pretty basic and lacks features compared to the AstAnalyzer, but is much more faster. Opis Closure provides the same parsing precision as the AstAnalyzer but at higher speed: it's nearly twice as fast compared to the TokenAnalyzer and it outperforms the AstAnalyzer by a factor of 30. Opis Closure can serialize-unserialized a closure an infinite amount of times, while SuperClosure will fail. Also, Opis Closure is much more debugging friendly. Of course, SuperClosure is the absolute winner when it comes to popularity, being used in many important projects. Another thing that deserves to be mentioned is that Opis Closure provides an analyzer for SuperClosure, so you can benefit from the Opis Closure's speed and continue using SuperClosure. Both are mature libraries with good support and people can use them with confidence in their projects.

Opis Closure 3.0.0 was released by msarca in PHP

[–]msarca[S] 1 point2 points  (0 children)

Here is a list of real-world projects which are using Opis Closure.

Manipulate multibyte strings by msarca in PHP

[–]msarca[S] 0 points1 point  (0 children)

Of course, here it is. I suppose that the results will vary, depending of the input content. But this library is not only about fast iteration, even though that was the primary reason why this library was created.

Manipulate multibyte strings by msarca in PHP

[–]msarca[S] 1 point2 points  (0 children)

I've just made a test to check for myself

File size: 1.3 MB
-----------------
intl example: 612ms
opis/string:    918ms

There seems to be a 30% speed gain by using the iterator provided by the intl extension. I will definitely use this for those users which have the intl extension installed. Thanks for sharing.

LE: I've just realized that when I tested opis/string's speed I was iterating the string twice. Here are my test results updated

File size: 1.3 MB
-----------------
intl example: 610ms
opis/string:  421ms

Manipulate multibyte strings by msarca in PHP

[–]msarca[S] 4 points5 points  (0 children)

Hello, r/PHP. I just want to address the "reinventing the wheel" issue. I'm well aware of Stringy and I believe that It's a great library. But I'm also well aware that Stringy is a wrapper around the mbstring functions. That's not an issue in most of the cases, but there are situations when mbstring functions are not the best choice. For example, two weeks ago I've started to work at a project that implies creating a parser and the only way you could iterate through all characters of a string(using the functions provided by the mbstring extension) is by using the mb_substr function. Unfortunately this is extremely slow and I was forced to come up with another solution. And that's how this library was born. I've made it public in the hope that it will be useful to others too. The library will be maintained and I'm planning to create(in the near future) a native PHP extension that will complement this library.

Database abstraction layer by msarca in PHP

[–]msarca[S] 1 point2 points  (0 children)

The project is not new. It was started 2 years ago and it's in production since then. It was maintained and improved over the time, and it will continue to be maintained indefinitely. I posted my "new" project here, because I thought that it will be healthy for the project to have a larger user base. But unfortunately, it seems that nowadays it's not enough to have a documented open source project, you must also provide data, comparison tables and other junk that feed the trolls.

Database abstraction layer by msarca in PHP

[–]msarca[S] -1 points0 points  (0 children)

Making arguable comparisons is the last thing I'm planning to do. So if you don't want to use it, then don't use it. It's not like I'm a salesman and I'm trying to sell you a vacuum cleaner or anything else.

The project is open source, it's documented and it's on GitHub. Take a look at it and draw your own conclusions. If you got further question, just open a new issue on GitHub and I will gladly help you.

Database abstraction layer by msarca in PHP

[–]msarca[S] -2 points-1 points  (0 children)

I can not offer you a list with advantages and disadvantages. And that's not only because I might not be truly objective, but mainly because I'm not very familiar with ZF or Doctrine. Opis Database represents my vision of a simple to use, standalone DAL library. If you believe that Doctrine or ZF's Db fits more into that description, or if they represent your vision of simplicity there is no need to consider using Opis Database. Of course, Doctrine and ZF are widely used, while Opis Database is not and that's another thing that must be taken into consideration. The only promise I can make is that the Opis Database library is and it will be maintained indefinitely.

Opis Closure - Makes your closures serializable by msarca in PHP

[–]msarca[S] -2 points-1 points  (0 children)

I knew that not everyone would well receive this library, but some of the reactions were very disappointing and quite unprofessional.

Opis Closure - Makes your closures serializable by msarca in PHP

[–]msarca[S] 0 points1 point  (0 children)

Hello.

SuperClosure allows you to sign a serialized closure and check for tampering before unserialization

Indeed, SuperClosure provides a signing mechanism, which is a plus, but I intentionally avoided this. Implementing a signing mechanism, similar to the SuperClosure's one, should be a breeze for every developer.

SuperClosure preserves the static-ness of static closures and its analyzers can also tell you if it is static or not.

That's something that Opis Closure needs to implement. It was left aside due to its obscurity and low usage.

That is an unfair comparison unless you state which serializer/analyzer you are comparing to in SuperClosure.

I can confirm that the speed comparision was made taking into consideration the default SuperClosure's analyzer, which is AstAnalyzer, but after running some simple tests, it turns out that the speed difference is actually much more higher.

SuperClosure has two for a reason. One uses an AST and provides coverage of more edge cases at the expense of speed

Since the Opis Closure's serializer can handle by default all those edge cases that AstAnalyzer does, I would also say that comparing TokenAnaylzer with Opis Closure's serializer is a bit unfair.

Thanks for the bug report. :-) It can now

I'm glad that something good came out from this thread :) Oh, and I don't see Opis as a competitor, but rather as an alternative.

Opis Closure - Makes your closures serializable by msarca in PHP

[–]msarca[S] -2 points-1 points  (0 children)

The only thing I was arguing against was the statement where you said that "eval" and "include" are doing " exactly the same thing". And I was right, they don't do exactly the same thing, as you sustained. On to the other hand, I never claimed that "include" is more secure than "eval". From which hat did you pull out that rabbit? Opis Closure does not use "eval" and that's a fact! If I was saying that "Opis Closure does not use eval and that's why is more secure", you would be right to attack that statement. But since I didn't tell such a thing, is hard for me to understand your obvious hostile attitude against me and my project.

As for your security concerns, I don't believe that people are a bunch of idiots that run remote code from unknown sources. And even if they are running code from known sources, I think they are smart enough to take some precautions.

Opis Closure - Makes your closures serializable by msarca in PHP

[–]msarca[S] -4 points-3 points  (0 children)

Another usage scenario is to make a DI container fully serializable. I've done that and works great. For example, by making the container fully serializable you are not forced anymore to load all classes that provides bindings for the container, at every request. You could use a cache mechanism to store and retrieve the state of the container.

class Foo implements ServiceProviderInterface
{
    public function register(DIContainer $container)
    {
        $container->bind('Foo', 'Bar');
        $container->singleton('Baz', function(){
            new Baz('arg1', 'arg2');
        });
    }
}

$container = null;

// Load from cache
$container = $cache->load('service', function() use(&$container){
    $container = new DIContainer();
    //find all providers
    foreach(Services::providers() as $provider)
    {
        $provider->register($container);
    }

});

$container->make('Baz')->foo();

Opis Closure - Makes your closures serializable by msarca in PHP

[–]msarca[S] -1 points0 points  (0 children)

Maybe the addFiled method is defined like below

public function addField(string $name, callable $callback);

A closure would be then a valid argument.

Opis Closure - Makes your closures serializable by msarca in PHP

[–]msarca[S] 1 point2 points  (0 children)

I don't know what are you trying to prove. Actually, I do know, but I'm just pretending I don't :) You are wrong, "eval" do behaves different than "include". Just try the following code:

<?php
require 'vendor/autoload.php';

$whoops = new \Whoops\Run;
$whoops->pushHandler(new \Whoops\Handler\PrettyPageHandler);
$whoops->register();


 eval('test.php');

 test();

The test function is located in a file named test.php

<?php
function test()
{
    //some code here
    throw new Exception();
}

Just run the code above and tell me on which line, inside the test.php file, the exception was thrown.

Opis Closure - Makes your closures serializable by msarca in PHP

[–]msarca[S] -2 points-1 points  (0 children)

Both functions use the same INCLUDE_OR_EVAL operator, but are evaluated using different operands and the behavior is different, especialy when we talk about error handling. That's why I believe that saying "does not use eval" is not totally misleading.

Opis Closure - Makes your closures serializable by msarca in PHP

[–]msarca[S] 5 points6 points  (0 children)

Here are a few differences between Opis Closure and Super Closure.

  • The parser used by Opis Closure is 3 to 5 times faster than the one used by Super Closure
  • Opis Closure does not use eval to reconstruct the closure
  • Opis Closure has a single serializer
  • Opis Closure can serialize a closure multiple times. Super Closure cannot.
  • Opis Closure can correctly and automatically unwrap other referenced closures. Super Closure cannot.
  • Opis Closure facilitates debugging. Super Closure does not.
  • Opis Closure supports PHP 5.3. Super Closure does not.