Re: [elixir-core:5971] Proposal for Random related functions

[eksperimental]

On Fri, 24 Jun 2016 01:13:53 +0200
José Valim  wrote:

> >
> > Please let me know how should I proceed
> > thank you for your feedback
> >  
> 
> For now let's go with the optimizations for Enum.random /
> Enum.take_random. :)
> 

ok. I will submit a PR as soon as I have some spare time

-- 
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/20160624061925.1b97227c.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5970] Proposal for Random related functions

[José Valim]

>
> Please let me know how should I proceed
> thank you for your feedback
>

For now let's go with the optimizations for Enum.random / Enum.take_random.
:)

-- 
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/CAGnRm4%2B-8gAxeABJE_FtkiaU4-9YHb9CvUdQH927NtC3P5u7FA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5969] Proposal: Enum.pad and Enum.pad_zip

[eksperimental]

great, I will look into this, and get back to it with some working
implementation
we can later on can discuss how to do for Stream
cheers

 On Fri, 24 Jun 2016 00:47:47 +0200
José Valim  wrote:

> I believe the proposal above does not fit the current definition of
> pad in Elixir. We use pad for values that are automatically cycled
> and leftover with the semantics in your code.
> 
> I am also not sure if zip_pad or pad_zip are the best names or if it
> would be better to follow the same road as chunk (i.e. discard by
> default, which we already do, and then allow a leftover to be given).
> I honestly don't like the leftover approach though. It is easy to do
> for chunk, because you know the chunk size, but with zip you
> typically do not.
> 
> 
> 
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
> 
> On Fri, Jun 24, 2016 at 12:25 AM, eksperimental
>  > wrote:  
> 
> > Jose could you please give me an answer on this,
> > as I would like to to finally make it into the Elixir.
> >
> > Thank you
> >
> > On Thu, 5 May 2016 11:56:47 +0700
> > eksperimental  wrote:
> >  
> > > Jose,
> > > It was earlier suggested that we should have a function like this.
> > > Could you please have a look at it,
> > > I would have to implement the Stream version of it (I may ask for
> > > guidance as I have worked with it before).
> > >  
> > > >  
> > https://github.com/eksperimental/experimental_elixir/blob/master/lib/enum_pad.ex
> >   
> > > >  
> > https://github.com/eksperimental/experimental_elixir/blob/master/test/enum_pad_test.exs
> >   
> > >
> > > cheers.
> > >
> > >
> > > On Wed, 13 Apr 2016 08:46:10 +0700
> > > eksperimental  wrote:
> > >  
> > > > I asked a while ago if there was a zip-padding function,
> > > >  
> > https://groups.google.com/d/msg/elixir-lang-talk/pil9caRXQnM/-newc1hUAAAJ  
> > > > and there was not, and José suggested that that would be a
> > > > desirable function to have in Enum, which I did... It's been
> > > > there siting for a while and I was actually thinking about
> > > > taking back on this week, to see that there is a similar
> > > > proposal.
> > > >
> > > > It's already a working version,
> > > >  
> > https://github.com/eksperimental/experimental_elixir/blob/master/lib/enum_pad.ex
> >   
> > > >  
> > https://github.com/eksperimental/experimental_elixir/blob/master/test/enum_pad_test.exs
> >   
> > > >
> > > > what I ended up doing was creating two sets of functions:
> > > > Enum.pad/3-4
> > > > Enum.pad_zip/3-4
> > > >
> > > > and Enum.enumerable?/1 to determine if we are dealing with an
> > > > enumerable (there are probably better ways to deal with this).
> > > >
> > > > I never submitted it because I never implemented the Stream
> > > > versions of them, but whatever is under Enum is ready for
> > > > review.
> > > >
> > > >
> > > > On Tue, 12 Apr 2016 23:19:49 +
> > > > Peter Hamilton  wrote:
> > > >  
> > > > > Here are the options I see:
> > > > > 1. zip/3 now and then when we split chunk/4 (breaking change)
> > > > > we can also split zip/3.
> > > > > 2. zip_pad (or whatever we call it) now, leave chunk/4 until a
> > > > > breaking change release and do chunk_pad.
> > > > > 3. do zip_pad and chunk_pad now and get them in the next
> > > > > breaking change release.
> > > > >
> > > > > The long term goal (which I think we all agree on) should be
> > > > > mirroring. There's a possible concession of a short term
> > > > > mismatch. My preference is for this functionality to be
> > > > > available sooner rather than later, so I wouldn't want to tie
> > > > > it to the release of chunk_pad unless there was a breaking
> > > > > release coming. That leaves #1 and #2. We've talked about #1
> > > > > plenty, but it's probably fair to say we shouldn't rule out
> > > > > #2 until we get a feel for what the new semantics would be
> > > > > like.
> > > > >
> > > > > I'm having a hard time envisioning the split. What did you
> > > > > have in mind?
> > > > >
> > > > > On Tue, Apr 12, 2016 at 2:43 PM José Valim
> > > > >  wrote:
> > > > >  
> > > > > > Should we just introduce zip/3 or should we go with a more
> > > > > > explicit name? I am aware mirroring chunk/4 is beneficial
> > > > > > but I always felt chunk/4 could have been more intuitive as
> > > > > > two separate functions.
> > > > > >
> > > > > > On Tuesday, April 12, 2016, Peter Hamilton
> > > > > >  wrote:
> > > > > >  
> > > > > >> Jose: Any notion of pad vs cycle should apply to chunk as
> > > > > >> well. I think so long as we have chunk/4 in its current
> > > > > >> state, zip/3 should have the same behavior. I don't think
> > > > > >> we want to change chunk at this point in time, so I think
> > > > > >> we're stuck with those semantics.
> > > > > >>
> > > > > >> On Tue, Apr 12, 2016 at 2:28 PM Quentin Crain
> > > > > >>  wrote:
> > > > > >>  
> > > > > >>> Yes, lovely!
> > > > > >>>
> > > > > >>> On Tue, Apr 12, 2016, 14:09 Peter Hamilton <> wrote:
> > > > > >>>  
> > > > > 

Re: [elixir-core:5968] Proposal for Random related functions

[eksperimental]

Initially Range.at/2 and Range.random/1 were part of Enum.at/2 and
Enum.random/1 respectively.
They were just moved to their own functions because it made more sense
to me.

These functions are fast enough IMO (as fast as I can
think of).

I would not get rid of Integer.random/1-2 as it's the base for all
other random functions. I think it is very cumbersome to
call `:rand.uniform(n + 1) - 1` every time a need a random number
between 0 and n, and even more complicated if i want a random number
between two integers.

Please let me know how should I proceed
thank you for your feedback

On Fri, 24 Jun 2016 00:42:13 +0200
José Valim  wrote:

> We should definitely optimize functions like at and random when we
> can, so definitely +1 on this front.
> 
> Regarding the other functions, I am still skeptical of their need. In
> particular, if we implement Enum.random fast enough for ranges, it
> would be enough to replace many of the other functions listed, like
> Integer.random and Range.random. :)
> 
> 
> 
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
> 
> On Fri, Jun 24, 2016 at 12:21 AM, eksperimental
>  > wrote:  
> 
> > An answer from someone from the core team would be more than
> > welcome on this proposal.
> >
> > In addition to the proposed funtions, this proposal also tackles an
> > issue in Enum.random/1 when dealing with
> > a ranges, which is really slow if the range is huge, since it
> > delegates to take_random to be converted to a list to later pick
> > one element.
> >
> > It optimized Enum.at/2 when dealing with ranges.
> >
> > Thank you.
> >
> > On Sat, 4 Jun 2016 08:37:19 +0700
> > eksperimental  wrote:
> >  
> > > I forgot to mention that Range.at/3 has been implemented.
> > >
> > > ***
> > > ### Range.at/3
> > >
> > > It works the same way as Enum.at/3, but given a range, it returns
> > > an integer at the given `index`.
> > >
> > > This function is used to optimize `Enum.at/3` when dealing with
> > > ranges. ***
> > >
> > > On Sat, 4 Jun 2016 08:18:21 +0700
> > > eksperimental  wrote:
> > >  
> > > > You can read this proposal formated
> > > > https://github.com/eksperimental/experimental/blob/random/PROPOSAL.md
> > > >
> > > > # Introducing random related functions
> > > >
> > > > First I would like to address the need for implementing in
> > > > Elixir our function for generating random integers:
> > > > `Integer.random/1` All functions using random numbers, are
> > > > calling `:erlang.random_uniform/1`. This Erlang function is not
> > > > zero based, so there is an overhead to deal with it every time,
> > > > adding and subtracting (`:rand.uniform(n + 1) - 1`), thus
> > > > leading to potential bugs.
> > > >
> > > >
> > > > ## Integer module
> > > >
> > > > So my proposal is to add `Integer.random/1` and
> > > > `Integer.random/2`
> > > >
> > > > - `Integer.random(limit)` - It returns a random integer from 0
> > > > to limit (positive or negative integers)
> > > >
> > > > - `Integer.random(lower_limit, upper_limit)` - It returns a
> > > > random integer withing two limits.
> > > >
> > > >
> > > > ## Range module
> > > >
> > > > - `Range.random(range)` - It returns an integer within range.
> > > > - `Range.random(range, count)` - It returns an list of `count`
> > > > integers within range. count can be bigger than the range size.
> > > >
> > > > Uses cases: `Range.random/2` can be useful for generating
> > > > charlists of random chars within a range. It is also used by
> > > > `Enum.random/2` when the enumerable is a range.
> > > >
> > > > ## Enum module
> > > >
> > > > - `Enum.random(enumerable, count)` - It returns a list of count
> > > > size, of random items from enumerable. The main difference with
> > > >   `Enum.take_random/2` is that latter will not include repeated
> > > >   results, and if count is greater than the number of elements
> > > > in the enumerable, it will return short. So `Enum.random/2`
> > > > guarantees the count of items, and allows them to be repeated.
> > > >
> > > > `Enum.random/1` has been updated to not to call
> > > > `Enum.take_random/2`, but to use `Enum.at/3` instead.
> > > >
> > > > `Enum.at/3` has been optimized to use `Range.at/3` when the
> > > > enumerable is a range.
> > > >
> > > >
> > > > ## Additional functions implemented
> > > >
> > > > ### Integer.pad_random/2
> > > >
> > > > If we are about to generate huge numbers,
> > > > `:erlang.random_uniform/1` will work to a certain limit.
> > > > `Integer.pad_random/2` has fine tuning options such as:
> > > >   - force_size: true | false
> > > >   - return: :integer | :positive | :negative | :zero_or_positive
> > > > | :zero_or_negative
> > > >
> > > > This list can generate incredible HUGE integers, in a very
> > > > efficient way.
> > > >
> > > > Use cases: benchmarking functions with different integers and
> > > > data size of specific length.
> > > >
> > > > ### Kernel.delta/2 and Range.delta/1
> > > >
> > > > I took the chance 

