Discussion:
R9C-1 release - note for Ericsson users
(too old to reply)
unknown
2004-05-27 09:05:05 UTC
Permalink
There used to be a mirror of www.erlang.org only visible
inside Ericsson at erlang.ericsson.se/opensource.

We have now removed that mirror. Use www.erlang.org instead.

Here is part of the release README file updated to reflect that
change.

Bug fix release : otp_src_R9C-1
Build from snapshot : 2004-05-26

This is a bug fix release 1 for the R9C release.
You can download the full source distribution from

http://www.erlang.org/download/otp_src_R9C-1.tar.gz
http://www.erlang.org/download/otp_src_R9C-1.readme (this file)

Note: To unpack the TAR archive you need a GNU TAR compatible
program. For instance, on MacOS X you need to use the 'gnutar' command;
you can't use the 'tar' command or StuffIt to unpack the sources.


For installation instructions please read the README that is part of
the distribution.

The Windows binary distribution can be downloaded from

http://www.erlang.org/download/otp_win32_R9C-1.exe

The documentation at http://www.erlang.org will be updated. You can
also download the complete HTML documentation or the Unix manual files

http://www.erlang.org/download/otp_html_R9C-1.tar.gz
http://www.erlang.org/download/otp_man_R9C-1.tar.gz

For some OTP applications there are more detailed release notes in the
HTML documentation.

We also want to thank those that sent us patches, suggestions and bug
reports,

The OTP Team
--
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
unknown
2004-05-27 21:55:29 UTC
Permalink
Post by unknown
Note: To unpack the TAR archive you need a GNU TAR compatible
program. For instance, on MacOS X you need to use the 'gnutar' command;
you can't use the 'tar' command or StuffIt to unpack the sources.
Maybe, but it still doesn't build on OS X

-lz still fails.

The shared libs still use the broken -lbundle1.o construct.

Sean
unknown
2004-05-28 08:55:03 UTC
Permalink
We didn't have any time for working on the Mac port for the
R9C-1 release. Sorry.

We'll hope to address the Mac problems in the R9C-2 release,
which we hope to get out this summer (within 1-2 months).

/Bjorn
Post by unknown
Post by unknown
Note: To unpack the TAR archive you need a GNU TAR compatible
program. For instance, on MacOS X you need to use the 'gnutar' command;
you can't use the 'tar' command or StuffIt to unpack the sources.
Maybe, but it still doesn't build on OS X
-lz still fails.
The shared libs still use the broken -lbundle1.o construct.
Sean
--
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
unknown
2004-05-30 23:20:05 UTC
Permalink
Post by unknown
We didn't have any time for working on the Mac port for the
R9C-1 release. Sorry.
We'll hope to address the Mac problems in the R9C-2 release,
which we hope to get out this summer (within 1-2 months).
I did not have any problem to build on my Mac Os X (10.2.8)


bash-2.05a$ /usr/local/bin/erl
Erlang (BEAM) emulator version 5.3.6.2 [source] [threads:0]

Eshell V5.3.6.2 (abort with ^G)
1>

/Tony
unknown
2004-05-31 18:14:56 UTC
Permalink
Post by unknown
Post by unknown
We didn't have any time for working on the Mac port for the
R9C-1 release. Sorry.
We'll hope to address the Mac problems in the R9C-2 release,
which we hope to get out this summer (within 1-2 months).
I did not have any problem to build on my Mac Os X (10.2.8)
bash-2.05a$ /usr/local/bin/erl
Erlang (BEAM) emulator version 5.3.6.2 [source] [threads:0]
Eshell V5.3.6.2 (abort with ^G)
1>
Indeed. The emulator build problem was introduced by Apple with OS
10.3.x. Seemingly related to the much later gcc supplied.

Sean
unknown
2004-06-08 10:06:12 UTC
Permalink
A simple question:

why is

if
f(X) =:= 42 ->
..
end

not allowed, but

Y = f(X),
if
Y =:= 42 ->
..
end

seems to be same to me and working.
Is it to have all f() evaluations (which might show up in
other clauses of the if again) before the if statement?

Regards,
Marc
unknown
2004-06-09 04:40:34 UTC
Permalink
Post by unknown
why is
if f(X) =:= 42 ->
..
end
not allowed, but
Y = f(X),
if
Y =:= 42 ->
..
end
most likely it is this way to ensure that the 'if branch selection' is
done in bounded time.
assume that the choosing of a branch is done inside the virtual machine.
in your first example that means that f(X) would run to compleation,
without letting any other process run.


bengt
unknown
2004-06-09 05:37:36 UTC
Permalink
Post by unknown
why is
if
f(X) =:= 42 ->
end
not allowed, but
Y = f(X),
if
Y =:= 42 ->
end
Functions can have side effects even if they fail. Bad things
happen if a failing guard test changes the state. Only the
guard bifs can apply ( == being one), so in this case you
can make it safe by generating the value and then testing
with a simple guard.
Post by unknown
Is there some means to identify a function (compare it to
a given function) that gets passed as argument?
The natural erlang way (in my mind) was to do a parse
transformation to a record like this:

-record icode(linenum, label, opcode, args, original).

genCode(Text, LineNum) ->
[Label, Operator | Args] = parseText(Text),
ICode = #icode(linenum=LineNum, label=Label, opcode=opToken(Operator),
args=Args, original=Text}.

opToken("Move") -> move; % or even fun(Arglist) -> move(Arglist) end
opToken("Drop") -> drop;

Then you would define functions for move and drop and
use apply(ICode#icode.opcode, ICode#icode.args) or in
the case of the fun, just call ICode#icode.opcode(ICode#icode.args).


Pattern matching and tuples are half the battle in transforming
text to internal tokens, with debuggable code falling out of the
record constructs automatically. I wrote lists of icode records
to files as if they were library.obj files, then used consult to
load up an obj file for execution or linking. Apply and funs make
the records directly executable. I used apply and was able to
run simulations in tens of seconds, but converting to funs
should speed things up nicely.

jay
unknown
2004-06-09 08:52:31 UTC
Permalink
Post by unknown
The natural erlang way (in my mind) was to do a parse
-record icode(linenum, label, opcode, args, original).
genCode(Text, LineNum) ->
[Label, Operator | Args] = parseText(Text),
ICode = #icode(linenum=LineNum, label=Label,
opcode=opToken(Operator),
args=Args, original=Text}.
opToken("Move") -> move; % or even fun(Arglist) ->
Interesting, thank you for that hint!

Regards,
Marc

Continue reading on narkive:
Loading...