Re: GHC and the future of Freenode

[Jakub Zalewski]

On Tue Jun 15, 2021 at 3:18 PM CEST, Janek Stolarek wrote:
> Apparently, Freenode deleted all registered users and channels several
> hours ago.

I guess that should solve the problem of communities being split between
Freenode and Libera.

If I may add towards using IRC, even though it may seem archaic towards
newcomers:

- it allows them to join without registration (via web.libera.chat), and
- it allows them to use a client of their choosing (I am not aware of
  any stable Matrix clients beside Element).

From my own experience, Electron-based clients (Element included)
consume unreasonable amounts of RAM:  Element is consuming ~700MiB of
RAM just to stay idle on my machine.  To give a fair comparison, the tab
for irccloud tends to consume ~300MiB.

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

Re: Notes from Ben's "contribute to ghc" discussion

[Jakub Zalewski]

Hi all,
I agree with Elliot that the idea of a mentor is really cool, but may not
be feasible at the moment. While the "on-demand" support (irc, reddit) from
the community is great, I believe that a potential new contributor should
be able to go as far as possible on their own because:
- newcomers may be hesitant to ask dumb questions about GHC (I know I was).
- newcomers may get turned away as the task will seems more complicated
that it is.
- the number of people working full-time on GHC is low.

For that, there needs to be a single and accessible place, where newcomers
can go and learn about ghc internals, the overall process, and what should
the do next to contribute.

Currently, there is wiki on trac, which is sometimes correct, sometimes
outdated, sometimes slightly chaotic, and sometimes difficult to use. In
addition to wiki, every member in the community is actively encouraged to
try out new features in ghc and blog about their experience, which works
perfectly fine for a tightly knit community, but presents an insurmountable
barrier of entry for newcomers.