Re: [elixir-core:5967] How to change the markdown engine to generate docs in Elixir Project

[José Valim]

>
> why wouldn't it be possible for other projects to set the markdown
> engine throuhg the CLI?
>

Because only Elixir uses it from the command line at this point and, even
if we make it available with the upcoming mix escript.install feature, c
dependencies can't be bundled in escripts, so the other alternative is
pandoc.

For changing the processes, just change this function and call what you
want directly:
https://github.com/elixir-lang/ex_doc/blob/master/lib/ex_doc/markdown.ex#L35

You can also add a config file and set the proper application key.

-- 
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/CAGnRm4%2B5%3Df8cNp_c-NsSWjNt0QmHuKgZeVr2f5F7nGRgChr9VA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5966] Proposal: Enum.pad and Enum.pad_zip

[José Valim]

I believe the proposal above does not fit the current definition of pad in
Elixir. We use pad for values that are automatically cycled and leftover
with the semantics in your code.

I am also not sure if zip_pad or pad_zip are the best names or if it would
be better to follow the same road as chunk (i.e. discard by default, which
we already do, and then allow a leftover to be given). I honestly don't
like the leftover approach though. It is easy to do for chunk, because you
know the chunk size, but with zip you typically do not.



*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D

On Fri, Jun 24, 2016 at 12:25 AM, eksperimental  wrote:

> Jose could you please give me an answer on this,
> as I would like to to finally make it into the Elixir.
>
> Thank you
>
> On Thu, 5 May 2016 11:56:47 +0700
> eksperimental  wrote:
>
> > Jose,
> > It was earlier suggested that we should have a function like this.
> > Could you please have a look at it,
> > I would have to implement the Stream version of it (I may ask for
> > guidance as I have worked with it before).
> >
> > >
> https://github.com/eksperimental/experimental_elixir/blob/master/lib/enum_pad.ex
> > >
> https://github.com/eksperimental/experimental_elixir/blob/master/test/enum_pad_test.exs
> >
> > cheers.
> >
> >
> > On Wed, 13 Apr 2016 08:46:10 +0700
> > eksperimental  wrote:
> >
> > > I asked a while ago if there was a zip-padding function,
> > >
> https://groups.google.com/d/msg/elixir-lang-talk/pil9caRXQnM/-newc1hUAAAJ
> > > and there was not, and José suggested that that would be a desirable
> > > function to have in Enum, which I did... It's been there siting for
> > > a while and I was actually thinking about taking back on this week,
> > > to see that there is a similar proposal.
> > >
> > > It's already a working version,
> > >
> https://github.com/eksperimental/experimental_elixir/blob/master/lib/enum_pad.ex
> > >
> https://github.com/eksperimental/experimental_elixir/blob/master/test/enum_pad_test.exs
> > >
> > > what I ended up doing was creating two sets of functions:
> > > Enum.pad/3-4
> > > Enum.pad_zip/3-4
> > >
> > > and Enum.enumerable?/1 to determine if we are dealing with an
> > > enumerable (there are probably better ways to deal with this).
> > >
> > > I never submitted it because I never implemented the Stream versions
> > > of them, but whatever is under Enum is ready for review.
> > >
> > >
> > > On Tue, 12 Apr 2016 23:19:49 +
> > > Peter Hamilton  wrote:
> > >
> > > > Here are the options I see:
> > > > 1. zip/3 now and then when we split chunk/4 (breaking change) we
> > > > can also split zip/3.
> > > > 2. zip_pad (or whatever we call it) now, leave chunk/4 until a
> > > > breaking change release and do chunk_pad.
> > > > 3. do zip_pad and chunk_pad now and get them in the next breaking
> > > > change release.
> > > >
> > > > The long term goal (which I think we all agree on) should be
> > > > mirroring. There's a possible concession of a short term mismatch.
> > > > My preference is for this functionality to be available sooner
> > > > rather than later, so I wouldn't want to tie it to the release of
> > > > chunk_pad unless there was a breaking release coming. That leaves
> > > > #1 and #2. We've talked about #1 plenty, but it's probably fair to
> > > > say we shouldn't rule out #2 until we get a feel for what the new
> > > > semantics would be like.
> > > >
> > > > I'm having a hard time envisioning the split. What did you have in
> > > > mind?
> > > >
> > > > On Tue, Apr 12, 2016 at 2:43 PM José Valim
> > > >  wrote:
> > > >
> > > > > Should we just introduce zip/3 or should we go with a more
> > > > > explicit name? I am aware mirroring chunk/4 is beneficial but I
> > > > > always felt chunk/4 could have been more intuitive as two
> > > > > separate functions.
> > > > >
> > > > > On Tuesday, April 12, 2016, Peter Hamilton
> > > > >  wrote:
> > > > >
> > > > >> Jose: Any notion of pad vs cycle should apply to chunk as
> > > > >> well. I think so long as we have chunk/4 in its current state,
> > > > >> zip/3 should have the same behavior. I don't think we want to
> > > > >> change chunk at this point in time, so I think we're stuck
> > > > >> with those semantics.
> > > > >>
> > > > >> On Tue, Apr 12, 2016 at 2:28 PM Quentin Crain
> > > > >>  wrote:
> > > > >>
> > > > >>> Yes, lovely!
> > > > >>>
> > > > >>> On Tue, Apr 12, 2016, 14:09 Peter Hamilton <> wrote:
> > > > >>>
> > > >  Yes. With the case:
> > > > 
> > > >  zip(1..8, 1..5, Stream.cycle(["Marcia"]))
> > > >  [{1, 1}, {2, 2}, {3, 3}, {4, 4}, {5, 5}, {6, "Marcia"}, {7,
> > > >  "Marcia"}, {8, "Marcia"}]
> > > > 
> > > >  also being true (important that the pad goes to whichever
> > > >  stream ends first)
> > > > 
> > > >   4}, {5, 5}]
> > > > >
> > > > > zip(1..5, 1..8, ["Marcia"])
> > > > > [{1, 1}, {2, 2}, {3, 3}, {4, 4}, {5, 5}, {"Marcia", 6}]
> > > > >
> > > > > zip(1..5,

Re: [elixir-core:5965] Proposal for Random related functions

[José Valim]

We should definitely optimize functions like at and random when we can, so
definitely +1 on this front.

Regarding the other functions, I am still skeptical of their need. In
particular, if we implement Enum.random fast enough for ranges, it would be
enough to replace many of the other functions listed, like Integer.random
and Range.random. :)



*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D

On Fri, Jun 24, 2016 at 12:21 AM, eksperimental  wrote:

> An answer from someone from the core team would be more than welcome on
> this proposal.
>
> In addition to the proposed funtions, this proposal also tackles an issue
> in Enum.random/1 when dealing with
> a ranges, which is really slow if the range is huge, since it delegates
> to take_random to be converted to a list to later pick one element.
>
> It optimized Enum.at/2 when dealing with ranges.
>
> Thank you.
>
> On Sat, 4 Jun 2016 08:37:19 +0700
> eksperimental  wrote:
>
> > I forgot to mention that Range.at/3 has been implemented.
> >
> > ***
> > ### Range.at/3
> >
> > It works the same way as Enum.at/3, but given a range, it returns an
> > integer at the given `index`.
> >
> > This function is used to optimize `Enum.at/3` when dealing with
> > ranges. ***
> >
> > On Sat, 4 Jun 2016 08:18:21 +0700
> > eksperimental  wrote:
> >
> > > You can read this proposal formated
> > > https://github.com/eksperimental/experimental/blob/random/PROPOSAL.md
> > >
> > > # Introducing random related functions
> > >
> > > First I would like to address the need for implementing in Elixir
> > > our function for generating random integers: `Integer.random/1` All
> > > functions using random numbers, are calling
> > > `:erlang.random_uniform/1`. This Erlang function is not zero based,
> > > so there is an overhead to deal with it every time, adding and
> > > subtracting (`:rand.uniform(n + 1) - 1`), thus leading to potential
> > > bugs.
> > >
> > >
> > > ## Integer module
> > >
> > > So my proposal is to add `Integer.random/1` and `Integer.random/2`
> > >
> > > - `Integer.random(limit)` - It returns a random integer from 0 to
> > > limit (positive or negative integers)
> > >
> > > - `Integer.random(lower_limit, upper_limit)` - It returns a random
> > >   integer withing two limits.
> > >
> > >
> > > ## Range module
> > >
> > > - `Range.random(range)` - It returns an integer within range.
> > > - `Range.random(range, count)` - It returns an list of `count`
> > > integers within range. count can be bigger than the range size.
> > >
> > > Uses cases: `Range.random/2` can be useful for generating charlists
> > > of random chars within a range. It is also used by `Enum.random/2`
> > > when the enumerable is a range.
> > >
> > > ## Enum module
> > >
> > > - `Enum.random(enumerable, count)` - It returns a list of count
> > > size, of random items from enumerable. The main difference with
> > >   `Enum.take_random/2` is that latter will not include repeated
> > >   results, and if count is greater than the number of elements in
> > > the enumerable, it will return short. So `Enum.random/2` guarantees
> > > the count of items, and allows them to be repeated.
> > >
> > > `Enum.random/1` has been updated to not to call
> > > `Enum.take_random/2`, but to use `Enum.at/3` instead.
> > >
> > > `Enum.at/3` has been optimized to use `Range.at/3` when the
> > > enumerable is a range.
> > >
> > >
> > > ## Additional functions implemented
> > >
> > > ### Integer.pad_random/2
> > >
> > > If we are about to generate huge numbers, `:erlang.random_uniform/1`
> > > will work to a certain limit. `Integer.pad_random/2` has fine tuning
> > > options such as:
> > >   - force_size: true | false
> > >   - return: :integer | :positive | :negative | :zero_or_positive
> > > | :zero_or_negative
> > >
> > > This list can generate incredible HUGE integers, in a very efficient
> > > way.
> > >
> > > Use cases: benchmarking functions with different integers and data
> > > size of specific length.
> > >
> > > ### Kernel.delta/2 and Range.delta/1
> > >
> > > I took the chance and introduce new functions that helped me archive
> > > random related functions listed above.
> > >
> > > - `Kernel.delta(number1, number2)`: It returns the absolute
> > > difference between two numbers (integer or float).
> > > - `Range.delta(range)`: It returns the absolute difference between
> > > the range limits.
> > >
> > > It may sound simple, but I had made mistakes in the past
> > > implementing a quick delta functions.
> > >
> > >
> > > ## Implemented code
> > >
> > > It can be found here:
> > > https://github.com/eksperimental/experimental/tree/random
> > >
> > > It can be cloned locally by running:
> > >
> > > $ git clone -b random --single-branch
> > > https://github.com/eksperimental/experimental.git
> > >
> > > Looking forward to hearing your opinion,
> > >
> > > — Eksperimental
> > >
> >
>
> --
> You received this message because you are subscribed to the Google Groups

Re: [elixir-core:5964] Proposal: Enum.pad and Enum.pad_zip

[eksperimental]

Jose could you please give me an answer on this, 
as I would like to to finally make it into the Elixir.

Thank you

On Thu, 5 May 2016 11:56:47 +0700
eksperimental  wrote:

> Jose,
> It was earlier suggested that we should have a function like this.
> Could you please have a look at it,
> I would have to implement the Stream version of it (I may ask for
> guidance as I have worked with it before).
> 
> > https://github.com/eksperimental/experimental_elixir/blob/master/lib/enum_pad.ex
> > https://github.com/eksperimental/experimental_elixir/blob/master/test/enum_pad_test.exs
> >   
> 
> cheers.
> 
> 
> On Wed, 13 Apr 2016 08:46:10 +0700
> eksperimental  wrote:
> 
> > I asked a while ago if there was a zip-padding function,
> > https://groups.google.com/d/msg/elixir-lang-talk/pil9caRXQnM/-newc1hUAAAJ
> > and there was not, and José suggested that that would be a desirable
> > function to have in Enum, which I did... It's been there siting for
> > a while and I was actually thinking about taking back on this week,
> > to see that there is a similar proposal.
> > 
> > It's already a working version,
> > https://github.com/eksperimental/experimental_elixir/blob/master/lib/enum_pad.ex
> > https://github.com/eksperimental/experimental_elixir/blob/master/test/enum_pad_test.exs
> > 
> > what I ended up doing was creating two sets of functions:
> > Enum.pad/3-4
> > Enum.pad_zip/3-4
> > 
> > and Enum.enumerable?/1 to determine if we are dealing with an
> > enumerable (there are probably better ways to deal with this).
> > 
> > I never submitted it because I never implemented the Stream versions
> > of them, but whatever is under Enum is ready for review.
> > 
> > 
> > On Tue, 12 Apr 2016 23:19:49 +
> > Peter Hamilton  wrote:
> >   
> > > Here are the options I see:
> > > 1. zip/3 now and then when we split chunk/4 (breaking change) we
> > > can also split zip/3.
> > > 2. zip_pad (or whatever we call it) now, leave chunk/4 until a
> > > breaking change release and do chunk_pad.
> > > 3. do zip_pad and chunk_pad now and get them in the next breaking
> > > change release.
> > > 
> > > The long term goal (which I think we all agree on) should be
> > > mirroring. There's a possible concession of a short term mismatch.
> > > My preference is for this functionality to be available sooner
> > > rather than later, so I wouldn't want to tie it to the release of
> > > chunk_pad unless there was a breaking release coming. That leaves
> > > #1 and #2. We've talked about #1 plenty, but it's probably fair to
> > > say we shouldn't rule out #2 until we get a feel for what the new
> > > semantics would be like.
> > > 
> > > I'm having a hard time envisioning the split. What did you have in
> > > mind?
> > > 
> > > On Tue, Apr 12, 2016 at 2:43 PM José Valim
> > >  wrote:
> > >   
> > > > Should we just introduce zip/3 or should we go with a more
> > > > explicit name? I am aware mirroring chunk/4 is beneficial but I
> > > > always felt chunk/4 could have been more intuitive as two
> > > > separate functions.
> > > >
> > > > On Tuesday, April 12, 2016, Peter Hamilton
> > > >  wrote:
> > > >  
> > > >> Jose: Any notion of pad vs cycle should apply to chunk as
> > > >> well. I think so long as we have chunk/4 in its current state,
> > > >> zip/3 should have the same behavior. I don't think we want to
> > > >> change chunk at this point in time, so I think we're stuck
> > > >> with those semantics.
> > > >>
> > > >> On Tue, Apr 12, 2016 at 2:28 PM Quentin Crain
> > > >>  wrote:
> > > >>  
> > > >>> Yes, lovely!
> > > >>>
> > > >>> On Tue, Apr 12, 2016, 14:09 Peter Hamilton <> wrote:
> > > >>>  
> > >  Yes. With the case:
> > > 
> > >  zip(1..8, 1..5, Stream.cycle(["Marcia"]))
> > >  [{1, 1}, {2, 2}, {3, 3}, {4, 4}, {5, 5}, {6, "Marcia"}, {7,
> > >  "Marcia"}, {8, "Marcia"}]
> > > 
> > >  also being true (important that the pad goes to whichever
> > >  stream ends first)
> > > 
> > >   4}, {5, 5}]  
> > > >
> > > > zip(1..5, 1..8, ["Marcia"])
> > > > [{1, 1}, {2, 2}, {3, 3}, {4, 4}, {5, 5}, {"Marcia", 6}]
> > > >
> > > > zip(1..5, 1..8, Stream.cycle(["Marcia"]))
> > > > [{1, 1}, {2, 2}, {3, 3}, {4, 4}, {5, 5}, {"Marcia", 6},
> > > > {"Marcia", 7}, {"Marcia", 8}]
> > > >
> > > > No? (Assuming I'm understanding.)
> > > >
> > > > << q
> > > >
> > > > --  
> > > >>> You received this message because you are subscribed to the
> > > >>> Google Groups "elixir-lang-talk" group.
> > > >>> To unsubscribe from this group and stop receiving emails from
> > > >>> it, send an email to
> > > >>> elixir-lang-talk+unsubscr...@googlegroups.com. To view this
> > > >>> discussion on the web visit
> > > >>> https://groups.google.com/d/msgid/elixir-lang-talk/CALNYqAsQs%2Bjg9JCV3c5a%3DtR3uwdQ8rtj%3DM3wb%3D-%3DNuDOUOEg4Q%40mail.gmail.com
> > > >>> 

Re: [elixir-core:5963] Proposal for Random related functions

[eksperimental]

An answer from someone from the core team would be more than welcome on
this proposal.

In addition to the proposed funtions, this proposal also tackles an issue in 
Enum.random/1 when dealing with
a ranges, which is really slow if the range is huge, since it delegates
to take_random to be converted to a list to later pick one element.

It optimized Enum.at/2 when dealing with ranges.

Thank you.

On Sat, 4 Jun 2016 08:37:19 +0700
eksperimental  wrote:

> I forgot to mention that Range.at/3 has been implemented.
> 
> ***
> ### Range.at/3
> 
> It works the same way as Enum.at/3, but given a range, it returns an
> integer at the given `index`.
> 
> This function is used to optimize `Enum.at/3` when dealing with
> ranges. ***
> 
> On Sat, 4 Jun 2016 08:18:21 +0700
> eksperimental  wrote:
> 
> > You can read this proposal formated
> > https://github.com/eksperimental/experimental/blob/random/PROPOSAL.md
> > 
> > # Introducing random related functions
> > 
> > First I would like to address the need for implementing in Elixir
> > our function for generating random integers: `Integer.random/1` All
> > functions using random numbers, are calling
> > `:erlang.random_uniform/1`. This Erlang function is not zero based,
> > so there is an overhead to deal with it every time, adding and
> > subtracting (`:rand.uniform(n + 1) - 1`), thus leading to potential
> > bugs.
> > 
> > 
> > ## Integer module
> > 
> > So my proposal is to add `Integer.random/1` and `Integer.random/2`
> > 
> > - `Integer.random(limit)` - It returns a random integer from 0 to
> > limit (positive or negative integers)
> > 
> > - `Integer.random(lower_limit, upper_limit)` - It returns a random
> >   integer withing two limits.
> > 
> > 
> > ## Range module
> > 
> > - `Range.random(range)` - It returns an integer within range.
> > - `Range.random(range, count)` - It returns an list of `count`
> > integers within range. count can be bigger than the range size.
> > 
> > Uses cases: `Range.random/2` can be useful for generating charlists
> > of random chars within a range. It is also used by `Enum.random/2`
> > when the enumerable is a range.
> > 
> > ## Enum module
> > 
> > - `Enum.random(enumerable, count)` - It returns a list of count
> > size, of random items from enumerable. The main difference with
> >   `Enum.take_random/2` is that latter will not include repeated
> >   results, and if count is greater than the number of elements in
> > the enumerable, it will return short. So `Enum.random/2` guarantees
> > the count of items, and allows them to be repeated.
> > 
> > `Enum.random/1` has been updated to not to call
> > `Enum.take_random/2`, but to use `Enum.at/3` instead.
> > 
> > `Enum.at/3` has been optimized to use `Range.at/3` when the
> > enumerable is a range. 
> > 
> > 
> > ## Additional functions implemented
> > 
> > ### Integer.pad_random/2
> > 
> > If we are about to generate huge numbers, `:erlang.random_uniform/1`
> > will work to a certain limit. `Integer.pad_random/2` has fine tuning
> > options such as:
> >   - force_size: true | false
> >   - return: :integer | :positive | :negative | :zero_or_positive
> > | :zero_or_negative
> > 
> > This list can generate incredible HUGE integers, in a very efficient
> > way.
> > 
> > Use cases: benchmarking functions with different integers and data
> > size of specific length.
> > 
> > ### Kernel.delta/2 and Range.delta/1
> > 
> > I took the chance and introduce new functions that helped me archive
> > random related functions listed above.
> > 
> > - `Kernel.delta(number1, number2)`: It returns the absolute
> > difference between two numbers (integer or float).
> > - `Range.delta(range)`: It returns the absolute difference between
> > the range limits.
> > 
> > It may sound simple, but I had made mistakes in the past
> > implementing a quick delta functions.
> > 
> > 
> > ## Implemented code
> > 
> > It can be found here:
> > https://github.com/eksperimental/experimental/tree/random
> > 
> > It can be cloned locally by running:
> > 
> > $ git clone -b random --single-branch
> > https://github.com/eksperimental/experimental.git
> > 
> > Looking forward to hearing your opinion,
> > 
> > — Eksperimental
> >   
> 

-- 
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/20160624052120.33c80adc.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5961] How to change the markdown engine to generate docs in Elixir Project

