| Author |
Message |
|
| Guest |
Posted: Fri May 28, 2010 11:56 am |
|
|
|
Guest
|
There is a patch that removes tid() from the list of predefined types.
It can be included as is provided that the 'export_type' branch is first
included in OTP. Otherwise, one has to manually remove the line which
reads:
-export_type([tab/0, tid/0]).
from file ets.erl
git fetch git://github.com/kostis/otp.git ets-tid-type
Kostis
________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
Posted: Fri May 28, 2010 11:57 am |
|
|
|
Guest
|
There is a patch that removes tid() from the list of predefined types.
It can be included as is provided that the 'export_type' branch is first
included in OTP. Otherwise, one has to manually remove the line which
reads:
-export_type([tab/0, tid/0]).
from file ets.erl
git fetch git://github.com/kostis/otp.git ets-tid-type
Kostis
________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
Posted: Mon May 31, 2010 2:34 pm |
|
|
|
Guest
|
On Fri, May 28, 2010 at 02:56:31PM +0300, Kostis Sagonas wrote:
> There is a patch that removes tid() from the list of predefined types.
> It can be included as is provided that the 'export_type' branch is first
> included in OTP. Otherwise, one has to manually remove the line which
> reads:
>
> -export_type([tab/0, tid/0]).
>
> from file ets.erl
>
>
> git fetch git://github.com/kostis/otp.git ets-tid-type
I got into merge conflicts due to the bootstrap code
update and more. I will have to take this tomorrow...
>
> Kostis
>
> ________________________________________________________________
> erlang-patches (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
Posted: Mon May 31, 2010 2:34 pm |
|
|
|
Guest
|
On Fri, May 28, 2010 at 02:56:31PM +0300, Kostis Sagonas wrote:
> There is a patch that removes tid() from the list of predefined types.
> It can be included as is provided that the 'export_type' branch is first
> included in OTP. Otherwise, one has to manually remove the line which
> reads:
>
> -export_type([tab/0, tid/0]).
>
> from file ets.erl
>
>
> git fetch git://github.com/kostis/otp.git ets-tid-type
I got into merge conflicts due to the bootstrap code
update and more. I will have to take this tomorrow...
>
> Kostis
>
> ________________________________________________________________
> erlang-patches (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
Posted: Tue Jun 01, 2010 8:19 am |
|
|
|
Guest
|
On Mon, May 31, 2010 at 05:43:12PM +0300, Kostis Sagonas wrote:
> Raimo Niskanen wrote:
> >On Fri, May 28, 2010 at 02:56:31PM +0300, Kostis Sagonas wrote:
> >>There is a patch that removes tid() from the list of predefined types.
> >>It can be included as is provided that the 'export_type' branch is first
> >>included in OTP. Otherwise, one has to manually remove the line which
> >>reads:
> >>
> >>-export_type([tab/0, tid/0]).
> >>
> >>from file ets.erl
> >>
> >>
> >> git fetch git://github.com/kostis/otp.git ets-tid-type
> >
> >I got into merge conflicts due to the bootstrap code
> >update and more. I will have to take this tomorrow...
>
> Raimo,
>
> The erl_lint.beam file in bootstrap is nothing special. It is just the
> .beam file that corresponds to the erl_lint.erl file so any such .beam
> file will do.
>
> The only thing that you have to be careful of is to include such a file
> before including the change in lib/debugger/src/dbg_iload.erl
Yes. That I can handle and/or ask Bj |
|
|
| Back to top |
|
| Guest |
Posted: Tue Jun 01, 2010 8:19 am |
|
|
|
Guest
|
On Mon, May 31, 2010 at 05:43:12PM +0300, Kostis Sagonas wrote:
> Raimo Niskanen wrote:
> >On Fri, May 28, 2010 at 02:56:31PM +0300, Kostis Sagonas wrote:
> >>There is a patch that removes tid() from the list of predefined types.
> >>It can be included as is provided that the 'export_type' branch is first
> >>included in OTP. Otherwise, one has to manually remove the line which
> >>reads:
> >>
> >>-export_type([tab/0, tid/0]).
> >>
> >>from file ets.erl
> >>
> >>
> >> git fetch git://github.com/kostis/otp.git ets-tid-type
> >
> >I got into merge conflicts due to the bootstrap code
> >update and more. I will have to take this tomorrow...
>
> Raimo,
>
> The erl_lint.beam file in bootstrap is nothing special. It is just the
> .beam file that corresponds to the erl_lint.erl file so any such .beam
> file will do.
>
> The only thing that you have to be careful of is to include such a file
> before including the change in lib/debugger/src/dbg_iload.erl
Yes. That I can handle and/or ask Bj |
|
|
| Back to top |
|
| Guest |
Posted: Tue Jun 01, 2010 8:21 am |
|
|
|
Guest
|
Raimo Niskanen wrote:
> ++<<<<<<< HEAD
> +-spec load_mod1(module(), file:filename(), binary(), tid()) -> no_return().
> ++=======
> + -spec load_mod1(atom(), file:filename(), binary(), ets:tid()) -> no_return().
> ++>>>>>>> ks/ets-tid-type
>
> load_mod1(Mod, File, Binary, Db) ->
> store_module(Mod, File, Binary, Db),
>
> In your new branch ks/ets-tid-type you use atom() instead of module()
> that was added by ks/cleanups as suggested by tidier. I know that
> the tid() -> ets:tid() change is expected buth the module() -> atom()
> is not my home turf...
You should take the atom() one (or change it manually).
Kostis
________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
Posted: Tue Jun 01, 2010 8:22 am |
|
|
|
Guest
|
Raimo Niskanen wrote:
> ++<<<<<<< HEAD
> +-spec load_mod1(module(), file:filename(), binary(), tid()) -> no_return().
> ++=======
> + -spec load_mod1(atom(), file:filename(), binary(), ets:tid()) -> no_return().
> ++>>>>>>> ks/ets-tid-type
>
> load_mod1(Mod, File, Binary, Db) ->
> store_module(Mod, File, Binary, Db),
>
> In your new branch ks/ets-tid-type you use atom() instead of module()
> that was added by ks/cleanups as suggested by tidier. I know that
> the tid() -> ets:tid() change is expected buth the module() -> atom()
> is not my home turf...
You should take the atom() one (or change it manually).
Kostis
________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
Posted: Wed Jun 02, 2010 9:21 pm |
|
|
|
Guest
|
Thanks a lot for this! Applied with minor tweaks to our R13B03-ish OTP.
However seeing the actual list of predefined types for the first
time:-), I think there are a few more of them that falls in the same
category as tid(), and should be made module-specific for the same
reasons:
{array, 0},
{dict, 0},
{digraph, 0},
{gb_set, 0},
{gb_tree, 0},
{queue, 0},
{set, 0},
E.g. having a predefined type queue(), which can only be defined as "The
opaque type returned by new/0 in the OTP module called 'queue'", and
which prevents all use of that type name in user-written modules (where
it could otherwise exist peacefully as mod:queue()), really doesn't seem
like a good idea to me. I won't argue this point further though.
--Per
Kostis Sagonas <kostis@cs.ntua.gr> wrote:
>
>There is a patch that removes tid() from the list of predefined types.
>It can be included as is provided that the 'export_type' branch is first
>included in OTP. Otherwise, one has to manually remove the line which
>reads:
>
>-export_type([tab/0, tid/0]).
>
>from file ets.erl
>
>
> git fetch git://github.com/kostis/otp.git ets-tid-type
>
>Kostis
________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
Posted: Wed Jun 02, 2010 9:21 pm |
|
|
|
Guest
|
Thanks a lot for this! Applied with minor tweaks to our R13B03-ish OTP.
However seeing the actual list of predefined types for the first
time:-), I think there are a few more of them that falls in the same
category as tid(), and should be made module-specific for the same
reasons:
{array, 0},
{dict, 0},
{digraph, 0},
{gb_set, 0},
{gb_tree, 0},
{queue, 0},
{set, 0},
E.g. having a predefined type queue(), which can only be defined as "The
opaque type returned by new/0 in the OTP module called 'queue'", and
which prevents all use of that type name in user-written modules (where
it could otherwise exist peacefully as mod:queue()), really doesn't seem
like a good idea to me. I won't argue this point further though.
--Per
Kostis Sagonas <kostis@cs.ntua.gr> wrote:
>
>There is a patch that removes tid() from the list of predefined types.
>It can be included as is provided that the 'export_type' branch is first
>included in OTP. Otherwise, one has to manually remove the line which
>reads:
>
>-export_type([tab/0, tid/0]).
>
>from file ets.erl
>
>
> git fetch git://github.com/kostis/otp.git ets-tid-type
>
>Kostis
________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
Posted: Wed Jun 02, 2010 9:57 pm |
|
|
|
Guest
|
Per Hedeland wrote:
> Thanks a lot for this! Applied with minor tweaks to our R13B03-ish OTP.
> However seeing the actual list of predefined types for the first
> time:-), I think there are a few more of them that falls in the same
> category as tid(), and should be made module-specific for the same
> reasons:
>
> {array, 0},
> {dict, 0},
> {digraph, 0},
> {gb_set, 0},
> {gb_tree, 0},
> {queue, 0},
> {set, 0},
>
> E.g. having a predefined type queue(), which can only be defined as "The
> opaque type returned by new/0 in the OTP module called 'queue'", and
> which prevents all use of that type name in user-written modules (where
> it could otherwise exist peacefully as mod:queue()), really doesn't seem
> like a good idea to me. I won't argue this point further though.
Per,
You are absolutely right about this and it is indeed my intention to
take these out from the list of predefined types. However, this is a
bit tricky to do at this point (for various reasons that I will not go
into now) and IMO it is best done when two other features are in place:
1. The ability to write -import_type attributes (analogous to -import)
so that one does not have to write: gb_trees:gb_tree() all over the
place.
2. The ability to have parameterized opaque types, e.g. set(atom())
which is currently not possible.
The first addition is relatively easy and may happen soon. The second
one is a significant change. When these two are in place, we will take
out these types from the list of predefined types.
Kostis
________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
Posted: Wed Jun 02, 2010 9:58 pm |
|
|
|
Guest
|
Per Hedeland wrote:
> Thanks a lot for this! Applied with minor tweaks to our R13B03-ish OTP.
> However seeing the actual list of predefined types for the first
> time:-), I think there are a few more of them that falls in the same
> category as tid(), and should be made module-specific for the same
> reasons:
>
> {array, 0},
> {dict, 0},
> {digraph, 0},
> {gb_set, 0},
> {gb_tree, 0},
> {queue, 0},
> {set, 0},
>
> E.g. having a predefined type queue(), which can only be defined as "The
> opaque type returned by new/0 in the OTP module called 'queue'", and
> which prevents all use of that type name in user-written modules (where
> it could otherwise exist peacefully as mod:queue()), really doesn't seem
> like a good idea to me. I won't argue this point further though.
Per,
You are absolutely right about this and it is indeed my intention to
take these out from the list of predefined types. However, this is a
bit tricky to do at this point (for various reasons that I will not go
into now) and IMO it is best done when two other features are in place:
1. The ability to write -import_type attributes (analogous to -import)
so that one does not have to write: gb_trees:gb_tree() all over the
place.
2. The ability to have parameterized opaque types, e.g. set(atom())
which is currently not possible.
The first addition is relatively easy and may happen soon. The second
one is a significant change. When these two are in place, we will take
out these types from the list of predefined types.
Kostis
________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
|
|
|