From vlad.dumitrescu@REDACTED  Mon Aug  2 20:48:33 1999
From: vlad.dumitrescu@REDACTED (Vlad Dumitrescu)
Date: Mon, 2 Aug 1999 20:48:33 +0200
Subject: questions
Message-ID: <93361984301@flashmail.com>

Hi all!

I have a few questions


how is the free source version of Erlang related to the professional 
    version? Will it always be one step back? (since the pro version now 
    is 4.8)
is  the VxWorks port just a regular port, or it does use the special 
    facilities of the OS in order to be more efficient?
Is  there any way to find out whether a specific VM is installed on a 
    node, or it is safe to assume both JAM and BEAM are present? (the 
    latter restricts the possible use of other VMs)

Thank you for the help
Vlad


From tobbe@REDACTED  Tue Aug  3 02:47:57 1999
From: tobbe@REDACTED (Torbjorn Tornkvist)
Date: Tue, 03 Aug 1999 10:47:57 +1000
Subject: questions 
In-Reply-To: <93361984301@flashmail.com> 
References: <93361984301@flashmail.com>
Message-ID: <199908030047.KAA01008@campari.serc.rmit.edu.au>


> Is there any way to find out whether a specific VM is installed on a 
> node, or it is safe to assume both JAM and BEAM are present? (the 
> latter restricts the possible use of other VMs)

One way of doing this is to compile a module with:

 erl -compile <MOD>

and then test if the resulting file suffix is beam or jam.

I've done this in combination with autoconf. 
So in the configure.in I have:

  dnl find out the type of Erlang machine which is used
  AC_MSG_CHECKING([checking for Erlang machine type])
  rm -f rootdir.{jam,beam}
  $ac_cv_erl -compile rootdir
  EDDIE_ROOTDIR_FILES=`echo rootdir.*`
  case "rootdir_FILES"in
  *jam*)
          EMULATOR=jam
          AC_SUBST(EMULATOR)
          AC_MSG_RESULT([jam])
          ;;
  *beam*) 
          EMULATOR=beam
          AC_SUBST(EMULATOR)
          AC_MSG_RESULT([beam])
          ;;
  *)
          AC_MSG_RESULT([no])
          AC_MSG_ERROR("Unable to determine Erlang machine type: jam/beam")
          ;;
  esac

I also uses the module 'rootdir' to get hold of where
the Erlang root directory is, so:

  -module(rootdir).
  -author('tobbe@REDACTED').
  %%% --------------------------------------------------------------------
  %%% Created : 26 Mar 1999 by tobbe@REDACTED
  %%% Function: Write the Erlang root dir to the file: root_dir.result
  %%% --------------------------------------------------------------------
  -vc('$Id: eddie_rootdir.erl,v 1.3 1999/05/13 02:36:03 ttey Exp $ ').
  -export([start/1]).
  
  start([ResultFile]) when atom(ResultFile) ->
      case file:open(atom_to_list(ResultFile),[write,raw]) of
          {ok,Fd} ->
              file:write(Fd,code:root_dir()),
              file:sync(Fd),
              file:close(Fd);
          _ ->
              false
      end,
      halt().

In the configure.in this is used as:

  dnl find out where the Erlang root dir is located
  AC_MSG_CHECKING([checking for the Erlang root dir])
  ROOTDIR_RESULT=rootdir.result
  rm -f ROOTDIR_RESULT
  $ac_cv_erl +B -noshell -s rootdir start rootdir_result
  ERLDIR=`cat $ROOTDIR_RESULT`
  AC_SUBST(ERLDIR)
  AC_MSG_RESULT([$ERLDIR])


Cheers /Tobbe





From tobbe@REDACTED  Tue Aug  3 02:47:57 1999
From: tobbe@REDACTED (Torbjorn Tornkvist)
Date: Tue, 03 Aug 1999 10:47:57 +1000
Subject: questions 
In-Reply-To: <93361984301@flashmail.com> 
References: <93361984301@flashmail.com>
Message-ID: <199908030047.KAA01008@campari.serc.rmit.edu.au>


> Is there any way to find out whether a specific VM is installed on a 
> node, or it is safe to assume both JAM and BEAM are present? (the 
> latter restricts the possible use of other VMs)

One way of doing this is to compile a module with:

 erl -compile <MOD>

and then test if the resulting file suffix is beam or jam.

I've done this in combination with autoconf. 
So in the configure.in I have:

  dnl find out the type of Erlang machine which is used
  AC_MSG_CHECKING([checking for Erlang machine type])
  rm -f rootdir.{jam,beam}
  $ac_cv_erl -compile rootdir
  EDDIE_ROOTDIR_FILES=`echo rootdir.*`
  case "rootdir_FILES"in
  *jam*)
          EMULATOR=jam
          AC_SUBST(EMULATOR)
          AC_MSG_RESULT([jam])
          ;;
  *beam*) 
          EMULATOR=beam
          AC_SUBST(EMULATOR)
          AC_MSG_RESULT([beam])
          ;;
  *)
          AC_MSG_RESULT([no])
          AC_MSG_ERROR("Unable to determine Erlang machine type: jam/beam")
          ;;
  esac

I also uses the module 'rootdir' to get hold of where
the Erlang root directory is, so:

  -module(rootdir).
  -author('tobbe@REDACTED').
  %%% --------------------------------------------------------------------
  %%% Created : 26 Mar 1999 by tobbe@REDACTED
  %%% Function: Write the Erlang root dir to the file: root_dir.result
  %%% --------------------------------------------------------------------
  -vc('$Id: eddie_rootdir.erl,v 1.3 1999/05/13 02:36:03 ttey Exp $ ').
  -export([start/1]).
  
  start([ResultFile]) when atom(ResultFile) ->
      case file:open(atom_to_list(ResultFile),[write,raw]) of
          {ok,Fd} ->
              file:write(Fd,code:root_dir()),
              file:sync(Fd),
              file:close(Fd);
          _ ->
              false
      end,
      halt().

In the configure.in this is used as:

  dnl find out where the Erlang root dir is located
  AC_MSG_CHECKING([checking for the Erlang root dir])
  ROOTDIR_RESULT=rootdir.result
  rm -f ROOTDIR_RESULT
  $ac_cv_erl +B -noshell -s rootdir start rootdir_result
  ERLDIR=`cat $ROOTDIR_RESULT`
  AC_SUBST(ERLDIR)
  AC_MSG_RESULT([$ERLDIR])


Cheers /Tobbe





From vlad.dumitrescu@REDACTED  Tue Aug  3 10:35:36 1999
From: vlad.dumitrescu@REDACTED (Vlad Dumitrescu)
Date: Tue, 3 Aug 1999 00:35:36 -800
Subject: more questions... :-)
Message-ID: <37a69bc8.195.0@flashmail.com>

- How does Erlang interface with other languages than C? For example to use Fortran
legacy code. It could be done by using a C layer in-between, but maybe there
is a more direct approach...

- I was looking at other concurrent programming environments/languages (mostly
Mozart/Oz) and am appreciating the more the simple and clean ways of Erlang.
But there are more advanced features that are complex to handle directly, and
extending the language might help in that direction. How does the thought of
using Erlang as a "assembler" language, most like Lisp (and C) are for so many
other higher-level languages, sound? Is it an heresy? hope not...

enjoy the summer!
Vlad
______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!


From tobbe@REDACTED  Tue Aug  3 14:18:47 1999
From: tobbe@REDACTED (Torbjorn Tornkvist)
Date: Tue, 03 Aug 1999 22:18:47 +1000
Subject: more questions... :-) 
In-Reply-To: <37a69bc8.195.0@flashmail.com> 
References: <37a69bc8.195.0@flashmail.com>
Message-ID: <199908031218.WAA01366@campari.serc.rmit.edu.au>


> How does Erlang interface with other languages than C ? 

Well, I think C (C++ ?) and Java is the only languages supported by IC.

/Tobbe





From Pekka.Hedqvist@REDACTED  Tue Aug  3 14:42:10 1999
From: Pekka.Hedqvist@REDACTED (Pekka.Hedqvist@REDACTED)
Date: Tue, 3 Aug 1999 22:42:10 +1000 (EST)
Subject: more questions... :-) 
In-Reply-To: <199908031218.WAA01366@campari.serc.rmit.edu.au>
References: <37a69bc8.195.0@flashmail.com>
	<199908031218.WAA01366@campari.serc.rmit.edu.au>
Message-ID: <14246.58274.625970.337520@universe.serc.rmit.edu.au>


And with Erlang comes the Orber application that is a CORBA compliant 
Object Request Brokers (ORB), which provides CORBA functionality in 
an Erlang environment. So if your "other" language has and IDL compiler
etc they can always use the Orber.

Torbjorn Tornkvist writes:
 > 
 > > How does Erlang interface with other languages than C ? 
 > 
 > Well, I think C (C++ ?) and Java is the only languages supported by IC.
 > 
 > /Tobbe
 > 
 > 
 > 
 > 


From jhague@REDACTED  Tue Aug  3 16:03:12 1999
From: jhague@REDACTED (James Hague)
Date: Tue, 3 Aug 1999 09:03:12 -0500 (CDT)
Subject: more questions... :-)
In-Reply-To: <37a69bc8.195.0@flashmail.com>
Message-ID: <Pine.LNX.3.96.990803085245.18880D-100000@babba.advancenet.net>

On Tue, 3 Aug 1999, Vlad Dumitrescu wrote:

> How does the thought of
> using Erlang as a "assembler" language, most like Lisp (and C) are for so
> many other higher-level languages, sound? Is it an heresy? hope not...

I'm not sure what you're getting at.  You'd like to compile other
languages into Erlang?

Erlang is the most wonderfully concise and easy to use language I've had
the pleasure of programming in.  But for many applications, Erlang needs
to be used in conjunction with another more "sequential, performance
oriented" language.  You certainly wouldn't want to complile sequential
code into Erlang; you'be be better off writing a custom compiler *using*
Erlang (now that would be fun!).

James



From vlad.dumitrescu@REDACTED  Tue Aug  3 22:07:01 1999
From: vlad.dumitrescu@REDACTED (Vlad Dumitrescu)
Date: Tue, 3 Aug 1999 22:07:01 +0200
Subject: Erlang as "assembler"
In-Reply-To: <Pine.LNX.3.96.990803085245.18880D-100000@babba.advancenet.net>
References: <37a69bc8.195.0@flashmail.com>
Message-ID: <93371096001@flashmail.com>

> > How does the thought of
> > using Erlang as a "assembler" language, most like Lisp (and C) are for
> > so many other higher-level languages, sound? Is it an heresy? hope
> > not...
> 
> I'm not sure what you're getting at.  You'd like to compile other
> languages into Erlang?

Something like that, yes. Not any language, but something more 
like a kind of "Erlang++". Let me explain by taking an example: 
constraint programming. One can express all constraints and rules 
in Erlang, but if an application uses a lot of it, it might be easier to 
use and debug if one could extend Erlang, and use a preprocessor 
to convert the source into 'clean' Erlang. 

One other example might have been the list comprehensions: if the 
language did not provide them, someone might use a preprocessor 
to 'compile' them into code. 

In the latter case, including that into the language is good because 
it is a general improvement and it's also faster than using hand-
coded routines. But when the change is specific, of limited use, I 
think it makes little sense to include it into the language.

> Erlang is the most wonderfully concise and easy to use language I've had
> the pleasure of programming in.  

I completely agree with you!! 

My question was in fact addressed to the creators of Erlang. I 
know that it might be a touchy question to (more or less) build a 
language on top of another - and I don't want to get on their black 
list! ;-) So I ask first, to find out their thoughts.

note: it is constraint programming that I would like to be able to 
express in a cleaner way.

/Vlad


From klacke@REDACTED  Tue Aug  3 23:11:07 1999
From: klacke@REDACTED (Klacke)
Date: Tue, 3 Aug 1999 23:11:07 +0200
Subject: Erlang as "assembler"
In-Reply-To: <93371096001@flashmail.com> (vlad.dumitrescu@flashmail.com)
References: <37a69bc8.195.0@flashmail.com> <93371096001@flashmail.com>
Message-ID: <199908032111.XAA01671@duva.bluetail.com>



