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

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

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

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

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

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

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

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

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

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

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

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.