If the tracer can execute code, then the tracer can have side-effects,
which may affect the value of the compilation. So we can put ourselves into
a position where the thing meant to observe the system is now affecting the
system. Of course we can say, "well, don't do that", but I think the value
of adding such capability in the first place has to be really justified.
Especially because the tracer already runs in the same process as the
compilation.
Here is an idea you can try though. An event tracer is just traversing
__CALLER__.tracers and sending an event. So you could change the gettext
macro to send the event that you want:
for trace <- __CALLER__.tracers do
trace.event({:gettext, string}, __CALLER__)
end
And now you can use tracers to collect the messages you need. This will at
least allow you to assess if the functionality is indeed better.
However, my suspicion is that the approaches are not really different. Both
are dispatching events somewhere and both are using mutable state to store
them.
On Sun, Oct 10, 2021 at 18:27 Jonatan Männchen <maennc...@joshmartin.ch>
wrote:
> Hi José,
>
> I'm not sure if this is the best way to do it. Looking through the
> existing extraction mechanism looked a bit "hacky" in my personal opinion.
> I thought I could reduce complexity very much using a compiler tracer.
>
> The approach of the tracer feels right to me, since extracting and
> executing are not done in the same macros/functions. This would separate
> the two functionalities more and would lead to cleaner and more
> understandable code.
>
> I value your opinion very much in this discussion, especially since I have
> no experience with the tracer. Do you think this might be a legit use case?
>
> What are the risks, if a compiler tracer can evaluate/execute arguments?
>
> I agree, that executing functions inside the users codebase might be
> unexpected to the user and should probably be discouraged except when the
> user is made aware of this fact. Reading "scalar" values however, should
> not be an issue.
>
> For example, I think a static analyzer could greatly profit from
> evaluating arguments to a function. (one example could be sobelow checking
> what headers were passed to the "put_secure_headers" plug)
>
> If you think this is a good idea, I would offer to actually work on this :)
>
> Best,
> Jonatan
> José Valim schrieb am Sonntag, 10. Oktober 2021 um 17:34:27 UTC+2:
>
>> Hi Jonatan,
>>
>> Yes, the tracer does not receive the macro arguments, but we did not have
>> a use case for such either. The biggest concern is that we could allow
>> tracers to evaluate and execute arguments and that’s a very risky line to
>> cross.
>>
>> Maybe this is the use case we were waiting for but then we would need to
>> expand if this would actually be better than macros.
>>
>> On Sun, Oct 10, 2021 at 17:20 Jonatan Männchen <maen...@joshmartin.ch>
>> wrote:
>>
>>> Hi All,
>>>
>>> I have recently had some issues with the Gettext library (the issues are
>>> irrelevant for this suggestion) and thought that maybe the Gettext
>>> Extraction could be rebuilt using compiler tracers.
>>>
>>> The basic idea was to collect all modules and gettext calls via a
>>> compiler tracer and replace the existing extractor with that. (See example
>>> in Attachment)
>>>
>>> However, there seems to be no way to access the args for a call for any
>>> of the following trace events: remote_function, remote_macro,
>>> local_function, local_macro.
>>>
>>> Did I overlook something or is there currently no way to access the arg
>>> values?
>>>
>>> If not, I think it could be a great addition to somehow make those
>>> values accessible.
>>>
>>> I'm playing around for the first time with compiler tracers. Therefore
>>> I'm sorry if this request doesn't make sense or this is a completely wrong
>>> approach.
>>>
>>> Thanks & Best,
>>> Jonatan
>>>
>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "elixir-lang-core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elixir-lang-co...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/elixir-lang-core/a51ab9f7-30d3-4fa6-a7a3-b3653bc52470n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/elixir-lang-core/a51ab9f7-30d3-4fa6-a7a3-b3653bc52470n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/0747ff1a-efd1-425f-a047-f5549b3c5f72n%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/0747ff1a-efd1-425f-a047-f5549b3c5f72n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JsL8pQNxtRB5eYWzkRSzxahxR0FRBmtGm-%3DRQew%3D6%3D%2Bw%40mail.gmail.com.
