Re: How to navigate around the source tree?

[Alan & Kim Zimmerman]

I use `hasktags -b .` in the compiler directory, and it generates a `tags`
file with lines in it like

```
tags\021080:mkHsPar ./GHC/Hs/Utils.hs 142
tags\021081:mkHsParPV ./parser/RdrHsSyn.hs 1920
tags\021082:mkHsParPV ./parser/RdrHsSyn.hs 2019
tags\021083:mkHsParPV ./parser/RdrHsSyn.hs 2072
tags\021084:mkHsParPV ./parser/RdrHsSyn.hs 2154
```

This gives the full path, and emacs is happy.
And of course in this example mkHsParPV does in fact have multiple
definitions, it is a class method.

Alan

On Thu, 24 Oct 2019 at 12:48, Andreas Klebinger 
wrote:

> Hello devs,
>
> I also often jump to files. In my case usually using VS Code using Ctr+P
> as well which searches for files by name.
> While I can check which folder a file is in in the case of duplicates it
> is a overhead which this refactor forces onto me.
>
> While there are workarounds, both for my case as for Matts. It's worth
> asking if requiring these workarounds is better
> than just accepting redundant prefixes on module names.
>
> Personally I would prefer unique file names even at the cost of redundancy.
> I rarely add import statements/full module names, but I *very* often jump
> to files.
>
> Cheers
> Andreas
>
> Bryan Richter schrieb am 23.10.2019 um 18:00:
>
> Duplicate record fields is going to make this a bigger problem. Vim does
> support duplicate tags (:tselect and :tjump and related bindings), but
> hopefully haskell-ide-engine will one day provide us with semantic tags and
> solve this problem once and for all!
>
> On Wed, 23 Oct 2019, 17.49 Matthew Pickering, 
> wrote:
>
>> Thanks Omer, Sylvain and Sebastian
>>
>> .
>>
>> I just configured my editor to use fzf and now I can use the `:GFiles`
>> command to perform fuzzy search on files which is probably better than
>> tags. If anyone else is using NixOS, all I had to do was add the
>> `fzf-vim` plugin to the vim configuration.
>>
>> Cheers,
>>
>> Matt
>>
>> On Wed, Oct 23, 2019 at 2:54 PM Ömer Sinan Ağacan 
>> wrote:
>> >
>> > I use a file finder (fzf) for jumping to files. Because module names
>> follow file
>> > paths to jump to e.g. StgToCmmUtils.Utils I usually type
>> `stgcmmutils` and
>> > fzf finds the correct file `compiler/GHC/StgToCmm/Utils.hs`.
>> >
>> > When generating tags I omit module names for this reason, it's easy
>> with a good
>> > file finder to jump to modules already, no need to generate tags for the
>> > modules.
>> >
>> > fast-tags commands I use:
>> >
>> > - When working on the compiler:
>> >
>> >   $ fast-tags --no-module-tags driver ghc compiler
>> >
>> > - When working on the RTS:
>> >
>> >   $ fast-tags --no-module-tags driver ghc compiler
>> >   $ ctags --append -R rts/**/*.c rts/**/*.h includes/**/*.h
>> >
>> > - When working on the libraries:
>> >
>> >   $ fast-tags --no-module-tags driver ghc compiler libraries
>> >
>> > Ömer
>> >
>> > Sebastian Graf , 23 Eki 2019 Çar, 16:49 tarihinde
>> > şunu yazdı:
>> > >
>> > > FWIW, I'm using VSCode's fuzzy file search with Ctrl+P (and vim's
>> equivalent) rather successfully. Just tried it for Hs/Utils.hs by typing
>> 'hsutils.hs'. It didn't turn up as the first result in VSCode, but it in
>> vim.
>> > >
>> > > Am Mi., 23. Okt. 2019 um 14:27 Uhr schrieb Matthew Pickering <
>> matthewtpicker...@gmail.com>:
>> > >>
>> > >> I use `fast-tags` which doesn't look at the hierarchy at all and I'm
>> > >> not sure what the improvement would be as the names of the modules
>> > >> would still clash.
>> > >>
>> > >> If there is some other recommended way to jump to a module then that
>> > >> would also work for me.
>> > >>
>> > >> Matt
>> > >>
>> > >>
>> > >> On Wed, Oct 23, 2019 at 12:08 PM Sylvain Henry 
>> wrote:
>> > >> >
>> > >> > Hi,
>> > >> >
>> > >> > How do you generate your tags file? It seems to be a shortcoming
>> of the
>> > >> > generator to not take into account the location of the definition
>> file.
>> > >> >
>> > >> >  > Perhaps `HsUtils` and `StgUtils` would be appropriate to
>> > >> > disambiguate`Hs/Utils` and `StgToCmm/Utils`.
>> > >> >
>> > >> > We are promoting the module prefixes (`Hs`, `Stg`, `Tc`, etc.) into
>> > >> > proper module layers (e.g. `HsUtils` becomes `GHC.Hs.Utils`) so it
>> would
>> > >> > be redundant to add the prefixes back. :/
>> > >> >
>> > >> > Cheers,
>> > >> > Sylvain
>> > >> >
>> > >> > On 23/10/2019 12:52, Matthew Pickering wrote:
>> > >> > > Hi,
>> > >> > >
>> > >> > > The module rework has broken my workflow.
>> > >> > >
>> > >> > > Now my tags file is useless for jumping for modules as there are
>> > >> > > multiple "Utils" and "Types" modules. Invariable I am jumping to
>> the
>> > >> > > wrong one. What do other people do to avoid this?
>> > >> > >
>> > >> > > Can we either revert these changes or give these modules unique
>> names
>> > >> > > to facilitate that only reliable way of navigating the code base.
>> > >> > > Perhaps `HsUtils` and `StgUtils` would be appropriate to
>> disambiguate
>> > >> > > `Hs/Utils` and `StgToCmm/Utils`.
>> > >> > >
>> > >> > > Cheers,