> in Erlang, but if an application uses a lot of it, it might be easier to 
> use and debug if one could extend Erlang, and use a preprocessor 
> to convert the source into 'clean' Erlang. 

This is not a bad idea at all, 


> 
> One other example might have been the list comprehensions: if the 
> language did not provide them, someone might use a preprocessor 
> to 'compile' them into code. 
> 

And as it happens, list comprehensions are implemented that
way already. lib/compiler/src/sys_pre_expand.erl
This was easy to implement, the drawback is that lc's are
a bit slower that they could be.


> In the latter case, including that into the language is good because 
> it is a general improvement and it's also faster than using hand-
> coded routines. But when the change is specific, of limited use, I 
> think it makes little sense to include it into the language.
> 

We used to discuss a sort of kernel erlang a couple of
years ago, it should a minimalistic language (possibly
imperative) that could be used to compile all kinds of
transformations and language extensions into. It was never
realized though but I still think it was a good idea.


Cheers


/klacke



From per@REDACTED  Wed Aug  4 00:48:41 1999
From: per@REDACTED (Per Hedeland)
Date: Wed, 4 Aug 1999 00:48:41 +0200 (MET DST)
Subject: questions
Message-ID: <199908032248.AAA16789@super.du.uab.ericsson.se>

Vlad Dumitrescu wrote:
>how is the free source version of Erlang related to the professional 
>    version? Will it always be one step back? (since the pro version now 
>    is 4.8)

I hope you don't think we're just sitting on the "pro" version for a
release interval until we release it as free source...:-) The problem is
that it's currently a lot of work, much of it manual, to turn "pro" into
something that can decently be released in source form, due to "pro"
being interwowen with the local development environment (ClearCase etc),
being targeted for binary-only releases, having portability problems,
etc.

That work has *so far* only been done once, with 4.7.4 -> open-source
47.4.0 - and the goal is that it shouldn't have to be done again;
quoting Sebastian Strollo from a message here back in May:

                                     Right now we are working hard
  to make sure that in the future we will make the main release the same
  as the open source release. The aim right now is to make the next
  major product release (beginning of November) this new unified source
  release.

I.e. we could in theory tar up the current "pro" and put it on the web
site, but virtually no one would be able to build it, and I don't think
that would benefit either the Erlang user community or Erlang's
reputation.:-) 

>is  the VxWorks port just a regular port, or it does use the special 
>    facilities of the OS in order to be more efficient?

I believe it's pretty regular, special facilities being used mostly to
overcome the mismatch between what the OS provides and what the Erlang
runtime system expects.:-) (E.g. it really doesn't have an equivalent of
a Unix pipe, so someone wrote a ("real OS") driver that implemented it.)

Basically, what is a Unix process in Unix is a "task" in VxWorks, rather
than (e.g.) Erlang processes being mapped to VxWorks tasks. Context
switches between VxWorks tasks should be less expensive than between
Unix processes, meaning that using "port programs" should be "cheaper"
in VxWorks, but as far as I know no measurements of this have been done.

--Per Hedeland
per@REDACTED


From luke@REDACTED  Wed Aug  4 21:35:03 1999
From: luke@REDACTED (Luke Gorrie)
Date: 05 Aug 1999 05:35:03 +1000
Subject: Concurrency problem
Message-ID: <87emhjl4pk.fsf@baked.vegetable.org>

Hi all,

I'm wondering if someone can help me with a pattern for avoiding a
deadlock.  Fundamentally, my problem is this:

I have two gen_server processes, A and B.  A wants to make a call on
B for the sake of the side-effects.  These side-effects involve making 
calls to A.

So, it seems to me that if A makes a gen_server:call to B, then when B 
does the same back to A, it will get a cycle in the call graph and
deadlock.  Now, it might seem that it's the inappropriate use of
side-effects that's the problem, and that B should just return a value 
for A to use, however I'm trying to follow an explicit mapping which
has things this way.  Specifically, a corba Portable Object Adapter
calling an AdapterActivator.

Any help would be appreciated.  Infact, I'd love to some general
information about managing things with Erlang's concurrency model, I'm 
sure there are oodles of useful patterns - pointers would be great!

Cheers,
Luke




From tobbe@REDACTED  Thu Aug  5 04:00:39 1999
From: tobbe@REDACTED (Torbjorn Tornkvist)
Date: Thu, 05 Aug 1999 12:00:39 +1000
Subject: Concurrency problem 
In-Reply-To: Your message of "05 Aug 1999 05:35:03 +1000."
             <87emhjl4pk.fsf@baked.vegetable.org> 
Message-ID: <199908050200.MAA14118@universe.serc.rmit.edu.au>


> So, it seems to me that if A makes a gen_server:call to B, then when B 
> does the same back to A, it will get a cycle in the call graph and
> deadlock.  

Yes, and to avoid that you can either:

 1. Use gen_server:cast/2 .
 2. Spawn of a new process P which does the the gen_server:/call 
    to B, and then relay the answer back to A.

In both cases you have to be make sure you can receive those 
messages (from P and B) in A.

Cheers /Tobbe


From Pekka.Hedqvist@REDACTED  Thu Aug  5 05:43:03 1999
From: Pekka.Hedqvist@REDACTED (Pekka.Hedqvist@REDACTED)
Date: Thu, 5 Aug 1999 13:43:03 +1000 (EST)
Subject: Concurrency problem 
In-Reply-To: <199908050200.MAA14118@universe.serc.rmit.edu.au>
References: <87emhjl4pk.fsf@baked.vegetable.org>
	<199908050200.MAA14118@universe.serc.rmit.edu.au>
Message-ID: <14249.2119.259922.585114@universe.serc.rmit.edu.au>


And in some cases it can be convenient to use the
'gen_server:reply(To, Reply)' call in a handle_call 
instead to make an explicit reply to the caller and 
then go on doing something..

Torbjorn Tornkvist writes:
 > 
 > > So, it seems to me that if A makes a gen_server:call to B, then when B 
 > > does the same back to A, it will get a cycle in the call graph and
 > > deadlock.  
 > 
 > Yes, and to avoid that you can either:
 > 
 >  1. Use gen_server:cast/2 .
 >  2. Spawn of a new process P which does the the gen_server:/call 
 >     to B, and then relay the answer back to A.
 > 
 > In both cases you have to be make sure you can receive those 
 > messages (from P and B) in A.
 > 
 > Cheers /Tobbe
 > 


From klacke@REDACTED  Thu Aug  5 10:28:15 1999
From: klacke@REDACTED (Klacke)
Date: Thu, 5 Aug 1999 10:28:15 +0200
Subject: Concurrency problem
In-Reply-To: <87emhjl4pk.fsf@baked.vegetable.org> (message from Luke Gorrie on
	05 Aug 1999 05:35:03 +1000)
References: <87emhjl4pk.fsf@baked.vegetable.org>
Message-ID: <199908050828.KAA25738@duva.bluetail.com>



> I'm wondering if someone can help me with a pattern for avoiding a
> deadlock.  Fundamentally, my problem is this:
> 
> I have two gen_server processes, A and B.  A wants to make a call on
> B for the sake of the side-effects.  These side-effects involve making 
> calls to A.
> 

This is a classic situation, I've encoutered the
same problem over and over again. Mnesia is for example
full with code that really would like to make a simple 
gen_server:call to the remote side but can't do it since the
other side would then do the same.

You need to do some sort of async solution here.

1. Send request.  (gen_server:cast)
2. Mark request as outstanding, (change server state)
3. When reply comes handle it as usual.

A bit irritating since this is such a common situation.

Cheers

/klacke



From klacke@REDACTED  Thu Aug  5 14:31:45 1999
From: klacke@REDACTED (Klacke)
Date: Thu, 5 Aug 1999 14:31:45 +0200
Subject: FreeBSD 3.2
Message-ID: <199908051231.OAA31542@duva.bluetail.com>


I've been having some trouble with erlang 47.4.1 + Mnesia on
FreeBSD 3.2. It appears as if pwrite() isn't working
correctly on FreeBSD 3.2.
For example the following program coredumps.

#include <sys/types.h>
#include <sys/uio.h>
#include <unistd.h>
main() { pwrite(0, "abc", 3, 0); exit(0); }

The call to pwrite() should simply fail (0 is not a seekable device), 
not coredump.

Anyway, the dets/mnesia modules uses pwrite() and the autoconf test
just checks that pread exists, not that pwrite works.

I've changed erts/autoconf/configure.in to do just that.

That is:

AC_TRY_RUN([
#include <sys/types.h>
#include <sys/uio.h>
#include <unistd.h>
main() { pwrite(0, "abc", 3, 0); exit(0); }],
pwrite_works=yes, 
pwrite_works=no,)


if test $pwrite_works = yes; then
  AC_DEFINE(HAVE_PREADWRITE)
fi

instead of

AC_CHECK_FUNC(pread, [AC_DEFINE(HAVE_PREADWRITE)])dnl FIXME convbreak


This means that each call to pread/pwrite will be transformed
into a call to seek, followed by a call to read/write. This is
of cource not good, but it's better than a core dump.

Possibly some of the more FreeBSD oriented people here on the
list knows about this problem ?? I can't be the first person
that calls pwrite() on FreeBSD 3.2 !!!! Or is my local system
screwed ??

autoconf complains with "AC_TRY_RUN called without default to allow cross compiling", but I've been told that the error message can be safely ignored.
Furthermore I've only tested this stuff on BSD and Linux.


Cheers

/klacke


From dwyer@REDACTED  Fri Aug  6 01:38:20 1999
From: dwyer@REDACTED (Mick Dwyer)
Date: Fri, 6 Aug 1999 09:38:20 +1000 (EST)
Subject: FreeBSD 3.2
In-Reply-To: <199908051231.OAA31542@duva.bluetail.com> from Klacke at "Aug 5, 99 02:31:45 pm"
Message-ID: <199908052338.JAA27098@universe.serc.rmit.edu.au>

> 
> I've been having some trouble with erlang 47.4.1 + Mnesia on
> FreeBSD 3.2. It appears as if pwrite() isn't working
> correctly on FreeBSD 3.2.
> For example the following program coredumps.
> 
> #include <sys/types.h>
> #include <sys/uio.h>
> #include <unistd.h>
> main() { pwrite(0, "abc", 3, 0); exit(0); }
> 
> The call to pwrite() should simply fail (0 is not a seekable device), 
> not coredump.

The above code works on my 3.2 box. (FreeBSD amber.serc.rmit.edu.au 3.2-RELEASE FreeBSD 3.2-RELEASE #0: Wed Jul  7 13:41:45 EST 1999     root@REDACTED:/usr/src/sys/compile/FBSDX  i386)

However, the code does not link on 2.2.8 or 3.1-RELEASE.

-- 
Mick Dwyer

-==================================================================-
 Software Engineering Research Centre              Phone: 9925-4026
 Level 3,                                            Fax: 9925-4094
 110 Victoria Street,                        dwyer@REDACTED
 Melbourne, Australia.                  http://www.serc.rmit.edu.au
-==================================================================-


From eeicmui@REDACTED  Fri Aug  6 11:34:56 1999
From: eeicmui@REDACTED (Chandrashekhar)
Date: Fri, 06 Aug 1999 10:34:56 +0100
Subject: OTP SNMP agent
Message-ID: <37AAAC40.E9E70A99@eei.ericsson.se>

Hi,

  I have a doubt about the Atomic SET transaction mechanism
  in the SNMP agent.
  Suppose I want to modify multiple rows in a single 
  SET request. I then must write is_set_ok, and undo
  operations for this table, right?

  The sequence will be:
    * For each row call is_set_ok.
    * If any one of them returns {error, Column}, then call
      undo for each of the previous ones and return error to Manager.
    * If all succeed, return success.

  Pls. let me know if I'm correct.

tia,
Chandru

-- 
Random Wodehouse Quote

Jeeves lugged my purple socks out of the drawer as if he were a
vegetarian fishing a caterpillar out of his salad.

Jeeves and the Chump Cyril, My Man Jeeves, 1919


From luke@REDACTED  Sat Aug  7 21:50:48 1999
From: luke@REDACTED (Luke Gorrie)
Date: 08 Aug 1999 05:50:48 +1000
Subject: Concurrency problem
In-Reply-To: Klacke's message of "Thu, 5 Aug 1999 10:28:15 +0200"
References: <87emhjl4pk.fsf@baked.vegetable.org> <199908050828.KAA25738@duva.bluetail.com>
Message-ID: <87emhfid47.fsf@baked.vegetable.org>

Klacke <klacke@REDACTED> writes:

> > I'm wondering if someone can help me with a pattern for avoiding a
> > deadlock.  Fundamentally, my problem is this:
> > 
> > I have two gen_server processes, A and B.  A wants to make a call on
> > B for the sake of the side-effects.  These side-effects involve making 
> > calls to A.
> > 
> 
> This is a classic situation, I've encoutered the
> same problem over and over again. Mnesia is for example
> full with code that really would like to make a simple 
> gen_server:call to the remote side but can't do it since the
> other side would then do the same.
> 
> You need to do some sort of async solution here.
> 
> 1. Send request.  (gen_server:cast)
> 2. Mark request as outstanding, (change server state)
> 3. When reply comes handle it as usual.
> 
> A bit irritating since this is such a common situation.

Thanks for the advice (and Tobbe and Pekka too).  I've had a quick
look at these parts of the Mnesia source and it's obvious there's
something for me to learn there.

I'd also really like to learn some more general rules for this sort of 
thing.  It seems that there should be useful design patterns for
structuring the concurrency safely.  Could anyone point me at some
documentation for this?  Infact, I'd like to read any documentation
that's related to erlang and can't be easily found on the website.

Something that particularly caught my eye was an abstract for a talk
Joe Armstrong gave that I found on the web, titled "Higher order
processes in Erlang".  Is there somewhere I could grab a paper
covering this material or some like it?

Cheers,
Luke




From dsolaz@REDACTED  Sat Aug  7 22:46:31 1999
From: dsolaz@REDACTED (Daniel Solaz)
Date: Sat, 07 Aug 1999 22:46:31 +0200
Subject: Erlang on BeOS
References: <37A22352.9830B4B5@sistelcom.com>
Message-ID: <37AC9B27.C0159715@sistelcom.com>

Hello.  I just tried to build Erlang on BeOS again and I've found what
(to me) seems like a configure problem.  Let me explain:

The configure script can't figure out the host type.  So I told it to
try 'i686-unknown-linux', since this the same linux box I usually run
Erlang on, and that's what the linux configure script used to build it. 
To my surprise, I've found the BeOS is pretty compatible.

All seems to go well except for the erts subdirectory.  For some reason,
the host type gets lost when going in there and configure says 'can not
guess host type'.  All other subdirectories are correctly configured.

Naturally, make fails in erts/system, which happens to be the first
place it goes into.

To me this looks like a configure problem, but I know virtually nothing
about autoconf and configure.  Can someone please tell me where to look
for something that could be wrong in the different configure scripts,
and what would that look like?

Thanks in advance.
-Daniel
-------------- next part --------------
beos45:~/tmp/erlang-47.4.1$ ./configure --host=i686-unknown-linux --prefix=/boot/home/config                                                                    checking host system type... i686-unknown-linux
checking for GNU make... yes (make)
checking for a BSD compatible install... /bin/install -c
checking whether ln -s works... yes
checking for ranlib... ranlib
Running configure in erts/autoconf...
creating cache /boot/home/tmp/erlang-47.4.1/erts/autoconf/i686-unknown-linux/config.cache
checking host system type... configure: error: can not guess host type; you must specify one
creating ./config.status
creating Makefile
configuring in lib
running /bin/sh /boot/home/tmp/erlang-47.4.1/lib/configure  --host=i686-unknown-linux --prefix=/boot/home/config --cache-file=.././config.cache --srcdir=/boot/home/tmp/erlang-47.4.1/lib
checking host system type... i686-unknown-linux
creating ./config.status
configuring in os_mon
running /bin/sh /boot/home/tmp/erlang-47.4.1/lib/os_mon/configure  --host=i686-unknown-linux --prefix=/boot/home/config --cache-file=../.././config.cache --srcdir=/boot/home/tmp/erlang-47.4.1/lib/os_mon
checking host system type... i686-unknown-linux
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for kstat_open in -lkstat... no
creating ./config.status
creating c_src/i686-unknown-linux/Makefile
configuring in orber
running /bin/sh /boot/home/tmp/erlang-47.4.1/lib/orber/configure  --host=i686-unknown-linux --prefix=/boot/home/config --cache-file=../.././config.cache --srcdir=/boot/home/tmp/erlang-47.4.1/lib/orber
checking host system type... i686-unknown-linux
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for c++... c++
checking whether the C++ compiler (c++  ) works... yes
checking whether the C++ compiler (c++  ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking for connect... yes
checking for gethostbyname... yes
checking for gethostbyname_r... no
checking how to run the C preprocessor... gcc -E
checking whether gcc needs -traditional... no
checking for INADDR_LOOPBACK in netinet/in.h... yes
creating ./config.status
creating c_src/i686-unknown-linux/Makefile
configuring in ig
running /bin/sh /boot/home/tmp/erlang-47.4.1/lib/ig/configure  --host=i686-unknown-linux --prefix=/boot/home/config --cache-file=../.././config.cache --srcdir=/boot/home/tmp/erlang-47.4.1/lib/ig
checking host system type... i686-unknown-linux
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
creating ./config.status
creating c_src/i686-unknown-linux/Makefile
configuring in ic
running /bin/sh /boot/home/tmp/erlang-47.4.1/lib/ic/configure  --host=i686-unknown-linux --prefix=/boot/home/config --cache-file=../.././config.cache --srcdir=/boot/home/tmp/erlang-47.4.1/lib/ic
checking host system type... i686-unknown-linux
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
creating ./config.status
creating c_src/i686-unknown-linux/Makefile
configuring in jive
running /bin/sh /boot/home/tmp/erlang-47.4.1/lib/jive/configure  --host=i686-unknown-linux --prefix=/boot/home/config --cache-file=../.././config.cache --srcdir=/boot/home/tmp/erlang-47.4.1/lib/jive
checking for javac... no
creating ./config.status
creating Makefile

beos45:~/tmp/erlang-47.4.1$ make
cd erts/system && ERL_TOP=/boot/home/tmp/erlang-47.4.1 make EMULATOR=jam opt
make[1]: Entering directory `/boot/home/tmp/erlang-47.4.1/erts/system'
Makefile:8: /boot/home/tmp/erlang-47.4.1/internal_tools/make//otp.mk: No such file or directory
make[1]: *** No rule to make target `/boot/home/tmp/erlang-47.4.1/internal_tools/make//otp.mk'.  Stop.
make[1]: Leaving directory `/boot/home/tmp/erlang-47.4.1/erts/system'
make: *** [emulator] Error 2
beos45:~/tmp/erlang-47.4.1$ 

From chandru@REDACTED  Sun Aug  8 13:46:58 1999
From: chandru@REDACTED (Chandru)
Date: Sun, 8 Aug 1999 12:46:58 +0100
Subject: Max SNMP message
Message-ID: <000b01bee193$b9c09240$6d8791c2@sharmila>

Hi,

  I was wondering if there was any limitation on the OTP SNMP agent
regarding the size of SNMP messages it can deal with. The max UDP dataram
size is 64K. Can the OTP SNMP agent handle SNMP messages of this size?

tia,
Chandru




From ulf.wiger@REDACTED  Sun Aug  8 19:06:23 1999
From: ulf.wiger@REDACTED (Ulf Wiger)
Date: Sun, 8 Aug 1999 19:06:23 +0200 (MET DST)
Subject: Concurrency problem
In-Reply-To: <87emhjl4pk.fsf@baked.vegetable.org>
Message-ID: <Pine.GSO.4.10.9908081901250.13633-100000@avc343>


One solution that I sometimes use is to store state data in ETS.
Say, for example (don't know if this fits your particular problem) that
A wants to make a "write" request to B, and B in the process wants to make
a "read" request to A, this can be solved by A storing readable values 
in a public or protected ETS table. This way, B can make a non-blocking
request and avoid deadlock.

To avoid creating a race condition instead, one should take case not to 
write to the ETS table from more than one process.

/Uffe

On 5 Aug 1999, Luke Gorrie wrote:

luke>Hi all,
luke>
luke>I'm wondering if someone can help me with a pattern for avoiding a
luke>deadlock.  Fundamentally, my problem is this:
luke>
luke>I have two gen_server processes, A and B.  A wants to make a call on
luke>B for the sake of the side-effects.  These side-effects involve making 
luke>calls to A.
luke>
luke>So, it seems to me that if A makes a gen_server:call to B, then when B 
luke>does the same back to A, it will get a cycle in the call graph and
luke>deadlock.  Now, it might seem that it's the inappropriate use of
luke>side-effects that's the problem, and that B should just return a value 
luke>for A to use, however I'm trying to follow an explicit mapping which
luke>has things this way.  Specifically, a corba Portable Object Adapter
luke>calling an AdapterActivator.
luke>
luke>Any help would be appreciated.  Infact, I'd love to some general
luke>information about managing things with Erlang's concurrency model, I'm 
luke>sure there are oodles of useful patterns - pointers would be great!
luke>
luke>Cheers,
luke>Luke
luke>
luke>
luke>

Ulf Wiger, Chief Designer AXD 301      <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuv?gen 9, ?lvsj?                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44



From luke@REDACTED  Sun Aug  8 21:34:40 1999
From: luke@REDACTED (Luke Gorrie)
Date: 09 Aug 1999 05:34:40 +1000
Subject: Mnesia deadlock detector
Message-ID: <87so5ugj73.fsf@baked.vegetable.org>

Hi all, me again,

I've been poking around with mnesia this time, and I've found some
strange behaviour apparently relating to deadlock detection.  I have a 
function which I'm using for transactions:

fun() -> mnesia:write(#test_rec{}) end

With: -record(test_rec, {id=1, date=now()}).

Running that function in mnesia:transaction/1 seems to take about
0.7ms on my machine.  However, when I run that function several times
concurrently the performance drops hugely.  It looks like Mnesia is
thinking there are deadlocks, because it cancels the transactions that 
miss out on the write lock, puts them to sleep for a random length of
time (I've experienced over 900ms), and then wakes them again (at
which point they seem to sleep/restart again if the lock isn't free).

Thought I'd report it incase it's a bug.  It sounds like
deadlock-avoidance behaviour, but all that's actually occuring here is 
contention for the write lock as far as I can tell.  Or maybe I'm
doing something silly. :-)

Code and output attached.  I'm using Mnesia 3.6.

Cheers,
Luke

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mnesia_deadlock.erl
URL: <http://erlang.org/pipermail/erlang-questions/attachments/19990809/a6f43694/attachment.ksh>
-------------- next part --------------

------------------------------------------------------------

Erlang (JAM) emulator version 47.4.1

Eshell V47.4.1  (abort with ^G)
(emacs@REDACTED)1> c("/home/luke/devel/erlang/mnesia_deadlock", [{outdir, "/home/luke/devel/erlang/"}]).
{ok,mnesia_deadlock}
(emacs@REDACTED)2> mnesia:start().
ok
(emacs@REDACTED)3> mnesia_deadlock:init().
{atomic,ok}
(emacs@REDACTED)4> mnesia_lib:set(debug, trace).
true
(emacs@REDACTED)5> mnesia_deadlock:run_test(3).
Mnesia('emacs@REDACTED'): ** ERROR ** mnesia_tm got local EXIT from unknown process: {<0.92.0>,
                                                                                                 normal}
Mnesia('emacs@REDACTED'): Restarting transaction {tid,16,<0.93.0>}: in 358ms {cyclic,'emacs@REDACTED',{test_rec,1},write,write,{tid,15,<0.92.0>}}
Mnesia('emacs@REDACTED'): Restarting transaction {tid,17,<0.94.0>}: in 359ms {cyclic,'emacs@REDACTED',{test_rec,1},write,write,{tid,15,<0.92.0>}}
Mnesia('emacs@REDACTED'): Restarting transaction {tid,17,<0.94.0>}: in 263ms {cyclic,'emacs@REDACTED',{test_rec,1},write,write,{tid,16,<0.93.0>}}
Mnesia('emacs@REDACTED'): ** ERROR ** mnesia_tm got local EXIT from unknown process: {<0.93.0>,
                                                                                                 normal}
ok
Mnesia('emacs@REDACTED'): ** ERROR ** mnesia_tm got local EXIT from unknown process: {<0.94.0>,
                                                                                                 normal}
(emacs@REDACTED)6> 

From dgud@REDACTED  Mon Aug  9 14:09:41 1999
From: dgud@REDACTED (Dan Gudmundsson)
Date: Mon, 9 Aug 1999 14:09:41 +0200 (MET DST)
Subject: Mnesia deadlock detector
In-Reply-To: <87so5ugj73.fsf@baked.vegetable.org>
References: <87so5ugj73.fsf@baked.vegetable.org>
Message-ID: <14254.50437.366497.358490@rian>

Hi Luke

You're right it is the deadlock avoidance algo. 
The lock will usally be queued but if that's not allowed 
(due to wrong order in transaction identifier)
the transaction will sleep for awhile and then be restarted.

The sleeping time has been decreased in mnesia 3.7 

/Dan

Luke Gorrie writes:
 > Hi all, me again,
 > 
 > I've been poking around with mnesia this time, and I've found some
 > strange behaviour apparently relating to deadlock detection.  I have a 
 > function which I'm using for transactions:
 > 
 > fun() -> mnesia:write(#test_rec{}) end
 > 
 > With: -record(test_rec, {id=1, date=now()}).
 > 
 > Running that function in mnesia:transaction/1 seems to take about
 > 0.7ms on my machine.  However, when I run that function several times
 > concurrently the performance drops hugely.  It looks like Mnesia is
 > thinking there are deadlocks, because it cancels the transactions that 
 > miss out on the write lock, puts them to sleep for a random length of
 > time (I've experienced over 900ms), and then wakes them again (at
 > which point they seem to sleep/restart again if the lock isn't free).
 > 
 > Thought I'd report it incase it's a bug.  It sounds like
 > deadlock-avoidance behaviour, but all that's actually occuring here is 
 > contention for the write lock as far as I can tell.  Or maybe I'm
 > doing something silly. :-)
 > 
 > Code and output attached.  I'm using Mnesia 3.6.
 > 
 > Cheers,
 > Luke
 > 
 > %%%----------------------------------------------------------------------
 > %%% File    : mnesia_deadlock.erl
 > %%% Author  : Luke Gorrie <luke@REDACTED>
 > %%% Purpose : Try to induce a lot of deadlocks into Mnesia to see if it'd
 > %%%           be useful to add "upgrade" locks.
 > %%% Created :  9 Aug 1999 by Luke Gorrie <luke@REDACTED>
 > %%%----------------------------------------------------------------------
 > 
 > -module(mnesia_deadlock).
 > -author('luke@REDACTED').
 > 
 > -record(test_rec, {id=1, date=now()}).
 > 
 > -export([init/0,run_test/1,cleanup/0, transaction/2]).
 > 
 > init() ->
 >     mnesia:create_table(test_rec,
 > 			[{attributes, record_info(fields, test_rec)}]),
 >     mnesia:transaction(fun() -> mnesia:write(#test_rec{}) end).
 > 
 > cleanup() ->
 >     mnesia:delete_table(test_rec).
 > 
 > run_test(N) ->
 >     Deadlocker =
 > 	fun() ->
 > 		mnesia:write(#test_rec{})
 > 	end,
 >     spawn_worker(N, Deadlocker),
 >     wait_responses(N).
 > 
 > spawn_worker(0, _F) ->
 >     ok;
 > spawn_worker(N, F) ->
 >     spawn_link(?MODULE, transaction, [self(), F]),
 >     %transaction(self(), F),
 >     spawn_worker(N-1, F).
 > 
 > wait_responses(0) ->
 >     ok;
 > wait_responses(N) ->
 >     receive
 > 	finished ->
 > 	    wait_responses(N-1)
 >     end.
 > 
 > transaction(Pid, F) ->
 >     {atomic, _} = mnesia:transaction(F),
 >     Pid ! finished.
 > 
 > 
 > ------------------------------------------------------------
 > 
 > Erlang (JAM) emulator version 47.4.1
 > 
 > Eshell V47.4.1  (abort with ^G)
 > (emacs@REDACTED)1> c("/home/luke/devel/erlang/mnesia_deadlock", [{outdir, "/home/luke/devel/erlang/"}]).
 > {ok,mnesia_deadlock}
 > (emacs@REDACTED)2> mnesia:start().
 > ok
 > (emacs@REDACTED)3> mnesia_deadlock:init().
 > {atomic,ok}
 > (emacs@REDACTED)4> mnesia_lib:set(debug, trace).
 > true
 > (emacs@REDACTED)5> mnesia_deadlock:run_test(3).
 > Mnesia('emacs@REDACTED'): ** ERROR ** mnesia_tm got local EXIT from unknown process: {<0.92.0>,
 >                                                                                                  normal}
 > Mnesia('emacs@REDACTED'): Restarting transaction {tid,16,<0.93.0>}: in 358ms {cyclic,'emacs@REDACTED',{test_rec,1},write,write,{tid,15,<0.92.0>}}
 > Mnesia('emacs@REDACTED'): Restarting transaction {tid,17,<0.94.0>}: in 359ms {cyclic,'emacs@REDACTED',{test_rec,1},write,write,{tid,15,<0.92.0>}}
 > Mnesia('emacs@REDACTED'): Restarting transaction {tid,17,<0.94.0>}: in 263ms {cyclic,'emacs@REDACTED',{test_rec,1},write,write,{tid,16,<0.93.0>}}
 > Mnesia('emacs@REDACTED'): ** ERROR ** mnesia_tm got local EXIT from unknown process: {<0.93.0>,
 >                                                                                                  normal}
 > ok
 > Mnesia('emacs@REDACTED'): ** ERROR ** mnesia_tm got local EXIT from unknown process: {<0.94.0>,
 >                                                                                                  normal}
 > (emacs@REDACTED)6> 

-- 
Dan Gudmundsson               Project:    Mnesia, Erlang/OTP
Ericsson Utvecklings AB       Phone:      +46  8 727 5762 
UAB/F/P                       Mobile:     +46 70 519 9469
S-125 25 Stockholm            Visit addr: Armborstv 1 



From vlad.dumitrescu@REDACTED  Sat Aug 14 09:59:17 1999
From: vlad.dumitrescu@REDACTED (Vlad Dumitrescu)
Date: Sat, 14 Aug 1999 09:59:17 +0200
Subject: mnesia databases
Message-ID: <93461775302@flashmail.com>

Hi!
Can one have several databases open in mnesia at the same time? 
It seems to me that since the database dir is specified as 
command line argument, there can be only one database per node. 
Is that true?

All the best.
/Vlad


From mbj@REDACTED  Mon Aug 16 09:12:27 1999
From: mbj@REDACTED (Martin Bjorklund)
Date: Mon, 16 Aug 1999 09:12:27 +0200
Subject: OTP SNMP agent
In-Reply-To: Your message of "Fri, 06 Aug 1999 10:34:56 +0100"
	<37AAAC40.E9E70A99@eei.ericsson.se>
References: <37AAAC40.E9E70A99@eei.ericsson.se>
Message-ID: <19990816091227Q.mbj@bluetail.com>

Chandrashekhar <eeicmui@REDACTED> wrote:
> Hi,
> 
>   I have a doubt about the Atomic SET transaction mechanism
>   in the SNMP agent.
>   Suppose I want to modify multiple rows in a single 
>   SET request. I then must write is_set_ok, and undo
>   operations for this table, right?

Right.  But unless the is_set_ok function modifies some state, you
don't need the undo function.

>   The sequence will be:
>     * For each row call is_set_ok.
>     * If any one of them returns {error, Column}, then call
>       undo for each of the previous ones and return error to Manager.
>     * If all succeed, return success.
> 
>   Pls. let me know if I'm correct.

This is correct.

However, there is an (undocumented) feature you can use to change this
behaviour.  Which SET transaction mechanism to use is configurable -
you can write your own set mechanism if you don't like the default
one.  Check the code for details.


/martin


From dgud@REDACTED  Mon Aug 16 09:43:18 1999
From: dgud@REDACTED (Dan Gudmundsson)
Date: Mon, 16 Aug 1999 09:43:18 +0200 (MET DST)
Subject: mnesia databases
In-Reply-To: <93461775302@flashmail.com>
References: <93461775302@flashmail.com>
Message-ID: <14263.49430.727228.129130@rian>


Hi 

That is correct, mnesia can only handle one database per 
erlang node.

/Dan

Vlad Dumitrescu writes:
 > Hi!
 > Can one have several databases open in mnesia at the same time? 
 > It seems to me that since the database dir is specified as 
 > command line argument, there can be only one database per node. 
 > Is that true?
 > 
 > All the best.
 > /Vlad



From mbj@REDACTED  Mon Aug 16 15:29:21 1999
From: mbj@REDACTED (Martin Bjorklund)
Date: Mon, 16 Aug 1999 15:29:21 +0200
Subject: Max SNMP message
In-Reply-To: Your message of "Sun, 8 Aug 1999 12:46:58 +0100"
	<000b01bee193$b9c09240$6d8791c2@sharmila>
References: <000b01bee193$b9c09240$6d8791c2@sharmila>
Message-ID: <19990816152921J.mbj@bluetail.com>

"Chandru" <chandru@REDACTED> wrote:
> Hi,
> 
>   I was wondering if there was any limitation on the OTP SNMP agent
> regarding the size of SNMP messages it can deal with. The max UDP dataram
> size is 64K. Can the OTP SNMP agent handle SNMP messages of this size?

Yes - There is no limit internally in the SNMP agent.


/martin



From luke@REDACTED  Tue Aug 17 00:18:30 1999
From: luke@REDACTED (Luke Gorrie)
Date: 17 Aug 1999 08:18:30 +1000
Subject: Erlang programming environments
Message-ID: <87907bnzd5.fsf@baked.vegetable.org>

Hi all,

I'm wondering if anyone could recommend any programming environments
for Erlang other than Emacs.  Maybe some of those fancy Windows
editors have some Erlang extensions?

-- 
Cheers,
Luke the Blasphemous




From tobbe@REDACTED  Tue Aug 17 01:29:22 1999
From: tobbe@REDACTED (Torbjorn Tornkvist)
Date: Tue, 17 Aug 1999 09:29:22 +1000
Subject: Erlang programming environments 
In-Reply-To: <87907bnzd5.fsf@baked.vegetable.org> 
References: <87907bnzd5.fsf@baked.vegetable.org>
Message-ID: <199908162329.JAA01281@campari.serc.rmit.edu.au>


> I'm wondering if anyone could recommend any programming environments
> for Erlang other than Emacs.  Maybe some of those fancy Windows
> editors have some Erlang extensions?

Sorry, but I don't think so. The guys behind Erlang are all
heavy Emacs users so there has never existed a reason for 
something else ;-) A long time ago, there existed a very simple
"integrated" environment built on top of Athena widgets. It was
mainly used during courses as a replacement for Sun's Textedit
(which some students used...). It had a similar look as the debugger.
If you fancy 'vi' (yuck !), I know there at least exist a coloring
mode for Erlang.

/Tobbe


From luke@REDACTED  Tue Aug 17 02:21:48 1999
From: luke@REDACTED (Luke Gorrie)
Date: 17 Aug 1999 10:21:48 +1000
Subject: Erlang programming environments
In-Reply-To: Torbjorn Tornkvist's message of "Tue, 17 Aug 1999 09:29:22 +1000"
References: <87907bnzd5.fsf@baked.vegetable.org> <199908162329.JAA01281@campari.serc.rmit.edu.au>
Message-ID: <87lnbbl0ir.fsf@baked.vegetable.org>

Torbjorn Tornkvist <tobbe@REDACTED> writes:

> > I'm wondering if anyone could recommend any programming environments
> > for Erlang other than Emacs.  Maybe some of those fancy Windows
> > editors have some Erlang extensions?
> 
> Sorry, but I don't think so. The guys behind Erlang are all
> heavy Emacs users so there has never existed a reason for 
> something else ;-)

What a great bit of history.  I'll just be more selective about who I
evangelise Erlang to. ;-)

Cheers,
Lukerlang




From eeicmui@REDACTED  Tue Aug 17 15:00:15 1999
From: eeicmui@REDACTED (Chandrashekhar)
Date: Tue, 17 Aug 1999 14:00:15 +0100
Subject: SNMP agent
Message-ID: <37B95CDF.4DB89C03@eei.ericsson.se>

Hi,

  Suppose two erlang nodes are active on the same machine and
  both have SNMP app active on them, and both these apps use
  the same SNMP configuration. If a request arrives, will both
  of these nodes act on it?? Assuming both have loaded the same
  MIB.bin files.

tia,
Chandru

-- 
Random Wodehouse Quote

I was behind the desk, crouching on the carpet and trying to
breathe solely through the pores.

Thank You, Jeeves, 1934


From per@REDACTED  Wed Aug 18 00:17:28 1999
From: per@REDACTED (Per Hedeland)
Date: Wed, 18 Aug 1999 00:17:28 +0200 (MET DST)
Subject: Erlang programming environments
Message-ID: <199908172217.AAA16587@super.du.uab.ericsson.se>

Luke Gorrie <luke@REDACTED> wrote:
>
>Torbjorn Tornkvist <tobbe@REDACTED> writes:
>
>> > I'm wondering if anyone could recommend any programming environments
>> > for Erlang other than Emacs.  Maybe some of those fancy Windows
>> > editors have some Erlang extensions?
>> 
>> Sorry, but I don't think so. The guys behind Erlang are all
>> heavy Emacs users so there has never existed a reason for 
>> something else ;-)
>
>What a great bit of history.  I'll just be more selective about who I
>evangelise Erlang to. ;-)

Well, Tobbe *did* put a smiley in there:-) - of course there has been
many reasons for something else (which is why the "xerl" was produced),
the problem seems to be that people don't want Erlang to come with a
programming environment, they want Erlang to fit into the programming
environment they already have.

I.e. it isn't a whole lot the "core" Erlang developers can do about it,
except preach the virtues of Erlang and hope that enough people demand
an "Erlang mode" for their favorite programming environment as a
result.:-) Anyway, in case you find something, please share the info.

--Per Hedeland
per@REDACTED



From mbj@REDACTED  Wed Aug 18 11:27:35 1999
From: mbj@REDACTED (Martin Bjorklund)
Date: Wed, 18 Aug 1999 11:27:35 +0200
Subject: SNMP agent
In-Reply-To: Your message of "Tue, 17 Aug 1999 14:00:15 +0100"
	<37B95CDF.4DB89C03@eei.ericsson.se>
References: <37B95CDF.4DB89C03@eei.ericsson.se>
Message-ID: <19990818112735B.mbj@bluetail.com>

Chandrashekhar <eeicmui@REDACTED> wrote:
> Hi,
> 
>   Suppose two erlang nodes are active on the same machine and
>   both have SNMP app active on them, and both these apps use
>   the same SNMP configuration. If a request arrives, will both
>   of these nodes act on it?? Assuming both have loaded the same
>   MIB.bin files.

No; since a single UDP port cannot be shared between two
OS-processes, you can't start two agents on the same host,
using the same UDP port.


/martin


From eeicmui@REDACTED  Wed Aug 18 12:24:13 1999
From: eeicmui@REDACTED (Chandrashekhar)
Date: Wed, 18 Aug 1999 11:24:13 +0100
Subject: SNMP agent
References: <37B95CDF.4DB89C03@eei.ericsson.se> <19990818112735B.mbj@bluetail.com>
Message-ID: <37BA89CD.C1B59F8C@eei.ericsson.se>

Martin Bjorklund wrote:
> 
> Chandrashekhar <eeicmui@REDACTED> wrote:
> > Hi,
> >
> >   Suppose two erlang nodes are active on the same machine and
> >   both have SNMP app active on them, and both these apps use
> >   the same SNMP configuration. If a request arrives, will both
> >   of these nodes act on it?? Assuming both have loaded the same
> >   MIB.bin files.
> 
> No; since a single UDP port cannot be shared between two
> OS-processes, you can't start two agents on the same host,
> using the same UDP port.

Yes - thats what I could expected. But I could start two nodes
as I have described above. I started two erlang nodes and started
snmp on both of them using the same configuration. I'm stumped.

regards,
Chandru

-- 
Random Wodehouse Quote

`You are probably not familiar with the inner workings of a paper like
Society Spice, Sir Gregory, but I may tell you that it is
foreign to the editorial policy ever to meet visitors who call with
horsewhips.' 

Summer Lightning (1929)


From ng@REDACTED  Thu Aug 19 14:41:18 1999
From: ng@REDACTED (Mark NG)
Date: Thu, 19 Aug 1999 22:41:18 +1000
Subject: C <-> Erlang with IC
Message-ID: <19990819224118.A22590@snipsnap.edfac.unimelb.edu.au>

G'day,

I am trying to export some C functions to Erlang and at the same time getting
those C functions to invoke Erlang functions in the same program. Like that
of the calback functions.  How can this be done in IC ?? if possible at all...


thanks,
mark



From dsolaz@REDACTED  Wed Aug 18 14:04:24 1999
From: dsolaz@REDACTED (Daniel Solaz)
Date: Wed, 18 Aug 1999 14:04:24 +0200
Subject: Erlang programming environments
References: <87907bnzd5.fsf@baked.vegetable.org> <199908162329.JAA01281@campari.serc.rmit.edu.au>
Message-ID: <37BAA148.D6F1CF4D@sistelcom.com>

Torbjorn Tornkvist wrote:
>If you fancy 'vi' (yuck !), I know there at least exist a coloring
>mode for Erlang.
Since I didn't bother to check, I don't know if there already exists
one somewhere, but I've got a nedit mode for Erlang.  I did it on my own
as I was learning the language and it's just syntax highlighting, no
macros.  But I think it is quite useful... IF you use nedit, of course.
Anyone interested just ask me for it.  I'll email it to whoever wants
it.
-Daniel




From tobbe@REDACTED  Thu Aug 19 16:12:29 1999
From: tobbe@REDACTED (Torbjorn Tornkvist)
Date: Fri, 20 Aug 1999 00:12:29 +1000
Subject: C <-> Erlang with IC 
In-Reply-To: <19990819224118.A22590@snipsnap.edfac.unimelb.edu.au> 
References: <19990819224118.A22590@snipsnap.edfac.unimelb.edu.au>
Message-ID: <199908191412.AAA01625@campari.serc.rmit.edu.au>


> I am trying to export some C functions to Erlang and at the same time getting
> those C functions to invoke Erlang functions in the same program. Like that
> of the calback functions.  How can this be done in IC ?? if possible at all...

Sorry, I know I shouldn't promote IG (since it is obsolete) but
I can't help myself. Actually I would also be interested in how
you would do it with IC. Anyway, here is how you do it with IG:

example.h
--------------------------------------------------------------
#ifndef _EXAMPLE_H
#define _EXAMPLE_H

#include <stdio.h>

#ifdef HIDE

/*
 * C functions we want to call from Erlang
 */
IG_fun FILE *fopen(IG_string path, IG_string mode);
IG_fun int fclose( FILE *);

#endif

#endif
--------------------------------------------------------------

Run this through IG:  

 erl-shell> ig:gen(example).

Compile the result:

 gcc -ansi -pedantic -Wall \
  -I /usr/local/lib/erlang/usr/include \
  -L /usr/local/lib/erlang/usr/lib \
  -o example example_stub.c \
  /usr/local/lib/erlang/usr/lib/igio.o \
  /usr/local/lib/erlang/usr/lib/igmain.o -lerl_interface

 erlc example.erl

Now you can call those functions from Erlang:
--------------------------------------------------------------
23:57 ~/junk> ls
example*        example.beam    example.erl     example.h       example_stub.c  
23:57 ~/junk> erl
Erlang (BEAM) emulator version 47.4.1
 
Eshell V47.4.1  (abort with ^G)
1> S=example:start().
<0.30.0>
2> {ok,Fd} = example:fopen(S,"TOUCH_ME","wb").
{ok,134618608}
3> example:fclose(S,Fd).
{ok,0}
4> 
BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded
       (v)ersion (k)ill (D)b-tables (d)istribution
a
23:58 ~/junk> ls
TOUCH_ME        example*        example.beam    example.erl     example.h       example_stub.c  
23:58 ~/junk> 
--------------------------------------------------------------

To call an Erlang function from C is a bit more complicated,
but basically: add the following to example.h:
--------------------------------------------------------------
/*
 * Erlang function we want to call from C
 */

typedef struct {  /* First a data type to store    */
  int hour;       /* the result from erlang:time/0 */ 
  int minute;
  int second;
} etime;

IG_call etime get_etime(void);
--------------------------------------------------------------

Run IG again. This time you will also get an 'example.hrl' out
from IG. As per default, IG will assume you are implementing
your callback Erlang functions in example_cb.erl, so create
this file:
--------------------------------------------------------------
-module(example_cb).
-export([get_etime/1]).

-include("example.hrl").

get_etime(_Pid) -> 
    {H,M,S} = time(),
    #etime{hour = H, minute = M, second = S}.
--------------------------------------------------------------

The hardest part is to write a C program that can trigger
this code. I leave this as an exercise for you... ;-)

Cheers /Tobbe




From ng@REDACTED  Fri Aug 20 14:24:02 1999
From: ng@REDACTED (Mark NG)
Date: Fri, 20 Aug 1999 22:24:02 +1000
Subject: C <-> Erlang with IC
In-Reply-To: <199908191412.AAA01625@campari.serc.rmit.edu.au>; from Torbjorn
 Tornkvist on Fri, Aug 20, 1999 at 12:12:29AM +1000
References: <19990819224118.A22590@snipsnap.edfac.unimelb.edu.au>
 <199908191412.AAA01625@campari.serc.rmit.edu.au>
Message-ID: <19990820222402.A29442@snipsnap.edfac.unimelb.edu.au>

On Fri, Aug 20, 1999 at 12:12:29AM +1000, Torbjorn Tornkvist wrote:
> 
> Sorry, I know I shouldn't promote IG (since it is obsolete) but

I have played with it a bit, and like it more than IC for some
tasks. :)


> I can't help myself. Actually I would also be interested in how
> you would do it with IC. Anyway, here is how you do it with IG:
> 

<example snipped>

Thanks for the example, but I am really after is something like
where I can pass a lambda to a C function and get that C function
to invoke this piece of Erlang code. 

The IC manual has examples on how to call "static" Erlang functions 
from C, but not dynamic ones.


mark


From dgud@REDACTED  Fri Aug 20 15:49:42 1999
From: dgud@REDACTED (Dan Gudmundsson)
Date: Fri, 20 Aug 1999 15:49:42 +0200 (MET DST)
Subject: C <-> Erlang with IC
In-Reply-To: <19990820222402.A29442@snipsnap.edfac.unimelb.edu.au>
References: <19990819224118.A22590@snipsnap.edfac.unimelb.edu.au>
	<199908191412.AAA01625@campari.serc.rmit.edu.au>
	<19990820222402.A29442@snipsnap.edfac.unimelb.edu.au>
Message-ID: <14269.23798.443987.257913@rian>


Something like this should be doable I guess.

Define in IDL:
#include <erlang.idl>

module dynamic
{
 interface dyn_erl
  {
    Status erlApply(in string module, 
               in string function, 
               in erlang::term listOfArgs,
               in out erlang::term res);
  }
}


And in the erlang callback module: 

erl_apply(State, Mod, Fun, Args) ->
   case catch apply(list_to_atom(Mod), 
                    list_to_atom(Fun), Args) of
        {'EXIT', R} -> 
	    {reply, {error, []}, State}};
	Result -> 
	    {reply, {ok, Result}, State}}
  end.

In 'C' the call would look something like 

   ETERM * result, empty;
   empty  = erl_mk_empty_list();
   status = dynamic_erlApply(NULL, "erlang", "date", empty, &result, env);

See the erl_interface doc about handling erlang data types in C.

/Dan

Mark NG writes:
 > On Fri, Aug 20, 1999 at 12:12:29AM +1000, Torbjorn Tornkvist wrote:
 > > 
 > > Sorry, I know I shouldn't promote IG (since it is obsolete) but
 > 
 > I have played with it a bit, and like it more than IC for some
 > tasks. :)
 > 
 > 
 > > I can't help myself. Actually I would also be interested in how
 > > you would do it with IC. Anyway, here is how you do it with IG:
 > > 
 > 
 > <example snipped>
 > 
 > Thanks for the example, but I am really after is something like
 > where I can pass a lambda to a C function and get that C function
 > to invoke this piece of Erlang code. 
 > 
 > The IC manual has examples on how to call "static" Erlang functions 
 > from C, but not dynamic ones.
 > 
 > 
 > mark
 > 

-- 
Dan Gudmundsson               Project:    Mnesia, Erlang/OTP
Ericsson Utvecklings AB       Phone:      +46  8 727 5762 
UAB/F/P                       Mobile:     +46 70 519 9469
S-125 25 Stockholm            Visit addr: Armborstv 1 



From nisse@REDACTED  Tue Aug 24 10:34:09 1999
From: nisse@REDACTED (Niels Möller)
Date: 24 Aug 1999 10:34:09 +0200
Subject: Garbage collection algorithms
Message-ID: <nnr9kty3um.fsf@sanna.lysator.liu.se>

Hello,

I'm a little curious about the garbage collection used in Erlang. The
question arose in a discussing about using Erlang on "real-time"
systems. Do you use some fancy incremental or real-time collector?

I'm mostly ignorant of the Erlang language, but I'm interesting in how
GC is being used in the Real World(tm).

Regards,
/Niels M?ller


From klacke@REDACTED  Tue Aug 24 12:21:09 1999
From: klacke@REDACTED (Klacke)
Date: Tue, 24 Aug 1999 12:21:09 +0200
Subject: Garbage collection algorithms
In-Reply-To: <nnr9kty3um.fsf@sanna.lysator.liu.se> (nisse@lysator.liu.se)
References: <nnr9kty3um.fsf@sanna.lysator.liu.se>
Message-ID: <199908241021.MAA04920@duva.bluetail.com>



> I'm a little curious about the garbage collection used in Erlang. The
> question arose in a discussing about using Erlang on "real-time"
> systems. Do you use some fancy incremental or real-time collector?
> 
> I'm mostly ignorant of the Erlang language, but I'm interesting in how
> GC is being used in the Real World(tm).
> 

GC in Erlang is done by a generational collector _per process_.
Each process has its own stack and two heaps, (2 generations)
Once a GC is needed for a process, either a generational or a 
fullsweap collection is performed on that process.

No real time characteristcs are achieved at all since a single process
can grow arbitrarily large. However GC time is bounded by the
size of the largest process in the system. This is dynamic and thus
no *real* real time characteristcs at all.

The generational algorithm applied is classical cheeney but with
two generations. This algorithm is from the mid 60'ies !! i think.


/klacke

Claes Wikstr?m                          Tel: +46 (0)8 692 22 09
Bluetail AB                             Email: klacke@REDACTED
Hantverkargatan 78                      WWW: http://www.bluetail.com
SE-112 38 Stockholm, SWEDEN





From jim@REDACTED  Tue Aug 24 17:59:28 1999
From: jim@REDACTED (Jim Larson)
Date: Tue, 24 Aug 1999 08:59:28 -0700
Subject: Sun ONC/RPC library and stub generator?
Message-ID: <199908241559.IAA14639@lefse.jetcafe.org>

Is anyone (else) working on a library and stub generator for
Sun's ONC/RPC?  Alternately, does anyone have a low-level NFS
client-side library implementation in Erlang?

Jim


From kenneth@REDACTED  Wed Aug 25 11:33:49 1999
From: kenneth@REDACTED (Kenneth Lundin)
Date: Wed, 25 Aug 1999 11:33:49 +0200
Subject: Join us in the development of Erlang/OTP
Message-ID: <37C3B87C.5E365FF3@erix.ericsson.se>

--------------------------------------------------------------------------------------------------------------------------------------

Join us and develop Erlang/OTP,
Ericsson's software platform based on the programming language Erlang
--------------------------------------------------------------------------------------------------------------------------------------

Open Telecom Platform, Product Development is an unit within the
department Open Systems at Rescan Utvecklings AB and consists today of
20 employees. We develop, among other things, Erlang/OTP, a software
platform aimed for developing of telecom systems. Erlang/OTP is used in
several Ericsson products.

Erlang/OTP is mainly based on the programming language Erlang and can
work on a several operating systems, as Solaris, Windows-NT/95/98,
Linux, and VxWorks.

Erlang is developed by Ericsson and is a functional programming language
well suited for development of robust systems with many parallel
communicating processes, typical for telecom applications.

Erlang/OTP is since 1998 available as Open Source and large interest has
been shown from programmers, even outside Ericsson.

The development of Erlang/OTP is going on in small teams with fast
decissions paths and minimums of administrative over-head.
All team-members are involved in the whole chain of development, as
systemizing, implementation, integration, and test.
The small teams conduce to a creative environment, where own initiatives
are encouraged.

The working environment is mostly Sun work stations with a number of PCs
added for Windows-NT, Linux etc.

Beside Erlang, the programming language C is used.

Our unit needs now strengthening of a number of positions (long term
local employment):

- Support, testing  and further development of Erlang/OTP on Windows
NT/98 (and W 2000).
- Further development and maintenance of our automatic test system
(implemented in Erlang).
- Customer support and production of upgraded packages with fault
corrections.
- Further development and support of Erlang/OTP giving you several
interesting possibilities due to your interests and competence. Some
examples are SNMP, HHTP-server, ASN.1 compiler, databases, and Corba.

The applicant should comply with some of the following points:
- You have some years experience of industrial software programming
projects
- You have a degree from an University within the field computer science
or equivalent competence
- You like programming and have good skills
- You have a good command of, and like to work with different
programming languages.
- You like to work independently and to take responsibilities for the
whole development chain of a software component
- You are time and cost oriented

Are you interested? You can get more information from:

Kenneth Lundin, Manager Phone: +46 8 727 5725
        e-mail: Kenneth@REDACTED
Gunilla Hugosson, Project Manager Phone +46 8 727 5730
        e-mail: gunilla@REDACTED
Magnus Karlsson, Product Manager Phone: +46 8 727 5730
        e-mail: mk@REDACTED


--
Kenneth Lundin              Ericsson Utvecklings AB
kenneth@REDACTED     ?T2/UAB/F/P
                            BOX 1505
+46 8 727 5725             125 25 ?lvsj?





From Bruce@REDACTED  Wed Aug 25 19:07:17 1999
From: Bruce@REDACTED (Bruce Fitzsimons)
Date: Wed, 25 Aug 1999 19:07:17 +0200
Subject: Toolbar in ETK
Message-ID: <000001beef1c$4cdb0f20$5be879c3@noddy.nl.unisys.com>

Hello,

I've started changing the toolbar app to use ETK instead of GS. Not because
I find it the killer application of Erlang, but its a nice simple app to
learn on.

I'm pulling out the "add GS items to menu" option, and I'm also going to do
something different with the help option (help, and help about help) as it
seems to be calling a non-existent module (tool_utils). I'm not sure if HTML
help can be implemented in a portable way though...suggestions are welcome.

Reasonable new feature requests will be considered, but don't expect wonders
from my first project.

Cheers,
Bruce

PS Is there a protocol for submitting enhancements to the OTP package? After
I've finished testing do I just mail it off to the erlang.org moderator like
a user contrib?



From vlad.dumitrescu@REDACTED  Fri Aug 27 10:26:38 1999
From: vlad.dumitrescu@REDACTED (Vlad Dumitrescu)
Date: Fri, 27 Aug 1999 00:26:38 -800
Subject: Garbage collection
Message-ID: <37c63dae.173.0@flashmail.com>

Hi!

On the "to do" list at erlang.org lies also an item about improving the garbage
collector. 

The question is whether the Boehm-Weiser could collector be used. It is a good
one, tested and free. On the right platforms, it offers incremental collection,
thus reducing the danger of a big process freezing the others while collecting.


There must be a reason for not using it, I don't imagine no one else thought
about that.


/Vlad
______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!


From klacke@REDACTED  Fri Aug 27 10:49:13 1999
From: klacke@REDACTED (Klacke)
Date: Fri, 27 Aug 1999 10:49:13 +0200 (CEST)
Subject: Garbage collection
In-Reply-To: <37c63dae.173.0@flashmail.com>
References: <37c63dae.173.0@flashmail.com>
Message-ID: <14278.20745.886840.764062@kricka.bluetail.com>



 > 
 > The question is whether the Boehm-Weiser could collector be used. It is a good
 > one, tested and free. On the right platforms, it offers incremental collection,
 > thus reducing the danger of a big process freezing the others while collecting.
 > 
 > 
 > There must be a reason for not using it, I don't imagine no one else thought
 > about that.
 > 


Well we have discussed using that sort of conservative collector
as well. We only talked about it a couple of years ago but as far as
I know nobody ever did any experiments with the Boehm collector.

It does however require a pretty extensive rewrite of the runtime
since it's a malloc/free plugin replacement. I also think that it would
be pretty slow for erlang since the absolute majority of allocations
in erlang is the allocation of a cons cell.

Allocating a cons is done as:

uint32 *mem = p->htop;
p->htop += 2;

This is fast, if the Boehm collector should be used, we
need to replace this with:

uint32 *mem = (uint32*) malloc(2);

which is slow, extremely slow.

However I'm not discarding the idea entirely, maybe the 
Boehm colect together with some hacks to do fast allocate
cons cells is good. I really don't know and it would take
a couple of months of hard work to find out.


/klacke






From vlad.dumitrescu@REDACTED  Fri Aug 27 12:01:47 1999
From: vlad.dumitrescu@REDACTED (Vlad Dumitrescu)
Date: Fri, 27 Aug 1999 02:01:47 -800
Subject: Garbage collection
Message-ID: <37c653fb.133.0@flashmail.com>

Hi!

I will try to look closer at the existing collector... it is an interesting
area. Difficult, but worth trying, I think. Only I have the time! :-)

>Allocating a cons is done as:
>
>uint32 *mem = p->htop;
>p->htop += 2;
>
>This is fast, 

The allocation is fast, but the collection will be slower!

> if the Boehm collector should be used, we
>need to replace this with:
>
>uint32 *mem = (uint32*) malloc(2);
>
>which is slow, extremely slow.

true, but the extra time is distributed, instead of a long collection phase.
Besides, as you say, hacks can be used - line allocating a bunch of cells at
once, instead of one by one.

In the end, since there is no "one size fits all" solution to GC, it depends
a lot on the way typical applications/processes use memory...

/Vlad
______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!


From etxuwig@REDACTED  Fri Aug 27 11:57:38 1999
From: etxuwig@REDACTED (Ulf Wiger)
Date: Fri, 27 Aug 1999 11:57:38 +0200 (MET DST)
Subject: Garbage collection
In-Reply-To: <37c653fb.133.0@flashmail.com>
Message-ID: <Pine.GSO.4.10.9908271150070.29088-100000@avc343>

On Fri, 27 Aug 1999, Vlad Dumitrescu wrote:

vlad.d>Hi!
vlad.d>
vlad.d>I will try to look closer at the existing collector... it is
vlad.d>an interesting area. Difficult, but worth trying, I think.
vlad.d>Only I have the time! :-)

One thing you could consider is making the per-process GC reentrant. This
would be a significant improvement of the system real-time characteristics.

If you could divide the collection in a couple of (perhaps 2-4) discrete
phases, between which the process could be suspended and rescheduled, this
would be a significant improvement.

Another tiny detail would be to check the reduction counter before starting
a GC -- if it's > 400, yield first, then GC. As it is implemented now, a
process could run its entire timeslice and then start a costly GC on the
500th reduction.

/Uffe

Ulf Wiger, Chief Designer AXD 301      <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuv?gen 9, ?lvsj?                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44



From bjarne@REDACTED  Fri Aug 27 12:57:57 1999
From: bjarne@REDACTED (Bjarne Däcker)
Date: 27 Aug 1999 12:57:57 +0200
Subject: Invitation to Erlang User Conference
Message-ID: <qyso55v6bu.fsf@erix.ericsson.se>

Dear Erlang friends

Your are all invited to the 5th International
Erlang User Conference which will take place
on September 30 here in Stockholm. Please
see the enclosed programme.

http://www.erlang.se/erlang/sure/main/news/euc99.shtml

The registration form can be found in

http://www.erlang.org/invitation_euc99.html

Welcome 

Bjarne D?cker
Computer Science Laboratory
Ericsson Utvecklings AB
Box 1505
S-125 25 ?lvsj? - Stockholm
Sweden


tel +46 8 727 5776


From vlad.dumitrescu@REDACTED  Fri Aug 27 14:55:18 1999
From: vlad.dumitrescu@REDACTED (Vlad Dumitrescu)
Date: Fri, 27 Aug 1999 04:55:18 -800
Subject: Garbage collection
Message-ID: <37c67ca6.183.0@flashmail.com>

Thanks Ulf!

I am not yet commited into seriously undertaking this project, but any help
is welcomed!

What I had in mind was using the kind of GC that ISE Eiffel is using. Of course,
their details are not published, but the GC is a more or less a background process
that tries to collect incrementally whenever it has the opportunity. If the
user can adjust the sensibility of the GC, in order to tune it with the needs
of the particular application, then it might be a good solution even for Erlang.


I think that there are many things to be done to adapt a GC algorithm to the
specifics of Erlang. Some might need some help from the compiler (for example,
tagging pure functional calls for optimizing local variable collection). 

/Vlad
______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!


From vlad.dumitrescu@REDACTED  Fri Aug 27 14:57:59 1999
From: vlad.dumitrescu@REDACTED (Vlad Dumitrescu)
Date: Fri, 27 Aug 1999 04:57:59 -800
Subject: JAM/BEAM documentation
Message-ID: <37c67d47.ef.0@flashmail.com>

Is there any available documentation about JAM design, bytecode instructions,
and so on - besides what's in the source code? BEAM is not so interesting for
me right now, as it doesn't work on Win32.

/Vlad
______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!


From vlad.dumitrescu@REDACTED  Fri Aug 27 16:02:05 1999
From: vlad.dumitrescu@REDACTED (Vlad Dumitrescu)
Date: Fri, 27 Aug 1999 06:02:05 -800
Subject: optimizing code
Message-ID: <37c68c4d.195.0@flashmail.com>

I just found Erik Johanssons and Christer Jonssons thesis "Native code compilation
for Erlang". It is an interesting study, and I have a couple of questions.

- is their compiler freely available? or is it commercial?

- could not a part of the optimizations they do, already be made in JAM? for
example, constant propagation... Or maybe it is now done (considering their
paper is from '96)?

regards,
/Vlad
______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!


From dg@REDACTED  Fri Aug 27 17:59:32 1999
From: dg@REDACTED (David Gould)
Date: Fri, 27 Aug 1999 08:59:32 -0700
Subject: Garbage collection
In-Reply-To: <37c653fb.133.0@flashmail.com>; from Vlad Dumitrescu on Fri, Aug 27, 1999 at 02:01:47AM +0000
References: <37c653fb.133.0@flashmail.com>
Message-ID: <19990827085932.A16043@hawk.oak.informix.com>

On Fri, Aug 27, 1999 at 02:01:47AM +0000, Vlad Dumitrescu wrote:
> Hi!
> 
> I will try to look closer at the existing collector... it is an interesting
> area. Difficult, but worth trying, I think. Only I have the time! :-)
> 
> >Allocating a cons is done as:
> >
> >uint32 *mem = p->htop;
> >p->htop += 2;

And also:

   if (p->htop >= p->maxhtop)
	gc(p);
Or however it gets coded.


> >This is fast, 
> 
> The allocation is fast, but the collection will be slower!
> 
> > if the Boehm collector should be used, we
> >need to replace this with:
> >
> >uint32 *mem = (uint32*) malloc(2);
> >
> >which is slow, extremely slow.

Uh no. The Boehm collector allocation is quite fast. Allocation gets inlined
as approximately:

 if (freelist[size]) {
     /* fast path allocation */
     mem = freelist[size];
     freelist[size] = *mem;
 } else
      /* possibly need to gc */
      gen_malloc(size);

Which is not that slow.

-dg

-- 
David Gould           dg@REDACTED            510.628.3783 or 510.305.9468 
Informix Software                       300 Lakeside Drive  Oakland, CA 94612
You will cooperate with Microsoft, for the good of Microsoft
and for your own survival.                 -- Navindra Umanee



From jhague@REDACTED  Fri Aug 27 20:15:39 1999
From: jhague@REDACTED (James Hague)
Date: Fri, 27 Aug 1999 13:15:39 -0500 (CDT)
Subject: Garbage collection
In-Reply-To: <19990827085932.A16043@hawk.oak.informix.com>
Message-ID: <Pine.LNX.3.96.990827130852.2647A-100000@babba.advancenet.net>

Isn't the goal of the Boehm collector to work with systems that otherwise
don't "understand" garbage collection on a fundamental level?  What's the
purpose of such a collector in a language where all datatypes are already
tagged?

James



From dg@REDACTED  Fri Aug 27 20:55:44 1999
From: dg@REDACTED (David Gould)
Date: Fri, 27 Aug 1999 11:55:44 -0700
Subject: Garbage collection
In-Reply-To: <Pine.LNX.3.96.990827130852.2647A-100000@babba.advancenet.net>; from James Hague on Fri, Aug 27, 1999 at 01:15:39PM -0500
References: <19990827085932.A16043@hawk.oak.informix.com> <Pine.LNX.3.96.990827130852.2647A-100000@babba.advancenet.net>
Message-ID: <19990827115544.A16294@hawk.oak.informix.com>

On Fri, Aug 27, 1999 at 01:15:39PM -0500, James Hague wrote:
> Isn't the goal of the Boehm collector to work with systems that otherwise
> don't "understand" garbage collection on a fundamental level?  What's the
> purpose of such a collector in a language where all datatypes are already
> tagged?

Yes, the Boehm collector is a conservative collector intended to work 
without type information. However, it can use type information if it is
available, and the lack of type information is not so much a hindrance as
one might suppose. The advantage of the Boehm collector is maturity of
development and wide use.

There is also an open question as to whether a copying collector as apparently
Erlang uses is better or worse than a mark-sweep collector on modern cache
intensive hardware. 

For a good discussion of this check out http://reality.sgi.com/boehm/gc.html.

-dg


-- 
David Gould           dg@REDACTED            510.628.3783 or 510.305.9468 
Informix Software                       300 Lakeside Drive  Oakland, CA 94612
You will cooperate with Microsoft, for the good of Microsoft
and for your own survival.                 -- Navindra Umanee



From ug-erlang@REDACTED  Fri Aug 27 21:33:26 1999
From: ug-erlang@REDACTED (David Brown)
Date: Fri, 27 Aug 1999 12:33:26 -0700 (PDT)
Subject: Garbage collection
In-Reply-To: <Pine.LNX.3.96.990827130852.2647A-100000@babba.advancenet.net>
References: <19990827085932.A16043@hawk.oak.informix.com>
	<Pine.LNX.3.96.990827130852.2647A-100000@babba.advancenet.net>
Message-ID: <14278.59398.30892.548062@opus.davidb.org>

>>>>> On Fri, 27 Aug 1999 13:15:39 -0500 (CDT), James Hague <jhague@REDACTED> said:

> Isn't the goal of the Boehm collector to work with systems that otherwise
> don't "understand" garbage collection on a fundamental level?  What's the
> purpose of such a collector in a language where all datatypes are already
> tagged?

Correct.  Boehm also has the (possibly serious) drawback that it is
conservative.  Since pointers and integers are not tagged, integers
that look like pointers will keep items from being collected.  I would
guess that Boehm would probably not perform as well as the existing GC
in the Erlang runtime, since it always has to scan blocks for more
pointers.  We know out types and only have to descend objects that
might contain pointers. 

Try a web search for "real time garbage".  There are a lot of papers
about algorithms and optimizations for real time.  ACM also has some
nice articles in their digital library.

Dave



From Bruce@REDACTED  Sat Aug 28 14:25:37 1999
From: Bruce@REDACTED (Bruce Fitzsimons)
Date: Sat, 28 Aug 1999 14:25:37 +0200
Subject: [Erlang] ODBC interface to Mnesia
Message-ID: <000001bef150$cc7749c0$40e879c3@noddy.nl.unisys.com>


H?kan Mattsson wrote in message ...

>A more ambitious approach is to implement an ODBC wrapper for Mnesia.
>As a result of a master thesis we have a SQL compiler which generates
>the internal format of Mnemosyne. The parser accepts the entire syntax
>of SQL, but the rest of the compiler is far from complete. It requires
>a substantial amount of work in order to implement an ODBC complient
>interface to Mnesia, but you are very welcome to make a try.
>
Thanks, thats all good information for me to use. I think there is some
alternatives to implementing the full SQL syntax in Erlang. They might not
be better alternatives but I don't know until I work through the
implications, and receive some input.

This page: http://www.openlink.co.uk/info/docs/odbcwhp/odbcobj.htm has quite
a good summary of the ODBC architecture in plain english.

Basically it seems that it would be possible to implement an SQL interpreter
in <your choice of language here> as a driver on the client side, and have
the driver use the IIOC interface to the Mnesia Session.

The limitations on this method are basically that I would have to find a way
to represent every type of SQL/ODBC query/action as something in
Mnesia/Mnemosyne. I haven't dug enough to see how well the two map together.

The other thing that I'm still considering is if this should be a
multi-level architecture where I attempt to do all the query processing on
the Erlang/Mnesia side, or simply to extract the data in a more raw form and
do query processing on the client side. There's arguments for both ways - it
depends on what I want to do(processing power of client vs server, datacom
link capacity), and also if I want this to be a generic solution.

I don't really need sub-second performance for my intended application, but
doing the query on the client side doesn't appeal.

Even if I used the SQL parser in Erlang, I still need to define some sort of
custom communications prototocol between the client driver and server
process. This would appear to have to be IIOC or "... yet another back end
for IC ...", with an Erlang server process processing the SQL.

Do you have any more comments on this? I'm still at an architecture level of
design - I think an ODBC interface would be very positive for the growth of
Erlang because it allows admin and reporting interfaces to be written with
familiar Windows tools (or *nix tools, if a compatible driver was written
for it).

You are correct about this being a lot of work. Its a good challenge to get
my teeth into on the fast approaching winter nights.

Cheers,
Bruce

PS Cross-posted to Erlang-Questions list, please send follow-ups there.





From Bruce@REDACTED  Sun Aug 29 18:56:01 1999
From: Bruce@REDACTED (Bruce Fitzsimons)
Date: Sun, 29 Aug 1999 18:56:01 +0200
Subject: File/Directory dialogs in ETK?
Message-ID: <000001bef23f$ea7a5620$9fe879c3@noddy.nl.unisys.com>

Hello again,

I've finished the basic rewrite of Toolbar into ETK, I'm now working on the
maintenance dialogs.

Does anyone have any File/Directory dialogs that I can reuse? I'm reluctant
to reinvent any wheels.

If I have to, I'm planning to write a set of standard "common dialogs" in
ETK for directory searching and file selection(at least). Does that sound
useful?

Thanks,
Bruce



From tobbe@REDACTED  Mon Aug 30 03:37:20 1999
From: tobbe@REDACTED (Torbjorn Tornkvist)
Date: 30 Aug 1999 11:37:20 +1000
Subject: File/Directory dialogs in ETK?
In-Reply-To: "Bruce Fitzsimons"'s message of "Sun, 29 Aug 1999 18:56:01 +0200"
References: <000001bef23f$ea7a5620$9fe879c3@noddy.nl.unisys.com>
Message-ID: <t4yaeuvyjz.fsf@universe.serc.rmit.edu.au>


> I've finished the basic rewrite of Toolbar into ETK, I'm now working on the
> maintenance dialogs.

Great !

> If I have to, I'm planning to write a set of standard "common dialogs" in
> ETK for directory searching and file selection(at least). Does that sound
> useful?

Yes, very useful !!

You'll find instructions for how to send in your contibutions at:

 http://www.erlang.org/contrib/rules.html

/Tobbe











From klacke@REDACTED  Mon Aug 30 10:14:53 1999
From: klacke@REDACTED (Klacke)
Date: Mon, 30 Aug 1999 10:14:53 +0200 (CEST)
Subject: Garbage collection
In-Reply-To: <14278.59398.30892.548062@opus.davidb.org>
References: <19990827085932.A16043@hawk.oak.informix.com>
	<Pine.LNX.3.96.990827130852.2647A-100000@babba.advancenet.net>
	<14278.59398.30892.548062@opus.davidb.org>
Message-ID: <14282.15741.415796.719737@kricka.bluetail.com>


David Brown writes:
 > I would
 > guess that Boehm would probably not perform as well as the existing GC
 > in the Erlang runtime, since it always has to scan blocks for more
 > pointers.  We know out types and only have to descend objects that
 > might contain pointers. 
 > 

So would I, but as usual, speculating gets us nowhere. :-(

Another major difference in the runtime would also be
that all the copying of data that takes place in the
current runtime could (possibly) be replaced by copying
pointers instead !!

Today message passing, ets.erl lookups/insertions are done
by *copying* the data between the process heaps.

(The structure copying code is highly optimized
 (erts/system/emulator/runtime/copy.c) and as
 long as messages are reasonably small, the copying
 overhead vanishes among all the other things that's 
 happening.)
 

Robert Virding had a couple of different erlang implementations
a couple of years ago (called VEE) that were using a global
heap for all the erlang processes instead, none of his implementations
reached production status though.

All in all, doing a little Boehm hack might be pretty
interesting. 

We also need to keep in mind that the typical sort of 
applications that Erlang is intended for are supposed to
run without stopping for a very long time[*]. This implies that
GC is good way to go, but it also implies that *all* data
must be eventually collected. A conservative collector may
forget 10 bytes/hour which leads to a very very hard to find bug.
So performance is important, but complete correctness is even more so.

/klacke


[*] I once read that the third most frequent bug in 
    the Ericsson AXE switch was 32/16 bit counters that 
    overflowed. There's a lot of counters in a telephone
    switch :-)




From hakan@REDACTED  Mon Aug 30 17:15:22 1999
From: hakan@REDACTED (Hakan Mattsson)
Date: Mon, 30 Aug 1999 17:15:22 +0200 (MET DST)
Subject: [Erlang] ODBC interface to Mnesia
In-Reply-To: <000001bef150$cc7749c0$40e879c3@noddy.nl.unisys.com>
Message-ID: <Pine.GSO.4.00.9908301635130.2872-100000@sam>


On Sat, 28 Aug 1999, Bruce Fitzsimons wrote:

Bruce>Do you have any more comments on this? I'm still at an architecture level of
Bruce>design - I think an ODBC interface would be very positive for the growth of
Bruce>Erlang because it allows admin and reporting interfaces to be written with
Bruce>familiar Windows tools (or *nix tools, if a compatible driver was written
Bruce>for it).
Bruce>
Bruce>You are correct about this being a lot of work. Its a good challenge to get
Bruce>my teeth into on the fast approaching winter nights.

Back in 1997, I did some estimations of the work needed in order to
implement a foreign language interface to Mnesia. I think that the
work could be divided in several phases, starting with "Mnesia SQL".
The actual figures will of course depend a lot of the ambition
level (conformance & quality) and of the skill of the implementor.

We decided to implement the last alternative "Mnesia Session" as it
made Mnesia open enough, without too much efforts.

/H?kan

    Mnesia is a DBMS implemented in Erlang and intended to be used from
    programs written in Erlang. The query language Mnemosyne is fully
    integrated with Erlang as a pure language extension. When discussing
    potential new interfaces to Mnesia, it is important to have in mind
    that interfaces for foreign languages always will add a significant
    overhead caused by impedance mismatch and interprocess communication.
    
    It would be very nice to have a SQL-based interface to Mnesia since it
    is standardized and is supported by many other relational DBMS's. The
    most straightforward approach for an implementation of a SQL interface
    to Mnesia is to map Mnesia's current functionality to SQL and make use
    of ODBC to benifit from already existing ODBC language bindings.
    
      1a/ We estimate the work of "Mnesia SQL" to be approximately
	  4-5 months.
    
    There are three conformance levels of SQL. The simplest one is called
    "Entry SQL" and in order to be conformant with that there are several
    features that OTP needs to be extended with. E.g. views, ordered
    tables, security, constraints, string pattern matching, foreign keys
    etc. This involves work in Mnesia, ERTS and StdLib.
    
      1b/ We estimate the work of "Entry SQL" to be approximately
	  10-12 months, plus the work of "Mnesia SQL".
    
    The next conformance level of SQL is called "Intermediate SQL" and
    requires Mnesia to be extended with features like domains, datetime,
    alternate isolation semantics in transactions, updatable views,
    dynamic SQL etc.
    
      1c/ We estimate the work of "Intermediate SQL" to be approximately
	  4-5 months, plus the work of "Entry SQL".
    
    The ultimate conformance level of SQL is called "Full SQL" and
    requires Mnesia to be extended with features like assertions,
    privileges with column granularity, cascading effects, various
    character sets, explicit time precision, multiple catalogs, temporary
    tables etc.
    
      1d/ We estimate the work of "Full SQL" to be approximately
	  4-5 months, plus the work of "Intermediate SQL".
    
    Another apporoach of open Mnesia for access from foreign languages is
    to specify an interface with OMG's IDL and make Mnesia's entire
    functionality available via our own ORB.
    
      2/ We estimate the work of "Mnesia Session" to be approximately
	 3-4 months.



From dg@REDACTED  Mon Aug 30 19:07:06 1999
From: dg@REDACTED (David Gould)
Date: Mon, 30 Aug 1999 10:07:06 -0700
Subject: Garbage collection
In-Reply-To: <14282.15741.415796.719737@kricka.bluetail.com>; from Klacke on Mon, Aug 30, 1999 at 10:14:53AM +0200
References: <19990827085932.A16043@hawk.oak.informix.com> <Pine.LNX.3.96.990827130852.2647A-100000@babba.advancenet.net> <14278.59398.30892.548062@opus.davidb.org> <14282.15741.415796.719737@kricka.bluetail.com>
Message-ID: <19990830100706.C17329@hawk.oak.informix.com>

On Mon, Aug 30, 1999 at 10:14:53AM +0200, Klacke wrote:
> 
> All in all, doing a little Boehm hack might be pretty
> interesting. 
> 
> We also need to keep in mind that the typical sort of 
> applications that Erlang is intended for are supposed to
> run without stopping for a very long time[*]. This implies that
> GC is good way to go, but it also implies that *all* data
> must be eventually collected. A conservative collector may
> forget 10 bytes/hour which leads to a very very hard to find bug.
> So performance is important, but complete correctness is even more so.

The Boehm collector can support type information if it is available. So there
is no need to use the "conservative" feature so this should be a non-issue
for Erlang.

-dg

-- 
David Gould           dg@REDACTED            510.628.3783 or 510.305.9468 
Informix Software                       300 Lakeside Drive  Oakland, CA 94612
You will cooperate with Microsoft, for the good of Microsoft
and for your own survival.                 -- Navindra Umanee



From jhague@REDACTED  Mon Aug 30 19:48:38 1999
From: jhague@REDACTED (James Hague)
Date: Mon, 30 Aug 1999 12:48:38 -0500 (CDT)
Subject: Garbage collection
In-Reply-To: <19990830100706.C17329@hawk.oak.informix.com>
Message-ID: <Pine.LNX.3.96.990830124351.20550B-100000@babba.advancenet.net>

> The Boehm collector can support type information if it is available. So there
> is no need to use the "conservative" feature so this should be a non-issue
> for Erlang.

Did this discussion start because someone was unhappy with the performance
of the Erlang garbage collector or is it pure (though interesting) 
conjecture about how to speed up the system? 

James



From vlad.dumitrescu@REDACTED  Tue Aug 31 09:00:14 1999
From: vlad.dumitrescu@REDACTED (Vlad Dumitrescu)
Date: Mon, 30 Aug 1999 23:00:14 -800
Subject: Garbage collection
Message-ID: <37cb6f6e.119.0@flashmail.com>

>Did this discussion start because someone was unhappy with the performance
>of the Erlang garbage collector or is it pure (though interesting) 
>conjecture about how to speed up the system? 
>

I started it, and it is on the "to do" list at erlang.org, so I suppose someone
has experienced slow collections... 

After being buried in the code for the weekend ;-) I realized the present collector
is rather tightly integrated with the rest of the runtime... which makes it
difficult to change.

The same applies to the specific VM information: right now the data structures
for JAM and BEAM are hard-coded into the other structures... I think the couplings
should be more loose...

/Vlad
______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!


From Bruce@REDACTED  Tue Aug 31 16:51:10 1999
From: Bruce@REDACTED (Bruce Fitzsimons)
Date: Tue, 31 Aug 1999 16:51:10 +0200
Subject: [Erlang] ODBC interface to Mnesia
In-Reply-To: <Pine.GSO.4.00.9908301635130.2872-100000@sam>
Message-ID: <000201bef3c0$639608c0$78e879c3@noddy.nl.unisys.com>

Hi H?kan,

Once again, thanks for your input. It is very valuable and I appreciate your
time.

In addition to the work on the Mnesia interface side, there is a significant
amount of work on the PC client side in supporting ODBC. Did you consider
that in your estimates?

But...it appears that if I spend some time reverse engineering it, I can use
the MyODBC ODBC driver. This driver (source) is Public Domain, and is used
for the ODBC interface to MySQL.

So that would be the client side of the interface made a lot easier - its
more a matter of cutting bits out and providing "default" responses to some
ODBC commands that can't be supported.

This driver sends commands over through tcp/ip ports between the client and
server, so it should be easy to replicate the server side in Erlang.

> Back in 1997, I did some estimations of the work needed in order to
> implement a foreign language interface to Mnesia. I think that the
> work could be divided in several phases, starting with "Mnesia SQL".

On the Mnesia/server side, I am expecting to only provide "Mnesia SQL"
conformance. Changing Mnesia to support the full SQL-92 spec is beyond my
scope and abilities.

It's also a can of worms I'd rather not open. Even some basic commands about
creating and deleting  databases can't be easily replicated in Mnesia...

Being honest, I'd be thrilled just to get "SELECT * FROM <table>" working
over ODBC.

Its probable that a lot of standard ODBC client applications won't like a
partial implementation of ODBC/SQL, but that doesn't matter for applications
that are written with Mnesia SQL in mind, and it provides a base for
enhancement.

> The actual figures will of course depend a lot of the ambition
> level (conformance & quality) and of the skill of the implementor.

Thanks for the reality check and helping me limit the scope. I am aware that
this is a lot of effort, but I think it is time well spent.

I was reading the Masters Thesis about the SQL parser in Erlang. Some
questions:

1. Was it finally possibly to get the full syntax compiled and working, or
are you still stuck with a cut down version?
2. Is it possible to get a copy of the source under the EPL?

Thanks,
Bruce