Have anybody written support for DUB project types in Emacs' projectile?

See: https://www.projectile.mx/en/latest/projects/#adding-custom-project-types

On Monday, 18 November 2019 at 23:06:14 UTC, Per Nordlöw wrote:
> Have anybody written support for DUB project types in Emacs' projectile?
>
> See: https://www.projectile.mx/en/latest/projects/#adding-custom-project-types

Normally it should be as easy as this:

(projectile-register-project-type
 'dub '("dub.json" "dub.sdl")
 :compile "dub compile"
 :test "dub test"
 :run "dub run")

But it doesn't work for me and I cannot figure out why.

On Saturday, 13 June 2020 at 19:27:53 UTC, Jean-Louis Leroy wrote:
> On Monday, 18 November 2019 at 23:06:14 UTC, Per Nordlöw wrote:
>> Have anybody written support for DUB project types in Emacs' projectile?
>>
>> See: https://www.projectile.mx/en/latest/projects/#adding-custom-project-types
>
> Normally it should be as easy as this:
>
> (projectile-register-project-type
>  'dub '("dub.json" "dub.sdl")
>  :compile "dub compile"
>  :test "dub test"
>  :run "dub run")
>
> But it doesn't work for me and I cannot figure out why.

The command is `dub build` which will build the project from the current work dir. You can set another work dir with arg `--root FOLDER` if needed. Same for `dub test` and `dub run`.

Kind regards
Andre

On Sunday, 14 June 2020 at 09:11:58 UTC, Andre Pany wrote:
> On Saturday, 13 June 2020 at 19:27:53 UTC, Jean-Louis Leroy wrote:
>> On Monday, 18 November 2019 at 23:06:14 UTC, Per Nordlöw wrote:
>>> Have anybody written support for DUB project types in Emacs' projectile?
>>>
>>> See: https://www.projectile.mx/en/latest/projects/#adding-custom-project-types
>>
>> Normally it should be as easy as this:
>>
>> (projectile-register-project-type
>>  'dub '("dub.json" "dub.sdl")
>>  :compile "dub compile"
>>  :test "dub test"
>>  :run "dub run")
>>
>> But it doesn't work for me and I cannot figure out why.
>
> The command is `dub build` which will build the project from the current work dir. You can set another work dir with arg `--root FOLDER` if needed. Same for `dub test` and `dub run`.
>
> Kind regards
> Andre

`dub build` - right, sorry for that. But the real problem (and the reason why I never noticed the compile/build mistake) is that projectile deigns not recognize the project type. Yet I did try it in directories containing a dub project, IOW a `dub.json` was present. I just lived with it, entering the commands manually when I need to restart emacs (which happens maybe once in a week). I should debug this, maybe I'll do that today...

On Sunday, 14 June 2020 at 16:04:32 UTC, Jean-Louis Leroy wrote:
> On Sunday, 14 June 2020 at 09:11:58 UTC, Andre Pany wrote:
>> On Saturday, 13 June 2020 at 19:27:53 UTC, Jean-Louis Leroy wrote:
>>> On Monday, 18 November 2019 at 23:06:14 UTC, Per Nordlöw wrote:
>>>> Have anybody written support for DUB project types in Emacs' projectile?
>>>>
>>>> See: https://www.projectile.mx/en/latest/projects/#adding-custom-project-types
>>>
>>> Normally it should be as easy as this:
>>>
>>> (projectile-register-project-type
>>>  'dub '("dub.json" "dub.sdl")
>>>  :compile "dub compile"
>>>  :test "dub test"
>>>  :run "dub run")
>>>
>>> But it doesn't work for me and I cannot figure out why.
>>
>> The command is `dub build` which will build the project from the current work dir. You can set another work dir with arg `--root FOLDER` if needed. Same for `dub test` and `dub run`.
>>
>> Kind regards
>> Andre
>
> `dub build` - right, sorry for that. But the real problem (and the reason why I never noticed the compile/build mistake) is that projectile deigns not recognize the project type. Yet I did try it in directories containing a dub project, IOW a `dub.json` was present. I just lived with it, entering the commands manually when I need to restart emacs (which happens maybe once in a week). I should debug this, maybe I'll do that today...

OK, projectile checks for the presence of *all* the files in the list. So there:

(defun projectile-dub-project-p ()
  "Check if a project contains a dub.json or dub.sdl file."
  (or (projectile-verify-file "dub.json")
      (projectile-verify-file "dub.sdl")))