ghc, rts/Linker.c, OpenBSD and WXNEEDED and NOPIE

[Matthias Kilian]

Hi,

tl;dr: with shared / dynamic libs, is anything from rts/Linker.c
still in use? If so, where and why?

I hope this hasn't already been discussed in the past, and I apolotzie
if all this is no longer relevant for ghc-8.8 or newer (I'm still
at 8.6)...

On OpenBSD, I had to explicitely mark ghc as WXNEEDED (i.e. allow
it to map pages both as writable and executable), which I would
like to get rid of. Likewise, I had to do some dances to explicitely
disable PIE. If my memory doesn't fail completely, most (if not
all) oft his was because of rts/Linker.c mmapping objects to be
loaded at runtime and kind of simulating what dlopen() does for
shared objects.

Recently, thanks to Greg Steuck (who helped me a lot with this),
we updated our ghc port to ghc-8.6 and also enabled shared (or
dynamic, if you prefer this term) libraries.

So my hope was that the code in rts/Linker.c were no longer used
(because dynamic loading as done by ghci or template Haskell) could
be done with dlopen().

However, after building ghc-8.6 with all the WXNNEDED stuff removed,
and running ghci from this build, I still get an abort because pages
are mapped both writable and executable (I've configured my system
to abort processes when a W^X violation happens). Here's a backtrace
in case it's helpfull at all:

#0  _thread_sys___syscall () at -:3
#1  0x0002010bb179 in _libc_mmap (addr=Variable "addr" is not available.) 
at /usr/src/lib/libc/sys/mmap.c:47
#2  0x00021be22374 in mmapForLinker (bytes=Variable "bytes" is not 
available.) at rts/Linker.c:1029
#3  0x00021be3e99b in m32_allocator_init () at rts/linker/M32Alloc.c:160
#4  0x0002fd518be1 in cimc_info () from 
/usr/local/lib/ghc/bin/../ghci-8.6.4/libHSghci-8.6.4-ghc8.6.4.so
#5  0x in ?? ()

Any thougts about this?

And, since W|X (and nopie) isn't good on any system: is anyone
working on getting rid of this for other unixes?

Thanks in advance for any help.

Ciao,
Kili
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Debugging specialization

[Alexis King]

Hi all,

I am trying to understand why GHC is not specializing an imported INLINABLE 
instance method, and the information provided by -ddump-spec 
-Wall-missed-specialisations has not been enough to help me figure it out. Is 
there some easy/well-trodden way that I could build GHC with some additional 
instrumentation in place to help me better understand the decisions being made 
by the specializer, or is -ddump-spec the most granularity available?

I’ve noticed that Specialise.hs has handful of pprTrace calls sprinkled about, 
but they are all commented out. Is the recommended method to just uncomment 
these calls and rebuild GHC?

Thanks,
Alexis

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to navigate around the source tree?

[Andreas Klebinger]

Hello devs,

I also often jump to files. In my case usually using VS Code using Ctr+P
as well which searches for files by name.
While I can check which folder a file is in in the case of duplicates it
is a overhead which this refactor forces onto me.

While there are workarounds, both for my case as for Matts. It's worth
asking if requiring these workarounds is better
than just accepting redundant prefixes on module names.