[eksperimental]

On Thu, 23 Jun 2016 23:47:17 +0200
José Valim  wrote:

> And thank you for looking into this!

sure, no worries.
always a pleasure to contribute to Elixir

-- 
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/20160624045640.0f20bce0.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5961] How to change the markdown engine to generate docs in Elixir Project

[eksperimental]

why wouldn't it be possible for other projects to set the markdown
engine throuhg the CLI?
I tried hacking ex_doc to use cmark, but it doens't
seem to work as earmark now is a required dependency.
What i used to do before was to remove the other dependencies in the
deps/ folder

I haven't hacked in ex_docs in a while, so Im a bit out of touch. ;-p

 On Thu, 23 Jun 2016 23:47:04 +0200
José Valim  wrote:

> My advice would be to change it in the source. Maybe there is a
> config in mix.exs. I don't think an option is worth it because it
> wouldn't likely be possible to use it by any project besides Elixir.
> 
> On Thursday, June 23, 2016, eksperimental
>  wrote:
> 
> > Hi,
> > I have found three offending lines when running `make docs_elixir`,
> > but Earmark is unable to tell (yet) which file is causing trouble.
> >
> > :42: warning: Closing unclosed backquotes ` at
> > end of input :392: warning: Closing unclosed backquotes `
> > at end of input :36: warning: Closing unclosed backquotes
> > ` at end of input
> >
> >
> > I thought of changing the markdown engine to see if other engines
> > will give me the right info, but I couldn't figure out how.
> > Maybe we should add this feature to the ExDoc CLI.
> >
> > any hints are appreciated
> >
> > --
> > 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/20160624034228.3d8b73ad.eksperimental%40autistici.org
> > .
> > For more options, visit https://groups.google.com/d/optout.
> >  
> 
> 

-- 
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/20160624045542.04cff711.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5959] How to change the markdown engine to generate docs in Elixir Project

[José Valim]

My advice would be to change it in the source. Maybe there is a config in
mix.exs. I don't think an option is worth it because it wouldn't likely be
possible to use it by any project besides Elixir.

On Thursday, June 23, 2016, eksperimental 
wrote:

> Hi,
> I have found three offending lines when running `make docs_elixir`, but
> Earmark is unable to tell (yet) which file is causing trouble.
>
> :42: warning: Closing unclosed backquotes ` at
> end of input :392: warning: Closing unclosed backquotes ` at
> end of input :36: warning: Closing unclosed backquotes ` at
> end of input
>
>
> I thought of changing the markdown engine to see if other engines will
> give me the right info, but I couldn't figure out how.
> Maybe we should add this feature to the ExDoc CLI.
>
> any hints are appreciated
>
> --
> 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/20160624034228.3d8b73ad.eksperimental%40autistici.org
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 


*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D

-- 
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/CAGnRm4JsRZV88PoRftQstv8VHMxffUrO9wXH5eU9k3C1TYyeKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5960] How to change the markdown engine to generate docs in Elixir Project

[José Valim]

And thank you for looking into this!

On Thursday, June 23, 2016, eksperimental 
wrote:

> Hi,
> I have found three offending lines when running `make docs_elixir`, but
> Earmark is unable to tell (yet) which file is causing trouble.
>
> :42: warning: Closing unclosed backquotes ` at
> end of input :392: warning: Closing unclosed backquotes ` at
> end of input :36: warning: Closing unclosed backquotes ` at
> end of input
>
>
> I thought of changing the markdown engine to see if other engines will
> give me the right info, but I couldn't figure out how.
> Maybe we should add this feature to the ExDoc CLI.
>
> any hints are appreciated
>
> --
> 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/20160624034228.3d8b73ad.eksperimental%40autistici.org
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 


*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D

-- 
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/CAGnRm4%2B2j94N8Uzb6DP%3DdVhemL49e2w%2Biz%2BHNo0RBZaJPhYX7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:5958] How to change the markdown engine to generate docs in Elixir Project

[eksperimental]

Hi,
I have found three offending lines when running `make docs_elixir`, but
Earmark is unable to tell (yet) which file is causing trouble.

:42: warning: Closing unclosed backquotes ` at
end of input :392: warning: Closing unclosed backquotes ` at
end of input :36: warning: Closing unclosed backquotes ` at
end of input


I thought of changing the markdown engine to see if other engines will
give me the right info, but I couldn't figure out how.
Maybe we should add this feature to the ExDoc CLI.

any hints are appreciated

-- 
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/20160624034228.3d8b73ad.eksperimental%40autistici.org.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5957] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

[Eric Entin]

Agreed on all points.

Just thought I'd mention it. :)

On Thu, Jun 23, 2016 at 3:32 PM, Josh Adams  wrote:

> Also for those looking for a way to "cancel the current line" in iex, you
>> can type #iex:break at any time to return to do so.
>>
>
> This is super useful to know.  And I know it.  And I still never use it
> because I don't think about until it's too late.  And I've been using
> Elixir, and known about this, for years.  I think no beginner will ever
> find out about it or use it! :)
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "elixir-lang-core" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elixir-lang-core/ZDbAdRgCvzw/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAA1-O0x4S8vdZM%2BF7u4kqVqUwSpsPh%2BoQ9xd2FO6XDCo86yQXQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAEu-Nftb1k3%3D%3DpwQ302pOrekEJ5KQNvkxmhuCfZe52TOMTON_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5956] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

[Josh Adams]

>
> Also for those looking for a way to "cancel the current line" in iex, you
> can type #iex:break at any time to return to do so.
>

This is super useful to know.  And I know it.  And I still never use it
because I don't think about until it's too late.  And I've been using
Elixir, and known about this, for years.  I think no beginner will ever
find out about it or use it! :)

-- 
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/CAA1-O0x4S8vdZM%2BF7u4kqVqUwSpsPh%2BoQ9xd2FO6XDCo86yQXQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5956] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

[Eric E.]

I like it as well.

Also for those looking for a way to "cancel the current line" in iex, you 
can type #iex:break at any time to return to do so.

On Thursday, June 23, 2016 at 2:15:46 PM UTC-4, José Valim wrote:
>
> Sounds good to me too!
>
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
>
> On Thu, Jun 23, 2016 at 8:11 PM, Paul Clegg  > wrote:
>
>> I can get behind this as a no-config-option compromise.  :)
>>
>> ...Paul
>>
>>
>>
>> On Thu, Jun 23, 2016 at 10:59 AM, Aleksei Magusev > > wrote:
>>
>>> I'm wondering, what if we go with combined approach:
>>> at first TAB we're getting autocomplete up to the "dot"
>>> and next TAB is appending the "dot".
>>>
>>> I believe it can be a good compromise. :)
>>>
>>>
>>> On Thursday, June 23, 2016 at 7:29:24 PM UTC+2, Myron Marston wrote:

 Since I haven't found a good way in iex to "cancel the current line", 