(projectile-register-project-type
 'dub #'projectile-dub-project-p
 :compile "dub build"
 :test "dub test"
 :run "dub run")

On Sunday, 14 June 2020 at 17:19:05 UTC, Jean-Louis Leroy wrote:
> [snip]

In case you missed it, I thought you would find this interesting
https://forum.dlang.org/thread/dytpsnkqnmgzniiwkyjr@forum.dlang.org

On Sunday, 14 June 2020 at 18:49:01 UTC, jmh530 wrote:
> On Sunday, 14 June 2020 at 17:19:05 UTC, Jean-Louis Leroy wrote:
>> [snip]
>
> In case you missed it, I thought you would find this interesting
> https://forum.dlang.org/thread/dytpsnkqnmgzniiwkyjr@forum.dlang.org

Nah, I saw it. Well. My take on it has been ready for months but I had to wait for my employer's permission to publish it. They are very open-source friendly, and as a consequence there is a glut of requests for open-sourcing personal projects. I guess I am going to cancel my request...

On the bright side, I just got authorized to contribute my work on function refraction (currently part of openmethods) to bolts. You can see it here: https://github.com/aliak00/bolts/pull/10

On Monday, 15 June 2020 at 13:17:11 UTC, Jean-Louis Leroy wrote:
> [snip]
>
> Nah, I saw it. Well. My take on it has been ready for months but I had to wait for my employer's permission to publish it. They are very open-source friendly, and as a consequence there is a glut of requests for open-sourcing personal projects. I guess I am going to cancel my request...
>

Ah. I suppose that depends implementation/performance/feature differences...

> On the bright side, I just got authorized to contribute my work on function refraction (currently part of openmethods) to bolts. You can see it here: https://github.com/aliak00/bolts/pull/10

I saw when you mentioned it earlier. Though it hasn't been something I've needed as yet, it's good to know that it's there.

This allows the function mixins to work when they are in different modules, right? I don't see a test for that, but it might be useful to include such an example (I'm pretty sure Atila's tardy makes use of a similar functionality when they are in different modules).

It's interesting that many of the examples for refract are like refract!(F, "F") or refract!(answer, "answer"). Would something like
Function refract(alias fun, string localSymbol = __traits(identifier, fun))()
work for you?

On Monday, 15 June 2020 at 16:03:08 UTC, jmh530 wrote:
> On Monday, 15 June 2020 at 13:17:11 UTC, Jean-Louis Leroy wrote:
>> [snip]
>>
>> Nah, I saw it. Well. My take on it has been ready for months but I had to wait for my employer's permission to publish it. They are very open-source friendly, and as a consequence there is a glut of requests for open-sourcing personal projects. I guess I am going to cancel my request...
>>
>
> Ah. I suppose that depends implementation/performance/feature differences...

No, it's just that they are essentially equivalent. I spent some time supporting InterfaceValues to immutable and const classes and objects. Not sure if he has that, I haven't played with tardy yet. OTOH I didn't bother with allocator support.

>
>> On the bright side, I just got authorized to contribute my work on function refraction (currently part of openmethods) to bolts. You can see it here: https://github.com/aliak00/bolts/pull/10
>
> I saw when you mentioned it earlier. Though it hasn't been something I've needed as yet, it's good to know that it's there.
>
> This allows the function mixins to work when they are in different modules, right? I don't see a test for that, but it might be useful to include such an example (I'm pretty sure

You mean an example with two modules?

I plan to write a D blog entry that walks through the pitfalls of cross-module mixing.

> Atila's tardy makes use of a similar functionality when they are in different modules).

Actually we were in contact (and with Ali of course). I pointed him to the part of openmethods that creates functions. He has a 'refraction.d' too. I coined the term 'refraction'. ;-)

> It's interesting that many of the examples for refract are like refract!(F, "F") or refract!(answer, "answer"). Would something like
> Function refract(alias fun, string localSymbol = __traits(identifier, fun))()
> work for you?

Not at all :-D That would return a name in the caller module. In the mixture you want to use only local names, and navigate from there.

Maybe I should change all the examples, including the unit tests, to avoid giving the impression that the original function name is a good default for the localSymbol. In most cases it's not.

On Monday, 15 June 2020 at 17:32:26 UTC, Jean-Louis Leroy wrote:
> [snip]

Thanks, cool.