Ingela Anderton Andin | 2 Nov 15:12 2007
Picon
Picon

Re: ODBC enhancement: support for out & inout parameters for stored procedures

Hi!

We can absolutely add this patch to odbc if it will pass our
test-suite. However it will probably not make it in time for R12B but
maybe R12B-1. It would also be good to have some new test case for
this functionality. If you could provide some test data it would speed
things up.  Preferably the test should be able to run on all database
backends. If it can not be made genericly we already use callbacks
for some special cases.  The currently tested backends are sql-server
and postgres. The test case should create a data base table, do operations
on the table to verify the functionality and then drop the table.

Regards Ingela - OTP team

Scott Lystig Fritchie wrote:
> Howdy.  We've been using the patch below for months without any ill
> effect and are wondering if it'd be useful for the community at
> large.  IIRC, it supports out & inout parameters for stored
> procedures ... er, or something else that the ODBC driver can't quite
> do.  :-)
>
> -Scott
>
> --- snip --- snip --- snip --- snip --- snip --- snip ---
>
> --- ./otp_src_R11B-5/lib/odbc/c_src/odbcserver.c.org	2007-01-29 05:17:56.000000000 -0800
> +++ ./otp_src_R11B-5/lib/odbc/c_src/odbcserver.c	2007-07-24 19:03:43.000000000 -0700
>  <at>  <at>  -81,7 +81,8  <at>  <at> 
>     N - integer
>     Binary - binary encodede tuple of {SQLQuery, NoRows, Parameters}
(Continue reading)

John Hughes | 6 Nov 19:36 2007

Loss of sharing

Try running hog:main() in the program below. It creates a data structure in one process, measuring heap size, and how it changes during the creation. Then it sends it to another, measuring the memory allocated in the receiving process. Here’s the output:

 

Creating tree:: allocated 0 bytes, heap size 987 bytes

Receiving tree:: allocated 116769407 bytes, heap size 116769640 bytes

true

 

That is, the structure is less than 1K bytes in the sender, but over 100MB in the receiver.

 

The reason is that it contains  a lot of sharing, and sharing is lost when messages are sent to other processes. Sharing is ALSO lost when values are copied to a new process being spawned. In fact, I’ve found no way to copy structures between processes WITHOUT losing sharing. This means that some data simply cannot practically be sent from one process to another.

 

I understand, of course, that if I send the same structure IN TWO SEPARATE MESSAGES, that I am bound to get two copies in the receiver. But if I send a structure in  ONE message, then there’s in principle no reason why the copy could not preserve sharing. That’s true even when copying between nodes.

 

In my real application the data is funs, constructed in a complex manner so that I cannot predict the sharing. When the sharing is lost, they get bigger than the tree in my example. If I can’t preserve sharing when I send them to another process, then I can’t structure my program using processes. That, in turn, limits my ability to trap exits.

 

Any chance of introducing a sharing-preserving copy in message send and spawn? It would be really useful!

 

John Hughes

 

 

-module(hog).

-compile(export_all).

 

% Builds a binary tree of depth N. Note the sharing!

tree(0) ->

    leaf;

tree(N) ->

    T = tree(N-1),

    {T,T}.

 

measure(S,F) ->

    {heap_size,Before} = process_info(self(),heap_size),

    Result = F(),

    {heap_size,After} = process_info(self(),heap_size),

    io:format("~s: allocated ~w bytes, heap size ~w bytes~n",

                                   [S,After-Before,After]),

    Result.

 

main() ->

    T = measure("Creating tree:",fun() -> tree(25) end),

    Child = spawn(fun() -> child() end),

    erlang:yield(),

    Child ! T,

    erlang:yield().

 

child() ->

    measure("Receiving tree:",fun() -> receive Tree -> ok end end).

                                                                                                                         

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs
Bjorn Gustavsson | 7 Nov 06:35 2007
Picon
Picon

Re: Loss of sharing

"John Hughes" <john.hughes <at> quviq.com> writes:

> Try running hog:main() in the program below. It creates a data structure in
> one process, measuring heap size, and how it changes during the creation.
> Then it sends it to another, measuring the memory allocated in the receiving
> process. Here's the output:
> 
> Creating tree:: allocated 0 bytes, heap size 987 bytes
> 
> Receiving tree:: allocated 116769407 bytes, heap size 116769640 bytes
> 
> true
> 
> That is, the structure is less than 1K bytes in the sender, but over 100MB
> in the receiver.
> 

For the traditional type of applications that Erlang is typically is used
for, loss of sharing is not an issue. There is typically no sharing at all.
Therefore term copying between process is optimized for speed.

> 
> The reason is that it contains  a lot of sharing, and sharing is lost when
> messages are sent to other processes. Sharing is ALSO lost when values are
> copied to a new process being spawned. In fact, I've found no way to copy
> structures between processes WITHOUT losing sharing. This means that some
> data simply cannot practically be sent from one process to another.