> if I get in that spot, I lose a lot of history and current variables and 
> whatnot.


 I've tend to do this, too, even though I've been using Elixir as my 
 main language at work for nearly a year.  It's a big reason I find the 
 appended period to be so annoying.

 If anything, my vote would be to make it optional -- but default it to 
> NOT appending the dot.

  
 I agree.  If we make it a config option, I think it would help 
 newcomers to the language if we made it opt-in instead of opt-out.  Given 
 that most auto-complete tooling does not usually add an extra period, 
 newcomers to the language are not going to expect it, and won't know how 
 to 
 get out of the "current line" issue Paul mentioned without exiting the IEx 
 session and restarting it.  Furthermore, since they are a newcomer, they 
 are not likely to know about the config option.

 OTOH, experienced users who may want the appended period will 
 understand IEx's config system and can more easily configure it for their 
 needs.

 Myron

 On Thursday, June 23, 2016 at 9:51:02 AM UTC-7, ...Paul wrote:
>
> I'm actually with Myron.  Since I haven't found a good way in iex to 
> "cancel the current line", if I get in that spot, I lose a lot of history 
> and current variables and whatnot.  If anything, my vote would be to make 
> it optional -- but default it to NOT appending the dot.  I prefer UI 
> elements that help me do what I want to do, not make presumptions about 
> what I want to do.
>
> ...Paul
>
>
>
> On Thu, Jun 23, 2016 at 9:42 AM, Louis Pop  
> wrote:
>
>> I share Jose' opinion here, but making it configurable sounds good.
>>
>> Cheers,
>> Louis
>>
>> On 23 June 2016 at 17:40, Myron Marston  wrote:
>>
>>> This behavior of IEx has always surprised and annoyed me. I 
>>> regularly type h [first few chars of mod name] in IEx 
>>> to read the read the moduledoc of a particular module, and the trailing 
>>> period gets in the way every time.
>>>
>>> Here’s a demonstration showing what happens to me regularly when I 
>>> try to read the @moduledoc for a module:
>>>
>>> [image: iex_autocomplete_original]
>>>
>>> With this change, it avoids this problem:
>>>
>>> [image: iex_autocomplete_improved]
>>>
>>> I opened a PR with this change 
>>>  but was asked to 
>>> redirect conversation here for community feedback first. On the PR, 
>>> @antipax said (and @josevalim concurred):
>>>
>>> I’m not in support of merging this, if only because the vast 
>>> majority of the time I autocomplete a module in IEx it is to make a 
>>> remote 
>>> call.
>>>
>>> I thought the purpose of autocomplete in IEx is to autocomplete 
>>> tokens (e.g. module and function names) not to guess the intention of 
>>> the 
>>> programmer and add additional characters after the token. IMO, it’s 
>>> much 
>>> more natural to just complete the module name, and people who want to 
>>> do a 
>>> remote call (or navigate to a “nested” module) can type a period, than 
>>> to 
>>> add the period and force the programmer to delete it. After all, I 
>>> believe 
>>> the autocomplete plugins in most text editors/IDEs would just 
>>> autocomplete 
>>> the module name, and not add the period.
>>>
>>> On the PR @antipax also said:
>>>
>>> I would be in support of making this configurable, however.
>>>
>>> Having this be configurable would meet my needs as long as I could 
>>> configure it globally (presumably in ~/.iex.exs) but the trailing 
>>> dot still feels like an odd default to me.
>>>
>>> Thoughts from the community?
>>>
>>> Thanks,
>>> Myron
>>> ​
>>>
>>> -- 
>>> You received this message because you are subscr

Re: [elixir-core:5954] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

[José Valim]

Sounds good to me too!



*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D

On Thu, Jun 23, 2016 at 8:11 PM, Paul Clegg  wrote:

> I can get behind this as a no-config-option compromise.  :)
>
> ...Paul
>
>
>
> On Thu, Jun 23, 2016 at 10:59 AM, Aleksei Magusev 
> wrote:
>
>> I'm wondering, what if we go with combined approach:
>> at first TAB we're getting autocomplete up to the "dot"
>> and next TAB is appending the "dot".
>>
>> I believe it can be a good compromise. :)
>>
>>
>> On Thursday, June 23, 2016 at 7:29:24 PM UTC+2, Myron Marston wrote:
>>>
>>> Since I haven't found a good way in iex to "cancel the current line", if
 I get in that spot, I lose a lot of history and current variables and
 whatnot.
>>>
>>>
>>> I've tend to do this, too, even though I've been using Elixir as my main
>>> language at work for nearly a year.  It's a big reason I find the appended
>>> period to be so annoying.
>>>
>>> If anything, my vote would be to make it optional -- but default it to
 NOT appending the dot.
>>>
>>>
>>> I agree.  If we make it a config option, I think it would help newcomers
>>> to the language if we made it opt-in instead of opt-out.  Given that most
>>> auto-complete tooling does not usually add an extra period, newcomers to
>>> the language are not going to expect it, and won't know how to get out of
>>> the "current line" issue Paul mentioned without exiting the IEx session and
>>> restarting it.  Furthermore, since they are a newcomer, they are not likely
>>> to know about the config option.
>>>
>>> OTOH, experienced users who may want the appended period will understand
>>> IEx's config system and can more easily configure it for their needs.
>>>
>>> Myron
>>>
>>> On Thursday, June 23, 2016 at 9:51:02 AM UTC-7, ...Paul wrote:

 I'm actually with Myron.  Since I haven't found a good way in iex to
 "cancel the current line", if I get in that spot, I lose a lot of history
 and current variables and whatnot.  If anything, my vote would be to make
 it optional -- but default it to NOT appending the dot.  I prefer UI
 elements that help me do what I want to do, not make presumptions about
 what I want to do.

 ...Paul



 On Thu, Jun 23, 2016 at 9:42 AM, Louis Pop  wrote:

> I share Jose' opinion here, but making it configurable sounds good.
>
> Cheers,
> Louis
>
> On 23 June 2016 at 17:40, Myron Marston  wrote:
>
>> This behavior of IEx has always surprised and annoyed me. I regularly
>> type h [first few chars of mod name] in IEx to read the
>> read the moduledoc of a particular module, and the trailing period gets 
>> in
>> the way every time.
>>
>> Here’s a demonstration showing what happens to me regularly when I
>> try to read the @moduledoc for a module:
>>
>> [image: iex_autocomplete_original]
>>
>> With this change, it avoids this problem:
>>
>> [image: iex_autocomplete_improved]
>>
>> I opened a PR with this change
>>  but was asked to
>> redirect conversation here for community feedback first. On the PR,
>> @antipax said (and @josevalim concurred):
>>
>> I’m not in support of merging this, if only because the vast majority
>> of the time I autocomplete a module in IEx it is to make a remote call.
>>
>> I thought the purpose of autocomplete in IEx is to autocomplete
>> tokens (e.g. module and function names) not to guess the intention of the
>> programmer and add additional characters after the token. IMO, it’s much
>> more natural to just complete the module name, and people who want to do 
>> a
>> remote call (or navigate to a “nested” module) can type a period, than to
>> add the period and force the programmer to delete it. After all, I 
>> believe
>> the autocomplete plugins in most text editors/IDEs would just 
>> autocomplete
>> the module name, and not add the period.
>>
>> On the PR @antipax also said:
>>
>> I would be in support of making this configurable, however.
>>
>> Having this be configurable would meet my needs as long as I could
>> configure it globally (presumably in ~/.iex.exs) but the trailing
>> dot still feels like an odd default to me.
>>
>> Thoughts from the community?
>>
>> Thanks,
>> Myron
>> ​
>>
>> --
>> 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/CADUxQmu%3Dnc1VpF9Y8oFE%2Bzsp45Xb_sCVZjdPLgBQivrpt2iv2g%40mail.gmail.com
>> 

Re: [elixir-core:5953] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

[Paul Clegg]

I can get behind this as a no-config-option compromise.  :)

...Paul



On Thu, Jun 23, 2016 at 10:59 AM, Aleksei Magusev  wrote:

> I'm wondering, what if we go with combined approach:
> at first TAB we're getting autocomplete up to the "dot"
> and next TAB is appending the "dot".
>
> I believe it can be a good compromise. :)
>
>
> On Thursday, June 23, 2016 at 7:29:24 PM UTC+2, Myron Marston wrote:
>>
>> Since I haven't found a good way in iex to "cancel the current line", if
>>> I get in that spot, I lose a lot of history and current variables and
>>> whatnot.
>>
>>
>> I've tend to do this, too, even though I've been using Elixir as my main
>> language at work for nearly a year.  It's a big reason I find the appended
>> period to be so annoying.
>>
>> If anything, my vote would be to make it optional -- but default it to
>>> NOT appending the dot.
>>
>>
>> I agree.  If we make it a config option, I think it would help newcomers
>> to the language if we made it opt-in instead of opt-out.  Given that most
>> auto-complete tooling does not usually add an extra period, newcomers to
>> the language are not going to expect it, and won't know how to get out of
>> the "current line" issue Paul mentioned without exiting the IEx session and
>> restarting it.  Furthermore, since they are a newcomer, they are not likely
>> to know about the config option.
>>
>> OTOH, experienced users who may want the appended period will understand
>> IEx's config system and can more easily configure it for their needs.
>>
>> Myron
>>
>> On Thursday, June 23, 2016 at 9:51:02 AM UTC-7, ...Paul wrote:
>>>
>>> I'm actually with Myron.  Since I haven't found a good way in iex to
>>> "cancel the current line", if I get in that spot, I lose a lot of history
>>> and current variables and whatnot.  If anything, my vote would be to make
>>> it optional -- but default it to NOT appending the dot.  I prefer UI
>>> elements that help me do what I want to do, not make presumptions about
>>> what I want to do.
>>>
>>> ...Paul
>>>
>>>
>>>
>>> On Thu, Jun 23, 2016 at 9:42 AM, Louis Pop  wrote:
>>>
 I share Jose' opinion here, but making it configurable sounds good.

 Cheers,
 Louis

 On 23 June 2016 at 17:40, Myron Marston  wrote:

> This behavior of IEx has always surprised and annoyed me. I regularly
> type h [first few chars of mod name] in IEx to read the
> read the moduledoc of a particular module, and the trailing period gets in
> the way every time.
>
> Here’s a demonstration showing what happens to me regularly when I try
> to read the @moduledoc for a module:
>
> [image: iex_autocomplete_original]
>
> With this change, it avoids this problem:
>
> [image: iex_autocomplete_improved]
>
> I opened a PR with this change
>  but was asked to
> redirect conversation here for community feedback first. On the PR,
> @antipax said (and @josevalim concurred):
>
> I’m not in support of merging this, if only because the vast majority
> of the time I autocomplete a module in IEx it is to make a remote call.
>
> I thought the purpose of autocomplete in IEx is to autocomplete tokens
> (e.g. module and function names) not to guess the intention of the
> programmer and add additional characters after the token. IMO, it’s much
> more natural to just complete the module name, and people who want to do a
> remote call (or navigate to a “nested” module) can type a period, than to
> add the period and force the programmer to delete it. After all, I believe
> the autocomplete plugins in most text editors/IDEs would just autocomplete
> the module name, and not add the period.
>
> On the PR @antipax also said:
>
> I would be in support of making this configurable, however.
>
> Having this be configurable would meet my needs as long as I could
> configure it globally (presumably in ~/.iex.exs) but the trailing dot
> still feels like an odd default to me.
>
> Thoughts from the community?
>
> Thanks,
> Myron
> ​
>
> --
> 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/CADUxQmu%3Dnc1VpF9Y8oFE%2Bzsp45Xb_sCVZjdPLgBQivrpt2iv2g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

 --
 You received this message because you are subscribed to the Google
 Groups "elixir-lang-core" group.
 To unsubscrib

Re: [elixir-core:5952] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

[Myron Marston]

I like this idea :).

On Thu, Jun 23, 2016 at 10:59 AM, Aleksei Magusev  wrote:

> I'm wondering, what if we go with combined approach:
> at first TAB we're getting autocomplete up to the "dot"
> and next TAB is appending the "dot".
>
> I believe it can be a good compromise. :)
>
>
> On Thursday, June 23, 2016 at 7:29:24 PM UTC+2, Myron Marston wrote:
>>
>> Since I haven't found a good way in iex to "cancel the current line", if
>>> I get in that spot, I lose a lot of history and current variables and
>>> whatnot.
>>
>>
>> I've tend to do this, too, even though I've been using Elixir as my main
>> language at work for nearly a year.  It's a big reason I find the appended
>> period to be so annoying.
>>
>> If anything, my vote would be to make it optional -- but default it to
>>> NOT appending the dot.
>>
>>
>> I agree.  If we make it a config option, I think it would help newcomers
>> to the language if we made it opt-in instead of opt-out.  Given that most
>> auto-complete tooling does not usually add an extra period, newcomers to
>> the language are not going to expect it, and won't know how to get out of
>> the "current line" issue Paul mentioned without exiting the IEx session and
>> restarting it.  Furthermore, since they are a newcomer, they are not likely
>> to know about the config option.
>>
>> OTOH, experienced users who may want the appended period will understand
>> IEx's config system and can more easily configure it for their needs.
>>
>> Myron
>>
>> On Thursday, June 23, 2016 at 9:51:02 AM UTC-7, ...Paul wrote:
>>>
>>> I'm actually with Myron.  Since I haven't found a good way in iex to
>>> "cancel the current line", if I get in that spot, I lose a lot of history
>>> and current variables and whatnot.  If anything, my vote would be to make
>>> it optional -- but default it to NOT appending the dot.  I prefer UI
>>> elements that help me do what I want to do, not make presumptions about
>>> what I want to do.
>>>
>>> ...Paul
>>>
>>>
>>>
>>> On Thu, Jun 23, 2016 at 9:42 AM, Louis Pop  wrote:
>>>
 I share Jose' opinion here, but making it configurable sounds good.

 Cheers,
 Louis

 On 23 June 2016 at 17:40, Myron Marston  wrote:

> This behavior of IEx has always surprised and annoyed me. I regularly
> type h [first few chars of mod name] in IEx to read the
> read the moduledoc of a particular module, and the trailing period gets in
> the way every time.
>
> Here’s a demonstration showing what happens to me regularly when I try
> to read the @moduledoc for a module:
>
> [image: iex_autocomplete_original]
>
> With this change, it avoids this problem:
>
> [image: iex_autocomplete_improved]
>
> I opened a PR with this change
>  but was asked to
> redirect conversation here for community feedback first. On the PR,
> @antipax said (and @josevalim concurred):
>
> I’m not in support of merging this, if only because the vast majority
> of the time I autocomplete a module in IEx it is to make a remote call.
>
> I thought the purpose of autocomplete in IEx is to autocomplete tokens
> (e.g. module and function names) not to guess the intention of the
> programmer and add additional characters after the token. IMO, it’s much
> more natural to just complete the module name, and people who want to do a
> remote call (or navigate to a “nested” module) can type a period, than to
> add the period and force the programmer to delete it. After all, I believe
> the autocomplete plugins in most text editors/IDEs would just autocomplete
> the module name, and not add the period.
>
> On the PR @antipax also said:
>
> I would be in support of making this configurable, however.
>
> Having this be configurable would meet my needs as long as I could
> configure it globally (presumably in ~/.iex.exs) but the trailing dot
> still feels like an odd default to me.
>
> Thoughts from the community?
>
> Thanks,
> Myron
> ​
>
> --
> 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/CADUxQmu%3Dnc1VpF9Y8oFE%2Bzsp45Xb_sCVZjdPLgBQivrpt2iv2g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

 --
 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 i

Re: [elixir-core:5952] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

[Aleksei Magusev]

I'm wondering, what if we go with combined approach:
at first TAB we're getting autocomplete up to the "dot"
and next TAB is appending the "dot".

I believe it can be a good compromise. :)

On Thursday, June 23, 2016 at 7:29:24 PM UTC+2, Myron Marston wrote:
>
> Since I haven't found a good way in iex to "cancel the current line", if I 
>> get in that spot, I lose a lot of history and current variables and whatnot.
>
>
> I've tend to do this, too, even though I've been using Elixir as my main 
> language at work for nearly a year.  It's a big reason I find the appended 
> period to be so annoying.
>
> If anything, my vote would be to make it optional -- but default it to NOT 
>> appending the dot.
>
>  
> I agree.  If we make it a config option, I think it would help newcomers 
> to the language if we made it opt-in instead of opt-out.  Given that most 
> auto-complete tooling does not usually add an extra period, newcomers to 
> the language are not going to expect it, and won't know how to get out of 
> the "current line" issue Paul mentioned without exiting the IEx session and 
> restarting it.  Furthermore, since they are a newcomer, they are not likely 
> to know about the config option.
>
> OTOH, experienced users who may want the appended period will understand 
> IEx's config system and can more easily configure it for their needs.
>
> Myron
>
> On Thursday, June 23, 2016 at 9:51:02 AM UTC-7, ...Paul wrote:
>>
>> I'm actually with Myron.  Since I haven't found a good way in iex to 
>> "cancel the current line", if I get in that spot, I lose a lot of history 
>> and current variables and whatnot.  If anything, my vote would be to make 
>> it optional -- but default it to NOT appending the dot.  I prefer UI 
>> elements that help me do what I want to do, not make presumptions about 
>> what I want to do.
>>
>> ...Paul
>>
>>
>>
>> On Thu, Jun 23, 2016 at 9:42 AM, Louis Pop  wrote:
>>
>>> I share Jose' opinion here, but making it configurable sounds good.
>>>
>>> Cheers,
>>> Louis
>>>
>>> On 23 June 2016 at 17:40, Myron Marston  wrote:
>>>
 This behavior of IEx has always surprised and annoyed me. I regularly 
 type h [first few chars of mod name] in IEx to read the 
 read the moduledoc of a particular module, and the trailing period gets in 
 the way every time.

 Here’s a demonstration showing what happens to me regularly when I try 
 to read the @moduledoc for a module:

 [image: iex_autocomplete_original]

 With this change, it avoids this problem:

 [image: iex_autocomplete_improved]

 I opened a PR with this change 
  but was asked to 
 redirect conversation here for community feedback first. On the PR, 
 @antipax said (and @josevalim concurred):

 I’m not in support of merging this, if only because the vast majority 
 of the time I autocomplete a module in IEx it is to make a remote call.

 I thought the purpose of autocomplete in IEx is to autocomplete tokens 
 (e.g. module and function names) not to guess the intention of the 
 programmer and add additional characters after the token. IMO, it’s much 
 more natural to just complete the module name, and people who want to do a 
 remote call (or navigate to a “nested” module) can type a period, than to 
 add the period and force the programmer to delete it. After all, I believe 
 the autocomplete plugins in most text editors/IDEs would just autocomplete 
 the module name, and not add the period.

 On the PR @antipax also said:

 I would be in support of making this configurable, however.

 Having this be configurable would meet my needs as long as I could 
 configure it globally (presumably in ~/.iex.exs) but the trailing dot 
 still feels like an odd default to me.

 Thoughts from the community?

 Thanks,
 Myron
 ​

 -- 
 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/CADUxQmu%3Dnc1VpF9Y8oFE%2Bzsp45Xb_sCVZjdPLgBQivrpt2iv2g%40mail.gmail.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> -- 
