axelson ( Jason Axelson )

Using "sourcer" as a command line application?

Hi! Currently, no, there is no command line wrapper that allows you to do that. It is relatively easy to write an utility that reads a file into a string, calls sourcer_indent:all() on it and writes the result in another file.

Note that I haven't been working on this in a while, so I can't guarantee it works with newer Erlang versions, nor that it matches recent versions of the Emacs formatter (which it did when it was written).

jacksonbenete

comment created time in an hour

pull request commentdanielo515/tiddlypouch

Dockerfile and scripts for development

Got integration tests running, ran yarn run nodemon ./node_modules/tiddlywiki/tiddlywiki.js ./wiki --build (is this the right way?) to populate ./output. The png diff indicates that installing some fonts might get that test green too...

schnittchen

comment created time in an hour

issue openederlang/sourcer

Using "sourcer" as a command line application?

Hello there,

Sorry if my question doesn't makes sense, I'm new to Erlang and even newer to rebar3.

I've been looking for a "code formatter", I've tried rebar3_format and rebar3_steamroller, but seems like they need to be called as "rebar3 <plugin_name>" from the project root, and they format the entire project. If I enter in the apps/src/ directory and try to call it in there it fails, because it doesn't find the command.

In README, sourcer says "The actual work is done by this application. It is meant to be LSP-agnostic so that it can be used in other contexts and tools.".

Does being used in other context and tools means that it can be somehow compiled and used without calling "rebar3"?

What I'm looking for is to be able to call sourcer file_name.erl in command line and it returns an indented file as output. As I've said, I'm new to rebar3, I don't know if it can be compiled and called in command line like this.

created time in 2 hours

issue openedelixir-lsp/elixir-ls

Hover document still show documentation when assign value to variable that is the same name in built-in function

Environment

Elixir & Erlang versions (elixir --version): 1.12.1
Operating system: Windows 10 64-bit
Editor or IDE name (e.g. Emacs/VSCode): VSCode
Editor Plugin/LSP Client name:

Description

Consider the example code below:

defmodule Vector do
  @spec magnitude(Vec2.t()) :: number()
  def magnitude(%Vec2{} = v), do: :math.sqrt(:math.pow(v.x, 2) + :math.pow(v.y, 2))

  @spec normalize(Vec2.t()) :: Vec2.t()
  def normalize(%Vec2{} = v) do
    length = magnitude(v)
    %{v | x: v.x / length, y: v.y / length}
  end
end

When I hover mouse on length in function normalize, the hover document will show length built-in document. But since magnitude function has type spec. I expected the hover should show it as a number or not show when hover on length variable.

created time in 2 hours

issue openednerves-project/toolchains

Bump Linux kernel headers to 4.19

They're currently on Linux 4.14. As systems move to 5.4 and 5.10, Linux 4.14 is seeming old and it feels like time to bump them to the next LTS release.

I don't believe this affects any official Nerves systems.

created time in 3 hours

PR opened erlang-ls/erlang_ls

Add support for hover on record expression.

With this change you can hover over a record expression, and get a definition of the record.

+67 -5

1 commit in ztion/erlang_ls/tree/hover_record erlang-ls/erlang_ls/tree/main

0 comment

7 changed files

pr created time in 6 hours

pull request commentfhunleth/muontrap

MuonTrap.Daemon new features

After thinking about it the past two weeks, my opinion on adding additional callbacks (non-telemetry ones) to the daemon options is not something I want. Part of this is due to a desire to keep the Daemon module as short and simple as possible and this was starting to add a decent amount of code (especially the start/exit callback one). I think that if you want to do something custom with callbacks that the code will be less subtle if you make your own Daemon GenServer. They also invite adding additional options. For example, if I could rewind to when I first wrote this, I could have chosen an :on_output callback and made a logging callback be the default. Since Daemon breaks output up based on lines, then if you don't what that, that's another option PR. And is stdout the best way for a long running program to communicate anyway? I keep on thinking of issues. Admittedly they might be small, but the line for where to stop adding options and encourage writing a new module needs to be drawn somewhere.

As for :telemetry, I'm still learning on a different project so my opinions aren't set yet. It does seem useful to define a :telemetry API that sends events when the daemon starts and exits and on line output. I'm pretty sure that I'd be interested in monitoring these events if they existed in my own programs. Since I haven't formed strong opinions on :telemetry, I'm going to wait on adding this myself, but if someone wants to start a PR to experiment with an API, then I'd be for that.

So in summary, I'd like to push forward on getting experience with :telemetry. It seems promising. If no one sends a PR up in the next month or so, I'll start one.

I hope this makes sense and thanks for hanging through this as we figure it out together.

alde103

comment created time in a day

push eventandyl/rfx

andyl

commit sha d40616053031cdebd8ddbd1201eae6cf11dca52b

Add content