Personally I would prefer unique file names even at the cost of redundancy.
I rarely add import statements/full module names, but I *very* often
jump to files.

Cheers
Andreas

Bryan Richter schrieb am 23.10.2019 um 18:00:

Duplicate record fields is going to make this a bigger problem. Vim
does support duplicate tags (:tselect and :tjump and related
bindings), but hopefully haskell-ide-engine will one day provide us
with semantic tags and solve this problem once and for all!

On Wed, 23 Oct 2019, 17.49 Matthew Pickering,
mailto:matthewtpicker...@gmail.com>> wrote:

Thanks Omer, Sylvain and Sebastian

.

I just configured my editor to use fzf and now I can use the `:GFiles`
command to perform fuzzy search on files which is probably better than
tags. If anyone else is using NixOS, all I had to do was add the
`fzf-vim` plugin to the vim configuration.

Cheers,

Matt

On Wed, Oct 23, 2019 at 2:54 PM Ömer Sinan Ağacan
mailto:omeraga...@gmail.com>> wrote:
>
> I use a file finder (fzf) for jumping to files. Because module
names follow file
> paths to jump to e.g. StgToCmmUtils.Utils I usually type
`stgcmmutils` and
> fzf finds the correct file `compiler/GHC/StgToCmm/Utils.hs`.
>
> When generating tags I omit module names for this reason, it's
easy with a good
> file finder to jump to modules already, no need to generate tags
for the
> modules.
>
> fast-tags commands I use:
>
> - When working on the compiler:
>
>   $ fast-tags --no-module-tags driver ghc compiler
>
> - When working on the RTS:
>
>   $ fast-tags --no-module-tags driver ghc compiler
>   $ ctags --append -R rts/**/*.c rts/**/*.h includes/**/*.h
>
> - When working on the libraries:
>
>   $ fast-tags --no-module-tags driver ghc compiler libraries
>
> Ömer
>
> Sebastian Graf mailto:sgraf1...@gmail.com>>, 23 Eki 2019 Çar, 16:49 tarihinde
> şunu yazdı:
> >
> > FWIW, I'm using VSCode's fuzzy file search with Ctrl+P (and
vim's equivalent) rather successfully. Just tried it for
Hs/Utils.hs by typing 'hsutils.hs'. It didn't turn up as the first
result in VSCode, but it in vim.
> >
> > Am Mi., 23. Okt. 2019 um 14:27 Uhr schrieb Matthew Pickering
mailto:matthewtpicker...@gmail.com>>:
> >>
> >> I use `fast-tags` which doesn't look at the hierarchy at all
and I'm
> >> not sure what the improvement would be as the names of the
modules
> >> would still clash.
> >>
> >> If there is some other recommended way to jump to a module
then that
> >> would also work for me.
> >>
> >> Matt
> >>
> >>
> >> On Wed, Oct 23, 2019 at 12:08 PM Sylvain Henry
mailto:sylv...@haskus.fr>> wrote:
> >> >
> >> > Hi,
> >> >
> >> > How do you generate your tags file? It seems to be a
shortcoming of the
> >> > generator to not take into account the location of the
definition file.
> >> >
> >> >  > Perhaps `HsUtils` and `StgUtils` would be appropriate to
> >> > disambiguate`Hs/Utils` and `StgToCmm/Utils`.
> >> >
> >> > We are promoting the module prefixes (`Hs`, `Stg`, `Tc`,
etc.) into
> >> > proper module layers (e.g. `HsUtils` becomes
`GHC.Hs.Utils`) so it would
> >> > be redundant to add the prefixes back. :/
> >> >
> >> > Cheers,
> >> > Sylvain
> >> >
> >> > On 23/10/2019 12:52, Matthew Pickering wrote:
> >> > > Hi,
> >> > >
> >> > > The module rework has broken my workflow.
> >> > >
> >> > > Now my tags file is useless for jumping for modules as
there are
> >> > > multiple "Utils" and "Types" modules. Invariable I am
jumping to the
> >> > > wrong one. What do other people do to avoid this?
> >> > >
> >> > > Can we either revert these changes or give these modules
unique names
> >> > > to facilitate that only reliable way of navigating the
code base.
> >> > > Perhaps `HsUtils` and `StgUtils` would be appropriate to
disambiguate
> >> > > `Hs/Utils` and `StgToCmm/Utils`.
> >> > >
> >> > > Cheers,
> >> > >
> >> > > Matt
> >> > > ___
> >> > > ghc-devs mailing list
> >> > > ghc-devs@haskell.org 
> >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >> > ___
> >> > ghc-devs mailing list
> >>