Correct.

> 
> Any chance of introducing a sharing-preserving copy in message send and
> spawn? It would be really useful!

It is not likely that it will become the default behaviour. But it could be
possible to make it possible as an option, for instance a new option for the
erlang:send/3 BIF.

/Bjorn

--

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs

Dominic Williams | 9 Nov 17:33 2007
Picon

Re: Does 'ic' (the CORBA IDL compiler) support recursive types?

Hi Nick,

> After a quick search in my mail boxes I found that the last time someone
> asked about rescursive types was back in Nov 2003. As you understand,
> since it's seldom used and one can solve this in other ways, it hasn't
> been a high prio IC extension.

I would just like to point out that this rationale only applies to
projects using
Erlang and Orber for custom CORBA interfaces (when the IDL can be
modified at will to work around an IC limitation).

We use Erlang and Orber in a product which allows our customers to
interface with any CORBA server themselves, without coding anything. In
practice they use this to interface with legacy external systems with a
fixed, published IDL that cannot be changed.

Luckily we have not yet come across one such IDL using recursive types,
but it would be preferable, for projects such as ours integrating Orber and
IC as a component of our product rather than using it as an internal
development tool, if IC could handle any legal IDL.

Regards,

Dominic Williams
http://dominicwilliams.net

----

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs

John Hughes | 10 Nov 12:18 2007

Lists module funnies

What's the next element in this sequence?

1> lists:seq(1,3).
[1,2,3]
2> lists:seq(1,2).
[1,2]
3> lists:seq(1,1).
[1]
4> lists:seq(1,0).

I expect [], but what I get is:

=ERROR REPORT==== 10-Nov-2007::12:11:21 ===
Error in process <0.30.0> with exit value:
{function_clause,[{lists,seq,[1,0]},{
erl_eval,do_apply,5},{shell,exprs,6},{shell,eval_loop,3}]}

** exited: {function_clause,[{lists,seq,[1,0]},
                             {erl_eval,do_apply,5},
                             {shell,exprs,6},
                             {shell,eval_loop,3}]} **

I've worked around this more times than I can remember, special-casing the
zero case to avoid calling seq, and I'll bet that many callers of seq have
to do the same thing. Any chance of changing this in the future? There can't
be much code that would break... code that only works today *because* seq
raises an exception.

John Hughes

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs

Zvi | 11 Nov 11:53 2007

Re: Lists module funnies


This is what I get in Matlab:

>> 1:0

ans =

   Empty matrix: 1-by-0

Anyway, I missing some Matlab-like syntactic sugar, this will be especially
usefull in list comprehensions:

>> 1:10

ans =

     1     2     3     4     5     6     7     8     9    10

>> 10:-1:1

ans =

    10     9     8     7     6     5     4     3     2     1

>> 0:0.1:1

ans =

         0    0.1000    0.2000    0.3000    0.4000    0.5000    0.6000   
0.7000    0.8000    0.9000    1.0000

Since ":" has special meaning in Erlang, as separator between module and
function names, we can use "..", this is similar to range in Pascal/Ada.
This might be implented as operator  erlang:'..'/2 or erlang:'..'/3 

From..To  == lists:seq(From,To)
   or   
From..Step..To == lists:seq(From,To,Step)

except, that lists:seq doesn't support floats.
Then calculating Multiplication table will look like this:

Table = [{N,M,N*M} || N<-1..10, M<-1..10].

Can this be implemented in R12 ?

Thanks in advance
Zvi

John Hughes-7 wrote:
> 
> What's the next element in this sequence?
> 
> 1> lists:seq(1,3).
> [1,2,3]
> 2> lists:seq(1,2).
> [1,2]
> 3> lists:seq(1,1).
> [1]
> 4> lists:seq(1,0).
> 
> I expect [], but what I get is:
> 
> =ERROR REPORT==== 10-Nov-2007::12:11:21 ===
> Error in process <0.30.0> with exit value:
> {function_clause,[{lists,seq,[1,0]},{
> erl_eval,do_apply,5},{shell,exprs,6},{shell,eval_loop,3}]}
> 
> ** exited: {function_clause,[{lists,seq,[1,0]},
>                              {erl_eval,do_apply,5},
>                              {shell,exprs,6},
>                              {shell,eval_loop,3}]} **
> 
> I've worked around this more times than I can remember, special-casing the
> zero case to avoid calling seq, and I'll bet that many callers of seq have
> to do the same thing. Any chance of changing this in the future? There
> can't
> be much code that would break... code that only works today *because* seq
> raises an exception.
> 
> John Hughes
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs <at> erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-bugs
> 
> 

--

-- 
View this message in context: http://www.nabble.com/Lists-module-funnies-tf4782240.html#a13690246
Sent from the Erlang Bugs mailing list archive at Nabble.com.

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs

Torbjorn Tornkvist | 12 Nov 09:54 2007

Re: Lists module funnies


While on the topic, wouldn't it be nice with arithmetic sequences a la
Haskell?

Example:

[2,3..10]  =>  [2,3,4,5,6,7,8,9,10]

[2,1.8..1]  => [2,1.8,1.6,1.4,1.2,1]

The semantics is thus something like:

[a,b..c] => d=b-a, [a,a+d,a+d*2,a+d*3,..etc...] until a+d*X > c

Cheers, Tobbe

John Hughes wrote:
> What's the next element in this sequence?
> 
> 1> lists:seq(1,3).
> [1,2,3]
> 2> lists:seq(1,2).
> [1,2]
> 3> lists:seq(1,1).
> [1]
> 4> lists:seq(1,0).
> 
> I expect [], but what I get is:
> 
> =ERROR REPORT==== 10-Nov-2007::12:11:21 ===
> Error in process <0.30.0> with exit value:
> {function_clause,[{lists,seq,[1,0]},{
> erl_eval,do_apply,5},{shell,exprs,6},{shell,eval_loop,3}]}
> 
> ** exited: {function_clause,[{lists,seq,[1,0]},
>                              {erl_eval,do_apply,5},
>                              {shell,exprs,6},
>                              {shell,eval_loop,3}]} **
> 
> I've worked around this more times than I can remember, special-casing the
> zero case to avoid calling seq, and I'll bet that many callers of seq have
> to do the same thing. Any chance of changing this in the future? There can't
> be much code that would break... code that only works today *because* seq
> raises an exception.
> 
> John Hughes
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs <at> erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-bugs
> 

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs

Niclas Eklund | 12 Nov 11:01 2007
Picon
Picon

Re: Does 'ic' (the CORBA IDL compiler) support recursive types?


Hello!

You're corrrect. It would also cause problems if a standard specification
(e.g. from OMG, 3GPP or Parlay) is issued and it contains rescursive
types. At the moment, due to lack of time, it's impopssible to say when
this could be added.

/Nick

On Fri, 9 Nov 2007, Dominic Williams wrote:

> Hi Nick,
> 
> > After a quick search in my mail boxes I found that the last time someone
> > asked about rescursive types was back in Nov 2003. As you understand,
> > since it's seldom used and one can solve this in other ways, it hasn't
> > been a high prio IC extension.
> 
> I would just like to point out that this rationale only applies to
> projects using
> Erlang and Orber for custom CORBA interfaces (when the IDL can be
> modified at will to work around an IC limitation).
> 
> We use Erlang and Orber in a product which allows our customers to
> interface with any CORBA server themselves, without coding anything. In
> practice they use this to interface with legacy external systems with a
> fixed, published IDL that cannot be changed.
> 
> Luckily we have not yet come across one such IDL using recursive types,
> but it would be preferable, for projects such as ours integrating Orber and
> IC as a component of our product rather than using it as an internal
> development tool, if IC could handle any legal IDL.
> 
> Regards,
> 
> Dominic Williams
> http://dominicwilliams.net
> 
> ----

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs

Hans Bolinder | 12 Nov 13:39 2007
Picon

Re: odd rr behaivor

[Matthew O'Gorman:]
> I wouldn't necessarily call this a bug, but it seems rr does not allow
> for passing an atom to it in the same way, for example
> 
> 1> ls().
> mog.hrl
> ok
> 2> rr(mog).
> {error, nofile}
> 3>rr("mog").
> []
> 4>rr("mog.hrl").
> [test]
> ...

Hi,

Sorry for not answering sooner.

rr(Atom) is essentially the same as rr(code:which(Atom)).

Instead of 'rr("long_path_to_a_header_file")' it is often convenient to
call 'rr(Module)' (Module an atom) where Module includes the header file.

An example: instead of
    rr("/usr/local/lib/erlang/lib/xmerl-1.1.5/include/xmerl.hrl").
one can do
    rr(xmerl).

Best regards,

Hans Bolinder, Erlang/OTP
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs

Anders Nygren | 15 Nov 17:44 2007
Picon

R12 - Internal consistency check failed

Using the R12 snapshot from 15-Nov-2007 12:53 I get the following error

/usr/local/src/otp/otp_src_R12B-0/bin/erlc -smp wfbm4_ets.erl
wfbm4_ets: function find/6+75:
  Internal consistency check failed - please report this bug.
  Instruction: {test,bs_start_match2,{f,45},[{y,7},3,0,{x,1}]}
  Error:       {match_context,{y,7}}:

make: *** [wfbm4_ets.beam] Error 1

when I compile the attached wfbm4_ets.erl

/Anders
Attachment (wfbm4_ets.erl): text/x-erlang, 5110 bytes
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://www.erlang.org/mailman/listinfo/erlang-bugs

Gmane