Nabble - Erlang Patches

PATCH: update of non existing row returns {error,"No SQL-driver information available."}

2009-11-24T03:02:52Z

Hi all,

I noticed the following when no rows were updated for an update statement:

4> odbc:param_query(Ref, "update tbadger set status = ? where
badger_id = ?", [{{sql_varchar,1},["R"]}, {sql_integer, [61111]}]).
{error,"No SQL-driver information available."}
5> odbc:param_query(Ref, "update tbadger set status = ? where
badger_id = ?", [{{sql_varchar,1},["R"]}, {sql_integer, [61]}]).
{updated,1}

The attached patch, which requires the ODBC patch from Andrew
Thompson, should fix it:

3> odbc:param_query(Ref, "update tbadger set status = ? where
badger_id = ?", [{{sql_varchar,1},["R"]}, {sql_integer, [61111]}]).
{updated,0}
4>

Cheers,
Paul.

[odbcserver.diff]

diff --git a/lib/odbc/c_src/odbcserver.c b/lib/odbc/c_src/odbcserver.c index 9d49fa7..9f2d605 100644 --- a/lib/odbc/c_src/odbcserver.c +++ b/lib/odbc/c_src/odbcserver.c @@ -749,11 +749,11 @@ static db_result_msg db_param_query(byte *buffer, db_state *state) byte *sql; db_result_msg msg; int i, num_param_values, ver = 0, - erl_type = 0, index = 0, size = 0, cols = 0; + erl_type = 0, index = 0, size = 0, cols = 0, sql_succ = 1; long long_num_param_values; param_status param_status; diagnos diagnos; - param_array *params; + param_array *params; if (associated_result_set(state)) { clean_state(state); @@ -784,12 +784,15 @@ static db_result_msg db_param_query(byte *buffer, db_state *state) num_param_values, state); if(params != NULL) { - if(!sql_success(SQLExecDirect(statement_handle(state), - sql, SQL_NTS))) { - diagnos = get_diagnos(SQL_HANDLE_STMT, statement_handle(state)); - msg = encode_error_message(diagnos.error_msg); + if (!sql_success(SQLExecDirect(statement_handle(state), sql, SQL_NTS))) { + sql_succ = 0; + diagnos = get_diagnos(SQL_HANDLE_STMT, statement_handle(state)); + } + /* SQLSTATE 00000 also indicates success */ + if(!sql_succ && !strcmp(diagnos.sqlState, INFO)) { + msg = encode_error_message(diagnos.error_msg); } else { - for (i = 0; i < param_status.params_processed; i++) { + for (i = 0; i < param_status.params_processed; i++) { switch (param_status.param_status_array[i]) { case SQL_PARAM_SUCCESS: case SQL_PARAM_SUCCESS_WITH_INFO: @@ -823,7 +826,7 @@ static db_result_msg db_param_query(byte *buffer, db_state *state) } } }

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

os_mon patch for get_memory_usage under OS X

2009-11-20T08:39:00Z

The attached patch adds support to using the memsup port to get memory information rather then parsing the output from vm_stat.

I have only tested this on 10.6, but it should work on previous versions.

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

darwin_memsup.patch (5K) Download Attachment

Re: Patch to fix ssh library

2009-11-20T00:41:30Z

Hello!

R13B03 will be released on Wednesday. Since SSH-1.1.7 contain two other
important fixes you should upgrade to that version. Some of the channel
modules has been changed which is why I suspect that your second patch
cannot be applied straight away. It would be great if you could take a
look at the new version, alter the patch if so required and send it to me
so I can investigate it.

/Niclas @ Erlang/OTP

On Thu, 19 Nov 2009, Kris Rasmussen wrote:

> Hi Niclas,
>
> I'm glad to hear that. Is there somewhere I can look to see the SSH-1.1.7
> code?
>
> I've also made a patch to enable customizing the way SSH keys are looked up
> with a callback module and am currently looking into giving ssh channel
> modules more control over the SSH window size. I'd like to know if some of
> this work is already being done.
>
> Thanks!
>
> Kris
>
> On Thu, Nov 19, 2009 at 12:44 AM, Niclas Eklund <nick@...>wrote:
>
>>
>> Hello!
>>
>> Thanks for the patch! This issue has already been solved in a slightly
>> different way in SSH-1.1.7, which will be included in R13B03.
>>
>> Best regards,
>>
>> /Niclas @ Erlang/OTP
>>
>>
>> On Wed, 18 Nov 2009, Kris Rasmussen wrote:
>>
>> I was noticing that when receiving large amounts of data the erlang SSH
>>> library would often freeze and no longer receive any data from the server
>>> I
>>> was connecting to. After a bit of work, I tracked this down to an
>>> "infinite"
>>> loop in ssh_connection_handler.erl. The problem occurs when the first
>>> block
>>> has not yet been decoded and a call to next_packet is made. This would
>>> trigger the process to send itself a socket-receive message but it's
>>> possible that there isn't additional data ready on the socket. I fixed
>>> this
>>> by adding a call to make the socket active again as is the case in the
>>> subsequent next_packet function definition when the decoded_data_buffer is
>>> not empty.
>>>
>>> From my testing so far, this resolves the issue and I have not yet seen
>>>> any
>>>>
>>> other side effects. Please let me know what you think.
>>>
>>> I've attached my patch for R13B02, but you can also get it here:
>>>
>>> http://github.com/krisr/erlang-macports/raw/master/lang/erlang/files/patch-lib-ssh-src-ssh_connection_handler.erl.diff
>>>
>>> Best,
>>> Kris
>>>
>>> --
>>> Kris Rasmussen
>>> kris@...
>>>
>>> Twitter: http://twitter.com/aptana
>>> Facebook: http://aptana.com/facebook
>>>
>>>
>>
>>
>
>
> --
> Kris Rasmussen
> kris@...
>
> Twitter: http://twitter.com/aptana
> Facebook: http://aptana.com/facebook
>

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: Patch to fix ssh library

2009-11-19T20:43:42Z

Hi Niclas,

I'm glad to hear that. Is there somewhere I can look to see the SSH-1.1.7
code?

I've also made a patch to enable customizing the way SSH keys are looked up
with a callback module and am currently looking into giving ssh channel
modules more control over the SSH window size. I'd like to know if some of
this work is already being done.

Thanks!

Kris

On Thu, Nov 19, 2009 at 12:44 AM, Niclas Eklund <nick@...>wrote:

>
> Hello!
>
> Thanks for the patch! This issue has already been solved in a slightly
> different way in SSH-1.1.7, which will be included in R13B03.
>
> Best regards,
>
> /Niclas @ Erlang/OTP
>
>
> On Wed, 18 Nov 2009, Kris Rasmussen wrote:
>
> I was noticing that when receiving large amounts of data the erlang SSH
>> library would often freeze and no longer receive any data from the server
>> I
>> was connecting to. After a bit of work, I tracked this down to an
>> "infinite"
>> loop in ssh_connection_handler.erl. The problem occurs when the first
>> block
>> has not yet been decoded and a call to next_packet is made. This would
>> trigger the process to send itself a socket-receive message but it's
>> possible that there isn't additional data ready on the socket. I fixed
>> this
>> by adding a call to make the socket active again as is the case in the
>> subsequent next_packet function definition when the decoded_data_buffer is
>> not empty.
>>
>> From my testing so far, this resolves the issue and I have not yet seen
>>> any
>>>
>> other side effects. Please let me know what you think.
>>
>> I've attached my patch for R13B02, but you can also get it here:
>>
>> http://github.com/krisr/erlang-macports/raw/master/lang/erlang/files/patch-lib-ssh-src-ssh_connection_handler.erl.diff
>>
>> Best,
>> Kris
>>
>> --
>> Kris Rasmussen
>> kris@...
>>
>> Twitter: http://twitter.com/aptana
>> Facebook: http://aptana.com/facebook
>>
>>
>
>

--
Kris Rasmussen
kris@...

Twitter: http://twitter.com/aptana
Facebook: http://aptana.com/facebook

Re: Patch to fix ssh library

2009-11-19T00:44:58Z

Hello!

Thanks for the patch! This issue has already been solved in a slightly
different way in SSH-1.1.7, which will be included in R13B03.

Best regards,

/Niclas @ Erlang/OTP

On Wed, 18 Nov 2009, Kris Rasmussen wrote:

> I was noticing that when receiving large amounts of data the erlang SSH
> library would often freeze and no longer receive any data from the server I
> was connecting to. After a bit of work, I tracked this down to an "infinite"
> loop in ssh_connection_handler.erl. The problem occurs when the first block
> has not yet been decoded and a call to next_packet is made. This would
> trigger the process to send itself a socket-receive message but it's
> possible that there isn't additional data ready on the socket. I fixed this
> by adding a call to make the socket active again as is the case in the
> subsequent next_packet function definition when the decoded_data_buffer is
> not empty.
>
>> From my testing so far, this resolves the issue and I have not yet seen any
> other side effects. Please let me know what you think.
>
> I've attached my patch for R13B02, but you can also get it here:
> http://github.com/krisr/erlang-macports/raw/master/lang/erlang/files/patch-lib-ssh-src-ssh_connection_handler.erl.diff
>
> Best,
> Kris
>
> --
> Kris Rasmussen
> kris@...
>
> Twitter: http://twitter.com/aptana
> Facebook: http://aptana.com/facebook
>

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Patch to fix ssh library

2009-11-18T11:00:33Z

I was noticing that when receiving large amounts of data the erlang SSH library would often freeze and no longer receive any data from the server I was connecting to. After a bit of work, I tracked this down to an "infinite" loop in ssh_connection_handler.erl. The problem occurs when the first block has not yet been decoded and a call to next_packet is made. This would trigger the process to send itself a socket-receive message but it's possible that there isn't additional data ready on the socket. I fixed this by adding a call to make the socket active again as is the case in the subsequent next_packet function definition when the decoded_data_buffer is not empty.

From my testing so far, this resolves the issue and I have not yet seen any other side effects. Please let me know what you think.

I've attached my patch for R13B02, but you can also get it here:
http://github.com/krisr/erlang-macports/raw/master/lang/erlang/files/patch-lib-ssh-src-ssh_connection_handler.erl.diff

Best,
Kris

--
Kris Rasmussen
kris@...

Twitter: http://twitter.com/aptana
Facebook: http://aptana.com/facebook

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

patch-lib-ssh-src-ssh_connection_handler.erl.diff (612 bytes) Download Attachment

Re: [PATCH] Correct two trivial typos in etp-commands

2009-11-18T09:37:55Z

On Wed, Nov 18, 2009 at 5:38 PM, Tuncer Ayaz <tuncer.ayaz@...> wrote:
> Noticed some trivial typos while reading etp-commands
> and related sources.

Thanks! Applied.

--
Björn Gustavsson, Erlang/OTP, Ericsson AB

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

[PATCH] Correct two trivial typos in etp-commands

2009-11-18T08:38:12Z

Noticed some trivial typos while reading etp-commands
and related sources.

Signed-off-by: Tuncer Ayaz <tuncer.ayaz@...>

---
erts/etc/unix/etp-commands | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/erts/etc/unix/etp-commands b/erts/etc/unix/etp-commands
index c69e9af..6a01e0b 100644
--- a/erts/etc/unix/etp-commands
+++ b/erts/etc/unix/etp-commands
@@ -32,7 +32,7 @@ document etp-help
% Same as "help etp-help"
%
% Emulator Toolbox for Pathologists
-% - GDB commad toolbox for analyzing core dumps form the
+% - GDB command toolbox for analyzing core dumps from the
% Erlang emulator (BEAM).
%
% Should work for 32-bit erts-5.2/R9B, ...
@@ -79,7 +79,7 @@ document etp-help
% tag bits. Do not forget about the e.g p, p/x, x and x/4x commands.
%
% Execution speed of user defined gdb commands is not lightning fast.
-% It may well take half a minute do dump a complex term with the default
+% It may well take half a minute to dump a complex term with the default
% max depth values on our old Sparc Ultra-10's.
%
% To use the Erlang support module, the environment variable ROOTDIR
--
1.6.5.3

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: ASN1 BER bit string encoding

2009-11-18T07:31:24Z

On Mon, Nov 2, 2009 at 10:21 AM, Anders Nygren <anders.nygren@...> wrote:

> Hi
> When encoding a bit string, that has a size constraint that is a
> range, and the value to encode
> is given using 'named bits', the encoded value always contains the
> maximum number of bits.
> This is a little inefficient since it forces the transmission of more
> bits that necessary.
>
> This is not a real problem, except that we have to communicate with a
> node that rejects the
> message if the encoded bit string contains more than the minimum number of bits.
>
> Also it might be a good idea to change lists:sort to lists:usort in
> asn1rt_ber_bin:get_all_bitposes/3 in order to not getting an error if
> the same named bit
> is specified more than once/
>
> /Anders
>

Hi
I just want to check if there are any comments on this.

/Anders

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: Patch fix for c:nc R13B02-1

2009-11-18T06:37:06Z

Any updates on this? I've been running it locally for months and
haven't had any issues. It'd be nice to see it brought in so users of
my software don't have to patch their erlang install.

Regards,
- Alex

On Wed, Sep 30, 2009 at 8:52 AM, Alex Suraci <i.am@...> wrote:

> Actually, that patch is wrong; fixed patch attached.
>
> Tested locally this time, works perfectly.
>
>
> On Wed, Sep 30, 2009 at 9:06 AM, Alex Suraci <i.am@...> wrote:
>> Discussion:
>> http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1525:lhkkmhkfakilgfinpgae
>>
>> Fixes c:nc not working when the source is compiled to an outdir or
>> compiled from anywhere but the cwd.
>>
>> Without this patch, things like `make:all([netload])' (or even just
>> `nc("path/to/file")')
>> are rendered completely useless. They'll compile the file, but not load them as
>> c:nc is almost always looking in the wrong place for the .beam file.
>>
>> --
>> Alex
>>
>
>
>
> --
> Alex
>

--
Alex

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: PATCH: ODBC application discarding sqlstate in get_diagnos function

2009-11-18T06:27:37Z

On Wed, Nov 18, 2009 at 09:12:39AM +0100, Dan Gudmundsson wrote:
> Thanks, I have applied it.
> /Dan
>
Thank you very much.

Andrew

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: PATCH: ODBC application discarding sqlstate in get_diagnos function

2009-11-18T00:12:39Z

Thanks, I have applied it.
/Dan

On Tue, Nov 10, 2009 at 6:27 PM, Andrew Thompson <andrew@...> wrote:

> Any feedback from the erlang team on this? I'm willing to work on the
> patch if its not satisfactory.
>
> Andrew
>
> ________________________________________________________________
> erlang-patches mailing list. See http://www.erlang.org/faq.html
> erlang-patches (at) erlang.org
>
>

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: PATCH: ODBC application discarding sqlstate in get_diagnos function

2009-11-10T09:27:57Z

Any feedback from the erlang team on this? I'm willing to work on the
patch if its not satisfactory.

Andrew

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

ASN1 BER bit string encoding

2009-11-02T08:21:28Z

Hi
When encoding a bit string, that has a size constraint that is a
range, and the value to encode
is given using 'named bits', the encoded value always contains the
maximum number of bits.
This is a little inefficient since it forces the transmission of more
bits that necessary.

This is not a real problem, except that we have to communicate with a
node that rejects the
message if the encoded bit string contains more than the minimum number of bits.

Also it might be a good idea to change lists:sort to lists:usort in
asn1rt_ber_bin:get_all_bitposes/3 in order to not getting an error if
the same named bit
is specified more than once/

/Anders

[asn1rt_berbin.patch]

diff otp_src_R13B02-1/lib/asn1/src//asn1rt_ber_bin.erl otp_src_R13B02-1_my/lib/asn1/src//asn1rt_ber_bin.erl 1268c1268,1269 < BitList = make_and_set_list(Max, ToSetPos, 0), --- > BitsToEnc=lists:min([Max,lists:max([_Min,lists:last(ToSetPos)+1])]), > BitList = make_and_set_list(BitsToEnc, ToSetPos, 0), Only in otp_src_R13B02-1_my/lib/asn1/src/: asn1rt_ber_bin.erl~

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: small patch for tv

2009-10-23T01:39:32Z

My last letter was written w/o testing for other problems, I've found there were other calls to lists:nthtail/2.

I've attached a new patch file in this letter

2009/10/22 Dmitriy Budashny <dmitriy.budashny@...>

Hi there
I've found some strange issue with tv while using stumpwm. tv was crashing while I was trying to load some table, so I got such output to my console:

### log begins here ###

=ERROR REPORT==== 22-Oct-2009::16:31:05 ===
Error in process <0.571.0> with exit value: {function_clause,[{lists,nthtail,[6,[]]},{tv_pg_gridfcns,resize_grid,3},{tv_pg,loop,1}]}

Internal error... restarting.
10>
=ERROR REPORT==== 22-Oct-2009::16:31:06 ===
Error in process <0.578.0> with exit value: {function_clause,[{lists,nthtail,[6,[]]},{tv_pg_gridfcns,resize_grid,3},{tv_pg,loop,1}]}

Internal error... restarting.
### log ends here ###

So it continued restarting over and over again. The problem was with call to lists:nthtail(6,[]) which raised exception:

** exception error: no function clause matching lists:nthtail(6,[])
So I've made small changes to tv_pg_gridfcns.erl file. Patch attached.

--
wbr, dym

--
wbr, dym

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

tv_pg_gridfcns.erl.patch (3K) Download Attachment

small patch for tv

2009-10-22T07:22:38Z

Hi there

I've found some strange issue with tv while using stumpwm. tv was crashing while I was trying to load some table, so I got such output to my console:

### log begins here ###

=ERROR REPORT==== 22-Oct-2009::16:31:05 ===
Error in process <0.571.0> with exit value: {function_clause,[{lists,nthtail,[6,[]]},{tv_pg_gridfcns,resize_grid,3},{tv_pg,loop,1}]}

Internal error... restarting.
10>
=ERROR REPORT==== 22-Oct-2009::16:31:06 ===
Error in process <0.578.0> with exit value: {function_clause,[{lists,nthtail,[6,[]]},{tv_pg_gridfcns,resize_grid,3},{tv_pg,loop,1}]}

Internal error... restarting.

### log ends here ###

So it continued restarting over and over again. The problem was with call to lists:nthtail(6,[]) which raised exception:

** exception error: no function clause matching lists:nthtail(6,[])

So I've made small changes to tv_pg_gridfcns.erl file. Patch attached.

--
wbr, dym

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

tv_pg_gridfcns.erl.patch (1K) Download Attachment

Re: Patch to fix 630 English typos in documentation

2009-10-21T07:15:52Z

Hi,
thank you for the spelling patch. We have now applied it to our
documentation.

Best regards,

/Lars , Erlang/OTP Ericsson

Badlop wrote:

> Hello,
>
> The attached patch fixes 630 English spelling typos in 198 documentation files.
>
> It is not comprehensive. For instance, the automated spell checking
> was limited to verify only lowercase words. During my manual
> verification I also discarded some changes.
>
> The typos were originally extracted from R13B01 documentation, but
> I've updated the patch to apply to R13B02, and manually verified it
> again.
>
>
>
> ---
> Badlop
> ProcessOne
>
>
> ------------------------------------------------------------------------
>
>
> ________________________________________________________________
> erlang-patches mailing list. See http://www.erlang.org/faq.html
> erlang-patches (at) erlang.org

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Capture stderr of spawned process

2009-10-21T03:55:08Z

This is patch, required to catch stderr of spawned process
(tools like x264 print their status to stderr).

bif open_port/2 gets new flag: error (maybe bad name?). If you pass
it, process will receive messages {error, ErrorData}

Patch made for R13B02-1, not appliable for QNX because I even cannot
imagine, how to test it.

Usage example:

Port = open_port({spawn_executable, Cmd}, [stream, {args, Args},
{line, 1000}, error, exit_status, binary, eof]),

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

0001-capture-stderr-of-spawned-process.patch (21K) Download Attachment

Re: R13B02-1: a patch for omitting a warning on {foo, bar}:fun(args) calls

2009-10-19T07:55:42Z

On 19-Oct-09, at 7:47 AM, Richard Carlsson wrote:

> Yurii Rashkovskii wrote:
>> Currently erlc will spit a warning on this kind of constructs:
>>
>> {db, "localhost"}:connect()
>>
>> as opposed to
>>
>> DB = {db, "localhost"},
>> DB:connect()
>>
>> The warning will look like:
>>
>> Warning: invalid module and/or function name; this call will always
>> fail
>>
>> which is misleading, because this call will not fail (provided
>> modules
>> are in place and such)
>
> When you write code like the above, you are depending on how the
> current
> implementation of parameterized modules works. Don't do that.

I am pretty much aware of this mantra, thanks.

In fact, I seldom use parametrized modules per se, I am just utilizing
Erlang's capability to treat tuples as modules in another approach to
parametrized modules I built for myself.

Yurii.

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

R13B02-1: a patch for omitting a warning on {foo, bar}:fun(args) calls

2009-10-19T04:33:06Z

Hi,

Currently erlc will spit a warning on this kind of constructs:

{db, "localhost"}:connect()

as opposed to

DB = {db, "localhost"},
DB:connect()

The warning will look like:

Warning: invalid module and/or function name; this call will always fail

which is misleading, because this call will not fail (provided modules
are in place and such)

Here is a proposed solution to the problem:

http://github.com/yrashk/erlang/commit/cda6f1727965e6794aa088a200bf6c37c4586958

I am not sure it is perfect (hey, I am not an erlang compiler hacker,
as of yet), but it proved to work quite well for me.

Any chance it can make it to the mainstream in some way?

Thanks,
Yurii.

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Bugs in httpc timeout and keep-alive queue handling

2009-10-19T01:17:54Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

Attached is a patch against R13B02-1 that fixes two bugs in
httpc_handler.erl.

The first part fixes a bug with request timeout. When a queued request
(ie. not the active one in #state.request) times out, the error is sent
to the process associated with the active request. If I understand the
problem correctly, this means that this process could receive the
timeout error and the HTTP response, but the process for which the
request timed out won't receive anything.

The second part fixes a bug with the keep-alive queue: in terminate/2,
the requests in this queue are "forgotten". With the patch, the
keep-alive queue is treated like the pipeline queue.

The third part adds a clause to the retry_pipline/2 function to not
retry timed out requests.

With this patch, I couldn't hang httpc with multiple concurrent requests
to the same URL (a slow webservice). The handle_info/2 clause printing a
warning about unexpected received data isn't triggered anymore (it was
added in R13B02).

- --
Jean-Sébastien Pédron
http://www.dumbbell.fr/

PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrcILIACgkQa+xGJsFYOlPy+ACeNJMIIkKBUaOH7+r7FYBKgSpG
C94AoIvGUW4NLh/FjjorTYJJxLVEFjiy
=D7JD
-----END PGP SIGNATURE-----

--- otp_src_R13B02-1.orig/lib/inets/src/http_client/httpc_handler.erl 2009-09-18 16:12:59.000000000 +0200
+++ otp_src_R13B02-1/lib/inets/src/http_client/httpc_handler.erl 2009-10-14 09:22:46.000000000 +0200
@@ -505,10 +505,25 @@
{stop, normal,
State#state{canceled = [RequestId | State#state.canceled],
request = Request#request{from = answer_sent}}};
-handle_info({timeout, RequestId}, State = #state{request = Request}) ->
- httpc_response:send(Request#request.from,
- httpc_response:error(Request,timeout)),
- {noreply, State#state{canceled = [RequestId | State#state.canceled]}};
+handle_info({timeout, RequestId}, State) ->
+ Fun = fun
+ (#request{id = Id} = Request) when Id == RequestId ->
+ httpc_response:send(Request#request.from,
+ httpc_response:error(Request,timeout)),
+ [Request#request{from = answer_sent}];
+ (_) ->
+ true
+ end,
+ case State#state.status of
+ pipeline ->
+ Pipeline = queue:filter(Fun, State#state.pipeline),
+ {noreply, State#state{canceled = [RequestId | State#state.canceled],
+ pipeline = Pipeline}};
+ keep_alive ->
+ KeepAlive = queue:filter(Fun, State#state.keep_alive),
+ {noreply, State#state{canceled = [RequestId | State#state.canceled],
+ keep_alive = KeepAlive}}
+ end;

handle_info(timeout_queue, State = #state{request = undefined}) ->
{stop, normal, State};
@@ -588,6 +603,12 @@
true ->
ok
end,
+ case queue:is_empty(State#state.keep_alive) of
+ false ->
+ retry_pipline(queue:to_list(State#state.keep_alive), State);
+ true ->
+ ok
+ end,
cancel_timer(Timers#timers.queue_timer, timeout_queue),
Socket = Session#tcp_session.socket,
http_transport:close(socket_type(Session#tcp_session.scheme), Socket);
@@ -1191,6 +1212,8 @@
retry_pipline([], _) ->
ok;

+retry_pipline([#request{from = answer_sent}|PipeLine], State) ->
+ retry_pipline(PipeLine, State);
retry_pipline([Request |PipeLine], State =
#state{timers = Timers, profile_name = ProfileName}) ->
NewState =

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: PATCH: ODBC application discarding sqlstate in get_diagnos function

2009-10-18T00:06:44Z

On Mon, Oct 12, 2009 at 11:33 PM, Juhani Ränkimies <juhani@...> wrote:
> On 10/11/09, Andrew Thompson <andrew@...> wrote:
>>
>> Ah, that does sound like a similar issue although I'm not sure my patch
>> will solve it. Does it happen consistantly or is it random? Are you
>> using parameterized queries?
>
> it now. I'll try to find time to reproduce it on weekend.
>

Yes, I'm using param_query.

I wasn't able to reproduce the problem at this time.
I couldn't use the environment where I observed the problem and the
test setup has at least these differences:
- newer version of erlang
- newer versions of sql server and drivers
- it's is not patched to support unicode strings
- my tests were light, so if it occurs rarely I might not have caught it

next week i'll drop my workaround for {error,"No SQL-driver
information available."} from couple of places and see what happens.

> Juhani
>

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: Epp Bugfix and macros overloading

2009-10-16T08:16:46Z

Robert Virding a écrit :

> I rather like this extension, it is something I always meant to do but never
> got around to doing.
>
> I am not sure, though, that I completely agree with how you choose which
> definition to use, especially the third case here which I think should give
> an undefined macro error. My reasoning is that if you define a macro to have
> arguments, one or many definitions, and call it with arguments, even with an
> empty argument list then you should only try for the matching definition and
> not take the one without arguments. So if:
>
> -define(M, a).
> -define(M(), b).
> -define(M(X,Y), {X,Y}).
>
> then
>
> ?M - should use 1st def
> ?M() - should use 2nd def
> ?M(a,b) - should use 3rd def
> ?M(a) - should generate an error
>
> However if only:
>
> -define(M, a).
>
> then all calls will use this definition.
>

Hi Robert,

Thanks for your comments. You are probably right. Your solution is less
error prone and avoids ambiguities.

I made a new patch that takes your suggestion into account. I also
modified some errors to be more precise in diagnostics.

--
Christopher Faulet <christopher.faulet@...>

--- lib/stdlib/src/epp.erl.orig 2009-10-16 14:11:07.000000000 +0200
+++ lib/stdlib/src/epp.erl 2009-10-16 16:28:14.000000000 +0200
@@ -99,18 +99,24 @@
io_lib:format("badly formed '~s'", [W]);
format_error({call,What}) ->
io_lib:format("illegal macro call '~s'",[What]);
-format_error({undefined,M}) ->
- io_lib:format("undefined macro '~w'", [M]);
+format_error({undefined,M,none}) ->
+ io_lib:format("undefined macro '~s'", [M]);
+format_error({undefined,M,A}) ->
+ io_lib:format("undefined macro '~s/~p'", [M,A]);
format_error({depth,What}) ->
io_lib:format("~s too deep",[What]);
format_error({mismatch,M}) ->
- io_lib:format("argument mismatch for macro '~w'", [M]);
+ io_lib:format("argument mismatch for macro '~s'", [M]);
format_error({arg_error,M}) ->
- io_lib:format("badly formed argument for macro '~w'", [M]);
+ io_lib:format("badly formed argument for macro '~s'", [M]);
format_error({redefine,M}) ->
- io_lib:format("redefining macro '~w'", [M]);
-format_error({circular,M}) ->
- io_lib:format("circular macro '~w'", [M]);
+ io_lib:format("redefining macro '~s'", [M]);
+format_error({redefine_predef,M}) ->
+ io_lib:format("redefining predefined macro '~s'", [M]);
+format_error({circular,M,none}) ->
+ io_lib:format("circular macro '~s'", [M]);
+format_error({circular,M,A}) ->
+ io_lib:format("circular macro '~s/~p'", [M,A]);
format_error({include,W,F}) ->
io_lib:format("can't find include ~s \"~s\"", [W,F]);
format_error({illegal,How,What}) ->
@@ -240,18 +246,23 @@
user_predef(Pdm, dict:store({atom,M}, {none,Exp}, Ms));
user_predef([{M,Val}|Pdm], Ms) when is_atom(M) ->
case dict:find({atom,M}, Ms) of
- {ok,_Def} ->
+ {ok,_Defs} when is_list(_Defs) -> %% User defined macros
{error,{redefine,M}};
+ {ok,_Def} -> %% Predefined macros
+ {error,{redefine_predef,M}};
error ->
Exp = erl_parse:tokens(erl_parse:abstract(Val)),
- user_predef(Pdm, dict:store({atom,M}, {none,Exp}, Ms))
+ user_predef(Pdm, dict:store({atom,M}, [{none, {none,Exp}}], Ms))
end;
user_predef([M|Pdm], Ms) when is_atom(M) ->
case dict:find({atom,M}, Ms) of
- {ok,_Def} ->
+ {ok,_Defs} when is_list(_Defs) -> %% User defined macros
{error,{redefine,M}};
+ {ok,_Def} -> %% Predefined macros
+ {error,{redefine_predef,M}};
error ->
- user_predef(Pdm, dict:store({atom,M}, {none,[{atom,1,true}]}, Ms))
+ user_predef(Pdm,
+ dict:store({atom,M}, [{none, {none,[{atom,1,true}]}}], Ms))
end;
user_predef([Md|_Pdm], _Ms) -> {error,{bad,Md}};
user_predef([], Ms) -> {ok,Ms}.
@@ -458,57 +469,55 @@

%% scan_define(Tokens, DefineToken, From, EppState)

-scan_define([{'(',_Lp},{atom,_Lm,M}=Mac,{',',_Lc}|Toks], _Def, From, St) ->
+scan_define([{'(',_Lp},{Type,_Lm,M}=Mac,{',',_Lc}|Toks], _Def, From, St)
+ when Type =:= atom; Type =:= var ->
case dict:find({atom,M}, St#epp.macs) of
- {ok,_OldDef} ->
- epp_reply(From, {error,{loc(Mac),epp,{redefine,M}}}),
- wait_req_scan(St);
- error ->
- scan_define_cont(From, St,
- {atom, M},
- {none,macro_expansion(Toks)})
+ {ok, Defs} when is_list(Defs) ->
+ %% User defined macros: can be overloaded
+ case proplists:is_defined(none, Defs) of
+ true ->
+ epp_reply(From, {error,{loc(Mac),epp,{redefine,M}}}),
+ wait_req_scan(St);
+ false ->
+ scan_define_cont(From, St,
+ {atom, M},
+ {none, {none,macro_expansion(Toks)}})
+ end;
+ {ok, _PreDef} ->
+ %% Predefined macros: cannot be overloaded
+ epp_reply(From, {error,{loc(Mac),epp,{redefine_predef,M}}}),
+ wait_req_scan(St);
+ error ->
+ scan_define_cont(From, St,
+ {atom, M},
+ {none, {none,macro_expansion(Toks)}})
end;
-scan_define([{'(',_Lp},{atom,_Lm,M}=Mac,{'(',_Lc}|Toks], Def, From, St) ->
- case dict:find({atom,M}, St#epp.macs) of
- {ok,_Def} ->
- epp_reply(From, {error,{loc(Mac),epp,{redefine,M}}}),
- wait_req_scan(St);
- error ->
- case catch macro_pars(Toks, []) of
- {ok, {As, Me}} ->
- scan_define_cont(From, St,
- {atom, M},
- {As, Me});
- _ ->
- epp_reply(From, {error,{loc(Def),epp,{bad,define}}}),
- wait_req_scan(St)
- end
- end;
-scan_define([{'(',_Lp},{var,_Lm,M}=Mac,{',',_Lc}|Toks], _Def, From, St) ->
- case dict:find({atom,M}, St#epp.macs) of
- {ok,_OldDef} ->
- epp_reply(From, {error,{loc(Mac),epp,{redefine,M}}}),
- wait_req_scan(St);
- error ->
- scan_define_cont(From, St,
- {atom, M},
- {none,macro_expansion(Toks)})
- end;
-scan_define([{'(',_Lp},{var,_Lm,M}=Mac,{'(',_Lc}|Toks], Def, From, St) ->
- case dict:find({atom,M}, St#epp.macs) of
- {ok,_Def} ->
- epp_reply(From, {error,{loc(Mac),epp,{redefine,M}}}),
- wait_req_scan(St);
- error ->
- case catch macro_pars(Toks, []) of
- {ok, {As, Me}} ->
- scan_define_cont(From, St,
- {atom, M},
- {As, Me});
- _ ->
- epp_reply(From, {error,{loc(Def),epp,{bad,define}}}),
- wait_req_scan(St)
- end
+scan_define([{'(',_Lp},{Type,_Lm,M}=Mac,{'(',_Lc}|Toks], Def, From, St)
+ when Type =:= atom; Type =:= var ->
+ case catch macro_pars(Toks, []) of
+ {ok, {As,Me}} ->
+ Len = length(As),
+ case dict:find({atom,M}, St#epp.macs) of
+ {ok, Defs} when is_list(Defs) ->
+ %% User defined macros: can be overloaded
+ case proplists:is_defined(Len, Defs) of
+ true ->
+ epp_reply(From,{error,{loc(Mac),epp,{redefine,M}}}),
+ wait_req_scan(St);
+ false ->
+ scan_define_cont(From, St, {atom, M},
+ {Len, {As, Me}})
+ end;
+ {ok, _PreDef} ->
+ %% Predefined macros: cannot be overloaded
+ epp_reply(From, {error,{loc(Mac),epp,{redefine_predef,M}}}),
+ wait_req_scan(St);
+ error ->
+ scan_define_cont(From, St, {atom, M}, {Len, {As, Me}})
+ end;
+ _ ->
+ epp_reply(From, {error,{loc(Def),epp,{bad,define}}}),
+ wait_req_scan(St)
end;
scan_define(_Toks, Def, From, St) ->
epp_reply(From, {error,{loc(Def),epp,{bad,define}}}),
@@ -523,13 +532,17 @@
%%% the information from St#epp.uses is traversed, and if a circularity
%%% is detected, an error message is thrown.

-scan_define_cont(F, St, M, Def) ->
- Ms = dict:store(M, Def, St#epp.macs),
- U = dict:store(M, macro_uses(Def), St#epp.uses),
- scan_toks(F, St#epp{uses=U, macs=Ms}).
+scan_define_cont(F, St, M, {Arity, Def}) ->
+ try
+ Ms = dict:append_list(M, [{Arity, Def}], St#epp.macs),
+ U = dict:append_list(M, [{Arity, macro_uses(Def)}], St#epp.uses),
+ scan_toks(F, St#epp{uses=U, macs=Ms})
+ catch
+ _:{error, Line, Reason} ->
+ epp_reply(F, {error,{Line,epp,Reason}}),
+ wait_req_scan(St)
+ end.

-macro_uses(undefined) ->
- undefined;
macro_uses({_Args, Tokens}) ->
Uses0 = macro_ref(Tokens),
lists:usort(Uses0).
@@ -538,31 +551,25 @@
[];
macro_ref([{'?', _}, {'?', _} | Rest]) ->
macro_ref(Rest);
-macro_ref([{'?', _}, {atom, _, A} | Rest]) ->
- [{atom, A} | macro_ref(Rest)];
-macro_ref([{'?', _}, {var, _, A} | Rest]) ->
- [{atom, A} | macro_ref(Rest)];
+macro_ref([{'?', _}, {atom, Lm, A} | Rest]) ->
+ Arity = count_args(Rest, Lm, A),
+ [{{atom, A}, Arity} | macro_ref(Rest)];
+macro_ref([{'?', _}, {var, Lm, A} | Rest]) ->
+ Arity = count_args(Rest, Lm, A),
+ [{{atom, A}, Arity} | macro_ref(Rest)];
macro_ref([_Token | Rest]) ->
macro_ref(Rest).

-all_macro_uses(D0) ->
- L = dict:to_list(D0),
- D = dict:new(),
- add_macro_uses(L, D).
-
-add_macro_uses([], D) ->
- D;
-add_macro_uses([{Key, Def} | Rest], D0) ->
- add_macro_uses(Rest, dict:store(Key, macro_uses(Def), D0)).
-
%% scan_undef(Tokens, UndefToken, From, EppState)

scan_undef([{'(',_Llp},{atom,_Lm,M},{')',_Lrp},{dot,_Ld}], _Undef, From, St) ->
- scan_toks(From, St#epp{macs=dict:erase({atom,M}, St#epp.macs),
- uses=all_macro_uses(St#epp.macs)});
+ Macs = dict:erase({atom,M}, St#epp.macs),
+ Uses = dict:erase({atom,M}, St#epp.uses),
+ scan_toks(From, St#epp{macs=Macs, uses=Uses});
scan_undef([{'(',_Llp},{var,_Lm,M},{')',_Lrp},{dot,_Ld}], _Undef, From,St) ->
- scan_toks(From, St#epp{macs=dict:erase({atom,M}, St#epp.macs),
- uses=all_macro_uses(St#epp.macs)});
+ Macs = dict:erase({atom,M}, St#epp.macs),
+ Uses = dict:erase({atom,M}, St#epp.uses),
+ scan_toks(From, St#epp{macs=Macs, uses=Uses});
scan_undef(_Toks, Undef, From, St) ->
epp_reply(From, {error,{loc(Undef),epp,{bad,undef}}}),
wait_req_scan(St).
@@ -801,42 +808,55 @@
%% (Type will always be 'atom')
{Ms, U} = Ms0,
Lm = loc(MacT),
- check_uses([{Type,M}], [], U, Lm),
Tinfo = element(2, MacT),
- case dict:find({Type,M}, Ms) of
- {ok,{none,Exp}} ->
- expand_macros(expand_macro(Exp, Tinfo, Toks, dict:new()), Ms0);
- {ok,{As,Exp}} ->
+ case expand_macro1(Type, Lm, M, Toks, Ms) of
+ {ok, {none,Exp}} ->
+ check_uses([{{Type,M}, none}], [], U, Lm),
+ Toks1 = expand_macros(expand_macro(Exp, Tinfo, [], dict:new()), Ms0),
+ expand_macros(Toks1++Toks, Ms0);
+ {ok, {As,Exp}} ->
+ check_uses([{{Type,M}, length(As)}], [], U, Lm),
{Bs,Toks1} = bind_args(Toks, Lm, M, As, dict:new()),
- %%io:format("Bound arguments to macro ~w (~w)~n", [M,Bs]),
- expand_macros(expand_macro(Exp, Tinfo, Toks1, Bs), Ms0);
- {ok,undefined} ->
- throw({error,Lm,{undefined,M}});
- error ->
- throw({error,Lm,{undefined,M}})
+ expand_macros(expand_macro(Exp, Tinfo, Toks1, Bs), Ms0)
+ end.
+
+expand_macro1(Type, Lm, M, Toks, Ms) ->
+ Arity = count_args(Toks, Lm, M),
+ case dict:find({Type,M}, Ms) of
+ {ok, [{none, Def}]} ->
+ {ok, Def};
+ {ok, Defs} when is_list(Defs) ->
+ case proplists:get_value(Arity, Defs) of
+ undefined ->
+ throw({error,Lm,{undefined,M,Arity}});
+ Def ->
+ {ok, Def}
+ end;
+ {ok, PreDef} -> %% Predefined macro
+ {ok, PreDef};
+ error ->
+ throw({error,Lm,{undefined,M,Arity}})
end.

-check_uses(undefined, _Anc, _U, _Lm) ->
- ok;
check_uses([], _Anc, _U, _Lm) ->
ok;
check_uses([M|Rest], Anc, U, Lm) ->
case lists:member(M, Anc) of
true ->
- {_, Name} = M,
- throw({error,Lm,{circular,Name}});
+ {{_, Name},Arity} = M,
+ throw({error,Lm,{circular,Name,Arity}});
false ->
L = get_macro_uses(M, U),
check_uses(L, [M|Anc], U, Lm),
check_uses(Rest, Anc, U, Lm)
end.
-
-get_macro_uses(M, U) ->
+
+get_macro_uses({M,Arity}, U) ->
case dict:find(M, U) of
error ->
[];
{ok, L} ->
- L
+ proplists:get_value(Arity, L, proplists:get_value(none, L, []))
end.

%% Macro expansion
@@ -889,6 +909,30 @@
store_arg(_L, _M, A, Arg, Bs) ->
dict:store(A, Arg, Bs).

+%% count_args(Tokens, MacroLine, MacroName)
+%% Count the number of arguments in a macro call.
+count_args([{'(', _Llp},{')',_Lrp}|_Toks], _Lm, _M) ->
+ 0;
+count_args([{'(', _Llp},{',',_Lc}|_Toks], Lm, M) ->
+ throw({error,Lm,{arg_error,M}});
+count_args([{'(',_Llp}|Toks0], Lm, M) ->
+ {_Arg,Toks1} = macro_arg(Toks0, [], []),
+ count_args(Toks1, Lm, M, 1);
+count_args(_Toks, _Lm, _M) ->
+ none.
+
+count_args([{')',_Lrp}|_Toks], _Lm, _M, NbArgs) ->
+ NbArgs;
+count_args([{',',_Lc},{')',_Lrp}|_Toks], Lm, M, _NbArgs) ->
+ throw({error,Lm,{arg_error,M}});
+count_args([{',',_Lc}|Toks0], Lm, M, NbArgs) ->
+ {_Arg,Toks1} = macro_arg(Toks0, [], []),
+ count_args(Toks1, Lm, M, NbArgs+1);
+count_args([], Lm, M, _NbArgs) ->
+ throw({error,Lm,{arg_error,M}});
+count_args(_Toks, Lm, M, _NbArgs) ->
+ throw({error,Lm,{mismatch,M}}).
+
%% macro_arg([Tok], [ClosePar], [ArgTok]) -> {[ArgTok],[RestTok]}.
%% Collect argument tokens until we hit a ',' or a ')'. We know a
%% enough about syntax to recognise "open parentheses" and keep

signature.asc (268 bytes) Download Attachment

Re: Epp Bugfix and macros overloading

2009-10-15T15:55:30Z

2009/10/9 christopher faulet <christopher.faulet@...>

> Hi all,
>
> Here are two patches for the module epp in R13B02-1.
>
> * The second patch includes the first one and adds support of multiple
> definitions for macros in the module epp (i.e. with the same name but
> with different arities). This feature wouldn't break any code (I hope so
> :) and might be usefull.
>
> Here is an simple example that uses it:
>
> =============================
> -module(test).
>
> -export([test/0]).
>
> -define(MY_MACRO(), foo).
> -define(MY_MACRO, bar).
> -define(MY_MACRO(X,Y), {X, Y}).
>
>
> test() -> %% return [bar, foo, foo, {foo, bar}]
> [
> ?MY_MACRO, %% use the 2nd def, replaced by bar
> ?MY_MACRO(), %% use the 1st def, replaced by foo
> ?MY_MACRO(foo), %% use the 2nd def, replaced by bar(foo)
> ?MY_MACRO(foo, bar) %% use the 3rd def, replaced by {foo,bar}
> ].
>
> bar(X) ->
> X.
> =============================
>

I rather like this extension, it is something I always meant to do but never
got around to doing.

I am not sure, though, that I completely agree with how you choose which
definition to use, especially the third case here which I think should give
an undefined macro error. My reasoning is that if you define a macro to have
arguments, one or many definitions, and call it with arguments, even with an
empty argument list then you should only try for the matching definition and
not take the one without arguments. So if:

-define(M, a).
-define(M(), b).
-define(M(X,Y), {X,Y}).

then

?M - should use 1st def
?M() - should use 2nd def
?M(a,b) - should use 3rd def
?M(a) - should generate an error

However if only:

-define(M, a).

then all calls will use this definition.

Robert

Re: wxe_server bug? (and patch)

2009-10-14T07:23:00Z

Mazen Harake wrote:
> Yeah I can see how using pids are useful but the semantic difference is
> that you can't really get the pid from somewhere unless you register it?
> I mean the return value is a wxWindow() type. I dunno... just a thought :)

wx_object:get_pid(Ref).

>
> Waiting patiently to learn the right way ;)

The right way is to not use term_to_binary(self()) when registrering the process
with the driver, because that representation changes when the node becomes distributed.

I.e. more code and changes in the driver, but better, nicer and uses less memory,
that code wasn't the best I have written :-)

/Dan

>
> /Mazen
>
> Dan Gudmundsson wrote:
>> I'll fix the problem, in the right way(tm).
>>
>> /Dan
>> PS: I just applied your wx_object patch but I allowed pids as well as
>> registered names and
>> added wx_object:cast/2.
>>
>> On Wed, Oct 14, 2009 at 3:25 PM, Mazen Harake
>> <mazen.harake@...> wrote:
>>
>>> A quick note:
>>> I just realized that this example doesn't work unless you have
>>> applied my
>>> previous patch for wx_object.erl. Either apply that or change the
>>> code to
>>> call the wx_object with the form (somehow) :)
>>>
>>> /Mazen
>>>
>>> Mazen Harake wrote:
>>>
>>>> Hi,
>>>>
>>>> There is a situation in the wx library that causes the wxe_server to
>>>> crash
>>>> when it receives a message with a pid which is considered by
>>>> distributed
>>>> Erlang to come from another node when in fact it isn't. This happens
>>>> when
>>>> net_kernel is started explicitly (I.e. Erlang going into
>>>> distribution mode)
>>>> and an wx_object (which was created before net_kernel was started) is
>>>> destroyed.
>>>>
>>>> Here is a simple example:
>>>> Create this module:
>>>> -module(test).
>>>> -compile(export_all).
>>>>
>>>> start() ->
>>>> wx:new(),
>>>> wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []).
>>>>
>>>> close(_, _) ->
>>>> wx_object:call(?MODULE, stop).
>>>>
>>>> init(Wx) ->
>>>> wx:set_env(Wx),
>>>> Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]),
>>>> wxFrame:show(Mf),
>>>> wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]),
>>>> {Mf, Mf}.
>>>>
>>>> handle_call(stop, _From, Mf) ->
>>>> wxFrame:destroy(Mf),
>>>> {stop, normal, ok, Mf}.
>>>>
>>>> terminate(normal, _) ->
>>>> ok.
>>>>
>>>> Then run this in the shell:
>>>> Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0]
>>>>
>>>> Eshell V5.7.1 (abort with ^G)
>>>> 1> c(test).
>>>> {ok,test}
>>>> 2> test:start().
>>>> {wx_ref,35,wxFrame,<0.42.0>}
>>>> 3>
>>>>
>>>> This should give you a small frame, don't close it yet,
>>>> Now do this:
>>>> 3> net_kernel:start([bad,shortnames]).
>>>> {ok,<0.49.0>}
>>>> (bad@prestine)4>
>>>>
>>>> Now close the frame and you should see:
>>>> =ERROR REPORT==== 14-Oct-2009::13:17:08 ===
>>>> ** Generic server <0.39.0> terminating
>>>> ** Last message in was {'_wxe_destroy_',<3.42.0>}
>>>> ** When Server state == {state,#Port<0.2605>,#Port<0.2602>,
>>>>
>>>> {1,{<0.32.0>,{user,[],[],undefined},nil,nil}},
>>>> [<0.57.0>],
>>>> {1,{#Fun<test.close.2>,1,nil,nil}},
>>>> 2}
>>>> ** Reason for termination ==
>>>> ** {badarg,[{erlang,is_process_alive,[<3.42.0>]},
>>>> {wxe_server,handle_info,2},
>>>> {gen_server,handle_msg,5},
>>>> {proc_lib,init_p_do_apply,3}]}
>>>>
>>>>
>>>> The pid which comes from the port is not recognized as a local pid and
>>>> thus erlang:is_process_alive/1 will exit with badarg. My question
>>>> is: Is
>>>> this a "feature" or a bug? I think this is a bug but I'm not sure
>>>> what is
>>>> expected from the wx library point of view. IMHO it shouldn't crash
>>>> and just
>>>> ignore it in this case because the wxe_server shouldn't be allowed
>>>> to crash.
>>>>
>>>> Anyway I put in a patch as well just in case this is something that
>>>> should
>>>> be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3.
>>>>
>>>> Cheers,
>>>>
>>>> /Mazen
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> ________________________________________________________________
>>>> erlang-patches mailing list. See http://www.erlang.org/faq.html
>>>> erlang-patches (at) erlang.org
>>>>
>>> ________________________________________________________________
>>> erlang-patches mailing list. See http://www.erlang.org/faq.html
>>> erlang-patches (at) erlang.org
>>>
>>>
>>>
>
>
> ________________________________________________________________
> erlang-patches mailing list. See http://www.erlang.org/faq.html
> erlang-patches (at) erlang.org
>

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: wxe_server bug? (and patch)

2009-10-14T07:13:15Z

Yeah I can see how using pids are useful but the semantic difference is
that you can't really get the pid from somewhere unless you register it?
I mean the return value is a wxWindow() type. I dunno... just a thought :)

Waiting patiently to learn the right way ;)

/Mazen

Dan Gudmundsson wrote:

> I'll fix the problem, in the right way(tm).
>
> /Dan
> PS: I just applied your wx_object patch but I allowed pids as well as
> registered names and
> added wx_object:cast/2.
>
> On Wed, Oct 14, 2009 at 3:25 PM, Mazen Harake
> <mazen.harake@...> wrote:
>
>> A quick note:
>> I just realized that this example doesn't work unless you have applied my
>> previous patch for wx_object.erl. Either apply that or change the code to
>> call the wx_object with the form (somehow) :)
>>
>> /Mazen
>>
>> Mazen Harake wrote:
>>
>>> Hi,
>>>
>>> There is a situation in the wx library that causes the wxe_server to crash
>>> when it receives a message with a pid which is considered by distributed
>>> Erlang to come from another node when in fact it isn't. This happens when
>>> net_kernel is started explicitly (I.e. Erlang going into distribution mode)
>>> and an wx_object (which was created before net_kernel was started) is
>>> destroyed.
>>>
>>> Here is a simple example:
>>> Create this module:
>>> -module(test).
>>> -compile(export_all).
>>>
>>> start() ->
>>> wx:new(),
>>> wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []).
>>>
>>> close(_, _) ->
>>> wx_object:call(?MODULE, stop).
>>>
>>> init(Wx) ->
>>> wx:set_env(Wx),
>>> Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]),
>>> wxFrame:show(Mf),
>>> wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]),
>>> {Mf, Mf}.
>>>
>>> handle_call(stop, _From, Mf) ->
>>> wxFrame:destroy(Mf),
>>> {stop, normal, ok, Mf}.
>>>
>>> terminate(normal, _) ->
>>> ok.
>>>
>>> Then run this in the shell:
>>> Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0]
>>>
>>> Eshell V5.7.1 (abort with ^G)
>>> 1> c(test).
>>> {ok,test}
>>> 2> test:start().
>>> {wx_ref,35,wxFrame,<0.42.0>}
>>> 3>
>>>
>>> This should give you a small frame, don't close it yet,
>>> Now do this:
>>> 3> net_kernel:start([bad,shortnames]).
>>> {ok,<0.49.0>}
>>> (bad@prestine)4>
>>>
>>> Now close the frame and you should see:
>>> =ERROR REPORT==== 14-Oct-2009::13:17:08 ===
>>> ** Generic server <0.39.0> terminating
>>> ** Last message in was {'_wxe_destroy_',<3.42.0>}
>>> ** When Server state == {state,#Port<0.2605>,#Port<0.2602>,
>>>
>>> {1,{<0.32.0>,{user,[],[],undefined},nil,nil}},
>>> [<0.57.0>],
>>> {1,{#Fun<test.close.2>,1,nil,nil}},
>>> 2}
>>> ** Reason for termination ==
>>> ** {badarg,[{erlang,is_process_alive,[<3.42.0>]},
>>> {wxe_server,handle_info,2},
>>> {gen_server,handle_msg,5},
>>> {proc_lib,init_p_do_apply,3}]}
>>>
>>>
>>> The pid which comes from the port is not recognized as a local pid and
>>> thus erlang:is_process_alive/1 will exit with badarg. My question is: Is
>>> this a "feature" or a bug? I think this is a bug but I'm not sure what is
>>> expected from the wx library point of view. IMHO it shouldn't crash and just
>>> ignore it in this case because the wxe_server shouldn't be allowed to crash.
>>>
>>> Anyway I put in a patch as well just in case this is something that should
>>> be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3.
>>>
>>> Cheers,
>>>
>>> /Mazen
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ________________________________________________________________
>>> erlang-patches mailing list. See http://www.erlang.org/faq.html
>>> erlang-patches (at) erlang.org
>>>
>> ________________________________________________________________
>> erlang-patches mailing list. See http://www.erlang.org/faq.html
>> erlang-patches (at) erlang.org
>>
>>
>>

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: wxe_server bug? (and patch)

2009-10-14T06:52:16Z

I'll fix the problem, in the right way(tm).

/Dan
PS: I just applied your wx_object patch but I allowed pids as well as
registered names and
added wx_object:cast/2.

On Wed, Oct 14, 2009 at 3:25 PM, Mazen Harake
<mazen.harake@...> wrote:

> A quick note:
> I just realized that this example doesn't work unless you have applied my
> previous patch for wx_object.erl. Either apply that or change the code to
> call the wx_object with the form (somehow) :)
>
> /Mazen
>
> Mazen Harake wrote:
>>
>> Hi,
>>
>> There is a situation in the wx library that causes the wxe_server to crash
>> when it receives a message with a pid which is considered by distributed
>> Erlang to come from another node when in fact it isn't. This happens when
>> net_kernel is started explicitly (I.e. Erlang going into distribution mode)
>> and an wx_object (which was created before net_kernel was started) is
>> destroyed.
>>
>> Here is a simple example:
>> Create this module:
>> -module(test).
>> -compile(export_all).
>>
>> start() ->
>> wx:new(),
>> wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []).
>>
>> close(_, _) ->
>> wx_object:call(?MODULE, stop).
>>
>> init(Wx) ->
>> wx:set_env(Wx),
>> Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]),
>> wxFrame:show(Mf),
>> wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]),
>> {Mf, Mf}.
>>
>> handle_call(stop, _From, Mf) ->
>> wxFrame:destroy(Mf),
>> {stop, normal, ok, Mf}.
>>
>> terminate(normal, _) ->
>> ok.
>>
>> Then run this in the shell:
>> Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0]
>>
>> Eshell V5.7.1 (abort with ^G)
>> 1> c(test).
>> {ok,test}
>> 2> test:start().
>> {wx_ref,35,wxFrame,<0.42.0>}
>> 3>
>>
>> This should give you a small frame, don't close it yet,
>> Now do this:
>> 3> net_kernel:start([bad,shortnames]).
>> {ok,<0.49.0>}
>> (bad@prestine)4>
>>
>> Now close the frame and you should see:
>> =ERROR REPORT==== 14-Oct-2009::13:17:08 ===
>> ** Generic server <0.39.0> terminating
>> ** Last message in was {'_wxe_destroy_',<3.42.0>}
>> ** When Server state == {state,#Port<0.2605>,#Port<0.2602>,
>>
>> {1,{<0.32.0>,{user,[],[],undefined},nil,nil}},
>> [<0.57.0>],
>> {1,{#Fun<test.close.2>,1,nil,nil}},
>> 2}
>> ** Reason for termination ==
>> ** {badarg,[{erlang,is_process_alive,[<3.42.0>]},
>> {wxe_server,handle_info,2},
>> {gen_server,handle_msg,5},
>> {proc_lib,init_p_do_apply,3}]}
>>
>>
>> The pid which comes from the port is not recognized as a local pid and
>> thus erlang:is_process_alive/1 will exit with badarg. My question is: Is
>> this a "feature" or a bug? I think this is a bug but I'm not sure what is
>> expected from the wx library point of view. IMHO it shouldn't crash and just
>> ignore it in this case because the wxe_server shouldn't be allowed to crash.
>>
>> Anyway I put in a patch as well just in case this is something that should
>> be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3.
>>
>> Cheers,
>>
>> /Mazen
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ________________________________________________________________
>> erlang-patches mailing list. See http://www.erlang.org/faq.html
>> erlang-patches (at) erlang.org
>
>
> ________________________________________________________________
> erlang-patches mailing list. See http://www.erlang.org/faq.html
> erlang-patches (at) erlang.org
>
>

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: wxe_server bug? (and patch)

2009-10-14T06:25:21Z

A quick note:
I just realized that this example doesn't work unless you have applied
my previous patch for wx_object.erl. Either apply that or change the
code to call the wx_object with the form (somehow) :)

/Mazen

Mazen Harake wrote:

> Hi,
>
> There is a situation in the wx library that causes the wxe_server to
> crash when it receives a message with a pid which is considered by
> distributed Erlang to come from another node when in fact it isn't.
> This happens when net_kernel is started explicitly (I.e. Erlang going
> into distribution mode) and an wx_object (which was created before
> net_kernel was started) is destroyed.
>
> Here is a simple example:
> Create this module:
> -module(test).
> -compile(export_all).
>
> start() ->
> wx:new(),
> wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []).
>
> close(_, _) ->
> wx_object:call(?MODULE, stop).
>
> init(Wx) ->
> wx:set_env(Wx),
> Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]),
> wxFrame:show(Mf),
> wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]),
> {Mf, Mf}.
>
> handle_call(stop, _From, Mf) ->
> wxFrame:destroy(Mf),
> {stop, normal, ok, Mf}.
>
> terminate(normal, _) ->
> ok.
>
> Then run this in the shell:
> Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0]
>
> Eshell V5.7.1 (abort with ^G)
> 1> c(test).
> {ok,test}
> 2> test:start().
> {wx_ref,35,wxFrame,<0.42.0>}
> 3>
>
> This should give you a small frame, don't close it yet,
> Now do this:
> 3> net_kernel:start([bad,shortnames]).
> {ok,<0.49.0>}
> (bad@prestine)4>
>
> Now close the frame and you should see:
> =ERROR REPORT==== 14-Oct-2009::13:17:08 ===
> ** Generic server <0.39.0> terminating
> ** Last message in was {'_wxe_destroy_',<3.42.0>}
> ** When Server state == {state,#Port<0.2605>,#Port<0.2602>,
>
> {1,{<0.32.0>,{user,[],[],undefined},nil,nil}},
> [<0.57.0>],
> {1,{#Fun<test.close.2>,1,nil,nil}},
> 2}
> ** Reason for termination ==
> ** {badarg,[{erlang,is_process_alive,[<3.42.0>]},
> {wxe_server,handle_info,2},
> {gen_server,handle_msg,5},
> {proc_lib,init_p_do_apply,3}]}
>
>
> The pid which comes from the port is not recognized as a local pid and
> thus erlang:is_process_alive/1 will exit with badarg. My question is:
> Is this a "feature" or a bug? I think this is a bug but I'm not sure
> what is expected from the wx library point of view. IMHO it shouldn't
> crash and just ignore it in this case because the wxe_server shouldn't
> be allowed to crash.
>
> Anyway I put in a patch as well just in case this is something that
> should be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3.
>
> Cheers,
>
> /Mazen
>
>
>
>
> ------------------------------------------------------------------------
>
>
> ________________________________________________________________
> erlang-patches mailing list. See http://www.erlang.org/faq.html
> erlang-patches (at) erlang.org

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

wxe_server bug? (and patch)

2009-10-14T06:22:42Z

Hi,

There is a situation in the wx library that causes the wxe_server to
crash when it receives a message with a pid which is considered by
distributed Erlang to come from another node when in fact it isn't. This
happens when net_kernel is started explicitly (I.e. Erlang going into
distribution mode) and an wx_object (which was created before net_kernel
was started) is destroyed.

Here is a simple example:
Create this module:
-module(test).
-compile(export_all).

start() ->
wx:new(),
wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []).

close(_, _) ->
wx_object:call(?MODULE, stop).

init(Wx) ->
wx:set_env(Wx),
Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]),
wxFrame:show(Mf),
wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]),
{Mf, Mf}.

handle_call(stop, _From, Mf) ->
wxFrame:destroy(Mf),
{stop, normal, ok, Mf}.

terminate(normal, _) ->
ok.

Then run this in the shell:
Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0]

Eshell V5.7.1 (abort with ^G)
1> c(test).
{ok,test}
2> test:start().
{wx_ref,35,wxFrame,<0.42.0>}
3>

This should give you a small frame, don't close it yet,
Now do this:
3> net_kernel:start([bad,shortnames]).
{ok,<0.49.0>}
(bad@prestine)4>

Now close the frame and you should see:
=ERROR REPORT==== 14-Oct-2009::13:17:08 ===
** Generic server <0.39.0> terminating
** Last message in was {'_wxe_destroy_',<3.42.0>}
** When Server state == {state,#Port<0.2605>,#Port<0.2602>,

{1,{<0.32.0>,{user,[],[],undefined},nil,nil}},
[<0.57.0>],
{1,{#Fun<test.close.2>,1,nil,nil}},
2}
** Reason for termination ==
** {badarg,[{erlang,is_process_alive,[<3.42.0>]},
{wxe_server,handle_info,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}

The pid which comes from the port is not recognized as a local pid and
thus erlang:is_process_alive/1 will exit with badarg. My question is: Is
this a "feature" or a bug? I think this is a bug but I'm not sure what
is expected from the wx library point of view. IMHO it shouldn't crash
and just ignore it in this case because the wxe_server shouldn't be
allowed to crash.

Anyway I put in a patch as well just in case this is something that
should be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3.

Cheers,

/Mazen

--- wxe_server.original.erl 2009-09-24 11:00:48.000000000 +0200
+++ wxe_server.erl 2009-10-14 15:06:41.141000000 +0200
@@ -177,12 +177,11 @@
{noreply, State}
end;
handle_info(Msg = {'_wxe_destroy_', Pid}, State) ->
- case erlang:is_process_alive(Pid) of
- true ->
- Pid ! Msg,
- ok;
- false ->
- ok
+ try
+ true = erlang:is_process_alive(Pid),
+ Pid ! Msg
+ catch
+ error:_ -> ok
end,
{noreply, State};
handle_info(_Info, State) ->

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: [erlang-questions] blowfish ECB implementation in erlang?

2009-10-14T01:05:46Z

On Sun, Sep 27, 2009 at 11:35 PM, Paul Oliver <puzza007@...> wrote:

On Fri, Sep 25, 2009 at 1:19 PM, Paul Oliver <puzza007@...> wrote:

On Wed, Sep 23, 2009 at 8:33 PM, Larry Ogrodnek <larry@...> wrote:
Hi, I'm wondering if anyone has put together an implementation of blowfish ECB?

thanks.

Hi Larry,

Check the following page for the patch that added cfb64.

http://www.nabble.com/Patch-to-add-Blowfish-cfb64-to-crypto-app-td24232164.html

You should almost be able to copy this verbatim to add ecb.

Cheers,
Paul.

Hi Larry,

The attached patch should do ECB for you. It works for me on the test data I obtained from http://www.schneier.com/code/vectors.txt.

puzza@imac:~/Downloads/otp_src_R13B02-1$ /tmp/bin/erl
Erlang R13B02 (erts-5.7.3) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false]

Eshell V5.7.3 (abort with ^G)
1> %% FEDCBA9876543210 == Key = <<254,220,186,152,118,84,50,16>>
1> %% 0123456789ABCDEF == Clear = <<1,35,69,103,137,171,205,239>>
1> %% 0ACEAB0FC6A0A28D == Enc = <<10,206,171,15,198,160,162,141>>
1>
1> crypto:start().
ok
2> Key = <<254,220,186,152,118,84,50,16>>.
<<254,220,186,152,118,84,50,16>>
3> Clear = <<1,35,69,103,137,171,205,239>>.
<<1,35,69,103,137,171,205,239>>
4> Enc = <<10,206,171,15,198,160,162,141>>.
<<10,206,171,15,198,160,162,141>>
5> Enc == crypto:blowfish_ecb_encrypt(Key, Clear).
true
6> Clear == crypto:blowfish_ecb_decrypt(Key, Enc).
true
7>

I'm off on holiday tomorrow so if it doesn't work as it should I'll take another look in a couple of weeks. ;} If it works OK please reply and perhaps it can be picked up in a future OTP release.

Cheers,
Paul.

Hi,

I've rounded out the patch to include the rest of the blowfish functions from openssl and included a primitive test program.

Cheers,
Paul.

[blowfish_ecb_cbc_ofb.patch]

diff --git a/lib/crypto/c_src/crypto_drv.c b/lib/crypto/c_src/crypto_drv.c index a5b301f..9d99591 100644 --- a/lib/crypto/c_src/crypto_drv.c +++ b/lib/crypto/c_src/crypto_drv.c @@ -212,6 +212,11 @@ static ErlDrvEntry crypto_driver_entry = { #define DRV_BF_CFB64_ENCRYPT 59 #define DRV_BF_CFB64_DECRYPT 60 +#define DRV_BF_ECB_ENCRYPT 61 +#define DRV_BF_ECB_DECRYPT 62 +#define DRV_BF_OFB64_ENCRYPT 63 +#define DRV_BF_CBC_ENCRYPT 64 +#define DRV_BF_CBC_DECRYPT 65 /* #define DRV_CBC_IDEA_ENCRYPT 34 */ /* #define DRV_CBC_IDEA_DECRYPT 35 */ @@ -507,17 +512,63 @@ static int control(ErlDrvData drv_data, unsigned int command, char *buf, (command == DRV_CBC_DES_ENCRYPT)); return dlen; + case DRV_BF_ECB_ENCRYPT: + case DRV_BF_ECB_DECRYPT: + { + /* buf = klen[4] key data */ + int bf_direction; + const unsigned char *bf_dbuf; /* blowfish input data */ + BF_KEY bf_key; /* blowfish key 8 */ + + klen = get_int32(buf); + key = buf + 4; + bf_dbuf = key + klen; + dlen = len - 4 - klen; + if (dlen < 0) return -1; + BF_set_key(&bf_key, klen, key); + bin = return_binary(rbuf,rlen,dlen); + if (bin==NULL) return -1; + bf_direction = command == DRV_BF_ECB_ENCRYPT ? BF_ENCRYPT : BF_DECRYPT; + BF_ecb_encrypt(bf_dbuf, bin, &bf_key, bf_direction); + return dlen; + } + + case DRV_BF_CBC_ENCRYPT: + case DRV_BF_CBC_DECRYPT: + { + /* buf = klen[4] key ivec[8] data */ + char* ivec; + unsigned char bf_tkey[8]; /* blowfish ivec */ + int bf_direction; + const unsigned char *bf_dbuf; /* blowfish input data */ + BF_KEY bf_key; /* blowfish key 8 */ + + klen = get_int32(buf); + key = buf + 4; + ivec = key + klen; + bf_dbuf = ivec + 8; + dlen = len - 4 - klen - 8; + if (dlen < 0) return -1; + BF_set_key(&bf_key, klen, key); + memcpy(bf_tkey, ivec, 8); + bin = return_binary(rbuf,rlen,dlen); + if (bin==NULL) return -1; + bf_direction = command == DRV_BF_CBC_ENCRYPT ? BF_ENCRYPT : BF_DECRYPT; + BF_cbc_encrypt(bf_dbuf, bin, dlen, &bf_key, bf_tkey, bf_direction); + return dlen; + } + case DRV_BF_CFB64_ENCRYPT: case DRV_BF_CFB64_DECRYPT: { /* buf = klen[4] key ivec[8] data */ char* ivec; - unsigned char bf_tkey[8]; /* blowfish ivec */ - int bf_n; /* blowfish ivec pos */ + unsigned char bf_tkey[8]; /* blowfish ivec */ + int bf_n; /* blowfish ivec pos */ int bf_direction; - const unsigned char *bf_dbuf; /* blowfish input data */ + const unsigned char *bf_dbuf; /* blowfish input data */ BF_KEY bf_key; /* blowfish key 8 */ - + klen = get_int32(buf); key = buf + 4; ivec = key + klen; @@ -534,6 +585,30 @@ static int control(ErlDrvData drv_data, unsigned int command, char *buf, return dlen; } + case DRV_BF_OFB64_ENCRYPT: + { + /* buf = klen[4] key ivec[8] data */ + char* ivec; + unsigned char bf_tkey[8]; /* blowfish ivec */ + int bf_n; /* blowfish ivec pos */ + const unsigned char *bf_dbuf; /* blowfish input data */ + BF_KEY bf_key; /* blowfish key 8 */ + + klen = get_int32(buf); + key = buf + 4; + ivec = key + klen; + bf_dbuf = ivec + 8; + dlen = len - 4 - klen - 8; + if (dlen < 0) return -1; + BF_set_key(&bf_key, klen, key); + memcpy(bf_tkey, ivec, 8); + bin = return_binary(rbuf,rlen,dlen); + if (bin==NULL) return -1; + bf_n = 0; + BF_ofb64_encrypt(bf_dbuf, bin, dlen, &bf_key, bf_tkey, &bf_n); + return dlen; + } + /* case DRV_CBC_IDEA_ENCRYPT: */ /* case DRV_CBC_IDEA_DECRYPT: */ /* buf = key[16] ivec[8] data */ diff --git a/lib/crypto/doc/src/crypto.xml b/lib/crypto/doc/src/crypto.xml index 7d96017..38dacc0 100644 --- a/lib/crypto/doc/src/crypto.xml +++ b/lib/crypto/doc/src/crypto.xml @@ -337,6 +337,53 @@ Mpint() = <![CDATA[<<ByteLen:32/integer-big, Bytes:ByteLen/binary>>]]> <c>Key3</c>, and <c>IVec</c> must be 64 bits (8 bytes). </desc> </func> + + <func> + <name>blowfish_ecb_encrypt(Key, Text) -> Cipher</name> + <fsummary>Encrypt the first 64 bits of <c>Text</c> using Blowfish in ECB mode</fsummary> + <type> + <v>Key = Text = iolist() | binary()</v> + <v>IVec = Cipher = binary()</v> + </type> + <desc> + Encrypts the first 64 bits of <c>Text</c> using Blowfish in ECB mode. <c>Key</c> is the Blowfish key. The length of <c>Text</c> must be at least 64 bits (8 bytes). + </desc> + <name>blowfish_ecb_decrypt(Key, Text) -> Cipher</name> + <fsummary>Decrypt the first 64 bits of <c>Text</c> using Blowfish in ECB mode</fsummary> + <type> + <v>Key = Text = iolist() | binary()</v> + <v>IVec = Cipher = binary()</v> + </type> + <desc> + Decrypts the first 64 bits of <c>Text</c> using Blowfish in ECB mode. <c>Key</c> is the Blowfish key. The length of <c>Text</c> must be at least 64 bits (8 bytes). + </desc> + </func> + + <func> + <name>blowfish_cbc_encrypt(Key, Text) -> Cipher</name> + <fsummary>Encrypt <c>Text</c> using Blowfish in CBC mode</fsummary> + <type> + <v>Key = Text = iolist() | binary()</v> + <v>IVec = Cipher = binary()</v> + </type> + <desc> + Encrypts <c>Text</c> using Blowfish in CBC mode. <c>Key</c> is the Blowfish key, and <c>IVec</c> is an + arbitrary initializing vector. The length of <c>IVec</c> + must be 64 bits (8 bytes). The length of <c>Text</c> must be a multiple of 64 bits (8 bytes). + </desc> + <name>blowfish_cbc_decrypt(Key, Text) -> Cipher</name> + <fsummary>Decrypt <c>Text</c> using Blowfish in CBC mode</fsummary> + <type> + <v>Key = Text = iolist() | binary()</v> + <v>IVec = Cipher = binary()</v> + </type> + <desc> + Decrypts <c>Text</c> using Blowfish in CBC mode. <c>Key</c> is the Blowfish key, and <c>IVec</c> is an + arbitrary initializing vector. The length of <c>IVec</c> + must be 64 bits (8 bytes). The length of <c>Text</c> must be a multiple 64 bits (8 bytes). + </desc> + </func> + <func> <name>blowfish_cfb64_encrypt(Key, IVec, Text) -> Cipher</name> <fsummary>Encrypt <c>Text</c>using Blowfish in CFB mode with 64 @@ -367,6 +414,23 @@ Mpint() = <![CDATA[<<ByteLen:32/integer-big, Bytes:ByteLen/binary>>]]> must be 64 bits (8 bytes). </desc> </func> + + <func> + <name>blowfish_ofb64_encrypt(Key, IVec, Text) -> Cipher</name> + <fsummary>Encrypt <c>Text</c>using Blowfish in OFB mode with 64 + bit feedback</fsummary> + <type> + <v>Key = Text = iolist() | binary()</v> + <v>IVec = Cipher = binary()</v> + </type> + <desc> + Encrypts <c>Text</c> using Blowfish in OFB mode with 64 bit + feedback. <c>Key</c> is the Blowfish key, and <c>IVec</c> is an + arbitrary initializing vector. The length of <c>IVec</c> + must be 64 bits (8 bytes). + </desc> + </func> + <func> <name>aes_cfb_128_encrypt(Key, IVec, Text) -> Cipher</name> <name>aes_cbc_128_encrypt(Key, IVec, Text) -> Cipher</name> diff --git a/lib/crypto/src/crypto.erl b/lib/crypto/src/crypto.erl index 5189677..fa33bad 100644 --- a/lib/crypto/src/crypto.erl +++ b/lib/crypto/src/crypto.erl @@ -30,7 +30,10 @@ -export([md5_mac/2, md5_mac_96/2, sha_mac/2, sha_mac_96/2]). -export([des_cbc_encrypt/3, des_cbc_decrypt/3, des_cbc_ivec/1]). -export([des3_cbc_encrypt/5, des3_cbc_decrypt/5]). --export([blowfish_cfb64_encrypt/3,blowfish_cfb64_decrypt/3]). +-export([blowfish_ecb_encrypt/2, blowfish_ecb_decrypt/2]). +-export([blowfish_cbc_encrypt/3, blowfish_cbc_decrypt/3]). +-export([blowfish_cfb64_encrypt/3, blowfish_cfb64_decrypt/3]). +-export([blowfish_ofb64_encrypt/3]). -export([des_ede3_cbc_encrypt/5, des_ede3_cbc_decrypt/5]). -export([aes_cfb_128_encrypt/3, aes_cfb_128_decrypt/3]). -export([exor/2]). @@ -115,6 +118,11 @@ -define(BF_CFB64_ENCRYPT, 59). -define(BF_CFB64_DECRYPT, 60). +-define(BF_ECB_ENCRYPT, 61). +-define(BF_ECB_DECRYPT, 62). +-define(BF_OFB64_ENCRYPT, 63). +-define(BF_CBC_ENCRYPT, 64). +-define(BF_CBC_DECRYPT, 65). %% -define(IDEA_CBC_ENCRYPT, 34). %% -define(IDEA_CBC_DECRYPT, 35). @@ -303,12 +311,27 @@ des_ede3_cbc_decrypt(Key1, Key2, Key3, IVec, Data) -> %% %% Blowfish %% +blowfish_ecb_encrypt(Key, Data) when byte_size(Data) >= 8 -> + control_bin(?BF_ECB_ENCRYPT, Key, list_to_binary([Data])). + +blowfish_ecb_decrypt(Key, Data) when byte_size(Data) >= 8 -> + control_bin(?BF_ECB_DECRYPT, Key, list_to_binary([Data])). + +blowfish_cbc_encrypt(Key, IVec, Data) when byte_size(Data) rem 8 =:= 0 -> + control_bin(?BF_CBC_ENCRYPT, Key, list_to_binary([IVec, Data])). + +blowfish_cbc_decrypt(Key, IVec, Data) when byte_size(Data) rem 8 =:= 0 -> + control_bin(?BF_CBC_DECRYPT, Key, list_to_binary([IVec, Data])). + blowfish_cfb64_encrypt(Key, IVec, Data) when byte_size(IVec) =:= 8 -> control_bin(?BF_CFB64_ENCRYPT, Key, list_to_binary([IVec, Data])). blowfish_cfb64_decrypt(Key, IVec, Data) when byte_size(IVec) =:= 8 -> control_bin(?BF_CFB64_DECRYPT, Key, list_to_binary([IVec, Data])). +blowfish_ofb64_encrypt(Key, IVec, Data) when byte_size(IVec) =:= 8 -> + control_bin(?BF_OFB64_ENCRYPT, Key, list_to_binary([IVec, Data])). + %% %% AES in cipher feedback mode (CFB) %%

[bf_test.erl]

-module(bf_test). -include_lib("eunit/include/eunit.hrl"). -define(KEY, to_bin("0123456789ABCDEFF0E1D2C3B4A59687")). -define(IVEC, to_bin("FEDCBA9876543210")). %% "7654321 Now is the time for " (includes trailing '\0') -define(DATA, to_bin("37363534333231204E6F77206973207468652074696D6520666F722000")). -define(DATA_PADDED, to_bin("37363534333231204E6F77206973207468652074696D6520666F722000000000")). ecb_test(KeyBytes, ClearBytes, CipherBytes) -> crypto:start(), {Key, Clear, Cipher} = {to_bin(KeyBytes), to_bin(ClearBytes), to_bin(CipherBytes)}, crypto:blowfish_ecb_encrypt(Key, Clear) =:= Cipher. ecb_1_test() -> ?assert(ecb_test("0000000000000000", "0000000000000000", "4EF997456198DD78")). ecb_2_test() -> ?assert(ecb_test("FFFFFFFFFFFFFFFF", "FFFFFFFFFFFFFFFF", "51866FD5B85ECB8A")). ecb_3_test() -> ?assert(ecb_test("3000000000000000", "1000000000000001", "7D856F9A613063F2")). ecb_4_test() -> ?assert(ecb_test("1111111111111111", "1111111111111111", "2466DD878B963C9D")). ecb_5_test() -> ?assert(ecb_test("0123456789ABCDEF", "1111111111111111", "61F9C3802281B096")). ecb_6_test() -> ?assert(ecb_test("1111111111111111", "0123456789ABCDEF", "7D0CC630AFDA1EC7")). ecb_7_test() -> ?assert(ecb_test("0000000000000000", "0000000000000000", "4EF997456198DD78")). ecb_8_test() -> ?assert(ecb_test("FEDCBA9876543210", "0123456789ABCDEF", "0ACEAB0FC6A0A28D")). ecb_9_test() -> ?assert(ecb_test("7CA110454A1A6E57", "01A1D6D039776742", "59C68245EB05282B")). ecb_10_test() -> ?assert(ecb_test("0131D9619DC1376E", "5CD54CA83DEF57DA", "B1B8CC0B250F09A0")). ecb_11_test() -> ?assert(ecb_test("07A1133E4A0B2686", "0248D43806F67172", "1730E5778BEA1DA4")). ecb_12_test() -> ?assert(ecb_test("3849674C2602319E", "51454B582DDF440A", "A25E7856CF2651EB")). ecb_13_test() -> ?assert(ecb_test("04B915BA43FEB5B6", "42FD443059577FA2", "353882B109CE8F1A")). ecb_14_test() -> ?assert(ecb_test("0113B970FD34F2CE", "059B5E0851CF143A", "48F4D0884C379918")). ecb_15_test() -> ?assert(ecb_test("0170F175468FB5E6", "0756D8E0774761D2", "432193B78951FC98")). ecb_16_test() -> ?assert(ecb_test("43297FAD38E373FE", "762514B829BF486A", "13F04154D69D1AE5")). ecb_17_test() -> ?assert(ecb_test("07A7137045DA2A16", "3BDD119049372802", "2EEDDA93FFD39C79")). ecb_18_test() -> ?assert(ecb_test("04689104C2FD3B2F", "26955F6835AF609A", "D887E0393C2DA6E3")). ecb_19_test() -> ?assert(ecb_test("37D06BB516CB7546", "164D5E404F275232", "5F99D04F5B163969")). ecb_20_test() -> ?assert(ecb_test("1F08260D1AC2465E", "6B056E18759F5CCA", "4A057A3B24D3977B")). ecb_21_test() -> ?assert(ecb_test("584023641ABA6176", "004BD6EF09176062", "452031C1E4FADA8E")). ecb_22_test() -> ?assert(ecb_test("025816164629B007", "480D39006EE762F2", "7555AE39F59B87BD")). ecb_23_test() -> ?assert(ecb_test("49793EBC79B3258F", "437540C8698F3CFA", "53C55F9CB49FC019")). ecb_24_test() -> ?assert(ecb_test("4FB05E1515AB73A7", "072D43A077075292", "7A8E7BFA937E89A3")). ecb_25_test() -> ?assert(ecb_test("49E95D6D4CA229BF", "02FE55778117F12A", "CF9C5D7A4986ADB5")). ecb_26_test() -> ?assert(ecb_test("018310DC409B26D6", "1D9D5C5018F728C2", "D1ABB290658BC778")). ecb_27_test() -> ?assert(ecb_test("1C587F1C13924FEF", "305532286D6F295A", "55CB3774D13EF201")). ecb_28_test() -> ?assert(ecb_test("0101010101010101", "0123456789ABCDEF", "FA34EC4847B268B2")). ecb_29_test() -> ?assert(ecb_test("1F1F1F1F0E0E0E0E", "0123456789ABCDEF", "A790795108EA3CAE")). ecb_30_test() -> ?assert(ecb_test("E0FEE0FEF1FEF1FE", "0123456789ABCDEF", "C39E072D9FAC631D")). ecb_31_test() -> ?assert(ecb_test("0000000000000000", "FFFFFFFFFFFFFFFF", "014933E0CDAFF6E4")). ecb_32_test() -> ?assert(ecb_test("FFFFFFFFFFFFFFFF", "0000000000000000", "F21E9A77B71C49BC")). ecb_33_test() -> ?assert(ecb_test("0123456789ABCDEF", "0000000000000000", "245946885754369A")). ecb_34_test() -> ?assert(ecb_test("FEDCBA9876543210", "FFFFFFFFFFFFFFFF", "6B5C5A9C5D9E0A5A")). %% Chaining mode tests cbc_test() -> crypto:start(), ?assert(crypto:blowfish_cbc_encrypt(?KEY, ?IVEC, ?DATA_PADDED) =:= to_bin("6B77B4D63006DEE605B156E27403979358DEB9E7154616D959F1652BD5FF92CC")). cfb64_test() -> crypto:start(), ?assert(crypto:blowfish_cfb64_encrypt(?KEY, ?IVEC, ?DATA) =:= to_bin("E73214A2822139CAF26ECF6D2EB9E76E3DA3DE04D1517200519D57A6C3")). ofb64_test() -> crypto:start(), ?assert(crypto:blowfish_ofb64_encrypt(?KEY, ?IVEC, ?DATA) =:= to_bin("E73214A2822139CA62B343CC5B65587310DD908D0C241B2263C2CF80DA")). %% @spec to_bin(string()) -> binary() %% @doc Convert a hexadecimal string to a binary. to_bin(L) -> to_bin(L, []). %% @spec dehex(char()) -> integer() %% @doc Convert a hex digit to its integer value. dehex(C) when C >= $0, C =< $9 -> C - $0; dehex(C) when C >= $a, C =< $f -> C - $a + 10; dehex(C) when C >= $A, C =< $F -> C - $A + 10. to_bin([], Acc) -> iolist_to_binary(lists:reverse(Acc)); to_bin([C1, C2 | Rest], Acc) -> to_bin(Rest, [(dehex(C1) bsl 4) bor dehex(C2) | Acc]).

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: PATCH: ODBC application discarding sqlstate in get_diagnos function

2009-10-12T13:33:16Z

On 10/11/09, Andrew Thompson <andrew@...> wrote:
>
> Ah, that does sound like a similar issue although I'm not sure my patch
> will solve it. Does it happen consistantly or is it random? Are you
> using parameterized queries?

I haven't worked with that part of the system in 5-6 months and i'm no
longer sure if it was consistent or not. I'm on a trip and can't check
it now. I'll try to find time to reproduce it on weekend.

Juhani

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: PATCH: ODBC application discarding sqlstate in get_diagnos function

2009-10-11T11:17:16Z

On Sun, Oct 11, 2009 at 10:40:10AM +0300, Juhani R?nkimies wrote:
> On Sat, Oct 10, 2009 at 7:45 PM, Andrew Thompson <andrew@...> wrote:
>

> Sometimes when an update/insert/delete is successfully executed in the
> db, I get {error,"No SQL-driver information available."}.
>
> My assumption (with no factual support) is that odbc app gets confused
> if the db sends additional information (SQLSTATE?) about the execution
> of the statement, like nulls ignored by aggregate functions or info
> about type conversions that were made.
>

Ah, that does sound like a similar issue although I'm not sure my patch
will solve it. Does it happen consistantly or is it random? Are you
using parameterized queries?

Andrew

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org

Re: PATCH: ODBC application discarding sqlstate in get_diagnos function

2009-10-11T00:40:10Z

On Sat, Oct 10, 2009 at 7:45 PM, Andrew Thompson <andrew@...> wrote:

>>
> If it doesn't, I can try to resurrect my windows build setup and do some
> investigating. What behaviour are you seeing?
>

Sometimes when an update/insert/delete is successfully executed in the
db, I get {error,"No SQL-driver information available."}.

My assumption (with no factual support) is that odbc app gets confused
if the db sends additional information (SQLSTATE?) about the execution
of the statement, like nulls ignored by aggregate functions or info
about type conversions that were made.

-juhani

________________________________________________________________
erlang-patches mailing list. See http://www.erlang.org/faq.html
erlang-patches (at) erlang.org