I proposed using stack overflow, as they are adding a new feature called
[documentation](http://stackoverflow.com/documentation), which allows to
maintain a list of examples for a given tag. For instance, there is a stack
overflow documentation for [haskell](
http://stackoverflow.com/documentation/haskell/topics). Furthermore, I
believe that most potential newcomers will be familiar with using stack
overflow.

Next week, I will start cleaning up the wiki, as there are some pages and
guides for newcomers which are out of date and cause unnecessary headaches
for people that are unfamiliar with ghc. I will figure out and fill any
missing information regarding checking out the source and I will check if
there are any wiki entries that need to be deduplicated.

Best wishes,
Jakub

On Sun, 25 Sep 2016 at 20:47, Elliot Cameron  wrote:

> Oh how the chatroom hath slain its thousands, and email its ten thousands!
> Flattening real, hard-working, deep-thinking people into a few paragraphs
> of letters does such injustice to propinquity that it's a wonder it ever
> works at all!
>
> It's for that very reason I want to voice my approval of the idea of
> mentors. The thing that IRC cannot give you is a (real) name and a real
> face. The true fabric underlying any process or system is the people that
> make it happen. If the relationships of the people are broken, no virtual
> system will ever be able to recover the loss. I can't help but believe that
> the best way to improve the community of contributors is to improve the
> relationships of the people in it. Therefore, having a process of providing
> mentorship could be the most effective way to address the myriad technical
> difficulties of contributing to GHC. Love covers a multitude of wrongs. A
> friendly helper could easily make up for the technical infelicities or
> inexperience. In the long term, the improved strength of community could
> begin to address any technical issues as well.
>
> That said, I am not sure if mentorship is a burden the current "in-crowd"
> would be able to bear. But even with minimal hand-holding the improvement
> to propinquity could have significant effect.
>
> Lastly, as one who is building his business, in part, on the advantage of
> Haskell, I want to express my deep gratitude to both sides of the debate.
> Chris, your efforts to improve the "on-boarding" process are truly
> herculean and a massive investment to the community. Thank you! Matthew,
> and other core devs, your hard work and world-class insight make Haskell
> the technology that it is today and I cannot thank you enough.
>
> Elliot Cameron
>
> On Sun, Sep 25, 2016 at 4:35 AM, Matthew Pickering <
> matthewtpicker...@gmail.com> wrote:
>
>> If we loop this discussion back to the original post. There is a
>> suggestion in there which seems to be what you are looking for.
>>
>> >  Have a GHC StackOverflow on haskell.org   (Jacob Zalewski
>> jakz...@gmail.com offers to do this! – thank you).  It has a useful new
>> Documentation feature.   Eg this would be good for “how do I look up a
>> RdrName to get a Name… there seem to be six different functions that do
>> that”.
>>
>> It is also probably lost that I said there was a phabricator module
>> 'ponder' which gives this kind of functionality so it should be quick
>> and easy to setup.
>>
>> Matt
>>
>> On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar
>>  wrote:
>> >
>> >
>> > On 25 September 2016 at 12:48, Joachim Breitner <
>> m...@joachim-breitner.de>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> > It will be great to have something like that. Something that you
>> >> > figure out digging at ghc trac wiki pages, mailing lists, google
>> >> > search etc will be a few minutes job for a mentor. It may be a bit
>> >> > taxing on the mentors but they can limit how many newbies they are
>> >> > mentoring and also breed new 

Re: Building a minimal/essential GHC

[Jakub Zalewski]

Hi Adam,
thank you for your reply; I've looked into HaLVM code and it is really
helpful.

After disabling some incompatible packages (in a similar fashion to HaLVM)
from ghc.mk I got to an issue that configure for ghc stage2 requires those
packages.

How did you solve that problem in HaLVM? Is it solved by calling parts of
the ghc build system from within the top Makefile in the HaLVM repository?

Best wishes,
Jakub


On Fri, Jul 3, 2015 at 12:07 AM Adam Wick aw...@galois.com wrote:

 Hi Jakub -

 You will find that many of these questions are things we’ve had to address
 in the HaLVM (http://github.com/GaloisInc/HaLVM). You may want to look in
 that code base for information on what we considered minimal and how we got
 around some of the build system and other issues a minimal build requires.


 - Adam

 On Jul 2, 2015, at 1:20 PM, Jakub Zalewski jakz...@gmail.com wrote:

 Dear all,
 I am working on porting GHC to [native client](
 https://developer.chrome.com/native-client), which has some degree of
 POSIX-compliance.

 I was thinking about building just the minimal/most essential parts of GHC
 that is enough to compile simple Haskell programs.

 I wanted to ask which parts of GHC are the most essential and sufficient
 enough to compile a simple Haskell program, for instance to compile `main =
 putStrLn Hello, world!`?

 I also wanted to ask how to force a GHC build without a particular package
 that comes by default, for instance how to build GHC without the `unix`
 package?

 Best wishes,
 Jakub

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



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

Building a minimal/essential GHC

[Jakub Zalewski]

Dear all,
I am working on porting GHC to [native client](
https://developer.chrome.com/native-client), which has some degree of
POSIX-compliance.

I was thinking about building just the minimal/most essential parts of GHC
that is enough to compile simple Haskell programs.

I wanted to ask which parts of GHC are the most essential and sufficient
enough to compile a simple Haskell program, for instance to compile `main =
putStrLn Hello, world!`?

I also wanted to ask how to force a GHC build without a particular package
that comes by default, for instance how to build GHC without the `unix`
package?

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

RTS dependency on POSIX signals

[Jakub Zalewski]

Dear all,

I am working on porting GHC to [native client](
https://developer.chrome.com/native-client) and I am currently trying to
figure out how to port the RTS.

On POSIX systems RTS seems to depend on two POSIX signals: timer signal and
interrupt signal; while native client has very limited POSIX signal support
--- for instance it does not define *siginfo_t* (which is referenced in the
base package).

So far, I know how to deal with the dependency on the timer signal, as
while browsing the source code in rts/posix/Itimer.c, I noticed that on iOS
the timer is not using POSIX signals to implement the timer signal.

I wanted to ask if there are any other POSIX signal dependencies in the
RTS, and would it safe to disable any signal handling in the RTS if I know
that there will be no interrupt signals sent to the RTS?

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