>>> 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-cor

Re: [elixir-core:5951] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

[Myron Marston]

>
> Since I haven't found a good way in iex to "cancel the current line", if I 
> get in that spot, I lose a lot of history and current variables and whatnot.


I've tend to do this, too, even though I've been using Elixir as my main 
language at work for nearly a year.  It's a big reason I find the appended 
period to be so annoying.

If anything, my vote would be to make it optional -- but default it to NOT 
> appending the dot.

 
I agree.  If we make it a config option, I think it would help newcomers to 
the language if we made it opt-in instead of opt-out.  Given that most 
auto-complete tooling does not usually add an extra period, newcomers to 
the language are not going to expect it, and won't know how to get out of 
the "current line" issue Paul mentioned without exiting the IEx session and 
restarting it.  Furthermore, since they are a newcomer, they are not likely 
to know about the config option.

OTOH, experienced users who may want the appended period will understand 
IEx's config system and can more easily configure it for their needs.

Myron

On Thursday, June 23, 2016 at 9:51:02 AM UTC-7, ...Paul wrote:
>
> I'm actually with Myron.  Since I haven't found a good way in iex to 
> "cancel the current line", if I get in that spot, I lose a lot of history 
> and current variables and whatnot.  If anything, my vote would be to make 
> it optional -- but default it to NOT appending the dot.  I prefer UI 
> elements that help me do what I want to do, not make presumptions about 
> what I want to do.
>
> ...Paul
>
>
>
> On Thu, Jun 23, 2016 at 9:42 AM, Louis Pop  > wrote:
>
>> I share Jose' opinion here, but making it configurable sounds good.
>>
>> Cheers,
>> Louis
>>
>> On 23 June 2016 at 17:40, Myron Marston > > wrote:
>>
>>> This behavior of IEx has always surprised and annoyed me. I regularly 
>>> type h [first few chars of mod name] in IEx to read the 
>>> read the moduledoc of a particular module, and the trailing period gets in 
>>> the way every time.
>>>
>>> Here’s a demonstration showing what happens to me regularly when I try 
>>> to read the @moduledoc for a module:
>>>
>>> [image: iex_autocomplete_original]
>>>
>>> With this change, it avoids this problem:
>>>
>>> [image: iex_autocomplete_improved]
>>>
>>> I opened a PR with this change 
>>>  but was asked to 
>>> redirect conversation here for community feedback first. On the PR, 
>>> @antipax said (and @josevalim concurred):
>>>
>>> I’m not in support of merging this, if only because the vast majority of 
>>> the time I autocomplete a module in IEx it is to make a remote call.
>>>
>>> I thought the purpose of autocomplete in IEx is to autocomplete tokens 
>>> (e.g. module and function names) not to guess the intention of the 
>>> programmer and add additional characters after the token. IMO, it’s much 
>>> more natural to just complete the module name, and people who want to do a 
>>> remote call (or navigate to a “nested” module) can type a period, than to 
>>> add the period and force the programmer to delete it. After all, I believe 
>>> the autocomplete plugins in most text editors/IDEs would just autocomplete 
>>> the module name, and not add the period.
>>>
>>> On the PR @antipax also said:
>>>
>>> I would be in support of making this configurable, however.
>>>
>>> Having this be configurable would meet my needs as long as I could 
>>> configure it globally (presumably in ~/.iex.exs) but the trailing dot 
>>> still feels like an odd default to me.
>>>
>>> Thoughts from the community?
>>>
>>> Thanks,
>>> Myron
>>> ​
>>>
>>> -- 
>>> 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/CADUxQmu%3Dnc1VpF9Y8oFE%2Bzsp45Xb_sCVZjdPLgBQivrpt2iv2g%40mail.gmail.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> -- 
>> 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/CAM-pwt4sRT8UVdTkEMm1eWsaLdrG%2BbYWnNN20zqtQEvJHq2rrg%40mail.gmail.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to

Re: [elixir-core:5949] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

[Paul Clegg]

I'm actually with Myron.  Since I haven't found a good way in iex to
"cancel the current line", if I get in that spot, I lose a lot of history
and current variables and whatnot.  If anything, my vote would be to make
it optional -- but default it to NOT appending the dot.  I prefer UI
elements that help me do what I want to do, not make presumptions about
what I want to do.

...Paul



On Thu, Jun 23, 2016 at 9:42 AM, Louis Pop  wrote:

> I share Jose' opinion here, but making it configurable sounds good.
>
> Cheers,
> Louis
>
> On 23 June 2016 at 17:40, Myron Marston  wrote:
>
>> This behavior of IEx has always surprised and annoyed me. I regularly
>> type h [first few chars of mod name] in IEx to read the read
>> the moduledoc of a particular module, and the trailing period gets in the
>> way every time.
>>
>> Here’s a demonstration showing what happens to me regularly when I try to
>> read the @moduledoc for a module:
>>
>> [image: iex_autocomplete_original]
>>
>> With this change, it avoids this problem:
>>
>> [image: iex_autocomplete_improved]
>>
>> I opened a PR with this change
>>  but was asked to
>> redirect conversation here for community feedback first. On the PR,
>> @antipax said (and @josevalim concurred):
>>
>> I’m not in support of merging this, if only because the vast majority of
>> the time I autocomplete a module in IEx it is to make a remote call.
>>
>> I thought the purpose of autocomplete in IEx is to autocomplete tokens
>> (e.g. module and function names) not to guess the intention of the
>> programmer and add additional characters after the token. IMO, it’s much
>> more natural to just complete the module name, and people who want to do a
>> remote call (or navigate to a “nested” module) can type a period, than to
>> add the period and force the programmer to delete it. After all, I believe
>> the autocomplete plugins in most text editors/IDEs would just autocomplete
>> the module name, and not add the period.
>>
>> On the PR @antipax also said:
>>
>> I would be in support of making this configurable, however.
>>
>> Having this be configurable would meet my needs as long as I could
>> configure it globally (presumably in ~/.iex.exs) but the trailing dot
>> still feels like an odd default to me.
>>
>> Thoughts from the community?
>>
>> Thanks,
>> Myron
>> ​
>>
>> --
>> 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/CADUxQmu%3Dnc1VpF9Y8oFE%2Bzsp45Xb_sCVZjdPLgBQivrpt2iv2g%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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/CAM-pwt4sRT8UVdTkEMm1eWsaLdrG%2BbYWnNN20zqtQEvJHq2rrg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAD3kWz86V6V%2BEg6QHeXBSNa6ak2BejkowbNLNb1T3JUStbDKzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5948] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

[Louis Pop]

I share Jose' opinion here, but making it configurable sounds good.

Cheers,
Louis

On 23 June 2016 at 17:40, Myron Marston  wrote:

> This behavior of IEx has always surprised and annoyed me. I regularly type h
> [first few chars of mod name] in IEx to read the read the
> moduledoc of a particular module, and the trailing period gets in the way
> every time.
>
> Here’s a demonstration showing what happens to me regularly when I try to
> read the @moduledoc for a module:
>
> [image: iex_autocomplete_original]
>
> With this change, it avoids this problem:
>
> [image: iex_autocomplete_improved]
>
> I opened a PR with this change
>  but was asked to
> redirect conversation here for community feedback first. On the PR,
> @antipax said (and @josevalim concurred):
>
> I’m not in support of merging this, if only because the vast majority of
> the time I autocomplete a module in IEx it is to make a remote call.
>
> I thought the purpose of autocomplete in IEx is to autocomplete tokens
> (e.g. module and function names) not to guess the intention of the
> programmer and add additional characters after the token. IMO, it’s much
> more natural to just complete the module name, and people who want to do a
> remote call (or navigate to a “nested” module) can type a period, than to
> add the period and force the programmer to delete it. After all, I believe
> the autocomplete plugins in most text editors/IDEs would just autocomplete
> the module name, and not add the period.
>
> On the PR @antipax also said:
>
> I would be in support of making this configurable, however.
>
> Having this be configurable would meet my needs as long as I could
> configure it globally (presumably in ~/.iex.exs) but the trailing dot
> still feels like an odd default to me.
>
> Thoughts from the community?
>
> Thanks,
> Myron
> ​
>
> --
> 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/CADUxQmu%3Dnc1VpF9Y8oFE%2Bzsp45Xb_sCVZjdPLgBQivrpt2iv2g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAM-pwt4sRT8UVdTkEMm1eWsaLdrG%2BbYWnNN20zqtQEvJHq2rrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:5947] Proposal: Stop appending a trailing dot when autocompleting modules in IEx

[Myron Marston]

This behavior of IEx has always surprised and annoyed me. I regularly type h
[first few chars of mod name] in IEx to read the read the
moduledoc of a particular module, and the trailing period gets in the way
every time.

Here’s a demonstration showing what happens to me regularly when I try to
read the @moduledoc for a module:

[image: iex_autocomplete_original]

With this change, it avoids this problem:

[image: iex_autocomplete_improved]

I opened a PR with this change
 but was asked to redirect
conversation here for community feedback first. On the PR, @antipax said
(and @josevalim concurred):

I’m not in support of merging this, if only because the vast majority of
the time I autocomplete a module in IEx it is to make a remote call.

I thought the purpose of autocomplete in IEx is to autocomplete tokens
(e.g. module and function names) not to guess the intention of the
programmer and add additional characters after the token. IMO, it’s much
more natural to just complete the module name, and people who want to do a
remote call (or navigate to a “nested” module) can type a period, than to
add the period and force the programmer to delete it. After all, I believe
the autocomplete plugins in most text editors/IDEs would just autocomplete
the module name, and not add the period.

On the PR @antipax also said:

I would be in support of making this configurable, however.

Having this be configurable would meet my needs as long as I could
configure it globally (presumably in ~/.iex.exs) but the trailing dot still
feels like an odd default to me.

Thoughts from the community?

Thanks,
Myron
​

-- 
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/CADUxQmu%3Dnc1VpF9Y8oFE%2Bzsp45Xb_sCVZjdPLgBQivrpt2iv2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5946] Re: Proposal: Enum.merge to extend uniq like functionality

[Peter Hamilton]

The problem with what we currently have is that it requires two passes.
There's no one-pass solution available via composition.

I spent quite a bit of time trying to get Stream.group_by working (back in
my streamz days) so we can compose things like this in a single pass. It
was rough, because it results in a stream of streams which makes it very
complicated. It requires one process per key, which leads to a lot
complexity around supervision/linking/monitoring and is sort of in it's own
league compared to the rest of Stream.

Working with RethinkDB I've seen an alternative approach. Rather than have
group_by produce a map of keys to lists, it produces a somewhat monadic
result. Applying map to a grouped stream doesn't iterate over keys, instead
it applies the function to each group of values. It continues to do so
until you call ungroup, at which point the result is an ordinary map of
keys to lists.

I'll try to find some time to take a stab at that approach, just to see
whether it is at all possible.

On Thu, Jun 23, 2016, 5:26 AM Martin Svalin  wrote:

> tors 23 juni 2016 kl 00:01 skrev Peter Hamilton  >:
>
>> Enum.group_map_reduce(list, group_key_fun, map_fun, initial_acc, reducer)
>>
>> Enum.group_map_reduce([1,1,2,3,5,5,8], &(&1), &(&1), 0, fn _, acc -> acc
>> + 1 end)
>>
>> That would produce:
>>
>> %{1 => 2, 2 => 1, 3 => 1, 5 => 2, 8 => 1}
>>
>
> The whole point here is to do some transformation on all unique values,
> right? So we can group unique values and transform them?
>
> I feel like this is a straightforward `list |> Enum.group_by(& &1) |>
> Enum.map(&transformation/1)`. Possibly piped to Map.new.
> For the case quoted above: `[1,1,2,3,5,5,8] |> Enum.group_by(& &1) |>
> Enum.map(fn {k, v} -> {k, Enum.count v} end) |> Map.new`.
>
> I feel like this is well-composed of what we already have in Enum. There
> are a bunch these "pre-composed" functions in Enum, like `reverse_slice`,
> `map_join`, `filter_map` etc. It's unclear to me when and how the need for
> these pre-composed functions arise. Are they all performance optimisations
> to have common compositions done in one pass? Is this particular case
> common enough to be included as `group_map_reduce`?
>
> Anyway, I would advice against the name `merge` or `merge_by`, as it
> carries the connotation of combining two enumerables, the way `Map.merge`
> does.
>
> - Martin
>
> --
> 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/CAAHw6C%2BM47dureeMaQNvKEM3jcag8PBwJWrqi7f%3D705i7%2BTe1g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAOMhEnxfaV%3DJm6MW2rFR6MRGMRM5iXfZ5ogB4QMgqqOTx7XaDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5945] Re: Proposal: Enum.merge to extend uniq like functionality

[Martin Svalin]

tors 23 juni 2016 kl 00:01 skrev Peter Hamilton :

> Enum.group_map_reduce(list, group_key_fun, map_fun, initial_acc, reducer)
>
> Enum.group_map_reduce([1,1,2,3,5,5,8], &(&1), &(&1), 0, fn _, acc -> acc +
> 1 end)
>
> That would produce:
>
> %{1 => 2, 2 => 1, 3 => 1, 5 => 2, 8 => 1}
>

The whole point here is to do some transformation on all unique values,
right? So we can group unique values and transform them?

I feel like this is a straightforward `list |> Enum.group_by(& &1) |>
Enum.map(&transformation/1)`. Possibly piped to Map.new.
For the case quoted above: `[1,1,2,3,5,5,8] |> Enum.group_by(& &1) |>
Enum.map(fn {k, v} -> {k, Enum.count v} end) |> Map.new`.

I feel like this is well-composed of what we already have in Enum. There
are a bunch these "pre-composed" functions in Enum, like `reverse_slice`,
`map_join`, `filter_map` etc. It's unclear to me when and how the need for
these pre-composed functions arise. Are they all performance optimisations
to have common compositions done in one pass? Is this particular case
common enough to be included as `group_map_reduce`?

Anyway, I would advice against the name `merge` or `merge_by`, as it
carries the connotation of combining two enumerables, the way `Map.merge`
does.

- Martin

-- 
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/CAAHw6C%2BM47dureeMaQNvKEM3jcag8PBwJWrqi7f%3D705i7%2BTe1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5944] Re: Proposal: Enum.merge to extend uniq like functionality

[Onorio Catenacci]

Well I was sort of guessing about your use case @Bartosz.  But I can see
that Peter has given you some code to work with anyway.

Just to be clear about what I'm saying people can propose anything they
want to propose--good ideas come from lots of ideas.  But I think a lot of
us feel as if any changes made to core libraries need to be of a
fundamental and pretty universally applicable nature.  The fact that we can
write code to answer some need doesn't mean it shouldn't be in the core
libraries--but if we add something to the core libs it should be something
with broad application and something of a pretty foundational quality. Of
course my opinion is only important to me anyway but I don't want anyone to
misunderstand my thinking.

--
Onorio


On Wed, Jun 22, 2016 at 4:34 PM, Bartosz Kalinowski 
wrote:

> I can perfectly understand being conservative about new features and I
> don't mind if this doesn't get accepted because of that. Although your
> example is a bit different. To be honest, what I tried to achieve felt like
> a natural extension of Enum.uniq and when I discovered it's not possible to
> do what I needed I was a bit dissapointed. Your example of this
> RunLengthEncoder is not really the same case. The solution to the quiz
> depends on the fact that the letters need to be one after the other and
> Enum.merge which I suggest takes into account every element of the list.
>
>
> On Wednesday, June 22, 2016 at 10:04:58 PM UTC+2, Onorio Catenacci wrote:
>>
>> I'm not sure what the use case is you were trying to address but this
>> seems very similar to a run length encoded use case.  If so, this isn't
>> that hard to roll with existing code. Here:
>>
>> https://gist.github.com/benjamintanweihao/7ea8f15a0b6bb7cca26e
>>
>> So, yeah, we don't _need_ this functionality.  That said, bear in mind,
>> that whenever new things are added to core libraries they have to be
>> supported from that point forward.  So we tend to be conservative about
>> what gets added to core libraries (and justifiably so).
>>
>> --
>> Onorio
>>
>>
>> On Wednesday, June 22, 2016 at 3:15:27 PM UTC-4, Bartosz Kalinowski wrote:
>>>
>>> Hey guys, this is my first proposal so please be kind :) I don't know if
>>> WE need this functionality, but I certainly needed this so I already
>>> developed it. Obviously I'm not that familiar with Elixir yet so it might
>>> happen that there is something very simmilar somewhere in the code, but I
>>> looked and couldn't find it.
>>>
>>>
>>> My idea is to "cleanup" lists which have duplicate values, but in a way
>>> that will merge the duplicate values (not just ignore them like uniq/1 does)
>>> by using given function (one of the params). Please let me know what you
>>> think.
>>>
>>>
>>> Examples:
>>>
>>>
>>>   iex> Enum.merge([1, 2, 3, 3, 2, 1], fn (x, y) -> x + y end)
>>>
>>>   [2, 4, 6]
>>>
>>>
>>>   # This one is simmilar to `Enum.uniq/1`
>>>
>>>   iex> Enum.merge([1, 2, 3, 3, 2, 1], fn (x, _y) -> x end)
>>>
>>>   [1, 2, 3]
>>>
>>>
>>>   iex> Enum.merge_by([{1, :x}, {2, :y}, {1, :z}], fn (x, _) -> x
>>> end, fn {x, _} -> x end)
>>>
>>>   [{1, :x}, {2, :y}]
>>>
>>>
>>>   iex> Enum.merge_by([a: {:tea, 2}, b: {:tea, 2}, c: {:coffee, 1}],
>>> fn (x, _) -> x end, fn {_, y} -> y end)
>>>
>>>   [a: {:tea, 2}, c: {:coffee, 1}]
>>>
>>>
>>>   iex> Enum.merge_by([%{k: "a", v: 1}, %{k: "b", v: 2}, %{k: "a", v:
>>> 3}, %{k: "b", v: 4}], fn(t1, t2) -> %{t1 | v: t1.v + t2.v} end, fn s ->
>>> s.k end)
>>>
>>>   [%{k: "a", v: 4}, %{k: "b", v: 6}]
>>>
>>>
>>> Because I'm new here I already created PR on github which obviously got
>>> closed immediately... :) But there is an upside to this, I already
>>> implemented this functionality so you can see the examples in more
>>> "human-readable" form on github (
>>> https://github.com/elixir-lang/elixir/pull/4854/files) to better
>>> understand what I wanted to achieve :)
>>>
>>>
>>> Please let me know if you think this would be useful and maybe if there
>>> is no simmilar functionality already!
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "elixir-lang-core" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elixir-lang-core/NVT7XEMmldo/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/84b33056-1ed1-4291-be72-5900e053fccb%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Onorio Catenacci

http://onor.io
http://www.google.com/+OnorioCatenacci

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this g