From roberto.aloi@REDACTED Fri Apr 9 13:00:33 2010 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Fri, 09 Apr 2010 12:00:33 +0100 Subject: Dialyzer Documentation Message-ID: <4BBF08D1.5010301@erlang-solutions.com> Hi all, in: http://www.erlang.org/doc/man/dialyzer.html The correct analysis types should be: {analysis_type, 'succ_typings' | 'plt_add' | 'plt_build' | 'plt_check' | 'plt_remove'} rather than: {analysis_type, 'success_typings' | 'plt_add' | 'plt_build' | 'plt_check' | 'plt_remove'} as in the source code (dialyzer_options.erl): analysis_type -> NewOptions = case Value of succ_typings -> Options#options{analysis_type = Value}; plt_add -> Options#options{analysis_type = Value}; plt_build -> Options#options{analysis_type = Value}; plt_check -> Options#options{analysis_type = Value}; plt_remove -> Options#options{analysis_type = Value}; dataflow -> bad_option("Analysis type is no longer supported", Term); old_style -> bad_option("Analysis type is no longer supported", Term); Other -> bad_option("Unknown analysis type", Other) Regards, Roberto Aloi -- University of Kent - Erlang Solutions Ltd. Twitter: @prof3ta Blog: http://aloiroberto.wordpress.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From kostis@REDACTED Fri Apr 9 13:39:59 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 09 Apr 2010 14:39:59 +0300 Subject: [erlang-bugs] Dialyzer Documentation In-Reply-To: <4BBF08D1.5010301@erlang-solutions.com> References: <4BBF08D1.5010301@erlang-solutions.com> Message-ID: <4BBF120F.6080705@cs.ntua.gr> Roberto Aloi wrote: > Hi all, > > in: > > http://www.erlang.org/doc/man/dialyzer.html > > The correct analysis types should be: > > {analysis_type, 'succ_typings' | 'plt_add' | 'plt_build' | 'plt_check' > | 'plt_remove'} > > rather than: > > {analysis_type, 'success_typings' | 'plt_add' | 'plt_build' | > 'plt_check' | 'plt_remove'} A fix for this has been pushed to git: http://github.com/kostis/otp/commit/3d5677439f9cdb87807530c181a4388e3dfc6aea and will hopefully also appear soon on the 'dev' branch of Erlang/OTP. Thanks for reporting this! Kostis From winborn@REDACTED Fri Apr 9 13:53:21 2010 From: winborn@REDACTED (Aaron Winborn) Date: Fri, 09 Apr 2010 07:53:21 -0400 Subject: Unable to compile erlang-dev 1:13.b.4 Message-ID: <4BBF1531.9020606@advomatic.com> sudo su mkdir erlang-dev-src cd erlang-dev-src wget http://ftp.de.debian.org/debian/pool/main/e/erlang/erlang_13.b.4-dfsg-4.dsc wget http://ftp.de.debian.org/debian/pool/main/e/erlang/erlang_13.b.4-dfsg.orig.tar.gz wget http://ftp.de.debian.org/debian/pool/main/e/erlang/erlang_13.b.4-dfsg-4.diff.gz dpkg-source -x erlang_13.b.4-dfsg-4.dsc cd erlang-13.b.4-dfsg dpkg-buildpackage -rfakeroot -b truncated output after 1.25 hrs: (.:13709): Gtk-WARNING **: cannot open display: make[4]: *** [../pdf/stdlib-1.16.5.pdf] Error 1 make[4]: Leaving directory `/home/advomatic/erlang-dev-src/erlang-13.b.4-dfsg/lib/stdlib/doc/src' make[3]: *** [docs] Error 2 make[3]: Leaving directory `/home/advomatic/erlang-dev-src/erlang-13.b.4-dfsg/lib/stdlib' make[2]: *** [docs] Error 2 make[2]: Leaving directory `/home/advomatic/erlang-dev-src/erlang-13.b.4-dfsg/lib' make[1]: *** [docs] Error 2 make[1]: Leaving directory `/home/advomatic/erlang-dev-src/erlang-13.b.4-dfsg' make: *** [docs-stamp] Error 2 dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 vps205:/home/advomatic/erlang-dev-src/erlang-13.b.4-dfsg# Apparently, it's requiring X server? That's not possible on our configuration. What should I do next? Thanks, Aaron -- Aaron Winborn Advomatic, LLC http://advomatic.com/ Drupal Multimedia available now! http://www.packtpub.com/create-multimedia-website-with-drupal/book My blog: http://aaronwinborn.com/ From tuncer.ayaz@REDACTED Fri Apr 9 14:20:12 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 9 Apr 2010 14:20:12 +0200 Subject: [erlang-bugs] Unable to compile erlang-dev 1:13.b.4 In-Reply-To: <4BBF1531.9020606@advomatic.com> References: <4BBF1531.9020606@advomatic.com> Message-ID: On Fri, Apr 9, 2010 at 1:53 PM, Aaron Winborn wrote: > sudo su > mkdir erlang-dev-src > cd erlang-dev-src > wget > http://ftp.de.debian.org/debian/pool/main/e/erlang/erlang_13.b.4-dfsg-4.dsc > wget > http://ftp.de.debian.org/debian/pool/main/e/erlang/erlang_13.b.4-dfsg.orig.tar.gz > wget > http://ftp.de.debian.org/debian/pool/main/e/erlang/erlang_13.b.4-dfsg-4.diff.gz > dpkg-source -x erlang_13.b.4-dfsg-4.dsc > cd erlang-13.b.4-dfsg > dpkg-buildpackage -rfakeroot -b > > truncated output after 1.25 hrs: > > (.:13709): Gtk-WARNING **: cannot open display: To understand the issue at hand please search for "apache fop headless server". That might help you decide what you can do to fix the issue. I am assuming that you want to build all docs and need the resulting PDF files. > make[4]: *** [../pdf/stdlib-1.16.5.pdf] Error 1 > make[4]: Leaving directory > `/home/advomatic/erlang-dev-src/erlang-13.b.4-dfsg/lib/stdlib/doc/src' > make[3]: *** [docs] Error 2 > make[3]: Leaving directory > `/home/advomatic/erlang-dev-src/erlang-13.b.4-dfsg/lib/stdlib' > make[2]: *** [docs] Error 2 > make[2]: Leaving directory > `/home/advomatic/erlang-dev-src/erlang-13.b.4-dfsg/lib' > make[1]: *** [docs] Error 2 > make[1]: Leaving directory > `/home/advomatic/erlang-dev-src/erlang-13.b.4-dfsg' > make: *** [docs-stamp] Error 2 > dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit > status 2 > vps205:/home/advomatic/erlang-dev-src/erlang-13.b.4-dfsg# > > Apparently, it's requiring X server? That's not possible on our > configuration. What should I do next? > > Thanks, > Aaron > > -- > Aaron Winborn > > Advomatic, LLC > http://advomatic.com/ > > Drupal Multimedia available now! > http://www.packtpub.com/create-multimedia-website-with-drupal/book > > My blog: > http://aaronwinborn.com/ > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > From sgolovan@REDACTED Fri Apr 9 14:24:24 2010 From: sgolovan@REDACTED (Sergei Golovan) Date: Fri, 9 Apr 2010 16:24:24 +0400 Subject: [erlang-bugs] Unable to compile erlang-dev 1:13.b.4 In-Reply-To: <4BBF1531.9020606@advomatic.com> References: <4BBF1531.9020606@advomatic.com> Message-ID: On Fri, Apr 9, 2010 at 3:53 PM, Aaron Winborn wrote: > dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit > status 2 > vps205:/home/advomatic/erlang-dev-src/erlang-13.b.4-dfsg# > > Apparently, it's requiring X server? That's not possible on our > configuration. What should I do next? When you build Erlang R13B04 in Debian (and from the Debian source package) it builds Erlang documentation from its sources. It requires fop tool which apparently doesn't work without X server in curent stable (lenny). So, if you want to build the Debian package I'd suggest to setup a build environment with X server (may be the dummy one, see xserver-xorg-video-dummy package). Anyway, this list doesn't seem to be an appropriate place to discuss distribution-specific problems. Submitting a bugreport to submit@REDACTED would be better. Cheers! -- Sergei Golovan From roberto.aloi@REDACTED Fri Apr 9 15:44:50 2010 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Fri, 09 Apr 2010 14:44:50 +0100 Subject: About Dialyzer and its dependencies Message-ID: <4BBF2F52.2070202@erlang-solutions.com> Hi all, I'm trying to include dialyzer in my application and I've noticed that one of its dependencies (wx) was missing an .app file. I've also noticed this has been fixed in the 'dev' branch of OTP. Still, another dependency (hipe) has something strange in its .app file: {modules, [cerl_cconv, cerl_closurean, cerl_hipeify, cerl_hybrid_transform, cerl_lib, cerl_messagean, cerl_pmatch, cerl_prettypr, cerl_to_icode, cerl_typean, erl_bif_types, erl_types, hipe, hipe_adj_list, hipe_amd64_assemble, hipe_amd64_defuse, hipe_amd64_encode, hipe_amd64_frame, hipe_amd64_liveness, hipe_amd64_main, hipe_amd64_pp, hipe_amd64_ra, hipe_amd64_ra_finalise, hipe_amd64_ra_ls, hipe_amd64_ra_naive, hipe_amd64_ra_postconditions, hipe_amd64_ra_sse2_postconditions, hipe_amd64_ra_x87_ls, hipe_amd64_registers, hipe_amd64_specific, hipe_amd64_specific_sse2, hipe_amd64_specific_x87, hipe_amd64_spill_restore, hipe_amd64_x87, hipe_arm, hipe_arm_assemble, hipe_arm_cfg, hipe_arm_defuse, hipe_arm_encode, hipe_arm_finalise, hipe_arm_frame, hipe_arm_liveness_gpr, hipe_arm_main, hipe_arm_pp, hipe_arm_ra, hipe_arm_ra_finalise, hipe_arm_ra_ls, hipe_arm_ra_naive, hipe_arm_ra_postconditions, hipe_arm_registers, hipe_arm_specific, hipe_bb, hipe_beam_to_icode, hipe_ceach, hipe_coalescing_regalloc, hipe_consttab, hipe_data_pp, hipe_digraph, hipe_dominators, hipe_dot, hipe_gen_cfg, hipe_gensym, hipe_graph_coloring_regalloc, hipe_icode, hipe_icode2rtl, hipe_icode_bincomp, hipe_icode_callgraph, hipe_icode_cfg, hipe_icode_coordinator, hipe_icode_ebb, hipe_icode_exceptions, hipe_icode_fp, hipe_icode_heap_test, hipe_icode_inline_bifs, hipe_icode_instruction_counter, hipe_icode_liveness, hipe_icode_mulret, hipe_icode_pp, hipe_icode_primops, hipe_icode_range, hipe_icode_ssa, hipe_icode_ssa_const_prop, hipe_icode_ssa_copy_prop, hipe_icode_ssa_struct_reuse, hipe_icode_split_arith, hipe_icode_type, hipe_ig, hipe_ig_moves, hipe_jit, hipe_ls_regalloc, hipe_main, hipe_moves, hipe_node_sets, hipe_optimistic_regalloc, hipe_pack_constants, hipe_ppc, hipe_ppc_assemble, hipe_ppc_cfg, hipe_ppc_defuse, hipe_ppc_encode, hipe_ppc_finalise, hipe_ppc_frame, hipe_ppc_liveness_all, hipe_ppc_liveness_fpr, hipe_ppc_liveness_gpr, hipe_ppc_main, hipe_ppc_pp, hipe_ppc_ra, hipe_ppc_ra_finalise, hipe_ppc_ra_ls, hipe_ppc_ra_naive, hipe_ppc_ra_postconditions, hipe_ppc_ra_postconditions_fp, hipe_ppc_registers, hipe_ppc_specific, hipe_ppc_specific_fp, hipe_profile, hipe_reg_worklists, hipe_regalloc_loop, hipe_rtl, hipe_rtl_arch, hipe_rtl_arith_32, hipe_rtl_arith_64, hipe_rtl_binary, hipe_rtl_binary_match, hipe_rtl_binary_construct, hipe_rtl_cfg, hipe_rtl_cleanup_const, hipe_rtl_exceptions, hipe_rtl_lcm, hipe_rtl_liveness, hipe_rtl_mk_switch, hipe_rtl_primops, hipe_rtl_ssa, hipe_rtl_ssa_const_prop, hipe_rtl_ssa_avail_expr, hipe_rtl_ssapre, hipe_rtl_symbolic, hipe_rtl_to_amd64, hipe_rtl_to_arm, hipe_rtl_to_ppc, hipe_rtl_to_sparc, hipe_rtl_to_x86, hipe_rtl_varmap, hipe_sdi, hipe_sparc, hipe_sparc_assemble, hipe_sparc_cfg, hipe_sparc_defuse, hipe_sparc_encode, hipe_sparc_finalise, hipe_sparc_frame, hipe_sparc_liveness_all, hipe_sparc_liveness_fpr, hipe_sparc_liveness_gpr, hipe_sparc_main, hipe_sparc_pp, hipe_sparc_ra, hipe_sparc_ra_finalise, hipe_sparc_ra_ls, hipe_sparc_ra_naive, hipe_sparc_ra_postconditions, hipe_sparc_ra_postconditions_fp, hipe_sparc_registers, hipe_sparc_specific, hipe_sparc_specific_fp, hipe_spillcost, hipe_spillmin, hipe_spillmin_color, hipe_spillmin_scan, hipe_tagscheme, hipe_temp_map, hipe_timing, hipe_tool, hipe_vectors, hipe_x86, hipe_x86_assemble, hipe_x86_cfg, hipe_x86_defuse, hipe_x86_encode, hipe_x86_frame, hipe_x86_liveness, hipe_x86_main, hipe_x86_postpass, hipe_x86_pp, hipe_x86_ra, hipe_x86_ra_finalise, hipe_x86_ra_ls, hipe_x86_ra_naive, hipe_x86_ra_postconditions, hipe_x86_ra_x87_ls, hipe_x86_registers, hipe_x86_specific, hipe_x86_specific_x87, hipe_x86_spill_restore, hipe_x86_x87]}, Lots of these modules seems to be architecture-dependent and I'm obviously missing most of them. Why they are listed in the .app file? This is what I get when trying to build everything: Creating boot script {{module_not_found,hipe,hipe}, {hipe,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} {{module_not_found,hipe,hipe_adj_list}, {hipe_adj_list,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} {{module_not_found,hipe,hipe_amd64_assemble}, {hipe_amd64_assemble,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} {{module_not_found,hipe,hipe_amd64_defuse}, {hipe_amd64_defuse,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} {{module_not_found,hipe,hipe_amd64_encode}, {hipe_amd64_encode,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} {{module_not_found,hipe,hipe_amd64_frame}, {hipe_amd64_frame,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} {{module_not_found,hipe,hipe_amd64_liveness}, {hipe_amd64_liveness,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} {{module_not_found,hipe,hipe_amd64_main}, {hipe_amd64_main,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} {{module_not_found,hipe,hipe_amd64_pp}, {hipe_amd64_pp,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} {{module_not_found,hipe,hipe_amd64_ra}, {hipe_amd64_ra,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} {{module_not_found,hipe,hipe_amd64_ra_finalise}, {hipe_amd64_ra_finalise,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} {{module_not_found,hipe,hipe_amd64_ra_ls}, [...] Roberto Aloi -- University of Kent - Erlang Solutions Ltd. Twitter: @prof3ta Blog: http://aloiroberto.wordpress.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From kostis@REDACTED Fri Apr 9 16:44:19 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 09 Apr 2010 17:44:19 +0300 Subject: [erlang-bugs] About Dialyzer and its dependencies In-Reply-To: <4BBF2F52.2070202@erlang-solutions.com> References: <4BBF2F52.2070202@erlang-solutions.com> Message-ID: <4BBF3D43.8070906@cs.ntua.gr> Roberto Aloi wrote: > Hi all, > > I'm trying to include dialyzer in my application and I've noticed that > one of its dependencies (wx) was missing an .app file. I've also noticed > this has been fixed in the 'dev' branch of OTP. > > Still, another dependency (hipe) has something strange in its .app file: > > {modules, [cerl_cconv, .... > > Lots of these modules seems to be architecture-dependent and I'm > obviously missing most of them. Why they are listed in the .app file? There is nothing architecture dependent here (but all these files are of course dependent on whether you have configured OTP with --enable-hipe or not). Anyway, these are the files of the 'hipe' application. Where exactly do you want us to specify them if not in the .app file of the corresponding application? In any case, if you think that something is wrong or does not match your needs, submit a git patch and we will consider it. Best, Kostis From mikpe@REDACTED Fri Apr 9 16:45:07 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 9 Apr 2010 16:45:07 +0200 Subject: [erlang-bugs] About Dialyzer and its dependencies In-Reply-To: <4BBF2F52.2070202@erlang-solutions.com> References: <4BBF2F52.2070202@erlang-solutions.com> Message-ID: <19391.15731.668657.674459@pilspetsen.it.uu.se> Roberto Aloi writes: > Hi all, > > I'm trying to include dialyzer in my application and I've noticed that > one of its dependencies (wx) was missing an .app file. I've also noticed > this has been fixed in the 'dev' branch of OTP. > > Still, another dependency (hipe) has something strange in its .app file: ... > hipe_amd64_assemble, > hipe_amd64_defuse, > hipe_amd64_encode, ... > Lots of these modules seems to be architecture-dependent and I'm > obviously missing most of them. Why they are listed in the .app file? Because they are part of HiPE and get built when HiPE proper is built. And while there are many arch-dependent modules, all of them get built. (HiPE can cross-compile, but issues with the runtime system prevent it from actually working.) > This is what I get when trying to build everything: > > Creating boot script > {{module_not_found,hipe,hipe}, > {hipe,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} > {{module_not_found,hipe,hipe_adj_list}, > {hipe_adj_list,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} > {{module_not_found,hipe,hipe_amd64_assemble}, > {hipe_amd64_assemble,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} > {{module_not_found,hipe,hipe_amd64_defuse}, > {hipe_amd64_defuse,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} > {{module_not_found,hipe,hipe_amd64_encode}, > {hipe_amd64_encode,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} > {{module_not_found,hipe,hipe_amd64_frame}, > {hipe_amd64_frame,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} > {{module_not_found,hipe,hipe_amd64_liveness}, > {hipe_amd64_liveness,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} > {{module_not_found,hipe,hipe_amd64_main}, > {hipe_amd64_main,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} > {{module_not_found,hipe,hipe_amd64_pp}, > {hipe_amd64_pp,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} > {{module_not_found,hipe,hipe_amd64_ra}, > {hipe_amd64_ra,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} > {{module_not_found,hipe,hipe_amd64_ra_finalise}, > {hipe_amd64_ra_finalise,'$$ignore$$',hipe,"3.7.5","lib/hipe-3.7.5/ebin"}} > {{module_not_found,hipe,hipe_amd64_ra_ls}, > [...] The issue that confuses you is that dialyzer depends on a subset of HiPE. That subset is built regardless of whether HiPE is enabled or not, but everything listed in HiPE's app file is not necessarily present. If this is a problem, post a patch to instantiate a different (smaller) hipe.app.src for the case when HiPE is disabled. /Mikael From roberto.aloi@REDACTED Fri Apr 9 19:47:16 2010 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Fri, 09 Apr 2010 18:47:16 +0100 Subject: [erlang-bugs] About Dialyzer and its dependencies In-Reply-To: <4BBF2F52.2070202@erlang-solutions.com> References: <4BBF2F52.2070202@erlang-solutions.com> Message-ID: <4BBF6824.7000801@erlang-solutions.com> Hi all, first of all thanks to Kostis and Mikael for their considerations. You're both perfectly right. I didn't realize the story behind the --enable-hipe flag at a first glance. I had hipe disabled, so the system couldn't find the "optional" modules. I'm trying to fix this, generating the proper hipe.app file based on the fact hipe is enabled or not. I'm almost done, but considering it's almost weekend, I'll probably push the changes on monday. Have a great weekend, Roberto Aloi -- University of Kent - Erlang Solutions Ltd. Twitter: @prof3ta Blog: http://aloiroberto.wordpress.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From aimsolaky@REDACTED Sat Apr 10 00:34:03 2010 From: aimsolaky@REDACTED (Angel) Date: Sat, 10 Apr 2010 00:34:03 +0200 Subject: missing libGLU dependencies on Wx Message-ID: <201004100034.03563.aimsolaky@gmail.com> Using OpenSUSE 11.2 erlang packages: Name : erlang Relocations: (not relocatable) Version : R13B04 Vendor: obs://build.opensuse.org/devel:languages:erlang Release : 2.1 Build Date: mar 23 mar 2010 15:34:01 CET Install Date: vie 09 abr 2010 22:04:36 CEST Build Host: build19 Group : Development/Languages/Erlang Source RPM: erlang-R13B04-2.1.src.rpm Size : 52685133 License: Erlang Public License Signature : DSA/SHA1, mar 23 mar 2010 15:36:51 CET, Key ID e457ae6fa34552c6 URL : http://www.erlang.org sinchan@REDACTED:/usr/lib/erlang/lib/wx-0.98.5/examples/demo> erl -smp enable Erlang R13B04 (erts-5.7.5) [source] [smp:1:1] [rq:1] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.7.5 (abort with ^G) 1> demo:start(). =ERROR REPORT==== 9-Apr-2010::23:59:04 === WX Failed loading "wxe_driver"@"/usr/lib/erlang/lib/wx-0.98.5/priv/i686-pc-linux-gnu" {error,{{load_driver,"undefined symbol: gluNewTess"}, [{wxe_server,start,0}, {wx,new,1}, {demo,init,1}, {wx_object,init_it,6}, {proc_lib,init_p_do_apply,3}]}} 2> From kruber@REDACTED Sun Apr 11 19:52:43 2010 From: kruber@REDACTED (Nico Kruber) Date: Sun, 11 Apr 2010 19:52:43 +0200 Subject: [erlang-bugs] missing libGLU dependencies on Wx In-Reply-To: <201004100034.03563.aimsolaky@gmail.com> References: <201004100034.03563.aimsolaky@gmail.com> Message-ID: <201004111952.44129.kruber@zib.de> A solution can be found in an Arch Linux bug report - I will push the changes to the appropriate package in the openSUSE BuildService - this is not the right mailing list to discuss that though... It is of interest however, why the erlang cnofigure scripts did not pickup the libglu dependency (or why they do not do that anymore) Regards, Nico Kruber On Saturday 10 April 2010 00:34:03 Angel wrote: > Using OpenSUSE 11.2 erlang packages: > > Name : erlang Relocations: (not relocatable) > Version : R13B04 Vendor: > obs://build.opensuse.org/devel:languages:erlang Release : 2.1 > Build Date: mar 23 mar 2010 15:34:01 CET Install Date: > vie 09 abr 2010 22:04:36 CEST Build Host: build19 Group : > Development/Languages/Erlang Source RPM: erlang-R13B04-2.1.src.rpm Size > : 52685133 License: Erlang Public License > Signature : DSA/SHA1, mar 23 mar 2010 15:36:51 CET, Key ID > e457ae6fa34552c6 URL : http://www.erlang.org > > > > sinchan@REDACTED:/usr/lib/erlang/lib/wx-0.98.5/examples/demo> erl -smp > enable Erlang R13B04 (erts-5.7.5) [source] [smp:1:1] [rq:1] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.7.5 (abort with ^G) > 1> demo:start(). > > =ERROR REPORT==== 9-Apr-2010::23:59:04 === > WX Failed loading > "wxe_driver"@"/usr/lib/erlang/lib/wx-0.98.5/priv/i686-pc-linux-gnu" > {error,{{load_driver,"undefined symbol: gluNewTess"}, > [{wxe_server,start,0}, > {wx,new,1}, > {demo,init,1}, > {wx_object,init_it,6}, > {proc_lib,init_p_do_apply,3}]}} > 2> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From anders.nygren@REDACTED Wed Apr 14 16:58:36 2010 From: anders.nygren@REDACTED (Anders Nygren) Date: Wed, 14 Apr 2010 09:58:36 -0500 Subject: io:get_line types Message-ID: In io.erl the types specified for get_line/1 is -type prompt() :: atom() | string(). -spec get_line(prompt()) -> iodata() | 'eof' | {'error', term()}. get_line(Prompt) -> get_line(default_input(), Prompt). And that is also what the documentation states. But in ssh/examples/ssh_sample_cli.erl there is Line = io:get_line({format, "CLI> ", []}), Is this a secret unsupported invocation or is it an error in the io documentation? If it is unsupported it should not be used in examples. /Anders From nick@REDACTED Fri Apr 16 14:54:50 2010 From: nick@REDACTED (Niclas Eklund) Date: Fri, 16 Apr 2010 14:54:50 +0200 (CEST) Subject: [erlang-bugs] io:get_line types In-Reply-To: References: Message-ID: Hello! I cannot tell why the io:get_line call didn't follow the documented API, but ssh_sample_cli.erl has now been corrected. Best regards, Niclas @ Erlang/OTP On Wed, 14 Apr 2010, Anders Nygren wrote: > In io.erl the types specified for get_line/1 is > > -type prompt() :: atom() | string(). > -spec get_line(prompt()) -> iodata() | 'eof' | {'error', term()}. > > get_line(Prompt) -> > get_line(default_input(), Prompt). > > And that is also what the documentation states. > > But in ssh/examples/ssh_sample_cli.erl there is > > Line = io:get_line({format, "CLI> ", []}), > > Is this a secret unsupported invocation or is it an error in the > io documentation? > > If it is unsupported it should not be used in examples. > > /Anders > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > From jebu.ittiachen@REDACTED Wed Apr 28 13:01:28 2010 From: jebu.ittiachen@REDACTED (Jebu Ittiachen) Date: Wed, 28 Apr 2010 16:31:28 +0530 Subject: https requests with parameters failing using 13b04 httpc module Message-ID: Hi, After moving to R13B04 oauth requests to fireeagle for the service I run at http://tweetaloc.nowwhat.in has been failing with an error "Invalid OAuth signature" from the server side. The same code has been working fine on R13B03. Digging thru it looks like httpc is sending the host header as host:port for ports other than 80. Here is the debug logs [inets httpc trace 60 <0.170.0> 2010:04:28 09:46:58 4773] send Content: [{module,httpc_request}, {line,109}, {message,["GET"," ", "/api/0.1/user?oauth_signature=HQf3ptyWHf%2BUZB0pbJz6oto%2F1%2B0%3D&oauth_token=XXXXXXXXXXXX&oauth_version=1.0&oauth_nonce=eMTdPddq2ReYDd0d8SKbK633iQcqRIs%2FjEuj9p%2F0%2F2w%3D&oauth_timestamp=1272448018&oauth_signature_method=HMAC-SHA1&oauth_consumer_key=XXXXXXXXXXXX", " ","HTTP/1.1","\r\n", "te: \r\nhost: fireeagle.yahooapis.com:443\r\nconnection: keep-alive\r\n", "\r\n",[]]}] Following patch fixes the issue atleast for this case, but not sure if the spec says the host header should have the port or not --- /tmp/httpc.erl 2010-04-28 16:26:39.000000000 +0530 +++ lib/inets/src/http_client/httpc.erl 2010-04-28 16:27:12.000000000 +0530 @@ -895,6 +895,8 @@ throw({error, {bad_option, Option, BadValue}}). +header_host(Host, 443 = _Port) -> + Host; header_host(Host, 80 = _Port) -> Host; header_host(Host, Port) -> -- Jebu Ittiachen jebu@REDACTED From matthew@REDACTED Wed Apr 28 16:10:14 2010 From: matthew@REDACTED (Matthew Sackman) Date: Wed, 28 Apr 2010 15:10:14 +0100 Subject: Bug in ssl_certificate.erl in R13B04 Message-ID: <20100428141014.GF2762@mrnibble.lshift.net> ssl_certificate.erl: find_issuer(OtpCert, PrevCandidateKey) -> case ssl_certificate_db:issuer_candidate(PrevCandidateKey) of no_more_candidates -> ... {Key, {_Cert, ErlCertCandidate}} -> ... end. The problem is that ssl_certificate_db:issuer_candidate returns no_more_candidates | {Key, [Candidate]}, which is not what its own comments suggest: %% Function: issuer_candidate() -> {Key, Candidate} | no_more_candidates issuer_candidate(no_candidate) -> Db = certificate_db_name(), case ets:first(Db) of '$end_of_table' -> no_more_candidates; Key -> [Cert] = lookup(Key, Db), {Key, Cert} end; So we assume that lookup returns a 1 element list. Fine: lookup(Key, Db) -> case ets:lookup(Db, Key) of [] -> undefined; Contents -> Pick = fun({_, Data}) -> Data; ({_,_,Data}) -> Data end, [Pick(Data) || Data <- Contents] end. Still looking fine, but what happens if the inner Data (in the Pick function) itself is a list? And can this happen? Well yes, it seems it can. If we look at cache_pem_file, we see: cache_pem_file(Pid, File, [CertsDb, _FileToRefDb, PidToFileDb]) -> Res = {ok, Content} = public_key:pem_to_der(File), insert({file, File}, Content, CertsDb), insert(Pid, File, PidToFileDb), Res. The CertsDB here is, I believe the certificate_db_name() mentioned above. The Content pem_to_der returns a list: %% Function: pem_to_der(CertSource) -> %% pem_to_der(CertSource, Password) -> {ok, [Entry]} | %% {error, Reason} And then we do the insert: insert(Key, Data, Db) -> true = ets:insert(Db, {Key, Data}). Which takes the list Data, and puts it in a tuple. Hence we end up with a list as the Data in the db, which then blows up the case in find_issuer right at the top. This didn't happen in R13B03 because cache_pem_file is totally different: cache_pem_file(Pid, File, [_CertsDb, FileToRefDb, PidToFileDb]) -> try ref_count(File, FileToRefDb,1) catch _:_ -> {ok, Content} = public_key:pem_to_der(File), insert(File,Content,1,FileToRefDb) end, insert(Pid, File, PidToFileDb), {ok, FileToRefDb}. For one thing, it never gets added to the CertsDB. Anyway, just to demonstrate this is really causing a problem, this bug has broken SSL support in Rabbit under R13B04: CRASH REPORT==== 4-Apr-2010::15:15:58 === crasher: initial call: ssl_connection:init/1 pid: <0.309.0> registered_name: [] exception exit: {{case_clause, {{file, "/home/matthew/rabbitmq-umbrella/rabbitmq-test/certs/server/cert.pem"}, [{cert, <<48,130,2,237,48,130,1,213,160,3,2,1,2,2,1,2, 48,13,6,9,42,134,72,134,247,13,1,1,5,5,0,48, ....lots more.... 102,134,32,110,107,45,24,26>>, not_encrypted}]}}, [{ssl_certificate,find_issuer,2}, {ssl_certificate,certificate_chain,4}, {ssl_handshake,certificate,3}, {ssl_connection,certify_server,1}, {ssl_connection,server_certify_and_key_exchange,1}, {ssl_connection,do_server_hello,2}, {lists,foldl,3}, {ssl_connection,handle_event,3}]} in function gen_fsm:terminate/7 ancestors: [ssl_connection_sup,ssl_sup,<0.232.0>] messages: [] links: [<0.236.0>] dictionary: [] trap_exit: false status: running heap_size: 2584 stack_size: 24 reductions: 1905 neighbours: It's possible we're doing something wrong, but my reading of the code above does seem to suggest there's a bug in the ssl code. Matthew From mevans@REDACTED Fri Apr 30 00:16:34 2010 From: mevans@REDACTED (Evans, Matthew) Date: Thu, 29 Apr 2010 18:16:34 -0400 Subject: [erlang-questions] pg2...a warning In-Reply-To: References: <4BD93552.5090809@erlang-solutions.com> <9B73EB73-8E1E-4BF2-A973-76D5911A3FF7@erlang.geek.nz> Message-ID: Ok, It does appear that processes will join in a very haphazard way. I created new Erlang node. Did a pg2:start() and then net_adm:ping(SomeNode) to join this new node to the rest of the pool of Erlang nodes. I can see on the new node 140 members of that process (when there are only 2), 72 on another node, and 52 on another. Presumably start order is important here. A few things I've noticed: 1) The pg2:init function will do net_kernel:monitor_nodes(). This means that whenever a node starts {nodeup,Node} will be sent to itself causing the pg2 process to 'exchange' it's list of processes and groups to the new pg2 process on the new node. The new node will then create an entry for those processes. Problem is, as I see things quickly, is that all other nodes in the pool of nodes will do the same thing - causing the counters to be increased (ets:update) many times. 2) The init function also sends {new_pg2,Node} to all nodes in the pool. This causes an additional exchange of member data (same logic as in 1, above). init([]) -> Ns = nodes(), net_kernel:monitor_nodes(true), lists:foreach(fun(N) -> {?MODULE, N} ! {new_pg2, node()}, self() ! {nodeup, N} end, Ns), pg2_table = ets:new(pg2_table, [ordered_set, protected, named_table]), {ok, #state{}}. It then sends a {nodeup,Node} to itself causing it to send its member data to other nodes in the group. Is there a possible race condition here whereby it has some member data from other nodes in the pool, and it will then send that data to all the other nodes? This probably needs looking into. Regards Matt -----Original Message----- From: Evans, Matthew Sent: Thursday, April 29, 2010 5:05 PM To: Evans, Matthew; Geoff Cant Cc: Ulf Wiger; erlang-questions@REDACTED Subject: RE: [erlang-questions] pg2...a warning One additional thing. Different nodes are reporting different values (i.e. quantity) for pg2:get_members(Group). -----Original Message----- From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] On Behalf Of Evans, Matthew Sent: Thursday, April 29, 2010 5:00 PM To: Geoff Cant Cc: Ulf Wiger; erlang-questions@REDACTED Subject: RE: [erlang-questions] pg2...a warning I agree, and was going to reply with almost what you wrote. It seems that this occurs when we reboot a card that is part of an Erlang cluster. There is also the following code: handle_info({nodeup, Node}, S) -> gen_server:cast({?MODULE, Node}, {exchange, node(), all_members()}), {noreply, S}; Correct me if I'm wrong, but in a large cluster, won't 'Node' get this message "number of nodes in cluster (-1)" times? Basically, I'm seeing very strange behavior here. I'll dig a little deeper. I too am tempted to modify pg2 to only allow a process to join once. Matt -----Original Message----- From: Geoff Cant [mailto:nem@REDACTED] Sent: Thursday, April 29, 2010 4:11 PM To: Evans, Matthew Cc: Ulf Wiger; erlang-questions@REDACTED Subject: Re: [erlang-questions] pg2...a warning I've also had some trouble with pg2 recently (the R13B04 version). It seems we have some code that joins groups repeatedly (or some other network condition - nodes parting/joining the cluster?) causes pg2 to think that pids have joined groups lots of times (for 180K values of lots). This causes spectacularly pathological behaviour in a pg2 cluster - you can get to the point where new nodes are no longer able to start pg2 as they run out of ram and abort when exchanging group definitions with other nodes. (pg2 does something like: all_members() -> [[G, group_members(G)] || G <- all_groups()]. group_members(Name) -> [P || [P, N] <- ets:match(pg2_table, {{member, Name, '$1'},'$2'}), _ <- lists:seq(1, N)]. all_groups() -> [N || [N] <- ets:match(pg2_table, {{group,'$1'}})]. when exchanging group membership information. In the pathological case I've run into it means sending [group_name, [ 180000 x Pid1, 180000 x Pid2, ... ] ] at startup. Clearly our code has some bugs as we're joining too often, but this behaviour is just nuts - it'd be cheaper to send our entire ets pg2_table over the wire) I'm pretty sure in our use of pg2 we want the 2nd and subsequent joins to be nops, and it's almost tempting to write 'pg3' just for that. Cheers, -Geoff On 2010-04-29, at 12:23 , Evans, Matthew wrote: > Thanks Ulf, > > Steve told mea bout your gproc work, It looks interesting. > > I actually ran into another pg2 strangeness today on another application. > > This process does a pg2:join in the init function. This is the ONLY place where this occurs. > > I would therefore like to know why pg2:get_members/2 reports two entries for that process? > > Very strange. > > -----Original Message----- > From: Ulf Wiger [mailto:ulf.wiger@REDACTED] > Sent: Thursday, April 29, 2010 3:29 AM > To: Evans, Matthew > Cc: erlang-questions@REDACTED > Subject: Re: [erlang-questions] pg2...a warning > > Evans, Matthew wrote: >> >> The problem is that an asynchronous operation, beyond our control, >> can cause pg2:join/2 to be called many times for the same process. >> The result of which is that pg2:get_closest_pid/1 will not be random >> (e.g. process on node 1 gets 5 "joins", and node 2 gets 3 "joins"). >> Or rather it will not be random in how we consider it to be (i.e. we >> only want a process to join a group a single time). > > This made me curious. > > I will admit to not having used pg2, but the other day I was inspired > to explore how to emulate pg2's behaviour using gproc [1]. > > I noted the part in the documentation stating that you can join > several times, but didn't catch the fact that get_members/1 would > include each pid once for each time it has joined. This seems to imply > that joining several times serves an entirely different purpose than > relieving the programmer of the trouble of keeping track of whether > or not it has joined the group before. > > OTOH, the man page doesn't mention this at all, which makes me believe > that it's a bug rather than a feature. It talks about how you should > use pg2:get_members/1 when you want to send a message to all members > of a group. This would be a good place to highlight the fact that > you need to remove duplicates from the list if you want the message > to be sent only once to each member. > > BR, > Ulf W > > [1] Making a pg2-like module on top of gproc is actually quite easy, > but requires the distributed gproc to work, which has not been the > case until now. I am in the process of verifying it, and will > hopefully be able to push a new version very soon. A solid, documented version of gproc would be a most welcome addition to OTP in my opinion. ________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED From PaulH@REDACTED Fri Apr 30 08:13:05 2010 From: PaulH@REDACTED (Paul Hampson) Date: Fri, 30 Apr 2010 16:13:05 +1000 Subject: sys:get_status kills gen_servers registered globally with something other than an atom Message-ID: <4BDA74F1.3050509@microforte.com> Using Erlang R13B04, I'm creating gen_servers with gen_server:start( { global, "Name" } ). This is valid according to the gen_server manpage, which states GlobalName is term(). However, if I call sys:get_status({global, "Name"}) (or sys_get:status( global:whereis_name( "Name" ) ) to rule out the name lookup as an issue) the gen_server dies, with: exception error: no true branch found when evaluating an if expression in function gen_server:format_status/2 in call from sys:get_status/5 in call from sys:do_cmd/6 in call from sys:handle_system_msg/8 This is because of the following code in gen_server:format_status: NameTag = if is_pid(Name) -> pid_to_list(Name); is_atom(Name) -> Name end, Header = lists:concat(["Status for generic server ", NameTag]), Which fails to handle that Name (which is stripped of {global,} in gen_server:name/1 or gen_server:get_proc_name/1) may be something other than an atom or pid. Interestingly, the comment above gen_server:start/3 indicates that the supplied server name is { global, atom() }, not { global, term() } as per the documentation. So either the documentation is wrong, or the gen_server implementation/comment is wrong. Bizarrely, I'm sure I was able to use sys:get_status against these same gen_servers a month ago, which would have been R13B03 or maybe an B13B03, but erlang/otp on github doesn't indicate any relevant changes. -- Paul "TBBle" Hampson Project: Find out what makes things tick Plan: Stop the ticking... From mevans@REDACTED Fri Apr 30 16:27:30 2010 From: mevans@REDACTED (Evans, Matthew) Date: Fri, 30 Apr 2010 10:27:30 -0400 Subject: FW: pg2...a warning Message-ID: Hi, I posted this on Erlang questions. I wonder if there are any planned fixes to pg2? Regards Matt -----Original Message----- From: Evans, Matthew Sent: Thursday, April 29, 2010 6:17 PM To: Evans, Matthew; Geoff Cant; erlang-bugs@REDACTED Cc: Ulf Wiger; erlang-questions@REDACTED Subject: RE: [erlang-questions] pg2...a warning Ok, It does appear that processes will join in a very haphazard way. I created new Erlang node. Did a pg2:start() and then net_adm:ping(SomeNode) to join this new node to the rest of the pool of Erlang nodes. I can see on the new node 140 members of that process (when there are only 2), 72 on another node, and 52 on another. Presumably start order is important here. A few things I've noticed: 1) The pg2:init function will do net_kernel:monitor_nodes(). This means that whenever a node starts {nodeup,Node} will be sent to itself causing the pg2 process to 'exchange' it's list of processes and groups to the new pg2 process on the new node. The new node will then create an entry for those processes. Problem is, as I see things quickly, is that all other nodes in the pool of nodes will do the same thing - causing the counters to be increased (ets:update) many times. 2) The init function also sends {new_pg2,Node} to all nodes in the pool. This causes an additional exchange of member data (same logic as in 1, above). init([]) -> Ns = nodes(), net_kernel:monitor_nodes(true), lists:foreach(fun(N) -> {?MODULE, N} ! {new_pg2, node()}, self() ! {nodeup, N} end, Ns), pg2_table = ets:new(pg2_table, [ordered_set, protected, named_table]), {ok, #state{}}. It then sends a {nodeup,Node} to itself causing it to send its member data to other nodes in the group. Is there a possible race condition here whereby it has some member data from other nodes in the pool, and it will then send that data to all the other nodes? This probably needs looking into. Regards Matt -----Original Message----- From: Evans, Matthew Sent: Thursday, April 29, 2010 5:05 PM To: Evans, Matthew; Geoff Cant Cc: Ulf Wiger; erlang-questions@REDACTED Subject: RE: [erlang-questions] pg2...a warning One additional thing. Different nodes are reporting different values (i.e. quantity) for pg2:get_members(Group). -----Original Message----- From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] On Behalf Of Evans, Matthew Sent: Thursday, April 29, 2010 5:00 PM To: Geoff Cant Cc: Ulf Wiger; erlang-questions@REDACTED Subject: RE: [erlang-questions] pg2...a warning I agree, and was going to reply with almost what you wrote. It seems that this occurs when we reboot a card that is part of an Erlang cluster. There is also the following code: handle_info({nodeup, Node}, S) -> gen_server:cast({?MODULE, Node}, {exchange, node(), all_members()}), {noreply, S}; Correct me if I'm wrong, but in a large cluster, won't 'Node' get this message "number of nodes in cluster (-1)" times? Basically, I'm seeing very strange behavior here. I'll dig a little deeper. I too am tempted to modify pg2 to only allow a process to join once. Matt -----Original Message----- From: Geoff Cant [mailto:nem@REDACTED] Sent: Thursday, April 29, 2010 4:11 PM To: Evans, Matthew Cc: Ulf Wiger; erlang-questions@REDACTED Subject: Re: [erlang-questions] pg2...a warning I've also had some trouble with pg2 recently (the R13B04 version). It seems we have some code that joins groups repeatedly (or some other network condition - nodes parting/joining the cluster?) causes pg2 to think that pids have joined groups lots of times (for 180K values of lots). This causes spectacularly pathological behaviour in a pg2 cluster - you can get to the point where new nodes are no longer able to start pg2 as they run out of ram and abort when exchanging group definitions with other nodes. (pg2 does something like: all_members() -> [[G, group_members(G)] || G <- all_groups()]. group_members(Name) -> [P || [P, N] <- ets:match(pg2_table, {{member, Name, '$1'},'$2'}), _ <- lists:seq(1, N)]. all_groups() -> [N || [N] <- ets:match(pg2_table, {{group,'$1'}})]. when exchanging group membership information. In the pathological case I've run into it means sending [group_name, [ 180000 x Pid1, 180000 x Pid2, ... ] ] at startup. Clearly our code has some bugs as we're joining too often, but this behaviour is just nuts - it'd be cheaper to send our entire ets pg2_table over the wire) I'm pretty sure in our use of pg2 we want the 2nd and subsequent joins to be nops, and it's almost tempting to write 'pg3' just for that. Cheers, -Geoff On 2010-04-29, at 12:23 , Evans, Matthew wrote: > Thanks Ulf, > > Steve told mea bout your gproc work, It looks interesting. > > I actually ran into another pg2 strangeness today on another application. > > This process does a pg2:join in the init function. This is the ONLY place where this occurs. > > I would therefore like to know why pg2:get_members/2 reports two entries for that process? > > Very strange. > > -----Original Message----- > From: Ulf Wiger [mailto:ulf.wiger@REDACTED] > Sent: Thursday, April 29, 2010 3:29 AM > To: Evans, Matthew > Cc: erlang-questions@REDACTED > Subject: Re: [erlang-questions] pg2...a warning > > Evans, Matthew wrote: >> >> The problem is that an asynchronous operation, beyond our control, >> can cause pg2:join/2 to be called many times for the same process. >> The result of which is that pg2:get_closest_pid/1 will not be random >> (e.g. process on node 1 gets 5 "joins", and node 2 gets 3 "joins"). >> Or rather it will not be random in how we consider it to be (i.e. we >> only want a process to join a group a single time). > > This made me curious. > > I will admit to not having used pg2, but the other day I was inspired > to explore how to emulate pg2's behaviour using gproc [1]. > > I noted the part in the documentation stating that you can join > several times, but didn't catch the fact that get_members/1 would > include each pid once for each time it has joined. This seems to imply > that joining several times serves an entirely different purpose than > relieving the programmer of the trouble of keeping track of whether > or not it has joined the group before. > > OTOH, the man page doesn't mention this at all, which makes me believe > that it's a bug rather than a feature. It talks about how you should > use pg2:get_members/1 when you want to send a message to all members > of a group. This would be a good place to highlight the fact that > you need to remove duplicates from the list if you want the message > to be sent only once to each member. > > BR, > Ulf W > > [1] Making a pg2-like module on top of gproc is actually quite easy, > but requires the distributed gproc to work, which has not been the > case until now. I am in the process of verifying it, and will > hopefully be able to push a new version very soon. A solid, documented version of gproc would be a most welcome addition to OTP in my opinion. ________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED