Re: 64-bit compile fails on Snow Leopard

I have no idea about autoconf, but I've checked logs and it looks like  
autoconf is using "uname -p" to get host architecture. Snow Leopard  
x64 returns i386 here.

Cheers,
D

On 01/10/2009, at 6:01 AM, Ryan Graham wrote:

> That's what I was trying to point out. It fails on the configure
> because it is looking for Darwin-i386 in the output from uname. The
> same check is done for each submodule as well. It should be a trivial
> fix, I just didn't have the time to make a patch for it.
>
> ~Ryan
>
> On Wed, Sep 30, 2009 at 2:04 AM, Dmitri Sosnik <dimavs <at> gmail.com>  
> wrote:
>> Thanks!
>>
>> But I've realised that it's an another problem. Configure detects  
>> wrong
>> architecture:
>>
>> checking build system type... i386-apple-darwin10.0.0
>> checking host system type... i386-apple-darwin10.0.0
>>
>> $uname -a
>> Darwin DMBP.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31  
>> 22:46:25

Re: 64-bit compile fails on Snow Leopard

Reboot and hold down the 6 and 4 keys on your keyboard. If your mac  
has a new enough CPU, it will boot up with the 64-bit kernel instead  
of the standard 32-bit kernel. The bug I'm reporting wouldn't  
typically be seen in normal use, but it is still wrong to assume non- 
i386 means ppc, which is what the check is probably there for.

~Ryan

On 2009-09-30, at 6:33 PM, Dmitri Sosnik <dimavs <at> gmail.com> wrote:

> I have no idea about autoconf, but I've checked logs and it looks  
> like autoconf is using "uname -p" to get host architecture. Snow  
> Leopard x64 returns i386 here.
>
> Cheers,
> D
>
>
>
> On 01/10/2009, at 6:01 AM, Ryan Graham wrote:
>
>> That's what I was trying to point out. It fails on the configure
>> because it is looking for Darwin-i386 in the output from uname. The
>> same check is done for each submodule as well. It should be a trivial
>> fix, I just didn't have the time to make a patch for it.
>>
>> ~Ryan
>>
>> On Wed, Sep 30, 2009 at 2:04 AM, Dmitri Sosnik <dimavs <at> gmail.com>  
>> wrote:

Re: 64-bit compile fails on Snow Leopard

I am already booted with x64 kernel and conf.log says:

uname -m = x86_64
uname -r = 10.0.0
uname -s = Darwin
uname -v = Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009;  
root:xnu-1456.1.25~1/RELEASE_X86_64

/usr/bin/uname -p = i386
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
hostinfo               = Mach kernel version:
      Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009;  
root:xnu-1456.1.25~1/RELEASE_X86_64

configure:1358: checking build system type
configure:1376: result: i386-apple-darwin10.0.0
configure:1384: checking host system type
configure:1398: result: i386-apple-darwin10.0.0

Cheers,
D

On 01/10/2009, at 2:20 PM, Ryan Graham wrote:

> Reboot and hold down the 6 and 4 keys on your keyboard. If your mac  
> has a new enough CPU, it will boot up with the 64-bit kernel instead  

Re: 64-bit compile fails on Snow Leopard

My Mac died last night, but I downloaded the latest source (R13B02-1)
onto my Linux box at work...

$ grep -Inr "TMPSYS" ./
./erts/configure.in:268:TMPSYS=`uname -s`-`uname -m`
./erts/configure.in:290:        if test X"$TMPSYS" '!=' X"Darwin-i386"; then
./erts/configure:2782:TMPSYS=`uname -s`-`uname -m`
./erts/configure:2806:  if test X"$TMPSYS" '!=' X"Darwin-i386"; then
./configure.in:210:TMPSYS=`uname -s`-`uname -m`
./configure.in:222:     if test X"$TMPSYS" '!=' X"Darwin-i386"; then
./configure.in:230:elif test X"$TMPSYS" '=' X"Darwin-i386"; then
./configure:2691:TMPSYS=`uname -s`-`uname -m`
./configure:2705:       if test X"$TMPSYS" '!=' X"Darwin-i386"; then
./configure:2715:elif test X"$TMPSYS" '=' X"Darwin-i386"; then

The configure scripts only allow the --enable-darwin-64bit switch if
you are running on the 32-bit kernel.

As your outputs show, if you boot up into the 64-bit kernel, `uname
-m` spits out x86_64 which results in the $TMPSYS being the string
"Darwin-x86_64", which the script fails to match against
"Darwin-i386". As a result, it prints out an error:

"$as_me:$LINENO: error: --enable-darwin-64bit only supported on x86 host"

~Ryan

On Wed, Sep 30, 2009 at 10:17 PM, Dmitri Sosnik <dimavs <at> gmail.com> wrote:
> I am already booted with x64 kernel and conf.log says:
>

Re: 64-bit compile fails on Snow Leopard

We are aware of the problem, but have no machines that will boot with a 64-bit kernel,
and can't test it.

We will try to fix it in the next release.

/Dan

Ryan Graham wrote:
> My Mac died last night, but I downloaded the latest source (R13B02-1)
> onto my Linux box at work...
> 
> $ grep -Inr "TMPSYS" ./
> ./erts/configure.in:268:TMPSYS=`uname -s`-`uname -m`
> ./erts/configure.in:290:        if test X"$TMPSYS" '!=' X"Darwin-i386"; then
> ./erts/configure:2782:TMPSYS=`uname -s`-`uname -m`
> ./erts/configure:2806:  if test X"$TMPSYS" '!=' X"Darwin-i386"; then
> ./configure.in:210:TMPSYS=`uname -s`-`uname -m`
> ./configure.in:222:     if test X"$TMPSYS" '!=' X"Darwin-i386"; then
> ./configure.in:230:elif test X"$TMPSYS" '=' X"Darwin-i386"; then
> ./configure:2691:TMPSYS=`uname -s`-`uname -m`
> ./configure:2705:       if test X"$TMPSYS" '!=' X"Darwin-i386"; then
> ./configure:2715:elif test X"$TMPSYS" '=' X"Darwin-i386"; then
> 
> The configure scripts only allow the --enable-darwin-64bit switch if
> you are running on the 32-bit kernel.
> 
> As your outputs show, if you boot up into the 64-bit kernel, `uname
> -m` spits out x86_64 which results in the $TMPSYS being the string
> "Darwin-x86_64", which the script fails to match against
> "Darwin-i386". As a result, it prints out an error:

Re: [erlang-questions] beam crasher: ets + write_concurrency

Dave Smith wrote:
> I believe that I have identified a VM crasher when using ETS with
> write concurrency enabled. Sample code is as follows:
>
> T = ets:new(?MODULE, [{write_concurrency, true}]),
> ets:insert_new(T, {foo, 1}),
> ets:match(T, {nosuchvalue, '$1'})

Yes, it's repeatable on my machine as well (Linux x86_64, 64-bit VM).
I will have a look at it right now.

Thanks for reporting.
/Sverker, Erlang/OTP

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

R12B3 tracing crashes emulator

Tracing on [all], or specifically [running, scheduler_id] trashes the
stack leading to some sort of SEGV or BUS fault. Seen on Solaris
i386/64-bit and OS/X i386/32-bit.
This doesn't seem to be related to the other thing reported/fixed
recently in R13.
Patch attached.

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

Re: R12B3 tracing crashes emulator

Hi Simon,

These issues are fixed in R12B-4 and later. This section of code was 
completely revised in R12B-4, ticket OTP-7481.

Are you seeing this on later releases as well?

Regards,
Björn-Egil
Erlang/OTP

Simon Cornish wrote:
> Tracing on [all], or specifically [running, scheduler_id] trashes the
> stack leading to some sort of SEGV or BUS fault. Seen on Solaris
> i386/64-bit and OS/X i386/32-bit.
> This doesn't seem to be related to the other thing reported/fixed
> recently in R13.
> Patch attached.
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org

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

Edoc crash when using macro with function

Hi!

Running edoc:file/1 on test.erl with this content will result in a crash in edoc:

-module(test).

-export([f/0]).

-define(FUNC, f() -> ok).

?FUNC.

Seems edoc in R13B02 can't handle the macro on line 7.

1> edoc:file("test.erl"). test.erl: at line 7: syntax error before: '.'
** exception exit: error
     in function  edoc:'-check_forms/2-fun-0-'/2
     in call from lists:foreach/2
     in call from edoc:read_source/2
     in call from edoc_extract:source/3
     in call from edoc:read/2
     in call from edoc:file/2

Cheers,
Adam

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

Re: Edoc crash when using macro with function

Thanks, didn't make that connection with the documentation at all.

Follow up question: Is it possible to make edoc just skip those files? Right now it says that is is skipping
them, but exits with an error anyway. I'd like it to generate the documentation for the modules that do
work. Is that possible?

Cheers,
Adam

----- "Richard Carlsson" <carlsson.richard <at> gmail.com> wrote:

> Adam Lindberg wrote:
> > Running edoc:file/1 on test.erl with this content will result in a
> crash in edoc:
> > 
> > -module(test).
> > 
> > -export([f/0]).
> > 
> > -define(FUNC, f() -> ok).
> > 
> > ?FUNC.
> > 
> > 
> > Seems edoc in R13B02 can't handle the macro on line 7.
> 
> That's not a bug, it's a feature. 
> 
> If you want to run edoc on files that contain too weird macros,
> you need to give it the 'preprocess' flag, and possibly specify